From nobody Mon Apr 4 05:27:29 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62B812D1E6 for ; Mon, 4 Apr 2016 05:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1-OcBgXpln0 for ; Mon, 4 Apr 2016 05:27:22 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::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 671AF12D13E for ; Mon, 4 Apr 2016 05:27:22 -0700 (PDT) Received: by mail-qg0-x229.google.com with SMTP id c6so18288325qga.1 for ; Mon, 04 Apr 2016 05:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to; bh=4L/ZRRCX95QM1/RoY4dZxSLoOmkeR7B7tufCqTdhbeE=; b=twJwOSbIfu2SzGooEjs4dXwfm3Q5OUlRVgzdlBtX0ONpMYf349hPmjs3znB4Q4//NO kOjsqdmIK/DpVT/KBz1HKU9y0QkCgnqHTm/uGM3iCgbRHqzqqs30l//xPkUq6kH/Cqof zGoLYgGDb2GmPHFzqWFp7SCBeWQ2MFoaEL+zJOnwrPf6wEadXXv6yc/ez5q62ScLhWUC 0ur1ngL3YSW7B2CQK0NqrtadcRMgitu4s5oi6sJ+ODTivXUYUyH3fYwzNMDEae9ijEL/ EJ4AoG2CO/TROAoF5Gwo4TN66SdFCwOvdTs015xP9CMx2T5GrqUTiHr5bPltsVjuX0SO AEyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to; bh=4L/ZRRCX95QM1/RoY4dZxSLoOmkeR7B7tufCqTdhbeE=; b=hy7urmG3ErrOlSOrstkhhMcQc6X3a/tQLNEk3avTU3jUaUJOOw3wQ5NceOB4pkOFbu EgvcOrlVed/0SS5xkyrGIpL1qC+Dax+JPWBIcjgpZqtMFA5/8CyMSD9/QDpuZ9jDXUSg cqt6qHso2ZNzo2JOy4/QYiI78guVtaI7Q3BC+dBNKmFOKjsqR97mx7guYl8jvula5Qky oLz/krDcLhZnI9tik6Wxbcjynal1dSau4amH6r52MxLtXHoj6oR6ttGkysNnKIpBOLUG 5chTbwazFVlWJWuGc3/EEJFRWdPfnXAGTzpODtPgJ+fGasO9keUcbukz7aXEFRAcAoq5 JPOw== X-Gm-Message-State: AD7BkJK310315Vz4CSXJCBuCVhP2mo+PR/L/9ctD+lm7xADMGZ+B+ad+0ygpZICxM++FMyWmdrCW2m1TZJ9sPw== MIME-Version: 1.0 X-Received: by 10.194.80.38 with SMTP id o6mr18759066wjx.57.1459772841410; Mon, 04 Apr 2016 05:27:21 -0700 (PDT) Sender: ilcon7e@gmail.com Received: by 10.28.14.73 with HTTP; Mon, 4 Apr 2016 05:27:21 -0700 (PDT) Date: Mon, 4 Apr 2016 14:27:21 +0200 X-Google-Sender-Auth: DxCJG4l7dSBmycIutxcfBW3w1H0 Message-ID: From: Vlad Olariu To: ospf@ietf.org Content-Type: multipart/alternative; boundary=047d7bb04db0aa5846052fa7d9ff Archived-At: Subject: [OSPF] Increasing the maximum number of links advertisable in a single Router LSA X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 12:27:29 -0000 --047d7bb04db0aa5846052fa7d9ff Content-Type: text/plain; charset=UTF-8 Hello All, Considering what the OSPFv2 RFC states: A.4.2 All of the router's links to the area must be described in a single > router-LSA. The maximum number of links advertisable in a single Router-LSA for a single LSA is around 5K. Following this, I have two questions: > How come the* # links* has 2 bytes, allowing for up to 65536 links? > Is there any way to bypass the 5K limit? Thank you. P.S This is of course just an exercise. I don't expect any sane network design to require that many links in the same area. --047d7bb04db0aa5846052fa7d9ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All,

Considering what the OSPFv2 = RFC states:

A.4.2 All of the router= 9;s links to the area must be described in a single router-LSA.

The maximum number of links advertisable in a single R= outer-LSA for a single LSA is around 5K.

Following= this, I have two questions:
> How come the # links=C2= =A0has 2 bytes, allowing for up to=C2=A065536 links?
> Is ther= e any way to bypass the 5K limit?

Thank you.
=

P.S This is of course just an exercise. I don't exp= ect any sane network design to require that many links in the same area.
--047d7bb04db0aa5846052fa7d9ff-- From nobody Mon Apr 4 06:56:07 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CE812D6EA for ; Mon, 4 Apr 2016 06:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HGVsOWRAECB for ; Mon, 4 Apr 2016 06:56:01 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CFCD12D6D9 for ; Mon, 4 Apr 2016 06:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6287; q=dns/txt; s=iport; t=1459778154; x=1460987754; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=fIlwZoMpPU1DZPli+9o0dAj76/0TrjdiP4k4NLDBPOg=; b=Suf5Ap9AbqSX9xSIoknc/6l/zfLUHQbPUB2BQNBkQNn4pPPKfAk1cKPh cPg8N0rmV4z2DeivqDefSg8VfhjXMzVM7x40X43KYN4h10xM66Zj7QSbi asiTp/+Sbp2ktuQU7Kj3icnkMNI7hNrnWNLr4isL+eLYnjaj0dUf8O4CY 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdBQAZcQJX/5NdJa1dgmtMgVAGr0yGZ?= =?us-ascii?q?YJhgh2BcoYNAhyBFzkTAQEBAQEBAWUnhEEBAQEDASNbCwIBCAQKAwMBAigDAgI?= =?us-ascii?q?CHxEUCQgCBAESiBIDCgirWowUDYUXAQEBAQEBAQECAQEBAQEBAQEYimqCQYFZR?= =?us-ascii?q?RaCSoJWBZMYhDgxAYwSgXWPD4dEh1UBIgI+ggEcFYE1bIZqPn4BAQE?= X-IronPort-AV: E=Sophos; i="5.24,440,1454976000"; d="scan'208,217"; a="93561449" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2016 13:55:53 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u34DtrkF005606 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2016 13:55:53 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 4 Apr 2016 09:55:52 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Mon, 4 Apr 2016 09:55:52 -0400 From: "Acee Lindem (acee)" To: Vlad Olariu , "ospf@ietf.org" Thread-Topic: [OSPF] Increasing the maximum number of links advertisable in a single Router LSA Thread-Index: AQHRjm1gIA22qvdkcEuFpxYylzWJ1Z95506A Date: Mon, 4 Apr 2016 13:55:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.33.108] Content-Type: multipart/alternative; boundary="_000_D327F78D56C71aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OSPF] Increasing the maximum number of links advertisable in a single Router LSA X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 13:56:03 -0000 --_000_D327F78D56C71aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVmxhZCwNCg0KRnJvbTogT1NQRiA8b3NwZi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvc3Bm LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgVmxhZCBPbGFyaXUgPGZsb3JpbnZsYWQu b2xhcml1QGdtYWlsLmNvbTxtYWlsdG86ZmxvcmludmxhZC5vbGFyaXVAZ21haWwuY29tPj4NCkRh dGU6IE1vbmRheSwgQXByaWwgNCwgMjAxNiBhdCA4OjI3IEFNDQpUbzogT1NQRiBXRyBMaXN0IDxv c3BmQGlldGYub3JnPG1haWx0bzpvc3BmQGlldGYub3JnPj4NClN1YmplY3Q6IFtPU1BGXSBJbmNy ZWFzaW5nIHRoZSBtYXhpbXVtIG51bWJlciBvZiBsaW5rcyBhZHZlcnRpc2FibGUgaW4gYSBzaW5n bGUgUm91dGVyIExTQQ0KDQpIZWxsbyBBbGwsDQoNCkNvbnNpZGVyaW5nIHdoYXQgdGhlIE9TUEZ2 MiBSRkMgc3RhdGVzOg0KDQpBLjQuMiBBbGwgb2YgdGhlIHJvdXRlcidzIGxpbmtzIHRvIHRoZSBh cmVhIG11c3QgYmUgZGVzY3JpYmVkIGluIGEgc2luZ2xlIHJvdXRlci1MU0EuDQoNClRoZSBtYXhp bXVtIG51bWJlciBvZiBsaW5rcyBhZHZlcnRpc2FibGUgaW4gYSBzaW5nbGUgUm91dGVyLUxTQSBm b3IgYSBzaW5nbGUgTFNBIGlzIGFyb3VuZCA1Sy4NCg0KRm9sbG93aW5nIHRoaXMsIEkgaGF2ZSB0 d28gcXVlc3Rpb25zOg0KPiBIb3cgY29tZSB0aGUgIyBsaW5rcyBoYXMgMiBieXRlcywgYWxsb3dp bmcgZm9yIHVwIHRvIDY1NTM2IGxpbmtzPw0KPiBJcyB0aGVyZSBhbnkgd2F5IHRvIGJ5cGFzcyB0 aGUgNUsgbGltaXQ/DQoNCk5vIC0gdGhpcyB3YXMgZml4ZWQgaW4gT1NQRnYzIGJ5IHN1cHBvcnRp bmcgYSB2YXJpYWJsZSBudW1iZXIgb2YgUm91dGVyLUxTQXMgd2hpY2ggYXJlIGNvbmNhdGVuYXRl ZC4gVGhpcyBpcyB5ZXQgYW5vdGhlciBhZHZhbnRhZ2Ugb2YgT1NQRnYzIG92ZXIgT1NQRnYyLg0K DQpUaGlzIGhhcyBub3QgYmVlbiBhIHByb2JsZW0gaGVyZXRvZm9yZSBhbmQgSSBrbm93IG9mIHNl dmVyYWwgaW1wbGVtZW50YXRpb25zIHRoYXQgaGF2ZSBsb3dlciBSb3V0ZXItTFNBIGxpbmsgbGlt aXRzIGR1ZSB0byBub3Qgc3VwcG9ydGluZyBJUCBmcmFnL3JlYXNzZW1ibHkgdXAgdG8gNjRLLg0K DQpUaGFua3MsDQpBY2VlDQoNCg0KDQoNClRoYW5rIHlvdS4NCg0KUC5TIFRoaXMgaXMgb2YgY291 cnNlIGp1c3QgYW4gZXhlcmNpc2UuIEkgZG9uJ3QgZXhwZWN0IGFueSBzYW5lIG5ldHdvcmsgZGVz aWduIHRvIHJlcXVpcmUgdGhhdCBtYW55IGxpbmtzIGluIHRoZSBzYW1lIGFyZWEuDQo= --_000_D327F78D56C71aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBWbGFkLCZu YnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsg dGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7 IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1M RUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29s aWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5PU1BGICZsdDs8YSBocmVmPSJt YWlsdG86b3NwZi1ib3VuY2VzQGlldGYub3JnIj5vc3BmLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0 OyBvbiBiZWhhbGYgb2YgVmxhZCBPbGFyaXUgJmx0OzxhIGhyZWY9Im1haWx0bzpmbG9yaW52bGFk Lm9sYXJpdUBnbWFpbC5jb20iPmZsb3JpbnZsYWQub2xhcml1QGdtYWlsLmNvbTwvYT4mZ3Q7PGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5Nb25kYXksIEFw cmlsIDQsIDIwMTYgYXQgODoyNyBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5UbzogPC9zcGFuPk9TUEYgV0cgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9zcGZAaWV0Zi5v cmciPm9zcGZAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5TdWJqZWN0OiA8L3NwYW4+W09TUEZdIEluY3JlYXNpbmcgdGhlIG1heGltdW0gbnVtYmVy IG9mIGxpbmtzIGFkdmVydGlzYWJsZSBpbiBhIHNpbmdsZSBSb3V0ZXIgTFNBPGJyPg0KPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVU SU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURE SU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJs dHIiPkhlbGxvIEFsbCwNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNvbnNpZGVyaW5nIHdoYXQg dGhlIE9TUEZ2MiBSRkMgc3RhdGVzOjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDti b3JkZXItbGVmdC13aWR0aDoxcHg7Ym9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTti b3JkZXItbGVmdC1zdHlsZTpzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCkEuNC4yIEFsbCBvZiB0 aGUgcm91dGVyJ3MgbGlua3MgdG8gdGhlIGFyZWEgbXVzdCBiZSBkZXNjcmliZWQgaW4gYSBzaW5n bGUgcm91dGVyLUxTQS48L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUg bWF4aW11bSBudW1iZXIgb2YgbGlua3MgYWR2ZXJ0aXNhYmxlIGluIGEgc2luZ2xlIFJvdXRlci1M U0EgZm9yIGEgc2luZ2xlIExTQSBpcyBhcm91bmQgNUsuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5Gb2xsb3dpbmcgdGhpcywgSSBoYXZlIHR3byBxdWVzdGlvbnM6PC9kaXY+DQo8ZGl2 PiZndDsgSG93IGNvbWUgdGhlPGI+ICMgbGlua3M8L2I+Jm5ic3A7aGFzIDIgYnl0ZXMsIGFsbG93 aW5nIGZvciB1cCB0byZuYnNwOzY1NTM2IGxpbmtzPzwvZGl2Pg0KPGRpdj4mZ3Q7IElzIHRoZXJl IGFueSB3YXkgdG8gYnlwYXNzIHRoZSA1SyBsaW1pdD88L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk5v IC0gdGhpcyB3YXMgZml4ZWQgaW4gT1NQRnYzIGJ5IHN1cHBvcnRpbmcgYSB2YXJpYWJsZSBudW1i ZXIgb2YgUm91dGVyLUxTQXMgd2hpY2ggYXJlIGNvbmNhdGVuYXRlZC4gVGhpcyBpcyB5ZXQgYW5v dGhlciBhZHZhbnRhZ2Ugb2YgT1NQRnYzIG92ZXIgT1NQRnYyLiZuYnNwOzwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBoYXMgbm90IGJlZW4gYSBwcm9ibGVtIGhlcmV0b2ZvcmUg YW5kIEkga25vdyBvZiBzZXZlcmFsIGltcGxlbWVudGF0aW9ucyB0aGF0IGhhdmUgbG93ZXIgUm91 dGVyLUxTQSBsaW5rIGxpbWl0cyBkdWUgdG8gbm90IHN1cHBvcnRpbmcgSVAgZnJhZy9yZWFzc2Vt Ymx5IHVwIHRvIDY0Sy4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5r cyw8L2Rpdj4NCjxkaXY+QWNlZTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9O Ij4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBz dHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJH SU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PlRoYW5rIHlvdS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlAu UyBUaGlzIGlzIG9mIGNvdXJzZSBqdXN0IGFuIGV4ZXJjaXNlLiBJIGRvbid0IGV4cGVjdCBhbnkg c2FuZSBuZXR3b3JrIGRlc2lnbiB0byByZXF1aXJlIHRoYXQgbWFueSBsaW5rcyBpbiB0aGUgc2Ft ZSBhcmVhLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9z cGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D327F78D56C71aceeciscocom_-- From nobody Thu Apr 7 13:09:22 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F9A12D599 for ; Thu, 7 Apr 2016 13:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 0yY6S6I6reR1 for ; Thu, 7 Apr 2016 13:09:16 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0132.outbound.protection.outlook.com [207.46.100.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD6812D609 for ; Thu, 7 Apr 2016 13:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=R920221c+hLMY52Jm9a3GCxhikWuP2NWHLe7PGLl1N0=; b=PsjzexM6rAqxtctMb+W9ktNjj40Bk20n+QaXML5AcQT5noQ5K6Az3cwFE/43EuqlSlcg30YZSHvOHlm709FO+srs3qU0bMh2TV/W8zE8TvGWLePgTu2ZFRB3rybDuevHvttARCyA/s4gxfsD2qswemtyAn38IHt3ZwIgNn300T0= Received: from BY2PR03MB125.namprd03.prod.outlook.com (10.242.36.14) by BY2PR03MB126.namprd03.prod.outlook.com (10.242.36.21) with Microsoft SMTP Server (TLS) id 15.1.447.15; Thu, 7 Apr 2016 20:09:12 +0000 Received: from BY2PR03MB125.namprd03.prod.outlook.com ([169.254.4.59]) by BY2PR03MB125.namprd03.prod.outlook.com ([169.254.4.59]) with mapi id 15.01.0447.027; Thu, 7 Apr 2016 20:09:12 +0000 From: "Paul Mattes (AZURE)" To: "ospf@ietf.org" Thread-Topic: Re: draft-ppsenak-ospf-te-link-attr-reuse-01 Thread-Index: AdGRBkuoT17MPXP6QIK/Jzco/SY5/Q== Date: Thu, 7 Apr 2016 20:09:12 +0000 Message-ID: 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=microsoft.com; x-originating-ip: [2001:67c:370:176:ecc1:f30f:2ca6:6842] x-ms-office365-filtering-correlation-id: 6a853516-c741-4b3e-369c-08d35f207cc8 x-microsoft-exchange-diagnostics: 1; BY2PR03MB126; 5:4zUwp2ylVhow0HTOM4qp/OliN0VqRmrNXg84mJ1/ImMIclneQeQcJ1rXpwhrLJL2athw+jlOJkjWbF9B5gblDSshThHe8cBwzZ0JRqrZlqRDIjZcnSVza0fYgrIDUnJ0VIrogDbOi1Uo9KX22GXt9A==; 24:4K7ooWAaRF2sD3f0+4LKiYry0z12rBFX0LdogbT6mTV2zPjIjxbLll2o+CfoEDKA/tSE4Dpk3cq6u/3ea526Dh2nTr74L6Ef/g6MfQCYo4c= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB126; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BY2PR03MB126; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB126; x-forefront-prvs: 0905A6B2C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(37854004)(11100500001)(76576001)(110136002)(2351001)(5004730100002)(19580395003)(92566002)(2501003)(5640700001)(5630700001)(86362001)(81166005)(230783001)(8990500004)(5002640100001)(10090500001)(74316001)(450100001)(107886002)(586003)(2906002)(16236675004)(10400500002)(19300405004)(5003600100002)(122556002)(2900100001)(19625215002)(10290500002)(97736004)(15975445007)(86612001)(3660700001)(5005710100001)(33656002)(3280700002)(790700001)(189998001)(1096002)(54356999)(87936001)(102836003)(6116002)(1730700002)(99286002)(50986999)(1220700001)(5008740100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB126; H:BY2PR03MB125.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB125654A47392F2CA88229CACA900BY2PR03MB125namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2016 20:09:12.4744 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB126 Archived-At: Subject: Re: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:09:20 -0000 --_000_BY2PR03MB125654A47392F2CA88229CACA900BY2PR03MB125namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to amplify some of the comments made about this draft at today= 's OSPF WG meeting. The draft refers generically to TE when it really means RSVP TE. The draft = should use the more-specific term "RSVP TE" or "RSVP-based TE" in most (but= not all) of the places where "TE" is used. The most unhelpful place this o= ccurs in section 1: Many of these link attributes are useful outside of the traditional MLP= LS (sic) Traffic Engineering or GMPLS. This should read: Many of these link attributes are useful outside of the traditional RSV= P-based Traffic Engineering, or GMPLS. Perhaps it would be helpful if SR-based Traffic Engineering were mentioned = as a typical consumer of this new information, which would distinguish it f= rom RSVP-TE as the primary consumer of the existing TLVs. In Section 3.1, I also have issue with this statement: Additionally, link attributes are only advertised once when both OSPF T= E and other applications are deployed on the same link. This is not expect= ed to be a common deployment scenario. I don't think that this is a desired result, and I believe this is what Chr= is Bowers was trying to emphasize with his earlier comments. If a router cu= rrently advertises the existing TE TLVs, it should continue to advertise th= em after it implements this draft. Turning off advertisement of the existin= g TE TLVs (if somehow they were being advertised without enabling RSVP-TE o= n the link) should not be the default behavior, though perhaps it could be = made an option. I know this default would be less efficient, but I don't th= ink it is worth breaking backwards compatibility to have. pdm --_000_BY2PR03MB125654A47392F2CA88229CACA900BY2PR03MB125namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would like to amplify some of the comments made ab= out this draft at today’s OSPF WG meeting.

 

The draft refers generically to TE when it really me= ans RSVP TE. The draft should use the more-specific term “RSVP TER= 21; or “RSVP-based TE” in most (but not all) of the places wher= e “TE” is used. The most unhelpful place this occurs in section 1:

    Many of these link attributes are= useful outside of the traditional MLPLS (sic) Traffic Engineering or GMPLS= .

This should read:

    Many of these link attributes are= useful outside of the traditional RSVP-based Traffic Engineering, or GMPLS= .

 

Perhaps it would be helpful if SR-based Traffic Engi= neering were mentioned as a typical consumer of this new information, which= would distinguish it from RSVP-TE as the primary consumer of the existing = TLVs.

 

In Section 3.1, I also have issue with this statemen= t:

    Additionally, link attributes are= only advertised once when both OSPF TE and other applications are deployed= on the same link.  This is not expected to be a common deployment sce= nario.

I don’t think that this is a desired result, a= nd I believe this is what Chris Bowers was trying to emphasize with his ear= lier comments. If a router currently advertises the existing TE TLVs, it sh= ould continue to advertise them after it implements this draft. Turning off advertisement of the existing TE TLVs (= if somehow they were being advertised without enabling RSVP-TE on the link)= should not be the default behavior, though perhaps it could be made an opt= ion. I know this default would be less efficient, but I don’t think it is worth breaking backwards com= patibility to have.

 

       pdm

 

--_000_BY2PR03MB125654A47392F2CA88229CACA900BY2PR03MB125namprd_-- From nobody Thu Apr 7 13:10:15 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC6912D602 for ; Thu, 7 Apr 2016 13:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 8JqB3RwkD98s for ; Thu, 7 Apr 2016 13:10:12 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0736.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD55C12D5ED for ; Thu, 7 Apr 2016 13:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YiOwfKLckuIBqkub2Ik7F0f5vmEXdUwhFkGDr4VRGcI=; b=abcnBUHYFgQAdSfLYcUEGRCsY0pU9s9WY4TyMEg8b09wGYngsc3t4Sw3OhVNqfFVOkZYn3Nknx1cpCLq7+7F41Tk65Ga4kj0a2TqFj8HWwdc/o/mTyCiBnvWEuCJ1kHuWX0hESozPESH5UZfuhvofD7BrxFOfH8wQzMqIn7nM7M= Received: from BY2PR03MB125.namprd03.prod.outlook.com (10.242.36.14) by BY2PR03MB126.namprd03.prod.outlook.com (10.242.36.21) with Microsoft SMTP Server (TLS) id 15.1.447.15; Thu, 7 Apr 2016 20:09:49 +0000 Received: from BY2PR03MB125.namprd03.prod.outlook.com ([169.254.4.59]) by BY2PR03MB125.namprd03.prod.outlook.com ([169.254.4.59]) with mapi id 15.01.0447.027; Thu, 7 Apr 2016 20:09:49 +0000 From: "Paul Mattes (AZURE)" To: "ospf@ietf.org" Thread-Topic: draft-ppsenak-ospf-te-link-attr-reuse-01 for IS-IS? Thread-Index: AdGRCWFwQxA5nUINRAeIjM4TdDDRaA== Date: Thu, 7 Apr 2016 20:09:48 +0000 Message-ID: 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=microsoft.com; x-originating-ip: [2001:67c:370:176:ecc1:f30f:2ca6:6842] x-ms-office365-filtering-correlation-id: 14ad5534-c90c-409d-6c3c-08d35f209291 x-microsoft-exchange-diagnostics: 1; BY2PR03MB126; 5:ZlxXBK9mlCFjfqYhpnPXsZB9HQzATPCABkChzOy0jnOVexS/8csRWl/R0GpyYKc9hkiTPfQe4HYASHfdsUVW+X3cgvV8WDu/IIwD7qmzGZjm45LvK9dM+9jIiSd0lvT+qb5eJkh2tcXAJJGHMs8z/A==; 24:BjEoXHPsGJ/dg3hAFjn9iIFK6Pl5Ku/0fxZZZyaYuX8VwPSNi8bKnYb6K7DL1WAR37vTUJhrpsMrkFpj12uFGDO+YgfgobQeRMFYVl16nGY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB126; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BY2PR03MB126; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB126; x-forefront-prvs: 0905A6B2C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(558084003)(97736004)(10290500002)(86612001)(15975445007)(2900100001)(19625215002)(5005710100001)(122556002)(3660700001)(2906002)(5003600100002)(19300405004)(10400500002)(16236675004)(87936001)(189998001)(1096002)(54356999)(102836003)(50986999)(1220700001)(5008740100001)(6116002)(1730700002)(99286002)(33656002)(3280700002)(790700001)(2501003)(5640700001)(86362001)(5630700001)(76576001)(110136002)(11100500001)(19580395003)(92566002)(2351001)(5004730100002)(229853001)(10090500001)(74316001)(8990500004)(5002640100001)(107886002)(586003)(450100001)(230783001)(81166005)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB126; H:BY2PR03MB125.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB1254C52C7ED629542D66D6ACA900BY2PR03MB125namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2016 20:09:48.8380 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB126 Archived-At: Subject: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse-01 for IS-IS? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:10:14 -0000 --_000_BY2PR03MB1254C52C7ED629542D66D6ACA900BY2PR03MB125namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is there an IS-IS equivalent of draft-ppsenak-ospf-te-link-attr-reuse-01? pdm --_000_BY2PR03MB1254C52C7ED629542D66D6ACA900BY2PR03MB125namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is there an IS-IS equivalent of draft-ppsenak-ospf-t= e-link-attr-reuse-01?

 

       pdm

 

--_000_BY2PR03MB1254C52C7ED629542D66D6ACA900BY2PR03MB125namprd_-- From nobody Thu Apr 7 20:03:13 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B942112D775 for ; Thu, 7 Apr 2016 20:03:11 -0700 (PDT) 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, 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 hOaBY22en_lw for ; Thu, 7 Apr 2016 20:03:09 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9712012D151 for ; Thu, 7 Apr 2016 20:03:09 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-ca-570719253a5b Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id EC.2C.30335.52917075; Fri, 8 Apr 2016 04:36:21 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0248.002; Thu, 7 Apr 2016 23:03:08 -0400 From: Uma Chunduri To: "Les Ginsberg (ginsberg)" , "Acee Lindem (acee)" , OSPF WG List Thread-Topic: WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment" Thread-Index: AQHRf/Ho6WRxQA5zQE2bUJRokiTbP59dC0kggCJ0YZA= Date: Fri, 8 Apr 2016 03:03:07 +0000 Message-ID: <1B502206DFA0C544B7A6046915200863580014D7@eusaamb106.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyuXSPn66qJHu4wdoZ+haT385jttjwZyO7 Rcu9e+wOzB5Tfm9k9Viy5CdTAFMUl01Kak5mWWqRvl0CV8a8k19ZC7YpV8xb+Ji9gfGAUhcj J4eEgInEphObmSFsMYkL99azdTFycQgJHGWU6FzzlBHCWcYo8X/KFRaQKjYBPYmPU3+ydzFy cIgIVEp8/S4FEhYWiJN4eWwJG4gtIhAvMW15HyOEbSXx4ekxMJtFQEVi/Y+j7CA2r4CvxJ3+ Q2BjhATSJE4esQYJcwq4SkyY8ogVxGYEuuf7qTVMIDazgLjErSfzmSDuFJBYsuc81M2iEi8f /2OFsJUk5ry+xgwykllAU2L9Ln2IVkWJKd0PobYKSpyc+YRlAqPoLCRTZyF0zELSMQtJxwJG llWMHKXFBTm56UYGmxiBEXFMgk13B+P96Z6HGAU4GJV4eBcIsIcLsSaWFVfmHmKU4GBWEuHN lQEK8aYkVlalFuXHF5XmpBYfYpTmYFES520M/hcmJJCeWJKanZpakFoEk2Xi4JRqYGT7xfz2 0jW9nLfq3iu0jRNCLZnUHr93yxHfbLku6NMVFoFDjy0rli8vkGEVOJf3SHPr/Iv156WKA77s N4/zPxa1Lb/QREDNq146Kf7v15eRsQ9Y2kXW6JYYLK1fUJdiHZr3hX1ySIejkgb3+7x93QzX 4p6xGEq0vt7dVxPNfC1Gbn+l2uEPSizFGYmGWsxFxYkAyZW3MYQCAAA= Archived-At: Subject: Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 03:03:11 -0000 TGVzLA0KDQpJbi1saW5lIFtVbWFdOg0KDQotLQ0KVW1hIEMuDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IE9TUEYgW21haWx0bzpvc3BmLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKQ0KU2VudDogV2VkbmVzZGF5LCBNYXJj aCAxNiwgMjAxNiA5OjQxIFBNDQpUbzogQWNlZSBMaW5kZW0gKGFjZWUpOyBPU1BGIFdHIExpc3QN ClN1YmplY3Q6IFJlOiBbT1NQRl0gV0cgQWRvcHRpb24gUG9sbCBmb3IgIlVzaW5nIE9wZXJhdG9y LWRlZmluZWQgVExWcyBmb3IgQWdpbGUgU2VydmljZSBEZXBsb3ltZW50Ig0KDQpNeSBvcGluaW9u IG9mIHRoZSBkcmFmdCBoYXMgbm90IGNoYW5nZWQuDQpJdCBpcyBkZWZpbmluZyBhIHdheSB0byB1 dGlsaXplIE9TUEYgdG8gc2VuZCBhcHBsaWNhdGlvbiBpbmZvcm1hdGlvbiAtIHdoaWNoIGlzIG5v dCBzb21ldGhpbmcgdGhlIHByb3RvY29sIHNob3VsZCBiZSB1c2VkIHRvIGRvLg0KRnVydGhlciwg aXQgbGVhdmVzIGRlZmluaXRpb24gb2YgdGhlIG5ldyBjb2RlcG9pbnRzIGFuZCBmb3JtYXRzIG9m IHRoZSBpbmZvcm1hdGlvbiBhZHZlcnRpc2VkIGNvbXBsZXRlbHkgdW5zcGVjaWZpZWQgLSB0aGUg bGF0ZXN0IGRyYWZ0IHJldmlzaW9uIHN0YXRlczoNCg0KIiBUaGUgbWVhbmluZyBvZiB0aGUgb3Bl cmF0b3ItZGVmaW5lZCBzdWItVExWIGlzIHRvdGFsbHkgb3BhcXVlIHRvIE9TUEYNCiAgIGFuZCBp cyBkZWZpbmVkIGJ5IHRoZSBuZXR3b3JrIGxvY2FsIHBvbGljeSBhbmQgaXMgY29udHJvbGxlZCB2 aWENCiAgIGNvbmZpZ3VyYXRpb24uICAiDQoNCkhvdyBpbnRlcm9wZXJhYmlsaXR5IGlzIGFjaGll dmVkIGlzIG5vdCBhZGRyZXNzZWQgYXQgYWxsLg0KDQpbVW1hXTogVGhlIHdob2xlIHBvaW50IG9m IHRoZSBkcmFmdCBpcywgIG5vdCB0byBkZWZpbmUgdGhlIGZvcm1hdCBmb3IgdGhlIHN1Yi1UTFZz IHNvIHRoYXQgaXQgY2FuIGJlIHVzZWQgIGFzIHBlciB0aGUgc3ViLXRsdiB0eXBlIGFzIHNldCBi eSB0aGUgb3BlcmF0b3IgKGZvciBleGFtcGxlIHNlcnZpY2UgYXR0cmlidXRlL0xhYmVsKS4gIFN1 Yi1UTFYgaGFzIHNldCBvZiBhdHRyaWJ1dGUgbGVuZ3RoIGFuZCBhdHRyaWJ1dGUgdmFsdWUgaW4g TkJPLg0KDQpJUy1JUyBoYXMgdGFrZW4gYSBtdWNoIG1vcmUgc3RyaW5nZW50IGFwcHJvYWNoIHRv IGEgc2ltaWxhciByZXF1ZXN0LiAJDQoNCltVbWFdOiAuLiBhbmQgaGVuY2UgdW5mb3J0dW5hdGVs eSBJIHNlZSBubyBib2R5IHNhdyB1c2luZyBpdC0gaW4gZmFjdCBpbmNsdWRpbmcgeW91LiBGb3Ig ZXhhbXBsZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pc2lzLXNiZmQt ZGlzY3JpbWluYXRvci0wMiBjb3VsZCBoYXZlIHVzZWQgR0VOQVBQIGJ1dCByYXRoZXIgcmVzb3J0 ZWQgdG8gUm91dGVyIGNhcGFiaWxpdGllcyAoUmVtZW1iZXIgSUVURjkwIGRpc2N1c3Npb24gYXJv dW5kIHRoaXMpLg0KDQpSRkMgNjgyMyAoR0VOQVBQKSByZXF1aXJlcyB0aGF0IGluZm9ybWF0aW9u IHNlbnQgaW4gdGhlIGdlbmVyaWMgY29udGFpbmVyIFRMViBNVVNUIGJlIGJhc2VkIG9uIGEgcHVi bGljIHNwZWNpZmljYXRpb24gLSBhbmQgdGhhdCBhbiBhcHBsaWNhdGlvbiBzcGVjaWZpYyBJRCBm b3IgdGhlIGFwcGxpY2F0aW9uIHVzaW5nIHRoaXMgbWVjaGFuaXNtIGJlIGFzc2lnbmVkIGJ5IElB TkEuIFRoaXMgYWRkcmVzc2VzIHRoZSBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlLg0KR0VOQVBQIGZ1 cnRoZXIgc3BlY2lmaWVzIHRoYXQgc3VjaCBpbmZvcm1hdGlvbiBTSE9VTEQgYmUgYWR2ZXJ0aXNl ZCBieSBhIHNlcGFyYXRlIGluc3RhbmNlIG9mIHRoZSByb3V0aW5nIHByb3RvY29sIChhcyBzcGVj aWZpZWQgaW4gUkZDIDY4MjIoTUkpKSBzbyBhcyB0byBtaW5pbWl6ZSB0aGUgaW1wYWN0IG9mIHRo ZSBhcHBsaWNhdGlvbiBpbmZvcm1hdGlvbiBmbG9vZGluZyBvbiB0aGUgcGVyZm9ybWFuY2Ugb2Yg dGhlIHJvdXRpbmcgcHJvdG9jb2wuDQoNCltVbWFdOiBBcyBJIGluZGljYXRlZCBlYXJsaWVyIFtJ LUQuaWV0Zi1vc3BmLXRyYW5zcG9ydC1pbnN0YW5jZV0gY2FuIGJlIGRlZmluaXRlbHkgdXNlZCBp ZiB0aGUgaW5mb3JtYXRpb24gcmVsYXRlZCB0byBhcHBsaWNhdGlvbiBuZWVkIHRvIGJlIHVzZWQg dGhlcmUuIElmIGl0IGlzIHVzZWQgZm9yIHN1cHBvcnRpbmcgcm91dGluZyBvbmUgY2FuIHVzZSB0 aGlzIFRMVi4NCg0KDQoNCldpdGhvdXQgYWRkcmVzc2luZyBib3RoIG9mIHRoZXNlIGlzc3VlcyBJ IGNhbm5vdCBzdXBwb3J0IHRoZSBkcmFmdC4NCg0KICAgTGVzDQoNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBPU1BGIFttYWlsdG86b3NwZi1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgQWNlZSBMaW5kZW0NCj4gKGFjZWUpDQo+IFNlbnQ6IFdlZG5lc2RheSwg TWFyY2ggMTYsIDIwMTYgNzowOSBQTQ0KPiBUbzogT1NQRiBXRyBMaXN0DQo+IFN1YmplY3Q6IFtP U1BGXSBXRyBBZG9wdGlvbiBQb2xsIGZvciAiVXNpbmcgT3BlcmF0b3ItZGVmaW5lZCBUTFZzIGZv ciANCj4gQWdpbGUgU2VydmljZSBEZXBsb3ltZW50Ig0KPiANCj4gV2XigJl2ZSBkaXNjdXNzZWQg dGhpcyBkcmFmdCBhIG51bWJlciBvZiB0aW1lcy4gSW4gbXkgb3BpbmlvbiwgaXQgc2VlbXMgDQo+ IGxpa2UgYSB1c2VmdWwgbWVjaGFuaXNtIGlmIG9uZSBlbnZpc2lvbnMgYSBnZW5lcmFsaXplZCBB UEkgYmV0d2VlbiANCj4gT1NQRiBhbmQgdXNlciBhbmQgdGhpcmQtcGFydHkgYXBwbGljYXRpb25z IHRvIGNvbnZleSANCj4gYXBwbGljYXRpb24tc3BlY2lmaWMgaW5mb3JtYXRpb24gbGVhcm5lZCBm cm9tIG90aGVyIE9TUEYgcm91dGVycy4gSW4gDQo+IG1hbnkgcmVzcGVjdHMsIHRoaXMgaGFzIGFs cmVhZHkgYmVlbiBlbnZpc2lvbmVkIGZvciBPU1BGIE5vZGUgVGFncy4gDQo+IFBsZWFzZSBpbmRp Y2F0ZSB5b3VyIG9waW5pb24gb24gdGhpcyBkcmFmdCBiZWZvcmUgTWFyY2ggMzFzdCwgMjAxNi4N Cj4gDQo+IFRoYW5rcywNCj4gQWNlZQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gT1NQRiBtYWlsaW5nIGxpc3QNCj4gT1NQRkBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29zcGYNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPU1BGIG1haWxpbmcgbGlz dA0KT1NQRkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v c3BmDQo= From nobody Thu Apr 7 20:09:54 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D6812D561 for ; Thu, 7 Apr 2016 20:09:52 -0700 (PDT) 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, 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 IidDiLQvrlD5 for ; Thu, 7 Apr 2016 20:09:50 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613C312D601 for ; Thu, 7 Apr 2016 20:09:50 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-1e-57071ab6592c Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 35.4C.30335.6BA17075; Fri, 8 Apr 2016 04:43:02 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Thu, 7 Apr 2016 23:09:49 -0400 From: Uma Chunduri To: prz , Peter Psenak Thread-Topic: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment" Thread-Index: AQHRf/Ho6WRxQA5zQE2bUJRokiTbP59dC0kggAByIYCAAMx3AIAhPlUA Date: Fri, 8 Apr 2016 03:09:48 +0000 Message-ID: <1B502206DFA0C544B7A604691520086358001503@eusaamb106.ericsson.se> References: <56EA5A23.6020807@cisco.com> <3fc89c87056187cfa0908a07ed4c9850@zeta2.ch> In-Reply-To: <3fc89c87056187cfa0908a07ed4c9850@zeta2.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZXLonXHebFHu4Qd8FNYuWe/fYLXbsbmez uNf1mNWB2WPK742sHkuW/GTy+LHsD3MAcxSXTUpqTmZZapG+XQJXxpP+PWwFD9QqDj3ZzNbA +EC1i5GTQ0LARKL1/Vp2CFtM4sK99WxdjFwcQgJHGSUWrl3CBOEsY5RY++UtC0gVm4CexMep P8E6RAQsJGbe/csEYjMLKEhcu3gLqJuDQ1ggVWLCGWuIkjSJL1tnMIKERQTcJD6014CEWQRU JP4fbmEDsXkFfCXaJ85mhVi1kVHizOqjYOM5gcZPaV3GDGIzAh33/dQaqFXiEreezGeCOFpA Ysme88wQtqjEy8f/WCFsJYk5r68xg+xlFtCUWL9LH6JVUWJK90N2iL2CEidnPmGZwCg2C8nU WQgds5B0zELSsYCRZRUjR2lxQU5uupHBJkZg1ByTYNPdwXh/uuchRgEORiUe3gUC7OFCrIll xZW5hxglOJiVRHhzZYBCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeRuD/4UJCaQnlqRmp6YWpBbB ZJk4OKUaGJceKvs2oUb59YXQaTYXuFpabX49OaMf1eCaWWo36UJJpZbHl4vdn1/nGNw8bVT3 e+ulrK3TJe7z3dY+UPx58fzDsfqHns6fsmwl314mr3kGGfKx6n/WlFRxHmNWZj1yrDJhhVjv 2ye8wdcNvDh1JfZZqtjNr3jCaGZwZhtn9aECzeSjSzd3aCuxFGckGmoxFxUnAgDa7bewlgIA AA== Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 03:09:52 -0000 VG9ueSwgIFBldGVyLA0KDQpBbHNvICBwbGVhc2Ugbm90ZSB0aGUgZm9sbG93aW5nIGNoYW5nZXMg YXJlIG1hZGUgcGVyIGxhc3QgV0cgQWRvcHRpb24gY2FsbDoNCg0KMS4gICIgRGlzc2VtaW5hdGlv biBvZiBkeW5hbWljIGluZm9ybWF0aW9uIiBJbmZvcm1hdGlvbiBpcyByZW1vdmVkIGxpa2UgbG9j YXRpb24gaW5mb3JtYXRpb24gZm9yIE1vYmlsZSBPU1BGIHJvdXRlcnMuCQ0KICAgICAgDQoyLiBT ZWN0aW9uIDMgLSBBcHBsaWNhYmlsaXR5IGhhcyBiZWVuIGFkZGVkDQoNCjMuIFNlY3Rpb24gNiBM YXN0IHBhcmFncmFwaCBoYXMgYmVlbiBhZGRlZCBjbGFyaWZ5aW5nIGluZm9ybWF0aW9uIGFib3V0 IHRyYW5zcG9ydCBpbnN0YW5jZSB1c2FnZS4NCg0KLS0NClVtYSBDLg0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPU1BGIFttYWlsdG86b3NwZi1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgcHJ6DQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMTcsIDIwMTYgMTI6MzAg UE0NClRvOiBQZXRlciBQc2VuYWsNCkNjOiBPU1BGIFdHIExpc3QNClN1YmplY3Q6IFJlOiBbT1NQ Rl0gV0cgQWRvcHRpb24gUG9sbCBmb3IgIlVzaW5nIE9wZXJhdG9yLWRlZmluZWQgVExWcyBmb3Ig QWdpbGUgU2VydmljZSBEZXBsb3ltZW50Ig0KDQoNCiArMSB0byBQZXRlcidzLCBMZXMncyBvcGlu aW9uIGhlcmUgKGFzIGluZGl2aWR1YWwsIG5vIGhhdCwgbm90IGV2ZW4gYSAgc3VyZ2ljYWwgbWFz aywgQWNlZSA7LSkgLi4uDQoNCiAtLS0gdG9ueQ0KDQoNCiBPbiBUaHUsIDE3IE1hciAyMDE2IDA4 OjE3OjU1ICswMTAwLCBQZXRlciBQc2VuYWsgPHBwc2VuYWtAY2lzY28uY29tPg0KIHdyb3RlOg0K PiBJIGFncmVlIHdpdGggTGVzIGFuZCBzaGFyZSB0aGUgc2FtZSBjb25jZXJucy4NCj4NCj4gUGV0 ZXINCj4NCj4gT24gMy8xNy8xNiAwNTo0MCAsIExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIHdyb3Rl Og0KPj4gTXkgb3BpbmlvbiBvZiB0aGUgZHJhZnQgaGFzIG5vdCBjaGFuZ2VkLg0KPj4NCj4+IEl0 IGlzIGRlZmluaW5nIGEgd2F5IHRvIHV0aWxpemUgT1NQRiB0byBzZW5kIGFwcGxpY2F0aW9uIGlu Zm9ybWF0aW9uDQo+PiAtIHdoaWNoIGlzIG5vdCBzb21ldGhpbmcgdGhlIHByb3RvY29sIHNob3Vs ZCBiZSB1c2VkIHRvIGRvLg0KPj4gRnVydGhlciwgaXQgbGVhdmVzIGRlZmluaXRpb24gb2YgdGhl IG5ldyBjb2RlcG9pbnRzIGFuZCBmb3JtYXRzIG9mIA0KPj4gdGhlIGluZm9ybWF0aW9uIGFkdmVy dGlzZWQgY29tcGxldGVseSB1bnNwZWNpZmllZCAtIHRoZSBsYXRlc3QgZHJhZnQgDQo+PiByZXZp c2lvbiBzdGF0ZXM6DQo+Pg0KPj4gIiBUaGUgbWVhbmluZyBvZiB0aGUgb3BlcmF0b3ItZGVmaW5l ZCBzdWItVExWIGlzIHRvdGFsbHkgb3BhcXVlIHRvIA0KPj4gT1NQRg0KPj4gICAgIGFuZCBpcyBk ZWZpbmVkIGJ5IHRoZSBuZXR3b3JrIGxvY2FsIHBvbGljeSBhbmQgaXMgY29udHJvbGxlZCB2aWEN Cj4+ICAgICBjb25maWd1cmF0aW9uLiAgIg0KPj4NCj4+IEhvdyBpbnRlcm9wZXJhYmlsaXR5IGlz IGFjaGlldmVkIGlzIG5vdCBhZGRyZXNzZWQgYXQgYWxsLg0KPj4NCj4+IElTLUlTIGhhcyB0YWtl biBhIG11Y2ggbW9yZSBzdHJpbmdlbnQgYXBwcm9hY2ggdG8gYSBzaW1pbGFyIHJlcXVlc3QuDQo+ PiBSRkMgNjgyMyAoR0VOQVBQKSByZXF1aXJlcyB0aGF0IGluZm9ybWF0aW9uIHNlbnQgaW4gdGhl IGdlbmVyaWMgDQo+PiBjb250YWluZXIgVExWIE1VU1QgYmUgYmFzZWQgb24gYSBwdWJsaWMgc3Bl Y2lmaWNhdGlvbiAtIGFuZCB0aGF0IGFuIA0KPj4gYXBwbGljYXRpb24gc3BlY2lmaWMgSUQgZm9y IHRoZSBhcHBsaWNhdGlvbiB1c2luZyB0aGlzIG1lY2hhbmlzbSBiZSANCj4+IGFzc2lnbmVkIGJ5 IElBTkEuIFRoaXMgYWRkcmVzc2VzIHRoZSBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlLg0KPj4gR0VO QVBQIGZ1cnRoZXIgc3BlY2lmaWVzIHRoYXQgc3VjaCBpbmZvcm1hdGlvbiBTSE9VTEQgYmUgYWR2 ZXJ0aXNlZCANCj4+IGJ5IGEgc2VwYXJhdGUgaW5zdGFuY2Ugb2YgdGhlIHJvdXRpbmcgcHJvdG9j b2wgKGFzIHNwZWNpZmllZCBpbiBSRkMNCj4+IDY4MjIoTUkpKSBzbyBhcyB0byBtaW5pbWl6ZSB0 aGUgaW1wYWN0IG9mIHRoZSBhcHBsaWNhdGlvbiBpbmZvcm1hdGlvbiANCj4+IGZsb29kaW5nIG9u IHRoZSBwZXJmb3JtYW5jZSBvZiB0aGUgcm91dGluZyBwcm90b2NvbC4NCj4+DQo+PiBXaXRob3V0 IGFkZHJlc3NpbmcgYm90aCBvZiB0aGVzZSBpc3N1ZXMgSSBjYW5ub3Qgc3VwcG9ydCB0aGUgZHJh ZnQuDQo+Pg0KPj4gICAgIExlcw0KPj4NCj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+PiBGcm9tOiBPU1BGIFttYWlsdG86b3NwZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgQWNlZSBMaW5kZW0NCj4+PiAoYWNlZSkNCj4+PiBTZW50OiBXZWRuZXNkYXksIE1hcmNo IDE2LCAyMDE2IDc6MDkgUE0NCj4+PiBUbzogT1NQRiBXRyBMaXN0DQo+Pj4gU3ViamVjdDogW09T UEZdIFdHIEFkb3B0aW9uIFBvbGwgZm9yICJVc2luZyBPcGVyYXRvci1kZWZpbmVkIFRMVnMgDQo+ Pj4gZm9yIEFnaWxlIFNlcnZpY2UgRGVwbG95bWVudCINCj4+Pg0KPj4+IFdl4oCZdmUgZGlzY3Vz c2VkIHRoaXMgZHJhZnQgYSBudW1iZXIgb2YgdGltZXMuIEluIG15IG9waW5pb24sIGl0IA0KPj4+ IHNlZW1zIGxpa2UgYSB1c2VmdWwgbWVjaGFuaXNtIGlmIG9uZSBlbnZpc2lvbnMgYSBnZW5lcmFs aXplZCBBUEkgDQo+Pj4gYmV0d2VlbiBPU1BGIGFuZCB1c2VyIGFuZCB0aGlyZC1wYXJ0eSBhcHBs aWNhdGlvbnMgdG8gY29udmV5IA0KPj4+IGFwcGxpY2F0aW9uLXNwZWNpZmljIGluZm9ybWF0aW9u IGxlYXJuZWQgZnJvbSBvdGhlciBPU1BGIHJvdXRlcnMuIEluIA0KPj4+IG1hbnkgcmVzcGVjdHMs IHRoaXMgaGFzIGFscmVhZHkgYmVlbiBlbnZpc2lvbmVkIGZvciBPU1BGIE5vZGUgVGFncy4gDQo+ Pj4gUGxlYXNlIGluZGljYXRlIHlvdXIgb3BpbmlvbiBvbiB0aGlzIGRyYWZ0IGJlZm9yZSBNYXJj aCAzMXN0LCAyMDE2Lg0KPj4+DQo+Pj4gVGhhbmtzLA0KPj4+IEFjZWUNCj4+Pg0KPj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gT1NQRiBtYWls aW5nIGxpc3QNCj4+PiBPU1BGQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vc3BmDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gT1NQRiBtYWlsaW5nIGxpc3QNCj4+IE9TUEZAaWV0Zi5vcmcNCj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3NwZg0KPj4NCj4NCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT1NQRiBtYWls aW5nIGxpc3QNCj4gT1NQRkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29zcGYNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCk9TUEYgbWFpbGluZyBsaXN0DQpPU1BGQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29zcGYNCg== From nobody Thu Apr 7 20:39:41 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F2812D789 for ; Thu, 7 Apr 2016 20:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZLQ9iACLmEO for ; Thu, 7 Apr 2016 20:39:38 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD61512D783 for ; Thu, 7 Apr 2016 20:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5412; q=dns/txt; s=iport; t=1460086778; x=1461296378; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=LG0vpFNX2U+jGMifoJkrdBm6/T/T5rF0JjFAayy2LmY=; b=YP4rECVuoSj/I/iQPLmz+TNltkvwTjYhpKrg2zeKeVqiprCWWeM3g+1Y jjQ60XnyLydWqGheZk7+40nhLMCTkumjvlYhdIXPJhrZfhFmWkkQfQsff nxeFH0uyZzv7aMeQKz0+fC25zHsB7P31rJsW8txtaRcB65icqFdJbnYLD 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D8AQAwJwdX/5RdJa1dgzdTfQa6QAENg?= =?us-ascii?q?XMXCoVsAhyBIzgUAQEBAQEBAWUnhEEBAQEDAQEBASAROhAHBAIBCBEEAQEDAiM?= =?us-ascii?q?DAgICJQsUAQgIAgQBEgiIFwgOsAqSDwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEf?= =?us-ascii?q?IUlhEuHP4JWBZgEAYV2iA6BboRNiFmPJAEeAQFCgjKBNWyIO34BAQE?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="91309017" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2016 03:39:37 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u383db1F016408 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 03:39:37 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 22:39:36 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Thu, 7 Apr 2016 22:39:36 -0500 From: "Les Ginsberg (ginsberg)" To: Uma Chunduri , "Acee Lindem (acee)" , OSPF WG List Thread-Topic: WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment" Thread-Index: AQHRf/Ho6WRxQA5zQE2bUJRokiTbP59dC0kggCJ0YZCAABBu8A== Date: Fri, 8 Apr 2016 03:39:36 +0000 Message-ID: References: <1B502206DFA0C544B7A6046915200863580014D7@eusaamb106.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A6046915200863580014D7@eusaamb106.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.126.203] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 03:39:40 -0000 VW1hIC0NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBVbWEgQ2h1bmR1 cmkgW21haWx0bzp1bWEuY2h1bmR1cmlAZXJpY3Nzb24uY29tXQ0KPiBTZW50OiBUaHVyc2RheSwg QXByaWwgMDcsIDIwMTYgODowMyBQTQ0KPiBUbzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZyk7IEFj ZWUgTGluZGVtIChhY2VlKTsgT1NQRiBXRyBMaXN0DQo+IFN1YmplY3Q6IFJFOiBXRyBBZG9wdGlv biBQb2xsIGZvciAiVXNpbmcgT3BlcmF0b3ItZGVmaW5lZCBUTFZzIGZvciBBZ2lsZQ0KPiBTZXJ2 aWNlIERlcGxveW1lbnQiDQo+IA0KPiBMZXMsDQo+IA0KPiBJbi1saW5lIFtVbWFdOg0KPiANCj4g LS0NCj4gVW1hIEMuDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogT1NQRiBbbWFpbHRvOm9zcGYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExlcyBH aW5zYmVyZw0KPiAoZ2luc2JlcmcpDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMTYsIDIwMTYg OTo0MSBQTQ0KPiBUbzogQWNlZSBMaW5kZW0gKGFjZWUpOyBPU1BGIFdHIExpc3QNCj4gU3ViamVj dDogUmU6IFtPU1BGXSBXRyBBZG9wdGlvbiBQb2xsIGZvciAiVXNpbmcgT3BlcmF0b3ItZGVmaW5l ZCBUTFZzIGZvcg0KPiBBZ2lsZSBTZXJ2aWNlIERlcGxveW1lbnQiDQo+IA0KPiBNeSBvcGluaW9u IG9mIHRoZSBkcmFmdCBoYXMgbm90IGNoYW5nZWQuDQo+IEl0IGlzIGRlZmluaW5nIGEgd2F5IHRv IHV0aWxpemUgT1NQRiB0byBzZW5kIGFwcGxpY2F0aW9uIGluZm9ybWF0aW9uIC0gd2hpY2ggaXMN Cj4gbm90IHNvbWV0aGluZyB0aGUgcHJvdG9jb2wgc2hvdWxkIGJlIHVzZWQgdG8gZG8uDQo+IEZ1 cnRoZXIsIGl0IGxlYXZlcyBkZWZpbml0aW9uIG9mIHRoZSBuZXcgY29kZXBvaW50cyBhbmQgZm9y bWF0cyBvZiB0aGUNCj4gaW5mb3JtYXRpb24gYWR2ZXJ0aXNlZCBjb21wbGV0ZWx5IHVuc3BlY2lm aWVkIC0gdGhlIGxhdGVzdCBkcmFmdCByZXZpc2lvbg0KPiBzdGF0ZXM6DQo+IA0KPiAiIFRoZSBt ZWFuaW5nIG9mIHRoZSBvcGVyYXRvci1kZWZpbmVkIHN1Yi1UTFYgaXMgdG90YWxseSBvcGFxdWUg dG8gT1NQRg0KPiAgICBhbmQgaXMgZGVmaW5lZCBieSB0aGUgbmV0d29yayBsb2NhbCBwb2xpY3kg YW5kIGlzIGNvbnRyb2xsZWQgdmlhDQo+ICAgIGNvbmZpZ3VyYXRpb24uICAiDQo+IA0KPiBIb3cg aW50ZXJvcGVyYWJpbGl0eSBpcyBhY2hpZXZlZCBpcyBub3QgYWRkcmVzc2VkIGF0IGFsbC4NCj4g DQo+IFtVbWFdOiBUaGUgd2hvbGUgcG9pbnQgb2YgdGhlIGRyYWZ0IGlzLCAgbm90IHRvIGRlZmlu ZSB0aGUgZm9ybWF0IGZvciB0aGUgc3ViLQ0KPiBUTFZzIHNvIHRoYXQgaXQgY2FuIGJlIHVzZWQg IGFzIHBlciB0aGUgc3ViLXRsdiB0eXBlIGFzIHNldCBieSB0aGUgb3BlcmF0b3IgKGZvcg0KPiBl eGFtcGxlIHNlcnZpY2UgYXR0cmlidXRlL0xhYmVsKS4gIFN1Yi1UTFYgaGFzIHNldCBvZiBhdHRy aWJ1dGUgbGVuZ3RoIGFuZA0KPiBhdHRyaWJ1dGUgdmFsdWUgaW4gTkJPLg0KPiANCltMZXM6XSBZ ZXMgLSBJIGtub3cuIDotKQ0KQW5kIEkgdGhpbmsgdGhpcyBpcyBhICJkaXNhc3RlciB3YWl0aW5n IHRvIGhhcHBlbiIuDQoNCk9uIHRoaXMgcG9pbnQgSSB0aGluayB3ZSBjdXJyZW50bHkgaGF2ZSBu byBjb21tb24gZ3JvdW5kLg0KDQogICBMZXMNCg0KPiBJUy1JUyBoYXMgdGFrZW4gYSBtdWNoIG1v cmUgc3RyaW5nZW50IGFwcHJvYWNoIHRvIGEgc2ltaWxhciByZXF1ZXN0Lg0KPiANCj4gW1VtYV06 IC4uIGFuZCBoZW5jZSB1bmZvcnR1bmF0ZWx5IEkgc2VlIG5vIGJvZHkgc2F3IHVzaW5nIGl0LSBp biBmYWN0IGluY2x1ZGluZw0KPiB5b3UuIEZvciBleGFtcGxlIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWlzaXMtc2JmZC0NCj4gZGlzY3JpbWluYXRvci0wMiBjb3VsZCBo YXZlIHVzZWQgR0VOQVBQIGJ1dCByYXRoZXIgcmVzb3J0ZWQgdG8gUm91dGVyDQo+IGNhcGFiaWxp dGllcyAoUmVtZW1iZXIgSUVURjkwIGRpc2N1c3Npb24gYXJvdW5kIHRoaXMpLg0KPiANCj4gUkZD IDY4MjMgKEdFTkFQUCkgcmVxdWlyZXMgdGhhdCBpbmZvcm1hdGlvbiBzZW50IGluIHRoZSBnZW5l cmljIGNvbnRhaW5lcg0KPiBUTFYgTVVTVCBiZSBiYXNlZCBvbiBhIHB1YmxpYyBzcGVjaWZpY2F0 aW9uIC0gYW5kIHRoYXQgYW4gYXBwbGljYXRpb24gc3BlY2lmaWMNCj4gSUQgZm9yIHRoZSBhcHBs aWNhdGlvbiB1c2luZyB0aGlzIG1lY2hhbmlzbSBiZSBhc3NpZ25lZCBieSBJQU5BLiBUaGlzDQo+ IGFkZHJlc3NlcyB0aGUgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZS4NCj4gR0VOQVBQIGZ1cnRoZXIg c3BlY2lmaWVzIHRoYXQgc3VjaCBpbmZvcm1hdGlvbiBTSE9VTEQgYmUgYWR2ZXJ0aXNlZCBieSBh DQo+IHNlcGFyYXRlIGluc3RhbmNlIG9mIHRoZSByb3V0aW5nIHByb3RvY29sIChhcyBzcGVjaWZp ZWQgaW4gUkZDIDY4MjIoTUkpKSBzbyBhcw0KPiB0byBtaW5pbWl6ZSB0aGUgaW1wYWN0IG9mIHRo ZSBhcHBsaWNhdGlvbiBpbmZvcm1hdGlvbiBmbG9vZGluZyBvbiB0aGUNCj4gcGVyZm9ybWFuY2Ug b2YgdGhlIHJvdXRpbmcgcHJvdG9jb2wuDQo+IA0KPiBbVW1hXTogQXMgSSBpbmRpY2F0ZWQgZWFy bGllciBbSS1ELmlldGYtb3NwZi10cmFuc3BvcnQtaW5zdGFuY2VdIGNhbiBiZQ0KPiBkZWZpbml0 ZWx5IHVzZWQgaWYgdGhlIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gYXBwbGljYXRpb24gbmVlZCB0 byBiZSB1c2VkDQo+IHRoZXJlLiBJZiBpdCBpcyB1c2VkIGZvciBzdXBwb3J0aW5nIHJvdXRpbmcg b25lIGNhbiB1c2UgdGhpcyBUTFYuDQo+IA0KPiANCj4gDQo+IFdpdGhvdXQgYWRkcmVzc2luZyBi b3RoIG9mIHRoZXNlIGlzc3VlcyBJIGNhbm5vdCBzdXBwb3J0IHRoZSBkcmFmdC4NCj4gDQo+ICAg IExlcw0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBP U1BGIFttYWlsdG86b3NwZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWNlZSBMaW5k ZW0NCj4gPiAoYWNlZSkNCj4gPiBTZW50OiBXZWRuZXNkYXksIE1hcmNoIDE2LCAyMDE2IDc6MDkg UE0NCj4gPiBUbzogT1NQRiBXRyBMaXN0DQo+ID4gU3ViamVjdDogW09TUEZdIFdHIEFkb3B0aW9u IFBvbGwgZm9yICJVc2luZyBPcGVyYXRvci1kZWZpbmVkIFRMVnMgZm9yDQo+ID4gQWdpbGUgU2Vy dmljZSBEZXBsb3ltZW50Ig0KPiA+DQo+ID4gV2XigJl2ZSBkaXNjdXNzZWQgdGhpcyBkcmFmdCBh IG51bWJlciBvZiB0aW1lcy4gSW4gbXkgb3BpbmlvbiwgaXQgc2VlbXMNCj4gPiBsaWtlIGEgdXNl ZnVsIG1lY2hhbmlzbSBpZiBvbmUgZW52aXNpb25zIGEgZ2VuZXJhbGl6ZWQgQVBJIGJldHdlZW4N Cj4gPiBPU1BGIGFuZCB1c2VyIGFuZCB0aGlyZC1wYXJ0eSBhcHBsaWNhdGlvbnMgdG8gY29udmV5 DQo+ID4gYXBwbGljYXRpb24tc3BlY2lmaWMgaW5mb3JtYXRpb24gbGVhcm5lZCBmcm9tIG90aGVy IE9TUEYgcm91dGVycy4gSW4NCj4gPiBtYW55IHJlc3BlY3RzLCB0aGlzIGhhcyBhbHJlYWR5IGJl ZW4gZW52aXNpb25lZCBmb3IgT1NQRiBOb2RlIFRhZ3MuDQo+ID4gUGxlYXNlIGluZGljYXRlIHlv dXIgb3BpbmlvbiBvbiB0aGlzIGRyYWZ0IGJlZm9yZSBNYXJjaCAzMXN0LCAyMDE2Lg0KPiA+DQo+ ID4gVGhhbmtzLA0KPiA+IEFjZWUNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gT1NQRiBtYWlsaW5nIGxpc3QNCj4gPiBPU1BGQGll dGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vc3BmDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9TUEYg bWFpbGluZyBsaXN0DQo+IE9TUEZAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vc3BmDQo= From nobody Thu Apr 7 20:56:01 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A0E12D791 for ; Thu, 7 Apr 2016 20:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qG5WtaqvkD5b for ; Thu, 7 Apr 2016 20:55:58 -0700 (PDT) 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 9FB1A12D78E for ; Thu, 7 Apr 2016 20:55:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4623; q=dns/txt; s=iport; t=1460087758; x=1461297358; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=vEPX0hXIb2uofAmc4g7biqejUwW0edpAFi4+D+zrEXg=; b=VtS0gycYTOpoQvcXQ2pNMpLC82d7/fsp4vVJR+WZ/PJJlWxxicjWmOr2 JPEPuyF3eCAaakITCCgepK8YFJWspwks9UHFHP8/ADq9nGIIexYdNcWyP 2xFsGIirZR6vAX3G5nOyA802kEchL8tgeUM568P/W3FNCm6Mjp/smtfu3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AQAuKwdX/40NJK1dgmtMU30GukABD?= =?us-ascii?q?YFzhg0CgT84FAEBAQEBAQFlJ4RBAQEBBC1cAgEIEQQBASgHMhQJCAEBBAESCIg?= =?us-ascii?q?fwisBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGES4R1hSAFmAQBjgSPFI8kAR4BA?= =?us-ascii?q?UKDZ2yIO34BAQE?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208,217";a="259008228" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2016 03:55:57 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u383tvFG008560 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 03:55:57 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 22:55:56 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Thu, 7 Apr 2016 22:55:56 -0500 From: "Les Ginsberg (ginsberg)" To: "Paul Mattes (AZURE)" , "ospf@ietf.org" Thread-Topic: draft-ppsenak-ospf-te-link-attr-reuse-01 for IS-IS? Thread-Index: AdGRCWFwQxA5nUINRAeIjM4TdDDRaAAQOPfg Date: Fri, 8 Apr 2016 03:55:56 +0000 Message-ID: <5c1a7d162ef547b584d446cab8baa0bc@XCH-ALN-001.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.24.126.203] Content-Type: multipart/alternative; boundary="_000_5c1a7d162ef547b584d446cab8baa0bcXCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse-01 for IS-IS? X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 03:56:00 -0000 --_000_5c1a7d162ef547b584d446cab8baa0bcXCHALN001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No - there isn't an IS-IS equivalent - though I agree that conceptually the= same arguments (for and against) apply to both protocols. For my part I am happy to let the discussion continue to a conclusion in OS= PF WG before deciding what should be done in IS-IS. Les From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Paul Mattes (AZURE) Sent: Thursday, April 07, 2016 1:10 PM To: ospf@ietf.org Subject: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse-01 for IS-IS? Is there an IS-IS equivalent of draft-ppsenak-ospf-te-link-attr-reuse-01? pdm --_000_5c1a7d162ef547b584d446cab8baa0bcXCHALN001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No – there isn&#= 8217;t an IS-IS equivalent – though I agree that conceptually the sam= e arguments (for and against) apply to both protocols.

 

For my part I am happy= to let the discussion continue to a conclusion in OSPF WG before deciding = what should be done in IS-IS.

 

   Les<= /o:p>

 

 

From: OSPF [ma= ilto:ospf-bounces@ietf.org] On Behalf Of Paul Mattes (AZURE)
Sent: Thursday, April 07, 2016 1:10 PM
To: ospf@ietf.org
Subject: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse-01 for IS-IS?<= o:p>

 

Is there an IS-IS equivalent of draft-ppsenak-ospf-t= e-link-attr-reuse-01?

 

       pdm

 

--_000_5c1a7d162ef547b584d446cab8baa0bcXCHALN001ciscocom_-- From nobody Fri Apr 8 01:14:00 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE1512D19A for ; Fri, 8 Apr 2016 01:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_83yO6Iz8_y for ; Fri, 8 Apr 2016 01:13:57 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9A912D17E for ; Fri, 8 Apr 2016 01:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2500; q=dns/txt; s=iport; t=1460103237; x=1461312837; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Yl/x7ljuuWgZuyknrW5AuwOmOJNrTcw3MTfBWxZbVG4=; b=N02FGEuLCOPklVupHEkLjlKC0IKFtrKGgX+p6S9WITgYAwzVG/j/fiNC Lw6ZzeYGHOI51pFUcfJJKeMv5xFk33yLHa245ZMcmlXbvFiU/r7if5nRh aAFVopjbcS/rzeRmua58y+RK7btqSUPEOlJiLXmaRsniqeJWjQY7nKuYN 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQCoZwdX/xbLJq1dhAp9ukYBDYFzF?= =?us-ascii?q?wqFbAKBcRQBAQEBAQEBZSeEQQEBAQMBAQEBLwEFNgoRCxgJFg8JAwIBAgEVMAY?= =?us-ascii?q?BDAYCAQGIGwgOwjQBAQEBAQEBAQEBAQEBAQEBAQEUBIYhhEuKFQEEmASODIFnh?= =?us-ascii?q?E2DBSOFMY8lHgEBQoNpOjCJOQEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="634041398" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2016 08:13:55 +0000 Received: from [10.60.140.57] (ams-ppsenak-nitro8.cisco.com [10.60.140.57]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u388DsAR021376; Fri, 8 Apr 2016 08:13:54 GMT Message-ID: <57076842.7030703@cisco.com> Date: Fri, 08 Apr 2016 10:13:54 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Paul Mattes (AZURE)" , "ospf@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 08:13:59 -0000 Hi Paul, please see inline: On 4/7/16 22:09 , Paul Mattes (AZURE) wrote: > I would like to amplify some of the comments made about this draft at > today’s OSPF WG meeting. > > The draft refers generically to TE when it really means RSVP TE. The > draft should use the more-specific term “RSVP TE” or “RSVP-based TE” in > most (but not all) of the places where “TE” is used. The most unhelpful > place this occurs in section 1: > > Many of these link attributes are useful outside of the traditional > MLPLS (sic) Traffic Engineering or GMPLS. > > This should read: > > Many of these link attributes are useful outside of the traditional > RSVP-based Traffic Engineering, or GMPLS. ok, will change. > > Perhaps it would be helpful if SR-based Traffic Engineering were > mentioned as a typical consumer of this new information, which would > distinguish it from RSVP-TE as the primary consumer of the existing TLVs. well, it's not just SR-based traffic engineering. LFA is another example, which is not related to SR TE. > > In Section 3.1, I also have issue with this statement: > > Additionally, link attributes are only advertised once when both > OSPF TE and other applications are deployed on the same link. This is > not expected to be a common deployment scenario. > > I don’t think that this is a desired result, and I believe this is what > Chris Bowers was trying to emphasize with his earlier comments. If a > router currently advertises the existing TE TLVs, it should continue to > advertise them after it implements this draft. Turning off advertisement > of the existing TE TLVs (if somehow they were being advertised without > enabling RSVP-TE on the link) should not be the default behavior, though > perhaps it could be made an option. I know this default would be less > efficient, but I don’t think it is worth breaking backwards > compatibility to have. section 3.1 talks about the other approach, which is to only use TE Opaque LSA for advertising any link attributes. In such case the link attribute is only advertise once. Section 3.2., which talks about the preferred option of using Extended Link LSA explicitly says "the same link attribute is advertised in both the TE Opaque and Extended Link Attribute LSAs". thanks, Peter > > /pdm/ > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From nobody Fri Apr 8 01:24:54 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FCC12D52A for ; Fri, 8 Apr 2016 01:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzLw85hUodEE for ; Fri, 8 Apr 2016 01:24:51 -0700 (PDT) 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 7383C12D0B3 for ; Fri, 8 Apr 2016 01:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4142; q=dns/txt; s=iport; t=1460103890; x=1461313490; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=dfIZRFzJ/tlCfhQQRg6649Xb6Kp8K1DHA1qCJandEDg=; b=krnnhvMVhmNGlL+Uysui2gmDl82wRWKYQeOQhciFjPAOxLBVBM0dAzAr 5HK2UoVV/duRpiUMvMwJkvQQQJ1BI/F8UpO13XA9R9mYJYd0oWZfslwbV tZ1EbA33b3rOzIRsdeC0/c6CdqbhIcjwJaR9Tql7hcL0wxyAGR/C3tCRm U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuBADkaQdX/xbLJq1dhAp9vEcXCoVsA?= =?us-ascii?q?oIFAQEBAQEBZieEQQEBAQQBAQEgDwEFNgoBDAQLEQQBAQECAgUWCAMCAgkDAgE?= =?us-ascii?q?CARUfCQgGAQwBBQIBAYgjDrAnkg0BAQEBAQEBAQEBAQEBAQEBAQEBAQERBHyFJ?= =?us-ascii?q?YRLhz+CVgEEmASODIFnhE2DBYVUjyVigjKBNzowiTkBAQE?= X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="635063072" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2016 08:24:48 +0000 Received: from [10.60.140.57] (ams-ppsenak-nitro8.cisco.com [10.60.140.57]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u388Olrt026037; Fri, 8 Apr 2016 08:24:47 GMT Message-ID: <57076ACF.8070608@cisco.com> Date: Fri, 08 Apr 2016 10:24:47 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Uma Chunduri , prz References: <56EA5A23.6020807@cisco.com> <3fc89c87056187cfa0908a07ed4c9850@zeta2.ch> <1B502206DFA0C544B7A604691520086358001503@eusaamb106.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A604691520086358001503@eusaamb106.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 08:24:53 -0000 Hi Uma, I still have a fundamental problem with leaving the sub-TLV definition to the operator. If the operator really wants to do define something proprietary, we have plenty of experimental/reserved code points in RI TLV space. I just don't see a point of standardizing a container that is used to advertise proprietary sub-TLVs. thanks, Peter On 4/8/16 05:09 , Uma Chunduri wrote: > Tony, Peter, > > Also please note the following changes are made per last WG Adoption call: > > 1. " Dissemination of dynamic information" Information is removed like location information for Mobile OSPF routers. > > 2. Section 3 - Applicability has been added > > 3. Section 6 Last paragraph has been added clarifying information about transport instance usage. > > -- > Uma C. > > > -----Original Message----- > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of prz > Sent: Thursday, March 17, 2016 12:30 PM > To: Peter Psenak > Cc: OSPF WG List > Subject: Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment" > > > +1 to Peter's, Les's opinion here (as individual, no hat, not even a surgical mask, Acee ;-) ... > > --- tony > > > On Thu, 17 Mar 2016 08:17:55 +0100, Peter Psenak > wrote: >> I agree with Les and share the same concerns. >> >> Peter >> >> On 3/17/16 05:40 , Les Ginsberg (ginsberg) wrote: >>> My opinion of the draft has not changed. >>> >>> It is defining a way to utilize OSPF to send application information >>> - which is not something the protocol should be used to do. >>> Further, it leaves definition of the new codepoints and formats of >>> the information advertised completely unspecified - the latest draft >>> revision states: >>> >>> " The meaning of the operator-defined sub-TLV is totally opaque to >>> OSPF >>> and is defined by the network local policy and is controlled via >>> configuration. " >>> >>> How interoperability is achieved is not addressed at all. >>> >>> IS-IS has taken a much more stringent approach to a similar request. >>> RFC 6823 (GENAPP) requires that information sent in the generic >>> container TLV MUST be based on a public specification - and that an >>> application specific ID for the application using this mechanism be >>> assigned by IANA. This addresses the interoperability issue. >>> GENAPP further specifies that such information SHOULD be advertised >>> by a separate instance of the routing protocol (as specified in RFC >>> 6822(MI)) so as to minimize the impact of the application information >>> flooding on the performance of the routing protocol. >>> >>> Without addressing both of these issues I cannot support the draft. >>> >>> Les >>> >>> >>>> -----Original Message----- >>>> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem >>>> (acee) >>>> Sent: Wednesday, March 16, 2016 7:09 PM >>>> To: OSPF WG List >>>> Subject: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs >>>> for Agile Service Deployment" >>>> >>>> We’ve discussed this draft a number of times. In my opinion, it >>>> seems like a useful mechanism if one envisions a generalized API >>>> between OSPF and user and third-party applications to convey >>>> application-specific information learned from other OSPF routers. In >>>> many respects, this has already been envisioned for OSPF Node Tags. >>>> Please indicate your opinion on this draft before March 31st, 2016. >>>> >>>> Thanks, >>>> Acee >>>> >>>> _______________________________________________ >>>> OSPF mailing list >>>> OSPF@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ospf >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >>> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From nobody Sat Apr 9 19:36:48 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E7012D131; Sat, 9 Apr 2016 19:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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.996, 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 XgPFgOBfmZUr; Sat, 9 Apr 2016 19:36:46 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C010512D0BA; Sat, 9 Apr 2016 19:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9617; q=dns/txt; s=iport; t=1460255805; x=1461465405; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YPOTWMiQmlSBEAx2nXpLVTMN90kfedwxemBsV3FPs5E=; b=Fbx7hNGj+gLfMGbLZYQOJkesQayUdMF6e6Km1GZwC/LTvlgZWlzm8NIS 3UTYQg0wUTBi/UnUqc9RTgYh8hDXYc1fpvNxA3Nz35CtU+AcY1ZF5yCj0 K556uYSL5bv3pqaIKpyOQ7sTx7jxcuAXbgRXgxAQGqGXPUMDJR5hRXz2A k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AgBzuwlX/40NJK1cgmtMU30GrneGZ?= =?us-ascii?q?YRzAQ2Bc4YNAhyBDDgUAQEBAQEBAWUnhEEBAQEEIwpMEAIBCBEDAQIWEgMCAgI?= =?us-ascii?q?fERQJCAEBBAENBYgSAxKpU4t9DYUfAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYpsg?= =?us-ascii?q?kGCHh+CQYJWBZMZhDoxAYwWgXWPDYdKh1sBHgEBQoNnbIgufgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,461,1454976000"; d="scan'208,217";a="258009029" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Apr 2016 02:36:44 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u3A2aixs024324 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 10 Apr 2016 02:36:44 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 9 Apr 2016 22:36:43 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Sat, 9 Apr 2016 22:36:43 -0400 From: "Acee Lindem (acee)" To: Wenhu Lu , "draft-ietf-ospf-transition-to-ospfv3.authors@ietf.org" Thread-Topic: IPR disclosure Thread-Index: AdGSBKaJNnZ6kUDDT72rWQu4fT1MkwAzSrmA Date: Sun, 10 Apr 2016 02:36:43 +0000 Message-ID: References: <360AE91BC9ADBF4698AA2D37D392EC62228F92F6@eusaamb103.ericsson.se> In-Reply-To: <360AE91BC9ADBF4698AA2D37D392EC62228F92F6@eusaamb103.ericsson.se> 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.202] Content-Type: multipart/alternative; boundary="_000_D32F342D58B22aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] IPR disclosure X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 02:36:47 -0000 --_000_D32F342D58B22aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgV2VuaHUgKERvY3VtZW50IFNoZXBoZXJkKSwNCkkgYW0gbm90IGF3YXJlIG9mIGFueSBJUFIu DQpUaGFua3MsDQpBY2VlDQoNCkZyb206IFdlbmh1IEx1IDx3ZW5odS5sdUBlcmljc3Nvbi5jb208 bWFpbHRvOndlbmh1Lmx1QGVyaWNzc29uLmNvbT4+DQpEYXRlOiBGcmlkYXksIEFwcmlsIDgsIDIw MTYgYXQgMTE6MDggUE0NClRvOiAiZHJhZnQtaWV0Zi1vc3BmLXRyYW5zaXRpb24tdG8tb3NwZnYz LmF1dGhvcnNAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtb3NwZi10cmFuc2l0aW9uLXRvLW9z cGZ2My5hdXRob3JzQGlldGYub3JnPiIgPGRyYWZ0LWlldGYtb3NwZi10cmFuc2l0aW9uLXRvLW9z cGZ2My5hdXRob3JzQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW9zcGYtdHJhbnNpdGlvbi10 by1vc3BmdjMuYXV0aG9yc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBJUFIgZGlzY2xvc3VyZQ0KDQpB dXRob3JzLA0KDQpJbiBwcmVwYXJpbmcgdGhlIHdyaXRldXAsIGNhbiBJIGhhdmUgeW91ciByZXNw b25zZSBmb3IgdGhlIGZvbGxvd2luZyBxdWVzdGlvbj8NCg0KMS4gICAgICAgQ2FuIGVhY2ggYXV0 aG9yIGNvbmZpcm0gaWYgdGhlcmUgaXMgYW55IElQUiBmaWxlZCB0aGF0IGlzIHJlbGF0ZWQgdG8g dGhpcyBkcmFmdD8NCg0KRllJLCBmb3VuZCBhIHR5cG86IGluIOKAnEFic3RyYWN04oCdIGxpbmUg MywgT1NGUHYyID0+IE9TUEZ2Mg0KRllJIDIsIG15IElFVEYgYWNjb3VudCBJRCBpcyB3ZW5odS5s dUBnbWFpbC5jb208bWFpbHRvOndlbmh1Lmx1QGdtYWlsLmNvbT4NCg0KVGhhbmsgeW91LA0KLXdl bmh1DQoNCg== --_000_D32F342D58B22aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <66E530A362BF7A429B8DD96AD4BF5D9E@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBXZW5odSAo RG9jdW1lbnQgU2hlcGhlcmQpLCZuYnNwOzwvZGl2Pg0KPGRpdj5JIGFtIG5vdCBhd2FyZSBvZiBh bnkgSVBSLiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PkFjZWU8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246 bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVG VDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQ QURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVIt UklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+V2VuaHUgTHUgJmx0OzxhIGhyZWY9Im1haWx0bzp3 ZW5odS5sdUBlcmljc3Nvbi5jb20iPndlbmh1Lmx1QGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5GcmlkYXksIEFwcmls IDgsIDIwMTYgYXQgMTE6MDggUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+ VG86IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1vc3BmLXRyYW5zaXRp b24tdG8tb3NwZnYzLmF1dGhvcnNAaWV0Zi5vcmciPmRyYWZ0LWlldGYtb3NwZi10cmFuc2l0aW9u LXRvLW9zcGZ2My5hdXRob3JzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmRyYWZ0LWlldGYtb3NwZi10cmFuc2l0aW9uLXRvLW9zcGZ2My5hdXRob3JzQGlldGYub3JnIj5k cmFmdC1pZXRmLW9zcGYtdHJhbnNpdGlvbi10by1vc3BmdjMuYXV0aG9yc0BpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5J UFIgZGlzY2xvc3VyZTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxF RlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0K PGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1h cy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNy b3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9U Ui9SRUMtaHRtbDQwIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0 IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5p dGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGku TXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9y aXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJv dHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8N CkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE5MzQ5MDAwMjU7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yODQ1MDA5NDAgNjc2OTg3MDMgNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2 OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21h bi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QXV0aG9ycyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gcHJlcGFyaW5nIHRoZSB3 cml0ZXVwLCBjYW4gSSBoYXZlIHlvdXIgcmVzcG9uc2UgZm9yIHRoZSBmb2xsb3dpbmcgcXVlc3Rp b24/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCEtLVtpZiAhc3VwcG9y dExpc3RzXS0tPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgZm9udC1zaXplOiA3cHQ7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJzsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPkNhbiBlYWNoIGF1dGhvciBjb25maXJtIGlm IHRoZXJlIGlzIGFueSBJUFIgZmlsZWQgdGhhdCBpcyByZWxhdGVkIHRvIHRoaXMgZHJhZnQ/PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1 aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RllJLCBmb3Vu ZCBhIHR5cG86IGluIOKAnEFic3RyYWN04oCdIGxpbmUgMywgT1NGUHYyID0mZ3Q7IE9TUEZ2Mjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RllJIDIsIG15IElFVEYgYWNjb3Vu dCBJRCBpcyA8YSBocmVmPSJtYWlsdG86d2VuaHUubHVAZ21haWwuY29tIj4NCndlbmh1Lmx1QGdt YWlsLmNvbTwvYT4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi13ZW5odTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D32F342D58B22aceeciscocom_-- From nobody Sun Apr 10 09:08:08 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DFA12D5FE for ; Sun, 10 Apr 2016 09:08:06 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-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 evwUr_D54FtM for ; Sun, 10 Apr 2016 09:08:04 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE44E12D5FC for ; Sun, 10 Apr 2016 09:08:04 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-75-570a7a3cf666 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 11.87.22441.C3A7A075; Sun, 10 Apr 2016 18:07:25 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0248.002; Sun, 10 Apr 2016 12:08:03 -0400 From: Uma Chunduri To: Peter Psenak , prz Thread-Topic: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment" Thread-Index: AQHRf/Ho6WRxQA5zQE2bUJRokiTbP59dC0kggAByIYCAAMx3AIAhPlUAgACbLYCAA2GjoA== Date: Sun, 10 Apr 2016 16:08:02 +0000 Message-ID: <1B502206DFA0C544B7A6046915200863580107CE@eusaamb105.ericsson.se> References: <56EA5A23.6020807@cisco.com> <3fc89c87056187cfa0908a07ed4c9850@zeta2.ch> <1B502206DFA0C544B7A604691520086358001503@eusaamb106.ericsson.se> <57076ACF.8070608@cisco.com> In-Reply-To: <57076ACF.8070608@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZXLonUNe2iivcYN0kRouWe/fYLXbsbmez uNf1mNWB2WPK742sHkuW/GTy+LHsD3MAcxSXTUpqTmZZapG+XQJXxoG3d5kLZphUvNy6gr2B 8Y1RFyMnh4SAicSyvyfYIWwxiQv31rN1MXJxCAkcZZRY+voWM4SznFHi/LSLTCBVbAJ6Eh+n /gTrEBGwkDi24i4ziM0soCBx7eItoG4ODmGBVIkJZ6whStIkvmydwQhhh0n8mLwZrJxFQFVi 8aSpYCN5BXwlup5MY4TYNYVJ4sWUj2DzOQU0JT6232UBsRmBrvt+ag0TxC5xiVtP5jNBXC0g sWTPeWYIW1Ti5eN/rBC2ksTH3/PZQe5hBpqzfpc+RKuixJTuh+wQewUlTs58wjKBUWwWkqmz EDpmIemYhaRjASPLKkaO0uKCnNx0I8NNjMC4OSbB5riDcW+v5yFGAQ5GJR7ehGrOcCHWxLLi ytxDjBIczEoivF8SucKFeFMSK6tSi/Lji0pzUosPMUpzsCiJ83pH/gsTEkhPLEnNTk0tSC2C yTJxcEo1MJqYV3dtO32wxSB4m+jsPQodsaZhBgKlqdf54iYsN81aWfpfqlLmVNm73kUSDEIL 15x9OcctT1boxpMSl2xPxjevrrhuXVr6RUdDb7eeds7yT2tmJ4tUPrb77HRItEzXwYFjzmar yeGCKzmkv8X9uiXGmfH+soTDgm02d2clWsod47ibFRE4U4mlOCPRUIu5qDgRAJeSY6SXAgAA Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 16:08:06 -0000 SGkgUGV0ZXIsDQoNCkkgd291bGQgcmUtY2xhcmlmeSBvbiB0aGUgcG9pbnQgeW91IHJhaXNlZCBi ZWxvdy4NCk15IHJlc3BvbnNlIGluLWxpbmUgW1VtYV06DQoNCi0tDQpVbWEgQy4NCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBldGVyIFBzZW5hayBbbWFpbHRvOnBwc2VuYWtA Y2lzY28uY29tXSANClNlbnQ6IEZyaWRheSwgQXByaWwgMDgsIDIwMTYgMToyNSBBTQ0KVG86IFVt YSBDaHVuZHVyaTsgcHJ6DQpDYzogT1NQRiBXRyBMaXN0DQpTdWJqZWN0OiBSZTogW09TUEZdIFdH IEFkb3B0aW9uIFBvbGwgZm9yICJVc2luZyBPcGVyYXRvci1kZWZpbmVkIFRMVnMgZm9yIEFnaWxl IFNlcnZpY2UgRGVwbG95bWVudCINCg0KSGkgVW1hLA0KDQpJIHN0aWxsIGhhdmUgYSBmdW5kYW1l bnRhbCBwcm9ibGVtIHdpdGggbGVhdmluZyB0aGUgc3ViLVRMViBkZWZpbml0aW9uIHRvIHRoZSBv cGVyYXRvci4gSWYgdGhlIG9wZXJhdG9yIHJlYWxseSB3YW50cyB0byBkbyBkZWZpbmUgc29tZXRo aW5nIHByb3ByaWV0YXJ5LCB3ZSBoYXZlIHBsZW50eSBvZiBleHBlcmltZW50YWwvcmVzZXJ2ZWQg Y29kZSBwb2ludHMgaW4gUkkgVExWIHNwYWNlLg0KDQpbVW1hXTogVGhpcyB3b3VsZCBlbmFibGUg dmVuZG9yIGFnbm9zdGljIGFwcHJvYWNoIHRvIHByb3Zpc2lvbiBhIGxvY2FsIHBvbGljeSAoIHN1 Yi10bHYgY29kZSBwb2ludCAmIGFzc29jaWF0ZWQgZGF0YSBpbiBOQk8pIHRvIGFkdmVydGlzZSBp biBPU1BGIGRvbWFpbi4gSSBkb24ndCB0aGluayB0aGlzIGNhbiBiZSBhY2hpZXZlZCBpbiBhIHN0 cnVjdHVyZWQgZmFzaGlvbiB3aXRoIGV4cGVyaW1lbnRhbCBUTFYuICBTbyB0aGlzIHdvdWxkIGhl bHAgZ2l2ZSBhIHN0cnVjdHVyZWQgaW5mb3JtYXRpb24gZm9yIHRoZSBkYXRhIHdoaWNoIGlzIGRl cGxveW1lbnQgc3BlY2lmaWMgYnV0IHZlbmRvciBuZXV0cmFsIGltcGxlbWVudGF0aW9uLg0KDQpJ IGp1c3QgZG9uJ3Qgc2VlIGEgcG9pbnQgb2Ygc3RhbmRhcmRpemluZyBhIGNvbnRhaW5lciB0aGF0 IGlzIHVzZWQgdG8gYWR2ZXJ0aXNlIHByb3ByaWV0YXJ5IHN1Yi1UTFZzLg0KDQp0aGFua3MsDQpQ ZXRlcg0KDQoNCk9uIDQvOC8xNiAwNTowOSAsIFVtYSBDaHVuZHVyaSB3cm90ZToNCj4gVG9ueSwg IFBldGVyLA0KPg0KPiBBbHNvICBwbGVhc2Ugbm90ZSB0aGUgZm9sbG93aW5nIGNoYW5nZXMgYXJl IG1hZGUgcGVyIGxhc3QgV0cgQWRvcHRpb24gY2FsbDoNCj4NCj4gMS4gICIgRGlzc2VtaW5hdGlv biBvZiBkeW5hbWljIGluZm9ybWF0aW9uIiBJbmZvcm1hdGlvbiBpcyByZW1vdmVkIGxpa2UgbG9j YXRpb24gaW5mb3JtYXRpb24gZm9yIE1vYmlsZSBPU1BGIHJvdXRlcnMuCQ0KPg0KPiAyLiBTZWN0 aW9uIDMgLSBBcHBsaWNhYmlsaXR5IGhhcyBiZWVuIGFkZGVkDQo+DQo+IDMuIFNlY3Rpb24gNiBM YXN0IHBhcmFncmFwaCBoYXMgYmVlbiBhZGRlZCBjbGFyaWZ5aW5nIGluZm9ybWF0aW9uIGFib3V0 IHRyYW5zcG9ydCBpbnN0YW5jZSB1c2FnZS4NCj4NCj4gLS0NCj4gVW1hIEMuDQo+DQo+DQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE9TUEYgW21haWx0bzpvc3BmLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBwcnoNCj4gU2VudDogVGh1cnNkYXksIE1hcmNoIDE3 LCAyMDE2IDEyOjMwIFBNDQo+IFRvOiBQZXRlciBQc2VuYWsNCj4gQ2M6IE9TUEYgV0cgTGlzdA0K PiBTdWJqZWN0OiBSZTogW09TUEZdIFdHIEFkb3B0aW9uIFBvbGwgZm9yICJVc2luZyBPcGVyYXRv ci1kZWZpbmVkIFRMVnMgZm9yIEFnaWxlIFNlcnZpY2UgRGVwbG95bWVudCINCj4NCj4NCj4gICAr MSB0byBQZXRlcidzLCBMZXMncyBvcGluaW9uIGhlcmUgKGFzIGluZGl2aWR1YWwsIG5vIGhhdCwg bm90IGV2ZW4gYSAgc3VyZ2ljYWwgbWFzaywgQWNlZSA7LSkgLi4uDQo+DQo+ICAgLS0tIHRvbnkN Cj4NCj4NCj4gICBPbiBUaHUsIDE3IE1hciAyMDE2IDA4OjE3OjU1ICswMTAwLCBQZXRlciBQc2Vu YWsgPHBwc2VuYWtAY2lzY28uY29tPg0KPiAgIHdyb3RlOg0KPj4gSSBhZ3JlZSB3aXRoIExlcyBh bmQgc2hhcmUgdGhlIHNhbWUgY29uY2VybnMuDQo+Pg0KPj4gUGV0ZXINCj4+DQo+PiBPbiAzLzE3 LzE2IDA1OjQwICwgTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgd3JvdGU6DQo+Pj4gTXkgb3Bpbmlv biBvZiB0aGUgZHJhZnQgaGFzIG5vdCBjaGFuZ2VkLg0KPj4+DQo+Pj4gSXQgaXMgZGVmaW5pbmcg YSB3YXkgdG8gdXRpbGl6ZSBPU1BGIHRvIHNlbmQgYXBwbGljYXRpb24gaW5mb3JtYXRpb24NCj4+ PiAtIHdoaWNoIGlzIG5vdCBzb21ldGhpbmcgdGhlIHByb3RvY29sIHNob3VsZCBiZSB1c2VkIHRv IGRvLg0KPj4+IEZ1cnRoZXIsIGl0IGxlYXZlcyBkZWZpbml0aW9uIG9mIHRoZSBuZXcgY29kZXBv aW50cyBhbmQgZm9ybWF0cyBvZiANCj4+PiB0aGUgaW5mb3JtYXRpb24gYWR2ZXJ0aXNlZCBjb21w bGV0ZWx5IHVuc3BlY2lmaWVkIC0gdGhlIGxhdGVzdCBkcmFmdCANCj4+PiByZXZpc2lvbiBzdGF0 ZXM6DQo+Pj4NCj4+PiAiIFRoZSBtZWFuaW5nIG9mIHRoZSBvcGVyYXRvci1kZWZpbmVkIHN1Yi1U TFYgaXMgdG90YWxseSBvcGFxdWUgdG8gDQo+Pj4gT1NQRg0KPj4+ICAgICAgYW5kIGlzIGRlZmlu ZWQgYnkgdGhlIG5ldHdvcmsgbG9jYWwgcG9saWN5IGFuZCBpcyBjb250cm9sbGVkIHZpYQ0KPj4+ ICAgICAgY29uZmlndXJhdGlvbi4gICINCj4+Pg0KPj4+IEhvdyBpbnRlcm9wZXJhYmlsaXR5IGlz IGFjaGlldmVkIGlzIG5vdCBhZGRyZXNzZWQgYXQgYWxsLg0KPj4+DQo+Pj4gSVMtSVMgaGFzIHRh a2VuIGEgbXVjaCBtb3JlIHN0cmluZ2VudCBhcHByb2FjaCB0byBhIHNpbWlsYXIgcmVxdWVzdC4N Cj4+PiBSRkMgNjgyMyAoR0VOQVBQKSByZXF1aXJlcyB0aGF0IGluZm9ybWF0aW9uIHNlbnQgaW4g dGhlIGdlbmVyaWMgDQo+Pj4gY29udGFpbmVyIFRMViBNVVNUIGJlIGJhc2VkIG9uIGEgcHVibGlj IHNwZWNpZmljYXRpb24gLSBhbmQgdGhhdCBhbiANCj4+PiBhcHBsaWNhdGlvbiBzcGVjaWZpYyBJ RCBmb3IgdGhlIGFwcGxpY2F0aW9uIHVzaW5nIHRoaXMgbWVjaGFuaXNtIGJlIA0KPj4+IGFzc2ln bmVkIGJ5IElBTkEuIFRoaXMgYWRkcmVzc2VzIHRoZSBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlLg0K Pj4+IEdFTkFQUCBmdXJ0aGVyIHNwZWNpZmllcyB0aGF0IHN1Y2ggaW5mb3JtYXRpb24gU0hPVUxE IGJlIGFkdmVydGlzZWQgDQo+Pj4gYnkgYSBzZXBhcmF0ZSBpbnN0YW5jZSBvZiB0aGUgcm91dGlu ZyBwcm90b2NvbCAoYXMgc3BlY2lmaWVkIGluIFJGQw0KPj4+IDY4MjIoTUkpKSBzbyBhcyB0byBt aW5pbWl6ZSB0aGUgaW1wYWN0IG9mIHRoZSBhcHBsaWNhdGlvbiANCj4+PiBpbmZvcm1hdGlvbiBm bG9vZGluZyBvbiB0aGUgcGVyZm9ybWFuY2Ugb2YgdGhlIHJvdXRpbmcgcHJvdG9jb2wuDQo+Pj4N Cj4+PiBXaXRob3V0IGFkZHJlc3NpbmcgYm90aCBvZiB0aGVzZSBpc3N1ZXMgSSBjYW5ub3Qgc3Vw cG9ydCB0aGUgZHJhZnQuDQo+Pj4NCj4+PiAgICAgIExlcw0KPj4+DQo+Pj4NCj4+Pj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogT1NQRiBbbWFpbHRvOm9zcGYtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFjZWUgTGluZGVtDQo+Pj4+IChhY2VlKQ0KPj4+PiBT ZW50OiBXZWRuZXNkYXksIE1hcmNoIDE2LCAyMDE2IDc6MDkgUE0NCj4+Pj4gVG86IE9TUEYgV0cg TGlzdA0KPj4+PiBTdWJqZWN0OiBbT1NQRl0gV0cgQWRvcHRpb24gUG9sbCBmb3IgIlVzaW5nIE9w ZXJhdG9yLWRlZmluZWQgVExWcyANCj4+Pj4gZm9yIEFnaWxlIFNlcnZpY2UgRGVwbG95bWVudCIN Cj4+Pj4NCj4+Pj4gV2XigJl2ZSBkaXNjdXNzZWQgdGhpcyBkcmFmdCBhIG51bWJlciBvZiB0aW1l cy4gSW4gbXkgb3BpbmlvbiwgaXQgDQo+Pj4+IHNlZW1zIGxpa2UgYSB1c2VmdWwgbWVjaGFuaXNt IGlmIG9uZSBlbnZpc2lvbnMgYSBnZW5lcmFsaXplZCBBUEkgDQo+Pj4+IGJldHdlZW4gT1NQRiBh bmQgdXNlciBhbmQgdGhpcmQtcGFydHkgYXBwbGljYXRpb25zIHRvIGNvbnZleSANCj4+Pj4gYXBw bGljYXRpb24tc3BlY2lmaWMgaW5mb3JtYXRpb24gbGVhcm5lZCBmcm9tIG90aGVyIE9TUEYgcm91 dGVycy4gDQo+Pj4+IEluIG1hbnkgcmVzcGVjdHMsIHRoaXMgaGFzIGFscmVhZHkgYmVlbiBlbnZp c2lvbmVkIGZvciBPU1BGIE5vZGUgVGFncy4NCj4+Pj4gUGxlYXNlIGluZGljYXRlIHlvdXIgb3Bp bmlvbiBvbiB0aGlzIGRyYWZ0IGJlZm9yZSBNYXJjaCAzMXN0LCAyMDE2Lg0KPj4+Pg0KPj4+PiBU aGFua3MsDQo+Pj4+IEFjZWUNCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+Pj4gT1NQRiBtYWlsaW5nIGxpc3QNCj4+Pj4gT1NQRkBp ZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29zcGYN Cj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ IE9TUEYgbWFpbGluZyBsaXN0DQo+Pj4gT1NQRkBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb3NwZg0KPj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IE9TUEYgbWFpbGluZyBsaXN0DQo+ PiBPU1BGQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29zcGYNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gT1NQRiBtYWlsaW5nIGxpc3QNCj4gT1NQRkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29zcGYNCj4NCg0K From nobody Sun Apr 10 14:56:50 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360F012D150 for ; Sun, 10 Apr 2016 14:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 42XmmaJ4jJSA for ; Sun, 10 Apr 2016 14:56:48 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 251EF12D104 for ; Sun, 10 Apr 2016 14:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=490; q=dns/txt; s=iport; t=1460325407; x=1461535007; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=5g1H4EfG/gGVYhRBTir5gcMsDjH1kA8hiitufbIrKwo=; b=Mm7eedFrOlCoQMda8A8uXQF+XwqyIRFaoT92KoiL4HTNIK2j8anC+x/2 6cmU91iSn8rzHNBrp3Gfmd8O7xrIZ6sQNQjD/3rMZzc/88qBddAOHkqVJ w2Ikv44jQCMp98pCeCZsa2mly6AkZTS/Gmt7hByufJXcgp0BUdzQieHD3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAgAQywpX/49dJa1cgyEIDlOBA7hBg?= =?us-ascii?q?g8BDYFzIYYKgQY4FAEBAQEBAQFlJ4Q6DiMRVwEiAiYCBDAVEgSFXAeCVw6bHY9?= =?us-ascii?q?djRqEGwEBAQEGAQEBAQEBFgR8kS+CVgWYBAGOC4FRARWETYhZhh+JBgEeAQFCg?= =?us-ascii?q?2eKGX4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,462,1454976000"; d="scan'208";a="95621497" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2016 21:56:47 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u3ALukWS013537 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sun, 10 Apr 2016 21:56:47 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 10 Apr 2016 17:56:46 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Sun, 10 Apr 2016 17:56:46 -0400 From: "Acee Lindem (acee)" To: OSPF WG List Thread-Topic: OSPF WG Minutes from IETF 95 Thread-Index: AQHRk3PgRnVqmNZNrEiwg2kB/ZG01A== Date: Sun, 10 Apr 2016 21:56:46 +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.202] Content-Type: text/plain; charset="utf-8" Content-ID: <70CFFE7F3490E44697590457D308C7DF@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [OSPF] OSPF WG Minutes from IETF 95 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 21:56:49 -0000 VGhlIG1pbnV0ZXMgZm9yIGFyZSBwb3N0ZWQgaGVyZToNCmh0dHBzOi8vd3d3LmlldGYub3JnL3By b2NlZWRpbmdzLzk1L21pbnV0ZXMvbWludXRlcy05NS1vc3BmDQoNClRoYW5rcyB0byBMZXMgR2lu c2JlcmcgZnJvbSBDaXNjbyBmb3IgdGFraW5nIHRoZW0uDQoNCk5vdGUgdGhhdCB0aGVyZSB3ZXJl IHR3byBuYW1lcyB0aGF0IHdlIHdlcmUgbm90IHN1cmUgb2YgYW5kIHRoZXkgYXJlDQpwcmVjZWRl ZCB3aXRoIOKAnCg/Pz8p4oCdLiBQbGVhc2UgRS1tYWlsIG1lIGlmIHlvdSBrbm93IGVpdGhlciBv ZiB0aGVzZSBmdWxsDQpuYW1lcyBhbmQgSSB3aWxsIHVwZGF0ZSB0aGUgbWludXRlcy4NCg0KVGhh bmtzLA0KQWNlZSANCg0K From nobody Mon Apr 11 05:13:50 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9B712ED48 for ; Mon, 11 Apr 2016 05:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.918 X-Spam-Level: X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982] 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 DxETdLazgQu9 for ; Mon, 11 Apr 2016 05:13:47 -0700 (PDT) Received: from zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id F164B12ED49 for ; Mon, 11 Apr 2016 05:13:44 -0700 (PDT) Received: from www.zeta2.ch (localhost [127.0.0.1]) (Authenticated sender: prz) by zeta2.ch (Postfix) with ESMTPA id 681631FB3D; Mon, 11 Apr 2016 14:13:36 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 11 Apr 2016 05:13:36 -0700 From: prz To: "Acee Lindem (acee)" In-Reply-To: References: Message-ID: <04479c8fba16697eb3a51ea89d0cd708@zeta2.ch> X-Sender: prz@zeta2.ch User-Agent: Roundcube Webmail/0.4.2 X-MailScanner-ID: 681631FB3D.AF086 X-MailScanner: Found to be clean X-MailScanner-SpamScore: s X-MailScanner-From: prz@zeta2.ch Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] OSPF WG Minutes from IETF 95 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 12:13:49 -0000 On Sun, 10 Apr 2016 21:56:46 +0000, "Acee Lindem (acee)" wrote: > The minutes for are posted here: > https://www.ietf.org/proceedings/95/minutes/minutes-95-ospf > > Thanks to Les Ginsberg from Cisco for taking them. > > Note that there were two names that we were not sure of and they are > preceded with “(???)â€. Please E-mail me if you know either of these > full > names and I will update the minutes. > hmm, reading minutes & grinning, wasn't that you that chided me on the mike 2-3 IETFs ago with "by now since 10 years e'one got the max-link-metric stuff right" ;-) Agree on the comment with the bandwidth encoding. No need to invent another one. --- tony From nobody Mon Apr 11 06:45:04 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6107112EEC6; Mon, 11 Apr 2016 06:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=kuatrotechnology.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 rFA0lnwOV4H8; Mon, 11 Apr 2016 06:45:01 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0696.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::696]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0B012EEC5; Mon, 11 Apr 2016 06:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kuatrotechnology.onmicrosoft.com; s=selector1-kuatrotech-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=j3tlhwl8m9Ry3tORhKiF4zyzIGKXk1hvka2YTIebjOI=; b=eYRuZRyZ4zY6dFepUMYpwp/OPfF1FL+Xy1bXI2BYPDXKRPrUwe4Eu0NNLYMq5FllcJVkjUwDSDRWQd60FzmvgbrYI+eBGqBL6Z7H71HMJGnGJFE39zXC0m0f5CxKCSawQyAl4uLeU/U482v3NjP8qRLtNELi9RLapZj8riqEveI= Received: from DB5PR06MB0950.eurprd06.prod.outlook.com (10.162.158.140) by DB5PR06MB0949.eurprd06.prod.outlook.com (10.162.158.14) with Microsoft SMTP Server (TLS) id 15.1.453.26; Mon, 11 Apr 2016 13:44:44 +0000 Received: from DB5PR06MB0950.eurprd06.prod.outlook.com ([10.162.158.140]) by DB5PR06MB0950.eurprd06.prod.outlook.com ([10.162.158.140]) with mapi id 15.01.0453.029; Mon, 11 Apr 2016 13:44:43 +0000 From: "Ing-Wher (Helen) Chen" To: "Acee Lindem (acee)" , Wenhu Lu , "draft-ietf-ospf-transition-to-ospfv3.authors@ietf.org" Thread-Topic: IPR disclosure Thread-Index: AdGSBKaJNnZ6kUDDT72rWQu4fT1MkwAzSrmAAEmV3fA= Date: Mon, 11 Apr 2016 13:44:43 +0000 Message-ID: References: <360AE91BC9ADBF4698AA2D37D392EC62228F92F6@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=kuatrotech.com; x-originating-ip: [98.191.72.170] x-ms-office365-filtering-correlation-id: 30fab468-86c7-4adf-3284-08d3620f7040 x-microsoft-exchange-diagnostics: 1; DB5PR06MB0949; 5:aWRQHqpBAVqmzSV7Co4rf7uOIpwYepK3Vfa0I4mxBMeUSKzQA5lHmAC4a7GFtrjcW2frm7OjR8UgqEnLnUL1H5mxX3taB6gDIX8lS6rGaSXyQdRPG0GEi0v9JQP2Iwsld7Fv8IcgMMdgVFe2QJly/w==; 24:MAFH0Bvuq2TgyC7xcZblO8ki177H13rh+Qkw5LIsT2soo0jVShvHYLhVNzJuy0/BgVA+hNaPDEVh6gNlk53YUb82vo8txtFN7CMmkGJNEs4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR06MB0949; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040074)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041046)(6043046); SRVR:DB5PR06MB0949; BCL:0; PCL:0; RULEID:; SRVR:DB5PR06MB0949; x-forefront-prvs: 09090B6B69 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(69234005)(377424004)(377454003)(33656002)(50986999)(76176999)(5008740100001)(10400500002)(221733001)(19617315012)(19625215002)(4326007)(122556002)(5004730100002)(54356999)(19609705001)(19300405004)(2501003)(87936001)(3280700002)(76576001)(3660700001)(3480700003)(2900100001)(5003600100002)(74316001)(2950100001)(77096005)(15975445007)(19580405001)(19580395003)(5002640100001)(6116002)(102836003)(790700001)(3846002)(2906002)(1096002)(1220700001)(9686002)(66066001)(81166005)(164054004)(92566002)(16236675004)(189998001)(86362001)(586003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR06MB0949; H:DB5PR06MB0950.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR06MB095005F5BC643DA81AEF7940D0940DB5PR06MB0950eurp_" MIME-Version: 1.0 X-OriginatorOrg: kuatrotech.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2016 13:44:43.5563 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 99314f4e-50ab-4d4e-a9c6-b21b0c887384 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR06MB0949 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] IPR disclosure X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 13:45:03 -0000 --_000_DB5PR06MB095005F5BC643DA81AEF7940D0940DB5PR06MB0950eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgV2VuaHUgKERvY3VtZW50IFNoZXBoZXJkKSwNCg0KSeKAmW0gbm90IGF3YXJlIG9mIGFueSBJ UFIuDQoNCkkgYWxzbyB1cGRhdGVkIHRoZSBkcmFmdCB0byBmaXggdGhlIHR5cG8gaW4gdGhlIGFi c3RyYWN0Lg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1vc3BmLXRyYW5zaXRp b24tdG8tb3NwZnYzLTA0LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBJ LiBDaGVuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAg ICAgICAgICAgICBkcmFmdC1pZXRmLW9zcGYtdHJhbnNpdGlvbi10by1vc3BmdjMNClJldmlzaW9u OiAgICAgICAgICAgICAgMDQNClRpdGxlOiAgICAgICAgICAgICAgICAgICAgICBPU1BGdjMgb3Zl ciBJUHY0IGZvciBJUHY2IFRyYW5zaXRpb24NCkRvY3VtZW50IGRhdGU6ICAgICAgICAgICAgICAg MjAxNi0wNC0xMQ0KR3JvdXA6ICAgICAgICAgICAgICAgICAgb3NwZg0KUGFnZXM6ICAgICAgICAg ICAgICAgICAgIDkNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtaWV0Zi1vc3BmLXRyYW5zaXRpb24tdG8tb3NwZnYzLTA0LnR4dA0KU3Rh dHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt b3NwZi10cmFuc2l0aW9uLXRvLW9zcGZ2My8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vc3BmLXRyYW5zaXRpb24tdG8tb3NwZnYzLTA0DQpE aWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtb3NwZi10cmFuc2l0aW9uLXRvLW9zcGZ2My0wNA0KDQpUaGFua3MsDQpIZWxlbg0KDQoNCkZy b206IEFjZWUgTGluZGVtIChhY2VlKSBbbWFpbHRvOmFjZWVAY2lzY28uY29tXQ0KU2VudDogU2F0 dXJkYXksIEFwcmlsIDksIDIwMTYgMTA6MzcgUE0NClRvOiBXZW5odSBMdSA8d2VuaHUubHVAZXJp Y3Nzb24uY29tPjsgZHJhZnQtaWV0Zi1vc3BmLXRyYW5zaXRpb24tdG8tb3NwZnYzLmF1dGhvcnNA aWV0Zi5vcmcNCkNjOiBPU1BGIFdHIExpc3QgPG9zcGZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog SVBSIGRpc2Nsb3N1cmUNCg0KSGkgV2VuaHUgKERvY3VtZW50IFNoZXBoZXJkKSwNCkkgYW0gbm90 IGF3YXJlIG9mIGFueSBJUFIuDQpUaGFua3MsDQpBY2VlDQoNCkZyb206IFdlbmh1IEx1IDx3ZW5o dS5sdUBlcmljc3Nvbi5jb208bWFpbHRvOndlbmh1Lmx1QGVyaWNzc29uLmNvbT4+DQpEYXRlOiBG cmlkYXksIEFwcmlsIDgsIDIwMTYgYXQgMTE6MDggUE0NClRvOiAiZHJhZnQtaWV0Zi1vc3BmLXRy YW5zaXRpb24tdG8tb3NwZnYzLmF1dGhvcnNAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtb3Nw Zi10cmFuc2l0aW9uLXRvLW9zcGZ2My5hdXRob3JzQGlldGYub3JnPiIgPGRyYWZ0LWlldGYtb3Nw Zi10cmFuc2l0aW9uLXRvLW9zcGZ2My5hdXRob3JzQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRm LW9zcGYtdHJhbnNpdGlvbi10by1vc3BmdjMuYXV0aG9yc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBJ UFIgZGlzY2xvc3VyZQ0KDQpBdXRob3JzLA0KDQpJbiBwcmVwYXJpbmcgdGhlIHdyaXRldXAsIGNh biBJIGhhdmUgeW91ciByZXNwb25zZSBmb3IgdGhlIGZvbGxvd2luZyBxdWVzdGlvbj8NCg0KMS4g ICAgICAgQ2FuIGVhY2ggYXV0aG9yIGNvbmZpcm0gaWYgdGhlcmUgaXMgYW55IElQUiBmaWxlZCB0 aGF0IGlzIHJlbGF0ZWQgdG8gdGhpcyBkcmFmdD8NCg0KRllJLCBmb3VuZCBhIHR5cG86IGluIOKA nEFic3RyYWN04oCdIGxpbmUgMywgT1NGUHYyID0+IE9TUEZ2Mg0KRllJIDIsIG15IElFVEYgYWNj b3VudCBJRCBpcyB3ZW5odS5sdUBnbWFpbC5jb208bWFpbHRvOndlbmh1Lmx1QGdtYWlsLmNvbT4N Cg0KVGhhbmsgeW91LA0KLXdlbmh1DQoNCg== --_000_DB5PR06MB095005F5BC643DA81AEF7940D0940DB5PR06MB0950eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1i b3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTkzNDkw MDAyNTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTI4 NDUwMDk0MCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTku MHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgV2VuaHUgKERvY3Vt ZW50IFNoZXBoZXJkKSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmW0gbm90IGF3YXJlIG9m IGFueSBJUFIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyB1cGRhdGVkIHRoZSBkcmFm dCB0byBmaXggdGhlIHR5cG8gaW4gdGhlIGFic3RyYWN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1vc3BmLXRyYW5zaXRpb24tdG8tb3Nw ZnYzLTA0LnR4dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBJLiBDaGVuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYg cmVwb3NpdG9yeS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmFtZTombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtaWV0Zi1vc3BmLXRyYW5zaXRpb24t dG8tb3NwZnYzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZXZpc2lvbjom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMDQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRpdGxlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPU1BGdjMgb3ZlciBJUHY0IGZvciBJUHY2IFRyYW5zaXRp b248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvY3VtZW50IGRhdGU6Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIwMTYtMDQtMTE8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkdyb3VwOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBvc3BmPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QYWdl czombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iU1YiPlVSTDom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1pZXRmLW9zcGYtdHJhbnNpdGlvbi10by1vc3BmdjMtMDQudHh0Ij48c3BhbiBs YW5nPSJTViI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYt b3NwZi10cmFuc2l0aW9uLXRvLW9zcGZ2My0wNC50eHQ8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IlNW Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJTViI+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1vc3BmLXRyYW5zaXRpb24tdG8tb3NwZnYzLyI+PHNwYW4gbGFuZz0iU1YiPmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb3NwZi10cmFuc2l0aW9uLXRv LW9zcGZ2My88L3NwYW4+PC9hPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJTViI+SHRtbGl6ZWQ6Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vc3BmLXRyYW5zaXRpb24tdG8tb3NwZnYzLTA0Ij48 c3BhbiBsYW5nPSJTViI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3Nw Zi10cmFuc2l0aW9uLXRvLW9zcGZ2My0wNDwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iU1YiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRpZmY6Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9zcGYtdHJhbnNp dGlvbi10by1vc3BmdjMtMDQiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWlldGYtb3NwZi10cmFuc2l0aW9uLXRvLW9zcGZ2My0wNDwvYT48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVs ZW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBBY2VlIExpbmRlbSAoYWNlZSkgW21haWx0bzph Y2VlQGNpc2NvLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBBcHJpbCA5LCAyMDE2 IDEwOjM3IFBNPGJyPg0KPGI+VG86PC9iPiBXZW5odSBMdSAmbHQ7d2VuaHUubHVAZXJpY3Nzb24u Y29tJmd0OzsgZHJhZnQtaWV0Zi1vc3BmLXRyYW5zaXRpb24tdG8tb3NwZnYzLmF1dGhvcnNAaWV0 Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IE9TUEYgV0cgTGlzdCAmbHQ7b3NwZkBpZXRmLm9yZyZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IElQUiBkaXNjbG9zdXJlPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6YmxhY2siPkhpIFdlbmh1IChEb2N1bWVudCBTaGVwaGVyZCksJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkkgYW0gbm90IGF3YXJlIG9m IGFueSBJUFIuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6Ymxh Y2siPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+ QWNlZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTog PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPldlbmh1IEx1ICZsdDs8YSBocmVm PSJtYWlsdG86d2VuaHUubHVAZXJpY3Nzb24uY29tIj53ZW5odS5sdUBlcmljc3Nvbi5jb208L2E+ Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEFwcmlsIDgsIDIwMTYgYXQgMTE6MDggUE08 YnI+DQo8Yj5UbzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW9zcGYtdHJh bnNpdGlvbi10by1vc3BmdjMuYXV0aG9yc0BpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1vc3BmLXRyYW5z aXRpb24tdG8tb3NwZnYzLmF1dGhvcnNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86ZHJhZnQtaWV0Zi1vc3BmLXRyYW5zaXRpb24tdG8tb3NwZnYzLmF1dGhvcnNAaWV0Zi5v cmciPmRyYWZ0LWlldGYtb3NwZi10cmFuc2l0aW9uLXRvLW9zcGZ2My5hdXRob3JzQGlldGYub3Jn PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+SVBSIGRpc2Nsb3N1cmU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0 OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluIiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxP Q0tRVU9URSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+QXV0aG9ycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ SW4gcHJlcGFyaW5nIHRoZSB3cml0ZXVwLCBjYW4gSSBoYXZlIHlvdXIgcmVzcG9uc2UgZm9yIHRo ZSBmb2xsb3dpbmcgcXVlc3Rpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Q2FuIGVhY2ggYXV0aG9yIGNvbmZpcm0gaWYgdGhlcmUgaXMgYW55IElQUiBmaWxl ZCB0aGF0IGlzIHJlbGF0ZWQgdG8gdGhpcyBkcmFmdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW4iPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5GWUksIGZvdW5kIGEgdHlwbzogaW4g 4oCcQWJzdHJhY3TigJ0gbGluZSAzLCBPU0ZQdjIgPSZndDsgT1NQRnYyPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5G WUkgMiwgbXkgSUVURiBhY2NvdW50IElEIGlzIDxhIGhyZWY9Im1haWx0bzp3ZW5odS5sdUBnbWFp bC5jb20iPg0Kd2VuaHUubHVAZ21haWwuY29tPC9hPiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+VGhhbmsgeW91LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+LXdlbmh1PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB5PR06MB095005F5BC643DA81AEF7940D0940DB5PR06MB0950eurp_-- From nobody Mon Apr 11 08:00:53 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C015C12D758 for ; Mon, 11 Apr 2016 08:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jakma-org.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 VDfgmeclpMlJ for ; Mon, 11 Apr 2016 08:00:50 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F1412D136 for ; Mon, 11 Apr 2016 08:00:49 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id f198so149564903wme.0 for ; Mon, 11 Apr 2016 08:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jakma-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=sKTwrByePjGDdgH//WBenNXtD9NiJocojvMVq97FA1o=; b=t6PO29R+CmuZSgbZynAyp08awdCbuKbLb5PqWG/OUvXtAR8yPWpt2W/Ol0RxJV1/v8 JJpFiVOmZqi4VcaEHaxiIX562BkKwg3r7UJYWCBYRFPQp4FCwJdWz4+tWeRV4bUW2gLA zxxrLluhunLf1dIUD6wxBqlPluahzGv3pRuclWo7KXGXHufDs0z9zzUGJ93RU28Ai7es LrQqLPFuW+OrHcEy7rr7EmvBZjyy5kaT0ao/UNp+qAFmmp+2DpQr+iif5rzCC0NEjSKG 0US40mQB1tHf8Koy/AqSVIsPZl/38kNDj3OTQ6VNDDj3ljusF8brbXj7vhyxYWLwzrpQ lJvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=sKTwrByePjGDdgH//WBenNXtD9NiJocojvMVq97FA1o=; b=gBP43fsKT3wd5qxVC2IS9q0YqZHCov4AuBZg89BwQTtPI09uG1C0jCWcvOeAgkxcat dKhqPTBddQ9qmppYu8rMEb8+7MOkYp4/ct73qZFmpH0dSevtOo0oIWSKl01f4QIvB7hl sNjgNMkB3MLwRw7qELvyxuKTGTKutJ8xjIE85NyFSpXBYweYitAPVclkDXX5D+ZlwV/d wrhdQBv/7QWnYYxdfIA4yWyj4mQcx1+RQC1FS3fhBNNwc0mEouetk5OlHE+lR5hp7oPw KkTvJBG6yDx0YF2YSIZUvAqIYkb5GDaapMi0ffO0+PZPDOvDvJJEgIL1sLIllyN8pR+/ wa8A== X-Gm-Message-State: AD7BkJLA9oss2r1M/DW7VYz9ODqCTImNj6+AcWtl7XTrX5+aISBhTl/6X7NPHPkzROnrkA== X-Received: by 10.28.213.142 with SMTP id m136mr19406256wmg.24.1460386847919; Mon, 11 Apr 2016 08:00:47 -0700 (PDT) Received: from stoner.jakma.org (stoner.jakma.org. [81.168.24.42]) by smtp.gmail.com with ESMTPSA id ux5sm28324298wjc.17.2016.04.11.08.00.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Apr 2016 08:00:46 -0700 (PDT) Date: Mon, 11 Apr 2016 16:00:45 +0100 (BST) From: Paul Jakma To: "Acee Lindem (acee)" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) X-Snooper: A life spent reading others private email is a sad and wasted one X-NSA: nitrate toxic DNDO hostage al aqsar fluffy jihad DHS cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt mustard gas x-ray british airways hydrogen washington peroxide cool FEMA emergency four lions encryption ricin table pandemic scanner power sleet catalyst injection acetone X-KEYSCORE: The greatest long-term threats to freedom and democracy are based in Langley and Fort Meade and Cheltenham MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] H-bit Support for OSPFv2 - draft-keyupate-ospf-ospfv2-hbit-01 WG Document Adoption Poll X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 15:00:52 -0000 Hi, Support, and hope this progresses to standards track ASAP. regards, Paul On Sat, 26 Sep 2015, Acee Lindem (acee) wrote: > This draft was presented in Prague and there was consensus in the room > that it was a valid use case. It provides protocol mechanisms to > absolutely prevent transit traffic for OSPFv2 Routers (RFC 6987 only > discourages transit traffic). The draft also includes assurance of > backward compatibility. > > Please indicate your support (or concerns) for adopting this as a WG > Document. > > Thanks, > Acee > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > -- Paul Jakma paul@jakma.org @pjakma Key ID: 64A2FF6A Fortune: A vivid and creative mind characterizes you. From nobody Mon Apr 11 08:29:38 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F116912F08A for ; Mon, 11 Apr 2016 08:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 RFwYUo2crE_X for ; Mon, 11 Apr 2016 08:29:34 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8386F12F088 for ; Mon, 11 Apr 2016 08:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3408; q=dns/txt; s=iport; t=1460388574; x=1461598174; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1kr1nfdv2ZaS3bT3D0YDyIWMTbiN+69FSpgz/7VO5h8=; b=BATjpaSNu8tT6dSuhqyLtCLfm5EWY8KCsKeTIn+lYkv32btQKF/Z8Hhw mm3Gp/W7fkzK6VfI6KXtHHI9axzdawVD4Jy6iliDHHKwXN1lzTqeuTf47 WeHop1/17zbqarwGhNqSz/uvZ6G3fM/xVk9HgO8wuX60XZoCHv91YXn7E I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AxBQCcwQtX/5BdJa1cgzdTfQa4RoIdg?= =?us-ascii?q?XIhgjyDMAIcgRE6EgEBAQEBAQFlJ4RBAQEBAwEjEUUFCwIBCBgCAiYCAgIwFRA?= =?us-ascii?q?CBA4FiB8IDq0OkVsBAQEBAQEBAQEBAQEBAQEBAQEBAQERBHyJcIRVgmqCVgWYB?= =?us-ascii?q?AGFdogVgWeETYhZhh+JBgEnDS6CBBmBSmyJLX4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,462,1454976000"; d="scan'208";a="95887887" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Apr 2016 15:29:33 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u3BFTXp4004274 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Apr 2016 15:29:33 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 11 Apr 2016 11:29:32 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Mon, 11 Apr 2016 11:29:32 -0400 From: "Acee Lindem (acee)" To: prz Thread-Topic: [OSPF] OSPF WG Minutes from IETF 95 Thread-Index: AQHRk+ug+9xkeFSUNUaQhV0sMu+UBZ+E5gwA Date: Mon, 11 Apr 2016 15:29:32 +0000 Message-ID: References: <04479c8fba16697eb3a51ea89d0cd708@zeta2.ch> In-Reply-To: <04479c8fba16697eb3a51ea89d0cd708@zeta2.ch> 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.202] Content-Type: text/plain; charset="utf-8" Content-ID: <420A9D780C54544D9E685E472D609EB5@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] OSPF WG Minutes from IETF 95 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 15:29:37 -0000 DQoNCk9uIDQvMTEvMTYsIDg6MTMgQU0sICJwcnoiIDxwcnpAemV0YTIuY2g+IHdyb3RlOg0KDQo+ IE9uIFN1biwgMTAgQXByIDIwMTYgMjE6NTY6NDYgKzAwMDAsICJBY2VlIExpbmRlbSAoYWNlZSki DQo+IDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQo+PiBUaGUgbWludXRlcyBmb3IgYXJlIHBvc3Rl ZCBoZXJlOg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTUvbWludXRlcy9t aW51dGVzLTk1LW9zcGYNCj4+DQo+PiBUaGFua3MgdG8gTGVzIEdpbnNiZXJnIGZyb20gQ2lzY28g Zm9yIHRha2luZyB0aGVtLg0KPj4NCj4+IE5vdGUgdGhhdCB0aGVyZSB3ZXJlIHR3byBuYW1lcyB0 aGF0IHdlIHdlcmUgbm90IHN1cmUgb2YgYW5kIHRoZXkgYXJlDQo+PiBwcmVjZWRlZCB3aXRoIOKA nCg/Pz8p4oCdLiBQbGVhc2UgRS1tYWlsIG1lIGlmIHlvdSBrbm93IGVpdGhlciBvZiB0aGVzZQ0K Pj4gZnVsbA0KPj4gbmFtZXMgYW5kIEkgd2lsbCB1cGRhdGUgdGhlIG1pbnV0ZXMuDQo+Pg0KPg0K PiBobW0sIHJlYWRpbmcgbWludXRlcyAmIGdyaW5uaW5nLCB3YXNuJ3QgdGhhdCB5b3UgdGhhdCBj aGlkZWQgbWUgb24gdGhlDQo+IG1pa2UgMi0zIElFVEZzIGFnbw0KPiB3aXRoICJieSBub3cgc2lu Y2UgMTAgeWVhcnMgZSdvbmUgZ290IHRoZSBtYXgtbGluay1tZXRyaWMgc3R1ZmYgcmlnaHQiDQo+ IDstKQ0KDQpJIGd1ZXNzIEkgdW5kZXJlc3RpbWF0ZWQgdGhlIGluaGVyZW50IGZhbGxpYmlsaXR5 IG9mIHNvZnR3YXJlIHByb2R1Y2VkIGJ5DQpob21vIHNhcGllbnMgO14pLg0KDQpEYXZpZCBMYW1w YXJ0ZXIgZGlkIHNvbWUgcmVzZWFyY2ggYW5kIGZvdW5kIHRoYXQgUkZDIDEyNDcgKEp1bHksIDE5 OTEpDQphY3R1YWxseSBoYWQgTFNJbmZpbml0eSBkZWZpbmVkIGFzIGEgdmFyaWFibGUgbGVuZ3Ro IGNvbnN0YW50Og0KDQoNCkxTSW5maW5pdHkNCiAgICBUaGUgbGluayBzdGF0ZSBtZXRyaWMgdmFs dWUgaW5kaWNhdGluZyB0aGF0IHRoZSBkZXN0aW5hdGlvbiBpcw0KICAgIHVucmVhY2hhYmxlLiAg SXQgaXMgZGVmaW5lZCB0byBiZSB0aGUgYmluYXJ5IHZhbHVlIG9mIGFsbCBvbmVzLiAgSXQNCiAg ICBkZXBlbmRzIG9uIHRoZSBzaXplIG9mIHRoZSBtZXRyaWMgZmllbGQsIHdoaWNoIGlzIDE2IGJp dHMgaW4gcm91dGVyDQogICAgbGlua3MgYWR2ZXJ0aXNlbWVudHMsIGFuZCAyNCBiaXRzIGluIGJv dGggc3VtbWFyeSBhbmQgQVMgZXh0ZXJuYWwNCiAgICBsaW5rcyBhZHZlcnRpc2VtZW50cy4NCg0K DQpBZGRpdGlvbmFsbHksIHRoZSBsaW5rIHdvdWxkIG5vdCBiZSB1c2VkIGZvciB0cmFuc2l0IHRy YWZmaWMgKHNlY3Rpb24NCjE2LjEpOiANCg0KDQogICAgKGQpIElmIHRoZSBjb3N0IG9mIHRoZSBs aW5rIChmcm9tIFYgdG8gVykgaXMgTFNJbmZpbml0eSwgdGhlIGxpbmsNCiAgICAgICAgc2hvdWxk IG5vdCBiZSB1c2VkIGZvciBkYXRhIHRyYWZmaWMuICBJbiB0aGlzIGNhc2UsIGV4YW1pbmUgdGhl DQogICAgICAgIG5leHQgbGluayBpbiB0aGUgYWR2ZXJ0aXNlbWVudC4NCg0KDQpIb3dldmVyLCB0 aGlzIHdhcyBjaGFuZ2VkIGluIFJGQyAxNTgzIChNYXJjaCwgMTk5NCkuDQoNCiBMU0luZmluaXR5 DQogICAgICAgIFRoZSBtZXRyaWMgdmFsdWUgaW5kaWNhdGluZyB0aGF0IHRoZSBkZXN0aW5hdGlv biBkZXNjcmliZWQgYnkgYQ0KICAgICAgICBsaW5rIHN0YXRlIGFkdmVydGlzZW1lbnQgaXMgdW5y ZWFjaGFibGUuIFVzZWQgaW4gc3VtbWFyeSBsaW5rDQogICAgICAgIGFkdmVydGlzZW1lbnRzIGFu ZCBBUyBleHRlcm5hbCBsaW5rIGFkdmVydGlzZW1lbnRzIGFzIGFuDQogICAgICAgIGFsdGVybmF0 aXZlIHRvIHByZW1hdHVyZSBhZ2luZyAoc2VlIFNlY3Rpb24gMTQuMSkuIEl0IGlzIGRlZmluZWQN CiAgICAgICAgdG8gYmUgdGhlIDI0LWJpdCBiaW5hcnkgdmFsdWUgb2YgYWxsIG9uZXM6IDB4ZmZm ZmZmLg0KDQpJZiBpbiAyMDE2ICgyMiB5ZWFycyBsYXRlciksIG9uZSBwYXJ0aWN1bGFyIGltcGxl bWVudGF0aW9uIGNob29zZXMgdG8gbm90DQpjb21wbHkgdG8gdGhlIHNwZWNpZmljYXRpb24sIHRo ZW4gdGhlcmUgcmVhbGx5IGlzbuKAmXQgYW55dGhpbmcgdGhlIFdHIGNhbg0KZG8gYWJvdXQgaXQu IFRoZSBkcmFmdA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1v c3BmLW9zcGZ2Mi1oYml0LyBhbGxvd3MgYQ0KbGluayB0byBiZSB1c2VkIGV4Y2x1c2l2ZWx5IGZv ciBub24tdHJhbnNpdCB0cmFmZmljLiBPZiBjb3Vyc2UsIGlmIHlvdQ0KYWxzbyBkaWRu4oCZdCB3 YW50IHRvIHVzZSB0aGUgbGluayBmb3IgYW55IHRyYWZmaWMgeW91IHNpbXBseSB3b3VsZG7igJl0 DQphZHZlcnRpc2UgaXQuIA0KDQpUaGFua3MsDQpBY2VlIA0KDQoNCg0KDQoNCj4NCj4gQWdyZWUg b24gdGhlIGNvbW1lbnQgd2l0aCB0aGUgYmFuZHdpZHRoIGVuY29kaW5nLiBObyBuZWVkIHRvIGlu dmVudA0KPiBhbm90aGVyIG9uZS4NCj4NCj4gLS0tIHRvbnkNCg0K From nobody Mon Apr 11 10:38:45 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F20712F27A; Mon, 11 Apr 2016 10:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 SU3s4l8RPdKd; Mon, 11 Apr 2016 10:38:42 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750FD12F253; Mon, 11 Apr 2016 10:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=666; q=dns/txt; s=iport; t=1460396322; x=1461605922; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=yc2GuvDinpc7HDdHPS/oyyh5ywvjJNBCWi69NKtIaJw=; b=jb+mwpVpo0Ks6bSk0tpoBrH5rzS2/JcLlmJPLXvpMteyYaJ+guc0bduF qiUmr4tJsiJ7NTJ/fJLJHLHNXg16bHCDRiyn9efUQKToVMpzqvrqAjxHQ fYpP9OT5NJgvReFff+4+e8vQp8IdvA768DYn403Flw3NkiWAPcKiLO0xz M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgCS4AtX/4oNJK1cgzeBVrhJgg8BD?= =?us-ascii?q?YFyhg0egRE4FAEBAQEBAQFlHAuERAQjEUUSASICJgIEMBUSBA6ILK1AkhMBAQE?= =?us-ascii?q?BAQEBAwEBAQEBARp8kS+CVgWYBAGOC4FRjTyPJQEeAQFCg2eKGX4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,462,1454976000"; d="scan'208";a="258554465" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Apr 2016 17:38:41 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u3BHcfuu019569 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Apr 2016 17:38:41 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 11 Apr 2016 13:38:41 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Mon, 11 Apr 2016 13:38:41 -0400 From: "Acee Lindem (acee)" To: "draft-ietf-ospf-mpls-elc@ietf.org" Thread-Topic: Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00 Thread-Index: AQHRlBj81Lqya0qQckSeteuSX15/fA== Date: Mon, 11 Apr 2016 17:38:41 +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.202] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: OSPF WG List Subject: [OSPF] Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 17:38:43 -0000 QXV0aG9ycywgDQoNCldlIHdpbGwgc29vbiBiZSBwcm9ncmVzc2luZyB0aGUgT1NQRnYyIFNSIGRy YWZ0LiBXaGF0IGlzIHlvdXIgaW50ZW50IGZvcg0KdGhpcyBkcmFmdD8gSXQgaXMgbWlzc2luZzoN CiAgIA0KICAgIDEuIEEgZmlndXJlIHdpdGggdGhlIFJJIGVuY29kaW5nIGxpa2Ugb3RoZXIgT1NQ RiBkb2N1bWVudHMNCiAgICAyLiBEaXNjdXNzaW9uIGFzIHRvIHByZWNpc2VseSBob3cgdGhlIGNh cGFiaWxpdHkgd291bGQgYmUgdXNlZCBieSBhDQpyb3V0ZXIgaW4gYW4gT1NQRiByb3V0aW5nIGRv bWFpbi4gRm9yIGV4YW1wbGUsIG11c3QgYSByb3V0ZXIgcmVtb3ZlIHRoZSBFTA0KaWYgdGhlIG5l eHQtaG9wIGRvZXNu4oCZdCBzdXBwb3J0IGl0Pw0KICAgIDMuIEEgZGlzY3Vzc2lvbiBvZiBiYWNr d2FyZCBjb21wYXRpYmlsaXR5IGZvciB0aGUgbmV3DQpSb3V0ZXItSW5mb3JtYXRpb24gTFNBIGNh cGFiaWxpdHkuDQoNClRoYW5rcywNCkFjZWUNCg0K From nobody Mon Apr 11 15:22:35 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6330212E775 for ; Mon, 11 Apr 2016 15:22:33 -0700 (PDT) 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, 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 fWdxrejhnpD7 for ; Mon, 11 Apr 2016 15:22:31 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E4B12D093 for ; Mon, 11 Apr 2016 15:22:31 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-9f-570c1d30e129 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 9F.B7.30335.03D1C075; Mon, 11 Apr 2016 23:54:56 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0248.002; Mon, 11 Apr 2016 18:22:30 -0400 From: Uma Chunduri To: "Les Ginsberg (ginsberg)" , "Acee Lindem (acee)" , OSPF WG List Thread-Topic: WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment" Thread-Index: AQHRf/Ho6WRxQA5zQE2bUJRokiTbP59dC0kggCJ0YZCAABBu8IAF71jA Date: Mon, 11 Apr 2016 22:22:28 +0000 Message-ID: <1B502206DFA0C544B7A604691520086358022771@eusaamb105.ericsson.se> References: <1B502206DFA0C544B7A6046915200863580014D7@eusaamb106.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyuXRPiK6BLE+4wbMbchaT385jttjwZyO7 Rcu9e+wOzB5Tfm9k9Viy5CdTAFMUl01Kak5mWWqRvl0CV8aCEw2sBbuMKjYd28fcwDjFsIuR k0NCwESi6eE1ZghbTOLCvfVsXYxcHEICRxklui9/YYJwljNKPF37HayKTUBP4uPUn+xdjBwc IgKVEl+/S4GEhQXiJF4eW8IGYosIxEtMW97HCGG7SRx5fp8FxGYRUJU43r0SzOYV8JX48ecU O8T8p4wSs58/B5vPKeAqMa/3DVgRI9BF30+tYQKxmQXEJW49mc8EcamAxJI956GuFpV4+fgf K4StKLGvfzrYbcwCmhLrd+lDtCpKTOl+yA6xV1Di5MwnLBMYRWchmToLoWMWko5ZSDoWMLKs YuQoLS7IyU03MtjECIyKYxJsujsY70/3PMQowMGoxMOrwModLsSaWFZcmXuIUYKDWUmEt0eB J1yINyWxsiq1KD++qDQntfgQozQHi5I4b2PwvzAhgfTEktTs1NSC1CKYLBMHp1QDY/7ZAzEO 6cqJ+9/lGfdETQzLci5ebyjw988qyyNJRtPqD5QrS/QFFqz/HflGYHKRUApXQub9M52HvBa5 607/osvWPkN+1znHD1Fs6jfXu/hyOYab7eGdsF7swsXpy0+c5CueNHvt/5/K5R+UZ0+RdfL/ dWT7x48nXosdMtylfE33usrdfT6ZW5RYijMSDbWYi4oTASrDVcKGAgAA Archived-At: Subject: Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 22:22:33 -0000 TGVzLA0KDQpJbi1saW5lIFtVbWFdOg0KDQotLQ0KVW1hIEMuDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIFttYWlsdG86Z2luc2Jl cmdAY2lzY28uY29tXSANClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwNywgMjAxNiA4OjQwIFBNDQpU bzogVW1hIENodW5kdXJpOyBBY2VlIExpbmRlbSAoYWNlZSk7IE9TUEYgV0cgTGlzdA0KU3ViamVj dDogUkU6IFdHIEFkb3B0aW9uIFBvbGwgZm9yICJVc2luZyBPcGVyYXRvci1kZWZpbmVkIFRMVnMg Zm9yIEFnaWxlIFNlcnZpY2UgRGVwbG95bWVudCINCg0KVW1hIC0NCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBVbWEgQ2h1bmR1cmkgW21haWx0bzp1bWEuY2h1bmR1cmlA ZXJpY3Nzb24uY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMDcsIDIwMTYgODowMyBQTQ0K PiBUbzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZyk7IEFjZWUgTGluZGVtIChhY2VlKTsgT1NQRiBX RyBMaXN0DQo+IFN1YmplY3Q6IFJFOiBXRyBBZG9wdGlvbiBQb2xsIGZvciAiVXNpbmcgT3BlcmF0 b3ItZGVmaW5lZCBUTFZzIGZvciANCj4gQWdpbGUgU2VydmljZSBEZXBsb3ltZW50Ig0KPiANCj4g TGVzLA0KPiANCj4gSW4tbGluZSBbVW1hXToNCj4gDQo+IC0tDQo+IFVtYSBDLg0KPiANCj4gDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE9TUEYgW21haWx0bzpvc3BmLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMZXMgR2luc2JlcmcNCj4gKGdpbnNiZXJnKQ0K PiBTZW50OiBXZWRuZXNkYXksIE1hcmNoIDE2LCAyMDE2IDk6NDEgUE0NCj4gVG86IEFjZWUgTGlu ZGVtIChhY2VlKTsgT1NQRiBXRyBMaXN0DQo+IFN1YmplY3Q6IFJlOiBbT1NQRl0gV0cgQWRvcHRp b24gUG9sbCBmb3IgIlVzaW5nIE9wZXJhdG9yLWRlZmluZWQgVExWcyANCj4gZm9yIEFnaWxlIFNl cnZpY2UgRGVwbG95bWVudCINCj4gDQo+IE15IG9waW5pb24gb2YgdGhlIGRyYWZ0IGhhcyBub3Qg Y2hhbmdlZC4NCj4gSXQgaXMgZGVmaW5pbmcgYSB3YXkgdG8gdXRpbGl6ZSBPU1BGIHRvIHNlbmQg YXBwbGljYXRpb24gaW5mb3JtYXRpb24gLSANCj4gd2hpY2ggaXMgbm90IHNvbWV0aGluZyB0aGUg cHJvdG9jb2wgc2hvdWxkIGJlIHVzZWQgdG8gZG8uDQo+IEZ1cnRoZXIsIGl0IGxlYXZlcyBkZWZp bml0aW9uIG9mIHRoZSBuZXcgY29kZXBvaW50cyBhbmQgZm9ybWF0cyBvZiB0aGUgDQo+IGluZm9y bWF0aW9uIGFkdmVydGlzZWQgY29tcGxldGVseSB1bnNwZWNpZmllZCAtIHRoZSBsYXRlc3QgZHJh ZnQgDQo+IHJldmlzaW9uDQo+IHN0YXRlczoNCj4gDQo+ICIgVGhlIG1lYW5pbmcgb2YgdGhlIG9w ZXJhdG9yLWRlZmluZWQgc3ViLVRMViBpcyB0b3RhbGx5IG9wYXF1ZSB0byBPU1BGDQo+ICAgIGFu ZCBpcyBkZWZpbmVkIGJ5IHRoZSBuZXR3b3JrIGxvY2FsIHBvbGljeSBhbmQgaXMgY29udHJvbGxl ZCB2aWENCj4gICAgY29uZmlndXJhdGlvbi4gICINCj4gDQo+IEhvdyBpbnRlcm9wZXJhYmlsaXR5 IGlzIGFjaGlldmVkIGlzIG5vdCBhZGRyZXNzZWQgYXQgYWxsLg0KPiANCj4gW1VtYV06IFRoZSB3 aG9sZSBwb2ludCBvZiB0aGUgZHJhZnQgaXMsICBub3QgdG8gZGVmaW5lIHRoZSBmb3JtYXQgZm9y IA0KPiB0aGUgc3ViLSBUTFZzIHNvIHRoYXQgaXQgY2FuIGJlIHVzZWQgIGFzIHBlciB0aGUgc3Vi LXRsdiB0eXBlIGFzIHNldCANCj4gYnkgdGhlIG9wZXJhdG9yIChmb3IgZXhhbXBsZSBzZXJ2aWNl IGF0dHJpYnV0ZS9MYWJlbCkuICBTdWItVExWIGhhcyANCj4gc2V0IG9mIGF0dHJpYnV0ZSBsZW5n dGggYW5kIGF0dHJpYnV0ZSB2YWx1ZSBpbiBOQk8uDQo+IA0KW0xlczpdIFllcyAtIEkga25vdy4g Oi0pDQpBbmQgSSB0aGluayB0aGlzIGlzIGEgImRpc2FzdGVyIHdhaXRpbmcgdG8gaGFwcGVuIi4N CltVbWFdOiBJIGFtIHJlYWxseSBzb3JyeSB5b3UgZmVsdCB0aGF0IHdheS4NClRoZXJlIGFyZSBs b3Qgb2YgdGhpbmdzIHdlIGNhbiBmdXJ0aGVyIGltcHJvdmUgaW4gdGhpcyBjYXNlIChpbmNsdWRp bmcgcmVzdHJpY3RpbmcgdGhlIHNpemUgb2YgdGhlIHN1Yi1UTFYgYW5kIHZhbHVlIGZpZWxkIGl0 c2VsZiksIGJ1dC4uDQpUbyBtZSBpdOKAmXMgZ29vZCB0byBoYXZlIHNvbWUgYmFsYW5jZSAgYmV0 d2VlbiBkZXBsb3ltZW50IGNvbXBsZXhpdHkgYW5kIHVzYWJpbGl0eSAocmVtZW1iZXIgT1NQRnYz IHdpdGggSVBTZWMgLSBhbWF6aW5nIHRoaW5nIGJ1dCB2ZXJ5IGZldyBkZXBsb3ltZW50cyBhbmQg bm93IHdlIGhhdmUgUkZDIDY1MDYvNzE2NikuIE5vIG9mZmVuY2UgbWVhbnQgZm9yIHRoZSB0ZWNo bm9sb2d5IGl0c2VsZi4uDQoNCg0KT24gdGhpcyBwb2ludCBJIHRoaW5rIHdlIGN1cnJlbnRseSBo YXZlIG5vIGNvbW1vbiBncm91bmQuDQoNCiAgIExlcw0KDQo+IElTLUlTIGhhcyB0YWtlbiBhIG11 Y2ggbW9yZSBzdHJpbmdlbnQgYXBwcm9hY2ggdG8gYSBzaW1pbGFyIHJlcXVlc3QuDQo+IA0KPiBb VW1hXTogLi4gYW5kIGhlbmNlIHVuZm9ydHVuYXRlbHkgSSBzZWUgbm8gYm9keSBzYXcgdXNpbmcg aXQtIGluIGZhY3QgDQo+IGluY2x1ZGluZyB5b3UuIEZvciBleGFtcGxlIA0KPiBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pc2lzLXNiZmQtDQo+IGRpc2NyaW1pbmF0b3It MDIgY291bGQgaGF2ZSB1c2VkIEdFTkFQUCBidXQgcmF0aGVyIHJlc29ydGVkIHRvIFJvdXRlciAN Cj4gY2FwYWJpbGl0aWVzIChSZW1lbWJlciBJRVRGOTAgZGlzY3Vzc2lvbiBhcm91bmQgdGhpcyku DQo+IA0KPiBSRkMgNjgyMyAoR0VOQVBQKSByZXF1aXJlcyB0aGF0IGluZm9ybWF0aW9uIHNlbnQg aW4gdGhlIGdlbmVyaWMgDQo+IGNvbnRhaW5lciBUTFYgTVVTVCBiZSBiYXNlZCBvbiBhIHB1Ymxp YyBzcGVjaWZpY2F0aW9uIC0gYW5kIHRoYXQgYW4gDQo+IGFwcGxpY2F0aW9uIHNwZWNpZmljIElE IGZvciB0aGUgYXBwbGljYXRpb24gdXNpbmcgdGhpcyBtZWNoYW5pc20gYmUgDQo+IGFzc2lnbmVk IGJ5IElBTkEuIFRoaXMgYWRkcmVzc2VzIHRoZSBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlLg0KPiBH RU5BUFAgZnVydGhlciBzcGVjaWZpZXMgdGhhdCBzdWNoIGluZm9ybWF0aW9uIFNIT1VMRCBiZSBh ZHZlcnRpc2VkIGJ5IA0KPiBhIHNlcGFyYXRlIGluc3RhbmNlIG9mIHRoZSByb3V0aW5nIHByb3Rv Y29sIChhcyBzcGVjaWZpZWQgaW4gUkZDIA0KPiA2ODIyKE1JKSkgc28gYXMgdG8gbWluaW1pemUg dGhlIGltcGFjdCBvZiB0aGUgYXBwbGljYXRpb24gaW5mb3JtYXRpb24gDQo+IGZsb29kaW5nIG9u IHRoZSBwZXJmb3JtYW5jZSBvZiB0aGUgcm91dGluZyBwcm90b2NvbC4NCj4gDQo+IFtVbWFdOiBB cyBJIGluZGljYXRlZCBlYXJsaWVyIFtJLUQuaWV0Zi1vc3BmLXRyYW5zcG9ydC1pbnN0YW5jZV0g Y2FuIA0KPiBiZSBkZWZpbml0ZWx5IHVzZWQgaWYgdGhlIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8g YXBwbGljYXRpb24gbmVlZCB0byANCj4gYmUgdXNlZCB0aGVyZS4gSWYgaXQgaXMgdXNlZCBmb3Ig c3VwcG9ydGluZyByb3V0aW5nIG9uZSBjYW4gdXNlIHRoaXMgVExWLg0KPiANCj4gDQo+IA0KPiBX aXRob3V0IGFkZHJlc3NpbmcgYm90aCBvZiB0aGVzZSBpc3N1ZXMgSSBjYW5ub3Qgc3VwcG9ydCB0 aGUgZHJhZnQuDQo+IA0KPiAgICBMZXMNCj4gDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gRnJvbTogT1NQRiBbbWFpbHRvOm9zcGYtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEFjZWUgTGluZGVtDQo+ID4gKGFjZWUpDQo+ID4gU2VudDogV2VkbmVzZGF5LCBN YXJjaCAxNiwgMjAxNiA3OjA5IFBNDQo+ID4gVG86IE9TUEYgV0cgTGlzdA0KPiA+IFN1YmplY3Q6 IFtPU1BGXSBXRyBBZG9wdGlvbiBQb2xsIGZvciAiVXNpbmcgT3BlcmF0b3ItZGVmaW5lZCBUTFZz IA0KPiA+IGZvciBBZ2lsZSBTZXJ2aWNlIERlcGxveW1lbnQiDQo+ID4NCj4gPiBXZeKAmXZlIGRp c2N1c3NlZCB0aGlzIGRyYWZ0IGEgbnVtYmVyIG9mIHRpbWVzLiBJbiBteSBvcGluaW9uLCBpdCAN Cj4gPiBzZWVtcyBsaWtlIGEgdXNlZnVsIG1lY2hhbmlzbSBpZiBvbmUgZW52aXNpb25zIGEgZ2Vu ZXJhbGl6ZWQgQVBJIA0KPiA+IGJldHdlZW4gT1NQRiBhbmQgdXNlciBhbmQgdGhpcmQtcGFydHkg YXBwbGljYXRpb25zIHRvIGNvbnZleSANCj4gPiBhcHBsaWNhdGlvbi1zcGVjaWZpYyBpbmZvcm1h dGlvbiBsZWFybmVkIGZyb20gb3RoZXIgT1NQRiByb3V0ZXJzLiBJbiANCj4gPiBtYW55IHJlc3Bl Y3RzLCB0aGlzIGhhcyBhbHJlYWR5IGJlZW4gZW52aXNpb25lZCBmb3IgT1NQRiBOb2RlIFRhZ3Mu DQo+ID4gUGxlYXNlIGluZGljYXRlIHlvdXIgb3BpbmlvbiBvbiB0aGlzIGRyYWZ0IGJlZm9yZSBN YXJjaCAzMXN0LCAyMDE2Lg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IEFjZWUNCj4gPg0KPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gT1NQRiBt YWlsaW5nIGxpc3QNCj4gPiBPU1BGQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vc3BmDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IE9TUEYgbWFpbGluZyBsaXN0DQo+IE9TUEZAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vc3BmDQo= From nobody Mon Apr 11 16:42:10 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AAF12D8D2; Mon, 11 Apr 2016 16:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 bO4j-y55z5yW; Mon, 11 Apr 2016 16:42:07 -0700 (PDT) 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 5747312D6DE; Mon, 11 Apr 2016 16:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2146; q=dns/txt; s=iport; t=1460418127; x=1461627727; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=j8FefVWMURrxZN+hgKSEjy1P7xz7qfWatkWcE/el6S4=; b=aLmyCmBNpqDISGGOU+ax0degQ6YREJ3k5p7Ch14JZQroM54dX876v6eH R7cBPo3wJS3w0VYuNkSJVIINYmea4PJ2xj7IH7gq7+Dkd50mTjdJzXy5s wP5xVHlXORCjNR+UcUhU/J6Y1cLJ5Rj5JcMgdAmo5OYh10OT4k8AUlTE6 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQBNNQxX/4MNJK1dgzdTfQa6XQENg?= =?us-ascii?q?XIXCoVsAoEwOBQBAQEBAQEBZSeEQQEBAQQBAQFrBAcMBgEIEQMBAlYLHQoEAQ0?= =?us-ascii?q?FiCcOwAYBAQEBAQEBAQEBAQEBAQEBAQEBEwSGIYRLihUFmAQBjguPDY8lAR4BA?= =?us-ascii?q?UKCMoE1bIkHfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,470,1454976000"; d="scan'208";a="90680797" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Apr 2016 23:42:06 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3BNg6YD027533 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Apr 2016 23:42:06 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 11 Apr 2016 19:42:05 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Mon, 11 Apr 2016 19:42:05 -0400 From: "Carlos Pignataro (cpignata)" To: "Acee Lindem (acee)" , "draft-ietf-ospf-mpls-elc@ietf.org" Thread-Topic: [OSPF] Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00 Thread-Index: AQHRlEvBpcuRzR4OpEWJ4X+miwJxNA== Date: Mon, 11 Apr 2016 23:42:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.101.176] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3FA822DBF86F84429D8594E3EC06C233@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 23:42:09 -0000 Authors, For this draft, it would be useful to also discuss and understand a few other things, such as: I. Has an approach similar to FAT-PW for LB (instead of the {ELI; EL} Entropy Label approach) been considered? It would save label stack entries, and allow precise positioning. Has this been ruled out? II. Definition of behavior for networks with hybrid support (some nodes support ELC, some do not). Like, can/should EL;ELI be used if some nodes in the path do not support it? This will be a very common case. Some downstream NHs might support it and some don=B9t. III. Are there multi instance or flooding scope implications? IV. As specified, there is no relationship between ELC and RLDC. Seems there is. Do these need to be supported simultaneously? Say, a node does not support ELC but advertises RLDC, what=B9s that mean? V. There are several operational considerations which are just unadressed. Say, a new LC is inserted in a node, which does not support ELC, or supports a RLD smaller than what=B9s been advertised. Or... VI. No security implications sounds quite optimistic :-) Thanks, =8B Carlos.=20 -----Original Message----- From: OSPF on behalf of "Acee Lindem (acee)" Date: Monday, April 11, 2016 at 2:38 PM To: "draft-ietf-ospf-mpls-elc@ietf.org" Cc: OSPF WG List Subject: [OSPF] Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00 >Authors,=20 > >We will soon be progressing the OSPFv2 SR draft. What is your intent for >this draft? It is missing: > =20 > 1. A figure with the RI encoding like other OSPF documents > 2. Discussion as to precisely how the capability would be used by a >router in an OSPF routing domain. For example, must a router remove the EL >if the next-hop doesn=B9t support it? > 3. A discussion of backward compatibility for the new >Router-Information LSA capability. > >Thanks, >Acee > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf From nobody Mon Apr 11 23:58:09 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF7F12E569; Mon, 11 Apr 2016 23:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.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 GhwGCVv0EcBC; Mon, 11 Apr 2016 23:58:02 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0136.outbound.protection.outlook.com [65.55.169.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D322612E5E4; Mon, 11 Apr 2016 23:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PgjYED4Q3dc4Vb8y36FFzQ3HE/NOwMbdRBZN9insuQk=; b=IpP/uUBchmkZm8A8toTbl34ukZTEEHjJK1A+X6IsqqQTZBrqEiFYaXCdc71L2Ud4N94gYt+LjLF0djELDjVXidb4X2OxmPCDWPAILqy6CRTkDdl/t3YVLinRJ1Ns0QfONnp+j0zYEyuA95S+OMq63PYVBNLfCAKY7EgramtR/uQ= Received: from BN3PR0201MB1059.namprd02.prod.outlook.com (10.161.209.14) by BN3PR0201MB1057.namprd02.prod.outlook.com (10.161.209.13) with Microsoft SMTP Server (TLS) id 15.1.447.15; Tue, 12 Apr 2016 06:57:56 +0000 Received: from BN3PR0201MB1059.namprd02.prod.outlook.com ([10.161.209.14]) by BN3PR0201MB1059.namprd02.prod.outlook.com ([10.161.209.14]) with mapi id 15.01.0447.028; Tue, 12 Apr 2016 06:57:56 +0000 From: Alan Davey To: "Derek Man-Kit Yeung (myeung)" , "draft-ietf-ospf-yang@ietf.org" Thread-Topic: draft-ietf-ospf-yang-03 questions and doubts Thread-Index: AdE3NLGjjtMGuql0QfiSt+s9ulh9zgoPjYmAAiVQNuADX5obgAcESYLg Date: Tue, 12 Apr 2016 06:57:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=metaswitch.com; x-originating-ip: [86.31.33.199] x-ms-office365-filtering-correlation-id: 0e50fec5-8cb9-41ac-651d-08d3629fc6c7 x-microsoft-exchange-diagnostics: 1; BN3PR0201MB1057; 5:TzgzW4s1Dvz5FmKfGRr++6qkj2PpQguMYUAh4d4igvXosrC6we+/0xjEj8prnbXlR6tfu/oRJyPqqTz+Xezwae9u4CwhxnedpJ9T4rf/IEvap/lIc2bTR8CTWLOAPD9/1o13O0OefZ/1wfCbY4GAEQ==; 24:8Cz9Fo7Xvgul57yZO23+7hO/VVdDhAY1QQpTYkAUxEBmqlYiAY3ojmybzpJFoDITnTIEylO2T554ScFQGJNaynh9MQYiB1MvkXNQUVPlhqg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0201MB1057; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN3PR0201MB1057; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0201MB1057; x-forefront-prvs: 0910AAF391 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51444003)(43544003)(51914003)(377454003)(19625215002)(33656002)(2950100001)(2501003)(5008740100001)(586003)(92566002)(2906002)(3660700001)(5890100001)(10400500002)(50986999)(86362001)(74316001)(1220700001)(189998001)(2900100001)(19580395003)(345774005)(102836003)(3846002)(19580405001)(790700001)(164054004)(19300405004)(11100500001)(4326007)(87936001)(16236675004)(5001770100001)(6116002)(66066001)(9686002)(5004730100002)(230783001)(54356999)(5003600100002)(81166005)(76576001)(122556002)(76176999)(93886004)(3280700002)(99286002)(15975445007)(1096002)(77096005)(5002640100001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB1057; H:BN3PR0201MB1059.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0201MB10597DBA718D60998EA82E0FF9950BN3PR0201MB1059_" MIME-Version: 1.0 X-OriginatorOrg: metaswitch.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2016 06:57:56.1931 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB1057 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] draft-ietf-ospf-yang-03 questions and doubts X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 06:58:05 -0000 --_000_BN3PR0201MB10597DBA718D60998EA82E0FF9950BN3PR0201MB1059_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Derek Thanks for your email, apologies for the delay in getting back to you. I h= ave followed up on a couple of points from our email exchange. Please let = me know your thoughts on the following. On the subject of separate containers for OSPFv2 and OSPFv3 interfaces, con= ditional statements add complexity. My analogy here is writing program code. In a similar situation, to suppor= t OSPFv2 and OSPFv3, I would have different top level functions for the two= versions and then call common functions where possible. This gives a stra= ightforward top-level with no conditional statements; simpler to write and = easier to read and understand. Therefore, I think that a simpler definition would follow from having versi= on-specific top level containers which then include common and version-spec= ific common definitions. In interface-common-operation, I think that the DR and BDR information is p= rovided to show the DR or BDR for a link as identified by the protocol. Th= erefore, for OSPFv3, this identification consists of the Router ID plus the= interface ID. Note the following. - On the use of interface ID, as per RFC 5340, this is used in OSP= Fv3 to uniquely identify (among its own interfaces) the DR's interface to t= he link. (Recall that a router may have multiple interfaces to the link.) - Using the link-local IPv6 address may not be the most user-frien= dly way of identifying the link. The link-local address is normally auto-g= enerated by the system, not assigned by the user, and therefore the user is= likely to have to search the system configuration to identify the link to = which it is associated. - The leaf bdr-ip-addr still has "type inet:ipv4-address" in versi= on 04 of the draft. Regards Alan Davey From: Derek Man-Kit Yeung (myeung) [mailto:myeung@cisco.com] Sent: 03 March 2016 21:55 To: Alan Davey ; draft-ietf-ospf-yang@ietf.org Cc: OSPF WG List Subject: Re: draft-ietf-ospf-yang-03 questions and doubts Hi Alan, Please see DY> below. From: Alan Davey > Date: Thursday, February 18, 2016 at 3:28 AM To: myeung >, "draft-ietf-ospf-ya= ng@ietf.org" > Cc: OSPF WG List > Subject: RE: draft-ietf-ospf-yang-03 questions and doubts Hi Derek Thank you for your response, and apologies for the delay in getting back to= you. Have you considered distinct ospfv3-interface-operation and ospfv2-i= nterface-operation? Or even distinct "container ospfv2" and "container osp= fv3"? DY> No, we do not plan to have explicit ospfv2 and ospfv3 container. We use= d when statement or if-feature to take care of OSPFv2 vs OSPFv3 specific fi= elds in general. There are a number of differences between the Interface Data Structure defi= ned in RFC2328 and in RFC5340. In particular, the following. Do you plan = to add all of these differences to the interface-operation grouping? - DR and BDR identification. o As you wrote, section 9 of RFC2328 specifies that the Interface Data St= ructure includes the Router ID and IP address for the DR and BDR. o Section 4.1.2 of RFC5340 does not specify how to identify the DR and BD= R, but given the OSPFv3 protocol, it seems reasonable that the router ID an= d interface ID would be stored. DY> In OSPFv3, the DR/BDR is still identified by a router ID. The interface= ID of the DR is used when generating LSA and by itself do not identify the= DR/BDR. DY> Given the DR/BDR router ID/ip address, one can locate the corresponding= neighbor information and find the interface ID there. DY> So we are not going the duplicate the interface ID of the DR in the int= erface container again. - Section 4.1.2 of RFC5340 specifies a number of objects that do n= ot appear in the RFC2328 version of the Interface Data Structure, as follow= s. o Interface ID. o Instance ID. DY> The two above will be added. It is missing now. To be clear. It is the = interface ID of the local router, not the one of the DR, for the interface= . o List of LSAs with link-local scope. DY> The model already have link-local LSA database. o List of IPv6 prefixes configured for the attached link. DY> Understood that it is mentioned in the OSPFv3 RFC. DY> However, looking at a few implementations there is no explicit display = of such information with the interface related OSPF show command. DY> The IPv6 prefixes (or IPv4 prefix in OSPFv2) advertised by the router c= ould be found already either from the interface module (IPv4/IPv6 augment) = or from the LSA database itself. DY> Extracting it again in OSPF model interface operation data seems redund= ant. DY> We don't think we need it in the base model, but vendors could augment = it if they find it useful. Thanks, - Derek Regards Alan From: Derek Man-Kit Yeung (myeung) [mailto:myeung@cisco.com] Sent: 04 February 2016 19:39 To: Alan Davey = >; draft-ietf-ospf-yang@ietf.org Cc: ospf@ietf.org Subject: Re: draft-ietf-ospf-yang-03 questions and doubts Hi Alan, Thanks for the comments. As you have pointed out, there are OSPFv3 specific fields missing in the mo= del now. For example, instance ID and interface ID. We will add them in the= next update. As for the DR, DR is conceptually one of the neighbor. In OSPFv2, the DR's router ID and IP address are used in protocol operation= . While in OSPFv3, the DR's router ID and interface ID are used in protocol o= peration. According to OSPFv2 and OSPFv3 RFC, the interface structure should keep bot= h the DR's router ID and IP address. We have the following in the current model. grouping interface-operation { leaf dr { type inet:ipv4-address; description "Designated Router (DR) IP address."; } } grouping neighbor-operation { leaf dr { type yang:dotted-quad; description "Designated Router."; } } To better match the RFC and accommodate both OSPFv2 and OSPFv3 in a cleaner= way, we plan to make the following changes. grouping interface-operation { leaf dr-router-id { type yang:dotted-quad; description "Designated Router (DR) router ID."; } leaf dr-ip-address { type inet:ip-address; description "Designated Router (DR) IP address."; } } grouping neighbor-operation { leaf dr-router-id { type yang:dotted-quad; description "Neighbor's Designated Router (DR) router ID."; } leaf dr-ip-address { type inet:ip-address; description "Neighbor's Designated Router (DR) IP address."; } } If one need the DR's interface ID in the OSPFv3 case, it could be found by = locating the neighbor entry for the DR and get the interface ID (To be adde= d) field there. Comments welcome. Thanks, - Derek From: Alan Davey > Date: Tuesday, December 15, 2015 8:23 AM To: "draft-ietf-ospf-yang@ietf.org" <= draft-ietf-ospf-yang@ietf.org> Cc: "ospf@ietf.org" > Subject: draft-ietf-ospf-yang-03 questions and doubts Folks I have a doubt about draft-ietf-ospf-yang-03. Please let me know your thou= ghts on the following. The text is OSPFv2-specific in places. I think that it would be better to = define separate top-level groupings and containers for OSPFv2 and OSPFv3 an= d define common groupings and containers, where possible, that are used by = both. For example, grouping interface-operation contains the following, which is = incorrect for OSPFv3. - leaf dr with type ipv4-address - leaf bdr with type ipv4-address. I think that it would be better to define something along the following lin= es. - ospfv3-interface-operation { o uses interface-config o uses ospf-common-interface-operation o leaf dr { ? type if:interface-ref ? description: * "The remote interface ID used by the Designated Router = on * this link. This is the interface index of the interfac= e local to the DR."; o etc - ospfv2-interface-operation { o uses interface-config o uses ospf-common-interface-operation o leaf dr { ? type inet:ipv4-address; ? description "Designated Router (DR) IP address."; o etc. Regards Alan Davey --_000_BN3PR0201MB10597DBA718D60998EA82E0FF9950BN3PR0201MB1059_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Derek

 

Thanks for your email,= apologies for the delay in getting back to you.  I have followed up o= n a couple of points from our email exchange.  Please let me know your= thoughts on the following.

 

On the subject of sepa= rate containers for OSPFv2 and OSPFv3 interfaces, conditional statements ad= d complexity. 

 

My analogy here is wri= ting program code.  In a similar situation, to support OSPFv2 and OSPF= v3, I would have different top level functions for the two versions and the= n call common functions where possible.  This gives a straightforward top-level with no conditional statements; sim= pler to write and easier to read and understand.

 

Therefore, I think tha= t a simpler definition would follow from having version-specific top level = containers which then include common and version-specific common definition= s.

 

In interface-common-op= eration, I think that the DR and BDR information is provided to show the DR= or BDR for a link as identified by the protocol.  Therefore, for OSPF= v3, this identification consists of the Router ID plus the interface ID.  Note the following.

 

-&n= bsp;         On the use of = interface ID, as per RFC 5340, this is used in OSPFv3 to uniquely identify = (among its own interfaces) the DR’s interface to the link.  (Rec= all that a router may have multiple interfaces to the link.)

-&n= bsp;         Using the link= -local IPv6 address may not be the most user-friendly way of identifying th= e link.  The link-local address is normally auto-generated by the syst= em, not assigned by the user, and therefore the user is likely to have to search the system configuration to identify = the link to which it is associated.

-&n= bsp;         The leaf bdr-i= p-addr still has “type inet:ipv4-address” in version 04 of the = draft.

 

Regards

Alan Davey<= /span>

 

From: Derek Man-Kit Yeung (myeung) [mailto:myeung@cisco.com]
Sent: 03 March 2016 21:55
To: Alan Davey <Alan.Davey@metaswitch.com>; draft-ietf-ospf-ya= ng@ietf.org
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: draft-ietf-ospf-yang-03 questions and doubts=

 

Hi Alan= ,

&n= bsp;

Please = see DY> below.

&n= bsp;

From: Alan Davey <Alan.Davey@metaswitch.com&g= t;
Date: Thursday, February 18, 2016 at 3:28 AM
To: myeung <myeung@cis= co.com>, "draft-ietf-ospf-yang@ietf.org" <draft-ietf-ospf-yang@ietf.org><= br> Cc: OSPF WG List <ospf@ie= tf.org>
Subject: RE: draft-ietf-ospf-yang-03 questions and doubts=

&n= bsp;

Hi Derek

 

Thank you for your res= ponse, and apologies for the delay in getting back to you.  Have you c= onsidered distinct ospfv3-interface-operation and ospfv2-interface-operatio= n?  Or even distinct “container ospfv2” and “container ospfv3”?

 

DY> No, we do not plan to have explicit ospfv2 and o= spfv3 container. We used when statement or if-feature to take care of OSPFv= 2 vs OSPFv3 specific fields in general.

 

There are a number of = differences between the Interface Data Structure defined in RFC2328 and in = RFC5340.  In particular, the following.  Do you plan to add all o= f these differences to the interface-operation grouping?

 

-&nbs= p;         DR and BDR ide= ntification.

o   As you wrote, = section 9 of RFC2328 specifies that the Interface Data Structure includes t= he Router ID and IP address for the DR and BDR.

o   Section 4.1.2 = of RFC5340 does not specify how to identify the DR and BDR, but given the O= SPFv3 protocol, it seems reasonable that the router ID and interface ID wou= ld be stored.

 

DY> In OSPFv3, the DR/BDR is still identified by a r= outer ID. The interface ID of the DR is used when generating LSA and by its= elf do not identify the DR/BDR.

DY> Given the DR/BDR router ID/ip address, one can l= ocate the corresponding neighbor information and find the interface ID ther= e.

DY> So we are not going the duplicate the interface = ID of the DR in the interface container again.

 

-&nbs= p;         Section 4.1.2 = of RFC5340 specifies a number of objects that do not appear in the RFC2328 = version of the Interface Data Structure, as follows.

o   Interface ID.<= /span>

o   Instance ID.

 

DY> The two above will be added. It is missing now. = To be clear. It is the interface ID of the local router, not the one of the= DR,  for the interface.

 

o   List of LSAs w= ith link-local scope.<= /p>

 

DY> The model already have link-local LSA database.<= o:p>

 

o   List of IPv6 p= refixes configured for the attached link.

 

DY> Understood that it is mentioned in the OSPFv3 RF= C. 

DY> However, looking at a few implementations there = is no explicit display of such information with the interface related OSPF = show command.

DY> The IPv6 prefixes (or IPv4 prefix in OSPFv2) adv= ertised by the router could be found already either from the interface modu= le (IPv4/IPv6 augment) or from the LSA database itself.

DY> Extracting it again in OSPF model interface oper= ation data seems redundant.

DY> We don’t think we need it in the base mode= l, but vendors could augment it if they find it useful.

 

Thanks,

- Derek

 

Regards

Alan

 

From: Derek Man-Kit Yeung (myeung) [mailto:myeung@cisco.com]
Sent: 04 February 2016 19:39
To: Alan Davey <Alan.Davey@met= aswitch.com>; draft-ietf-ospf-yang@ietf.org= <= br> Cc: ospf@ietf.org
Subject: Re: draft-ietf-ospf-yang-03 questions and doubts

 =

Hi Alan= ,

 <= /span>

Thanks = for the comments.

As you = have pointed out, there are OSPFv3 specific fields missing in the model now= . For example, instance ID and interface ID. We will add them in the next u= pdate.

 <= /span>

As for = the DR, DR is conceptually one of the neighbor. 

In OSPF= v2, the DR's router ID and IP address are used in protocol operation.

While i= n OSPFv3, the DR's router ID and interface ID are used in protocol operatio= n.

Accordi= ng to OSPFv2 and OSPFv3 RFC, the interface structure should keep both the D= R's router ID and IP address.=

 <= /span>

We have= the following in the current model.

 <= /span>

  = grouping interface-operation {

  =   leaf dr {

  =     type inet:ipv4-address;

  =     description "Designated Router (DR) IP address.";

  =   }

  = }

  = grouping neighbor-operation {=

  =   leaf dr {

  =     type yang:dotted-quad;

  =     description

  =       "Designated Router.";

  =   }

  = }

 <= /span>

To bett= er match the RFC and accommodate both OSPFv2 and OSPFv3 in a cleaner way, w= e plan to make the following changes.

 <= /span>

  = grouping interface-operation {

  =   leaf dr-router-id {

  =     type yang:dotted-quad;

  =     description

  =       "Designated Router (DR) router ID.";<= span style=3D"color:black">

  =   }

  =   leaf dr-ip-address {

  =     type inet:ip-address;=

  =     description "Designated Router (DR) IP address.";

  =   }

  = }

  = grouping neighbor-operation {=

  =   leaf dr-router-id {

  =     type yang:dotted-quad;

  =     description

  =       "Neighbor's Designated Router (DR) router ID.&quo= t;;

  =   }

  =   leaf dr-ip-address {

  =     type inet:ip-address;=

  =     description "Neighbor's Designated Router (DR) IP addres= s.";

  =   }

  = }

 <= /span>

If one = need the DR's interface ID in the OSPFv3 case, it could be found by locatin= g the neighbor entry for the DR and get the interface ID (To be added) fiel= d there.

 <= /span>

Comment= s welcome.

 <= /span>

Thanks,=

- Derek=

 <= /span>

From: Alan Davey <Alan.Davey@metaswitch.com&g= t;
Date: Tuesday, December 15, 2015 8:23 AM
To: "dr= aft-ietf-ospf-yang@ietf.org" <draft-ietf-ospf-yang@iet= f.org>
Cc: "ospf@ietf.org<= span style=3D"color:black">" <ospf@ietf.org>
Subject: draft-ietf-ospf-yang-03 questions and doubts

 <= /span>

Folks<= /p>

 =

I have a doubt about dra= ft-ietf-ospf-yang-03.  Please let me know your thoughts on the followi= ng.

 =

The text is OSPFv2-speci= fic in places.  I think that it would be better to define separate top= -level groupings and containers for OSPFv2 and OSPFv3 and define common gro= upings and containers, where possible, that are used by both.

 =

For example, grouping in= terface-operation contains the following, which is incorrect for OSPFv3.

 =

-&nbs= p;         leaf dr with typ= e ipv4-address

-&nbs= p;         leaf bdr with ty= pe ipv4-address.

 

I think that it would be= better to define something along the following lines.

 =

-&nbs= p;         ospfv3-interface= -operation {

o   uses interface-c= onfig

o   uses ospf-common= -interface-operation

o   leaf dr {

§  type if:interfac= e-ref

§  description:

·           &nbs= p;       "The remote interface ID u= sed by the Designated Router on

·           &nbs= p;       this link.  This is the in= terface index of the interface local to the DR.";

o   etc

-&nbs= p;         ospfv2-interface= -operation {

o   uses interface-c= onfig

o   uses ospf-common= -interface-operation

o   leaf dr {

§    &nbs= p;      type inet:ipv4-address;

§    &nbs= p;      description "Designated Router (= DR) IP address.";

o   etc.<= /span>

 =

Regards

Alan Davey

 =

--_000_BN3PR0201MB10597DBA718D60998EA82E0FF9950BN3PR0201MB1059_-- From nobody Tue Apr 12 12:09:23 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11D112E69E for ; Tue, 12 Apr 2016 12:09:22 -0700 (PDT) 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, 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 FbqkG4cDdSJ4 for ; Tue, 12 Apr 2016 12:09:21 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F2912E6D7 for ; Tue, 12 Apr 2016 12:09:16 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-3d-570d415af889 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 5D.03.09012.A514D075; Tue, 12 Apr 2016 20:41:30 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0248.002; Tue, 12 Apr 2016 15:09:15 -0400 From: Jeff Tantsura To: "Acee Lindem (acee)" , "ospf@ietf.org" Thread-Topic: WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment" Thread-Index: AQHRf/Ho6WRxQA5zQE2bUJRokiTbP5+G1Qyg///WZIA= Date: Tue, 12 Apr 2016 19:09:14 +0000 Message-ID: References: <1B502206DFA0C544B7A60469152008635802F09C@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008635802F09C@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZXLonUDfKkTfc4Nkla4vJb+cxW7Tcu8fu wOQx5fdGVo8lS34yBTBFcdmkpOZklqUW6dslcGWcve9WcIaz4uaD2ywNjGs4uxg5OSQETCRO v93NAmGLSVy4t56ti5GLQ0jgKKPEv72zWEESQgLLGSU27KoGsdkEDCT+fzsO1iAi4CVxY2IT O4gtLBAnsWj3VnaIeLzEtOV9jBC2lcSOpi1MXYwcHCwCqhLXHmiChHkF7CXWrT/KDDE+X2La 7/dgIzkF/CR+bvrFBmIzAt3z/dQaJhCbWUBc4taT+UwQdwpILNlznhnCFpV4+fgf2JmiAroS L+6uhfpFSeLj7/nsIGuZBTQl1u/ShzCtJfb1mkJMVJSY0v2QHeIaQYmTM5+wTGAUn4Vk2SyE 5lkIzbOQNM9C0ryAkXUVI0dpcUFObrqRwSZGYCQdk2DT3cF4f7rnIUYBDkYlHt4FYTzhQqyJ ZcWVuYcYJTiYlUR4q114w4V4UxIrq1KL8uOLSnNSiw8xSnOwKInzNgb/CxMSSE8sSc1OTS1I LYLJMnFwSjUwqlkHG82xO3xVd5mQ/UHtjWcZj8dOyCy/v9x0R2D7jmXHT3o8rlwuf3yp57m9 yzKt3jEtv/NRMejr1rOmGtevBGvPWlQgxqB9Wk6g/qvsKueYkxafD5rWeK4PFX8yi6tkWuL0 xXK3Z+z4Vvczvuz/rCVTTy6POvtlcue5y2HMKybPCe6eVh0Y9k6JpTgj0VCLuag4EQAkexdx oAIAAA== Archived-At: Subject: Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 19:09:23 -0000 SGkgQWNlZSwNCg0KSSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoZSBkcmFmdCENCg0KQ2hlZXJzLA0K SmVmZg0KDQoNCg0KDQoNCg0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBP U1BGIFttYWlsdG86b3NwZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWNlZSBMaW5k ZW0gKGFjZWUpDQo+U2VudDogV2VkbmVzZGF5LCBNYXJjaCAxNiwgMjAxNiA3OjA5IFBNDQo+VG86 IE9TUEYgV0cgTGlzdA0KPlN1YmplY3Q6IFtPU1BGXSBXRyBBZG9wdGlvbiBQb2xsIGZvciAiVXNp bmcgT3BlcmF0b3ItZGVmaW5lZCBUTFZzIGZvciBBZ2lsZSBTZXJ2aWNlIERlcGxveW1lbnQiDQo+ DQo+V2XigJl2ZSBkaXNjdXNzZWQgdGhpcyBkcmFmdCBhIG51bWJlciBvZiB0aW1lcy4gSW4gbXkg b3BpbmlvbiwgaXQgc2VlbXMgbGlrZSBhIHVzZWZ1bCBtZWNoYW5pc20gaWYgb25lIGVudmlzaW9u cyBhIGdlbmVyYWxpemVkIEFQSSBiZXR3ZWVuIE9TUEYgYW5kIHVzZXIgYW5kIHRoaXJkLXBhcnR5 IGFwcGxpY2F0aW9ucyB0byBjb252ZXkgYXBwbGljYXRpb24tc3BlY2lmaWMgaW5mb3JtYXRpb24g bGVhcm5lZCBmcm9tIG90aGVyIE9TUEYgcm91dGVycy4gSW4gbWFueSByZXNwZWN0cywgdGhpcyBo YXMgYWxyZWFkeSBiZWVuIGVudmlzaW9uZWQgZm9yIE9TUEYgTm9kZSBUYWdzLiBQbGVhc2UgaW5k aWNhdGUgeW91ciBvcGluaW9uIG9uIHRoaXMgZHJhZnQgYmVmb3JlIE1hcmNoIDMxc3QsIDIwMTYu DQo+DQo+VGhhbmtzLA0KPkFjZWUNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPk9TUEYgbWFpbGluZyBsaXN0DQo+T1NQRkBpZXRmLm9yZw0KPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3NwZg0K From nobody Tue Apr 12 13:06:09 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5680A12D6F1; Tue, 12 Apr 2016 13:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 vJ8aYd-tSdTJ; Tue, 12 Apr 2016 13:06:06 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::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 030A212DB50; Tue, 12 Apr 2016 13:06:02 -0700 (PDT) Received: by mail-ob0-x229.google.com with SMTP id k9so18979547obk.2; Tue, 12 Apr 2016 13:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=T06wtnyZ07E1a0MRNQO/X7wHtplQ9gjDRhY/4tJs8oE=; b=M4z3r3YbJK+ABoIYBsRBDOAn6FQs7XYhpo7m3nqpm11dL//UTKvaXN1fbiyk/U4FCI sHXGW0dRZxO8/bz16hXCM7FLhPG199TGOKULuzpP/e4WY1kZ5IoZO1ooZsRuIM9fmSnC 5YmGto4hBve5QFxR6TjppnAPwOnGCWqHjYUbKlW6Oe4BaAIba2UjUC89OG2TBByLwCyv qyR/x6j6ch5IJq0zJd5/zOwaLz7cGhwVhZP0mLGzpnW5vMZB9LU92D3OyWXWlW0BL7nI 6EuKnCVRMlSr6RwSHSs08cXiZ7n8dYs2lcQs2x7R2g2mi+ZWC1/eE4ma81BnGFkCvlEa zCJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=T06wtnyZ07E1a0MRNQO/X7wHtplQ9gjDRhY/4tJs8oE=; b=WkQxsWJrDlWUgTRccgs+Bq9+iiPxL1CJ5zHYr0O1sIIes/go4BAU5nrBxPYeUbHwjK VVIIo28fTf5BdXyftptq4+s4xFKMGpqztanNG/QWzZ1UNeoLMrx1kpAj0rNED85FxliQ AzBSTbhcCHTxaMja9CXiA/iwZq4oHLPCg0bg49tUAItByc1l9/Awu346hvgRDq/GUyI9 UwJ4d+PeBrG6aWG0FEi2/IYiEP7uVsFd7XEjeSWsAmQtjqbyQ3wIcyTP/ZwMPf7JiwZw DEpcg1CSR3NYJL6ZduZQdGc9yVeqbeyY/vxNlt3/o13r25km//aEPMk1DzeiegwP+WYk 3nIA== X-Gm-Message-State: AOPr4FVfQ815buIi9nXm/7xPUmVxUpJWFNlTPqfq8hrq7mbA+y02cPz161DrOA5l+YutfjtiJ8kEe4o+VUIguQ== MIME-Version: 1.0 X-Received: by 10.182.38.233 with SMTP id j9mr2400872obk.57.1460491562315; Tue, 12 Apr 2016 13:06:02 -0700 (PDT) Received: by 10.60.115.168 with HTTP; Tue, 12 Apr 2016 13:06:02 -0700 (PDT) Date: Tue, 12 Apr 2016 16:06:02 -0400 Message-ID: From: Alia Atlas To: OSPF List , draft-ietf-ospf-sbfd-discriminator@ietf.org Content-Type: multipart/alternative; boundary=001a11c33936c4f90f05304f3040 Archived-At: Subject: [OSPF] AD review of draft-ietf-ospf-sbfd-disciminator-03 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 20:06:07 -0000 --001a11c33936c4f90f05304f3040 Content-Type: text/plain; charset=UTF-8 First, thanks very much to the authors Manav, Carlos, Sam, and Trilok for their work on this document. As is customary, I have done my AD review before requesting IETF Last Call. In this case, I have a couple minor comments that I would like the authors to address during IETF Last Call. In addition to IETF Last Call, I am requesting a Routing Directorate review. I expect that both of these will conclude by April 27 and that this draft will be on the IESG telechat on May 5. During this period, it is critical that the authors be extremely responsive and update the draft as appropriate so that the process runs as smoothly and quickly as feasible Minor comments: 1) Draft references RFC 4970 instead of RFC 7770 which obsoleted it. In addition to updating the reference, please reread RFC 7770 and be certain that there are no surprises that can come from multiple RI LSAs being allowed or other nuances. I personally don't see any right now. 2) In Sec 2.1, it specifies "Routers that do not recognize the S-BFD Discriminator TLV Type MUST ignore the TLV." I don't think that this document can mandate what routers that don't implement it do. I went back through RFC 7770 and don't see any description *sigh* for the expected router behavior if a sub-TLV isn't recognized. This might be a very useful errata to add to RFC 7770 - unless someone else can find where the behavior is specified. For this draft, please think about what "ignoring the TLV" means and what routers that do not know about this draft are likely to do - and then update this sentence. Thanks! Alia --001a11c33936c4f90f05304f3040 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
First, thanks very much to the authors Manav, Carlos,= Sam, and Trilok for their work on this document. =C2=A0

As is customary, I have done my AD review before requesting IETF Las= t Call.=C2=A0 In this case, I have a couple minor comments that I would lik= e the authors to address during IETF Last Call.

In= addition to IETF Last Call, I am requesting a Routing Directorate review.= =C2=A0 I expect that both of these will conclude by April 27 and that this = draft will be on the IESG telechat on May 5.=C2=A0 During this period, it i= s critical that the authors be extremely responsive and update the draft as= appropriate so that the process runs as smoothly and quickly as feasible


Minor comments:
=C2=A0 =C2=A01) Draft= references RFC 4970 instead of RFC 7770 which obsoleted it.=C2=A0 In addit= ion to updating the reference, please reread RFC 7770 and be certain that t= here are no surprises that can come from multiple RI LSAs being allowed or = other nuances.=C2=A0 I personally don't see any right now.
=C2=A0 =C2=A02) In Sec 2.1, it specifies=C2=A0"Routers th= at do not recognize the S-BFD Discriminator TLV Type MUST=C2=A0ignore the T= LV." =C2=A0I don't think that this document can mandate what route= rs that don't implement it do.=C2=A0 I went back through RFC 7770 and d= on't see any description *sigh* for the expected router behavior if a s= ub-TLV isn't recognized.=C2=A0 This might be a very useful errata to ad= d to RFC 7770 - unless someone else can find where the behavior is specifie= d.=C2=A0 For this draft, please think about what "ignoring the TLV&quo= t; means and what routers that do not know about this draft are likely to d= o - and then update this sentence.

Thanks!
Alia
--001a11c33936c4f90f05304f3040-- From nobody Tue Apr 12 15:50:00 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBC312E21F; Tue, 12 Apr 2016 15:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 wLHU82vKGjnX; Tue, 12 Apr 2016 15:49:57 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A1A12E3E7; Tue, 12 Apr 2016 15:49:56 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id p188so41325114oih.2; Tue, 12 Apr 2016 15:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=CqZJ96HIKnPb/1e7+LKiBfJoMp02ogXfvb04h7RvyjQ=; b=DB+X50L+kjCcZ+26RoZByTZOn/rMFXqeaiEponRYVMBbMhTSO/sxSi2peFhnQZEcjX 34RM7MVjBj8ig9oSPPMBaNkqFdpDAnwlJQAq8x/fsupeveWJ6Hw07eNczqdI0UDZnSht fu0Aqh4hiQyrVjjPfbgl2b2hTMWCxNIdw63tnnJKg51diG+XWAF0xxwZFV6oEBcKm5Ym n9NXDeJGdDujpCcqGtejsbDKnj1UciLwUqpHMHFQXq8PkWbM2hwVkU7EbV1mAQeWp82g i2BkdLB/KNp768uPqQWk6RrMqkkD06pw+u5zGQYTtKZX988RJ+ULC3KGBhCzKifWBRmw UGbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=CqZJ96HIKnPb/1e7+LKiBfJoMp02ogXfvb04h7RvyjQ=; b=atEKZknCw9vL5l8CKtq1ldNoBDec+D+AcJQDj0/8rZBJCI4VoNdd8h0WiGtmRAMomC aVhx2mObczbxqC9UwL+Ifkqjmai2ecCmrOxZmyWcIIJaYJB2qSV/iD7VifKd+xaBI+Bq yw+GJNj8i+CvGSQ4sAejRtlrgrIOHRPVa5CbkPb2A5u3mFcGd5KdFeWadd0WzaSw1LoI ClVc076LWR6QeZ05yZesu//6TznXiuqN66K7b0Ymx3UrLUXKLY+jSzJmVWCy8qBtyq1S DvKu2bTuyjUcCOj6DzPJhuxXESXbD2iKsN41OvVAFtOJAHeplInt/QErbB0jaaN5k/Qr 3oXA== X-Gm-Message-State: AOPr4FVr06NrtzAsYh0VYxaRBB8TqSqljYxYHbDReDpT8uLO+jl0DgRAwG7Ps6VxDvJdSTEXcUJ3yLu+Yb/u9g== MIME-Version: 1.0 X-Received: by 10.202.90.3 with SMTP id o3mr2708228oib.96.1460501396131; Tue, 12 Apr 2016 15:49:56 -0700 (PDT) Received: by 10.60.115.168 with HTTP; Tue, 12 Apr 2016 15:49:56 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Apr 2016 18:49:56 -0400 Message-ID: From: Alia Atlas To: OSPF List , draft-ietf-ospf-sbfd-discriminator@ietf.org Content-Type: multipart/alternative; boundary=001a113d5edce917ae0530517a7d Archived-At: Subject: Re: [OSPF] AD review of draft-ietf-ospf-sbfd-disciminator-03 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 22:49:58 -0000 --001a113d5edce917ae0530517a7d Content-Type: text/plain; charset=UTF-8 On Tue, Apr 12, 2016 at 4:06 PM, Alia Atlas wrote: > First, thanks very much to the authors Manav, Carlos, Sam, and Trilok for > their work on this document. > > As is customary, I have done my AD review before requesting IETF Last > Call. In this case, I have a couple minor comments that I would like the > authors to address during IETF Last Call. > > In addition to IETF Last Call, I am requesting a Routing Directorate > review. I expect that both of these will conclude by April 27 and that > this draft will be on the IESG telechat on May 5. During this period, it > is critical that the authors be extremely responsive and update the draft > as appropriate so that the process runs as smoothly and quickly as feasible > > > Minor comments: > 1) Draft references RFC 4970 instead of RFC 7770 which obsoleted it. > In addition to updating the reference, please reread RFC 7770 and be > certain that there are no surprises that can come from multiple RI LSAs > being allowed or other nuances. I personally don't see any right now. > > 2) In Sec 2.1, it specifies "Routers that do not recognize the S-BFD > Discriminator TLV Type MUST ignore the TLV." I don't think that this > document can mandate what routers that don't implement it do. I went back > through RFC 7770 and don't see any description *sigh* for the expected > router behavior if a sub-TLV isn't recognized. This might be a very useful > errata to add to RFC 7770 - unless someone else can find where the behavior > is specified. For this draft, please think about what "ignoring the TLV" > means and what routers that do not know about this draft are likely to do - > and then update this sentence. > Thanks to Les for politely pointing out the sentence I'd skimmed over in RFC 7770. The behavior for unrecognized types is in Sec 2.3 so this draft should just reference it. Thanks, Alia > Thanks! > Alia > --001a113d5edce917ae0530517a7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 12, 2016 at 4:06 PM, Alia Atlas <akatlas= @gmail.com> wrote:
First, thanks v= ery much to the authors Manav, Carlos, Sam, and Trilok for their work on th= is document. =C2=A0

As is customary, I have done m= y AD review before requesting IETF Last Call.=C2=A0 In this case, I have a = couple minor comments that I would like the authors to address during IETF = Last Call.

In addition to IETF Last Call, I am req= uesting a Routing Directorate review.=C2=A0 I expect that both of these wil= l conclude by April 27 and that this draft will be on the IESG telechat on = May 5.=C2=A0 During this period, it is critical that the authors be extreme= ly responsive and update the draft as appropriate so that the process runs = as smoothly and quickly as feasible


Minor comm= ents:
=C2=A0 =C2=A01) Draft references RFC 4970 instead of RFC 77= 70 which obsoleted it.=C2=A0 In addition to updating the reference, please = reread RFC 7770 and be certain that there are no surprises that can come fr= om multiple RI LSAs being allowed or other nuances.=C2=A0 I personally don&= #39;t see any right now.

=C2=A0 =C2=A02) In Sec 2.= 1, it specifies=C2=A0"Routers that do not recognize the S-BFD Discrimi= nator TLV Type MUST=C2=A0ignore the TLV." =C2=A0I don't think that= this document can mandate what routers that don't implement it do.=C2= =A0 I went back through RFC 7770 and don't see any description *sigh* f= or the expected router behavior if a sub-TLV isn't recognized.=C2=A0 Th= is might be a very useful errata to add to RFC 7770 - unless someone else c= an find where the behavior is specified.=C2=A0 For this draft, please think= about what "ignoring the TLV" means and what routers that do not= know about this draft are likely to do - and then update this sentence.

Thanks to Les for politely pointi= ng out the sentence I'd skimmed over in RFC 7770. The behavior for unre= cognized types is in Sec 2.3 so this draft
should just refer= ence it.

Thanks,
Alia
= =C2=A0
=C2=A0
<= div>Thanks!
Alia

--001a113d5edce917ae0530517a7d-- From nobody Tue Apr 12 17:32:41 2016 Return-Path: X-Original-To: ospf@ietf.org Delivered-To: ospf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA9C12DA00; Tue, 12 Apr 2016 17:32:40 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160413003240.32301.55455.idtracker@ietfa.amsl.com> Date: Tue, 12 Apr 2016 17:32:40 -0700 Archived-At: Cc: ospf-chairs@ietf.org, ospf@ietf.org, draft-ietf-ospf-sbfd-discriminator@ietf.org Subject: [OSPF] Last Call: (OSPF extensions to advertise S-BFD Target Discriminator) to Proposed Standard X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 00:32:40 -0000 The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'OSPF extensions to advertise S-BFD Target Discriminator' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-04-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood the S-BFD discriminator values associated with a target network identifier. This mechanism is applicable to both OSPFv2 and OSPFv3. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ospf-sbfd-discriminator/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ospf-sbfd-discriminator/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Apr 13 00:42:09 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0B512DBCD; Wed, 13 Apr 2016 00:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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.996, 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 Vwo8qLImAr7R; Wed, 13 Apr 2016 00:42:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6781612DB0B; Wed, 13 Apr 2016 00:42:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHF90335; Wed, 13 Apr 2016 07:42:01 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 13 Apr 2016 08:41:58 +0100 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; Wed, 13 Apr 2016 15:41:37 +0800 From: Xuxiaohu To: "Acee Lindem (acee)" , "draft-ietf-ospf-mpls-elc@ietf.org" Thread-Topic: Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00 Thread-Index: AQHRlBj81Lqya0qQckSeteuSX15/fJ+HehHg Date: Wed, 13 Apr 2016 07:41:36 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539826@NKGEML515-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] 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.0A090205.570DF84B.0070, 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: a599237cdaaf9e338ff22176db06957d Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 07:42:08 -0000 SGkgQWNlZSwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIG15IHJlc3Bv bnNlIGluIGxpbmUuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWNl ZSBMaW5kZW0gKGFjZWUpIFttYWlsdG86YWNlZUBjaXNjby5jb21dDQo+IFNlbnQ6IFR1ZXNkYXks IEFwcmlsIDEyLCAyMDE2IDE6MzkgQU0NCj4gVG86IGRyYWZ0LWlldGYtb3NwZi1tcGxzLWVsY0Bp ZXRmLm9yZw0KPiBDYzogT1NQRiBXRyBMaXN0DQo+IFN1YmplY3Q6IFNpZ25hbGluZyBFbnRyb3B5 IExhYmVsIENhcGFiaWxpdHkgVXNpbmcgT1NQRiAtDQo+IGRyYWZ0LWlldGYtb3NwZi1tcGxzLWVs Yy0wMA0KPiANCj4gQXV0aG9ycywNCj4gDQo+IFdlIHdpbGwgc29vbiBiZSBwcm9ncmVzc2luZyB0 aGUgT1NQRnYyIFNSIGRyYWZ0LiBXaGF0IGlzIHlvdXIgaW50ZW50IGZvciB0aGlzDQo+IGRyYWZ0 PyBJdCBpcyBtaXNzaW5nOg0KPiANCj4gICAgIDEuIEEgZmlndXJlIHdpdGggdGhlIFJJIGVuY29k aW5nIGxpa2Ugb3RoZXIgT1NQRiBkb2N1bWVudHMNCg0KV2lsbCBhZGQgdHdvIGZpZ3VyZXMgZm9y IEVMQyBUTFYgYW5kIFJMU0RDIFRMViByZXNwZWN0aXZlbHkuDQoNCj4gICAgIDIuIERpc2N1c3Np b24gYXMgdG8gcHJlY2lzZWx5IGhvdyB0aGUgY2FwYWJpbGl0eSB3b3VsZCBiZSB1c2VkIGJ5IGEg cm91dGVyIGluDQo+IGFuIE9TUEYgcm91dGluZyBkb21haW4uIEZvciBleGFtcGxlLCBtdXN0IGEg cm91dGVyIHJlbW92ZSB0aGUgRUwgaWYgdGhlDQo+IG5leHQtaG9wIGRvZXNu4oCZdCBzdXBwb3J0 IGl0Pw0KDQpUaGlzIGRvY3VtZW50IG9ubHkgZGVzY3JpYmVzIGhvdyB0aGUgRUxDIGFuZCBSTFNE QyBhcmUgYWR2ZXJ0aXNlZCB2aWEgT1NQRi4gQXMgZm9yIGhvdyB0aGVzZSBjYXBhYmlsaXRpZXMg d291bGQgYmUgdXNlZCBhcmUgYWN0dWFsbHkgZGVzY3JpYmVkIGluIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1wbHMtc3ByaW5nLWVudHJvcHktbGFiZWwuIEJ5IHRoZSB3 YXksIGEgcm91dGVyIGRvZXNuJ3QgbmVlZCB0byByZW1vdmUgdGhlIEVMIGlmIHRoZSBuZXh0LWhv cCBkb2Vzbid0IHN1cHBvcnQgaXQuIFRoZSBvbmx5IHJlcXVpcmVtZW50IG9uIHVzaW5nIEVMIGlz OiBBbiBpbmdyZXNzIExTUiBjYW5ub3QgaW5zZXJ0IEVMcyBmb3IgcGFja2V0cyBnb2luZyBpbnRv IGEgZ2l2ZW4gdHVubmVsIHVubGVzcyBhbiBlZ3Jlc3MgTFNSIGhhcyBpbmRpY2F0ZWQgdmlhIHNp Z25hbGluZyB0aGF0IGl0IGNhbiBwcm9jZXNzIEVMcyBvbiB0aGF0IHR1bm5lbC4NCg0KPiAgICAg My4gQSBkaXNjdXNzaW9uIG9mIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgZm9yIHRoZSBuZXcgUm91 dGVyLUluZm9ybWF0aW9uDQo+IExTQSBjYXBhYmlsaXR5Lg0KDQpJcyBpdCBlbm91Z2ggdG8gYWRk IHRoZSBmb2xsb3dpbmcgdGV4dDoNCg0KIlRvIGJlIGNvbXBhdGlibGUgd2l0aCBSRkM3NzcwLCBF TEMgYW5kIFJMU0RDIFRMVnMgU0hPVUxEIGNvbnRpbnVlIHRvIGJlIGFkdmVydGlzZWQgaW4gdGhl IGZpcnN0IGluc3RhbmNlLCBpLmUuLCAwLCBvZiB0aGUgUm91dGVyIEluZm9ybWF0aW9uIExTQS4i DQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IFRoYW5rcywNCj4gQWNlZQ0KDQo= From nobody Wed Apr 13 01:10:15 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9AE12D8A1; Wed, 13 Apr 2016 01:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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.996, 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 ytNtx_-aW1ZO; Wed, 13 Apr 2016 01:10:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F9712D80C; Wed, 13 Apr 2016 01:10:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHF94365; Wed, 13 Apr 2016 08:10:05 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 13 Apr 2016 09:10:05 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Wed, 13 Apr 2016 16:09:55 +0800 From: Xuxiaohu To: "Carlos Pignataro (cpignata)" , "Acee Lindem (acee)" , "draft-ietf-ospf-mpls-elc@ietf.org" Thread-Topic: [OSPF] Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00 Thread-Index: AQHRlEvBpcuRzR4OpEWJ4X+miwJxNJ+Hhvew Date: Wed, 13 Apr 2016 08:09:55 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539860@NKGEML515-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.570DFEDE.001A, 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: 9448aad51e50029710ab9330b5711744 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 08:10:13 -0000 Hi Carlos, Thanks for your comments. Please see my response inline. > -----Original Message----- > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Carlos Pignataro > (cpignata) > Sent: Tuesday, April 12, 2016 7:42 AM > To: Acee Lindem (acee); draft-ietf-ospf-mpls-elc@ietf.org > Cc: OSPF WG List > Subject: Re: [OSPF] Signaling Entropy Label Capability Using OSPF - > draft-ietf-ospf-mpls-elc-00 >=20 > Authors, >=20 > For this draft, it would be useful to also discuss and understand a few o= ther > things, such as: >=20 > I. Has an approach similar to FAT-PW for LB (instead of the {ELI; EL} Ent= ropy > Label approach) been considered? It would save label stack entries, and a= llow > precise positioning. Has this been ruled out? This document only describes how the ELC and RLSDC are advertised via OSPF.= How these capabilities would be used are actually described in https://too= ls.ietf.org/html/draft-ietf-mpls-spring-entropy-label. As for an approach s= imilar to FAT-PW, it may deserve a separate doc. > II. Definition of behavior for networks with hybrid support (some nodes s= upport > ELC, some do not). Like, can/should EL;ELI be used if some nodes in the p= ath do > not support it? This will be a very common case. Some downstream NHs migh= t > support it and some don=B9t. See above. > III. Are there multi instance or flooding scope implications? As for multi-instances, the following text would be added into the next rev= ision if the WG believe it's appropriate: "To be compatible with RFC7770, ELC and RLSDC TLVs SHOULD continue to be ad= vertised in the first instance, i.e., 0, of the Router Information LSA." As for the flooding scope, it said in the doc that "The scope of the advert= isement depends on the application but it is recommended that it SHOULD be = AS-scoped." > IV. As specified, there is no relationship between ELC and RLDC. Seems th= ere is. > Do these need to be supported simultaneously? Say, a node does not suppor= t > ELC but advertises RLDC, what=B9s that mean? ELC and RLDC don't need to be supported simultaneously. For instance, a non= -egress node doesn't need to support ELC but it's desirable to advertise th= e RLDC. > V. There are several operational considerations which are just unadressed= . > Say, a new LC is inserted in a node, which does not support ELC, or suppo= rts a > RLD smaller than what=B9s been advertised. Or... As for ELC, there is no difference from the current use of ELC as specified= in RFC6790. In other words, a router should not advertise the ELC unless a= ll of its LCs support ELC. In fact, this point has been raised before, the = WG consensus was that there is no need to mention it explicitly in the doc,= if I remembered it correctly. As for ELD, it said in the doc that "If a ro= uter has multiple linecards with different capabilities of reading the maxi= mum label stack depth, the router MUST advertise the smallest one in the RL= DC TLV. " > VI. No security implications sounds quite optimistic :-) Do you have any good suggestion on the security considerations? Best regards, Xiaohu > Thanks, >=20 > < Carlos. >=20 > -----Original Message----- > From: OSPF on behalf of "Acee Lindem (acee)" > > Date: Monday, April 11, 2016 at 2:38 PM > To: "draft-ietf-ospf-mpls-elc@ietf.org" > Cc: OSPF WG List > Subject: [OSPF] Signaling Entropy Label Capability Using OSPF - > draft-ietf-ospf-mpls-elc-00 >=20 > >Authors, > > > >We will soon be progressing the OSPFv2 SR draft. What is your intent > >for this draft? It is missing: > > > > 1. A figure with the RI encoding like other OSPF documents > > 2. Discussion as to precisely how the capability would be used by a > >router in an OSPF routing domain. For example, must a router remove the > >EL if the next-hop doesn=B9t support it? > > 3. A discussion of backward compatibility for the new > >Router-Information LSA capability. > > > >Thanks, > >Acee > > > >_______________________________________________ > >OSPF mailing list > >OSPF@ietf.org > >https://www.ietf.org/mailman/listinfo/ospf >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From nobody Wed Apr 13 05:41:31 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C029C12E141; Wed, 13 Apr 2016 05:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 0WvWFE9_GpVc; Wed, 13 Apr 2016 05:41:20 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE57612E109; Wed, 13 Apr 2016 05:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3022; q=dns/txt; s=iport; t=1460551279; x=1461760879; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0RZ39WyoHqb0GmUhPYVdJR0Pmzmw9sYZdYiDVBcRDnM=; b=BA6d56C7G6kLzB2US+xl2/NXPgmkRZANWFl84LNTPhj80wdx17CEqrXL ztlg5DTiqKTUIC3JYVbl78W+Qxn/Xdhu56hqb/IBpwgyMZEZzwAd0CbKu 3S87GB2IMiFhdAZz2aX8rbP4GxvBspgzK/z0BMurVDWsH3vHMnuEKkQG8 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgCbPQ5X/4sNJK1egzdTfQa4OIIPA?= =?us-ascii?q?Q2BdCKFbAIcgSA4FAEBAQEBAQFlJ4RBAQEBAwEjEUUMBAIBCBEEAQEDAiMDAgI?= =?us-ascii?q?CMBQBCAgCBAENBYggCA6wTJJHAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQR8iG6BA?= =?us-ascii?q?oQ9gwKCVgEEjVCKOAGFdogWgWeETohbjyYBHgEBQoNnbIh8fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,479,1454976000"; d="scan'208";a="90978894" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Apr 2016 12:41:18 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u3DCfI8S020846 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Apr 2016 12:41:18 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Apr 2016 08:41:17 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Wed, 13 Apr 2016 08:41:17 -0400 From: "Acee Lindem (acee)" To: Xuxiaohu , "draft-ietf-ospf-mpls-elc@ietf.org" Thread-Topic: Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00 Thread-Index: AQHRlBj81Lqya0qQckSeteuSX15/fJ+HehHggABhRAA= Date: Wed, 13 Apr 2016 12:41:17 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539826@NKGEML515-MBX.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539826@NKGEML515-MBX.china.huawei.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.202] Content-Type: text/plain; charset="utf-8" Content-ID: <469619767C4A0F4BB8ADAAB7D1CDCC8D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 12:41:31 -0000 SGkgVGlnZXIsIA0KDQpPbiA0LzEzLzE2LCAzOjQxIEFNLCAiWHV4aWFvaHUiIDx4dXhpYW9odUBo dWF3ZWkuY29tPiB3cm90ZToNCg0KPkhpIEFjZWUsDQo+DQo+VGhhbmtzIGZvciB5b3VyIGNvbW1l bnRzLiBQbGVhc2Ugc2VlIG15IHJlc3BvbnNlIGluIGxpbmUuDQo+DQo+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogQWNlZSBMaW5kZW0gKGFjZWUpIFttYWlsdG86YWNlZUBj aXNjby5jb21dDQo+PiBTZW50OiBUdWVzZGF5LCBBcHJpbCAxMiwgMjAxNiAxOjM5IEFNDQo+PiBU bzogZHJhZnQtaWV0Zi1vc3BmLW1wbHMtZWxjQGlldGYub3JnDQo+PiBDYzogT1NQRiBXRyBMaXN0 DQo+PiBTdWJqZWN0OiBTaWduYWxpbmcgRW50cm9weSBMYWJlbCBDYXBhYmlsaXR5IFVzaW5nIE9T UEYgLQ0KPj4gZHJhZnQtaWV0Zi1vc3BmLW1wbHMtZWxjLTAwDQo+PiANCj4+IEF1dGhvcnMsDQo+ PiANCj4+IFdlIHdpbGwgc29vbiBiZSBwcm9ncmVzc2luZyB0aGUgT1NQRnYyIFNSIGRyYWZ0LiBX aGF0IGlzIHlvdXIgaW50ZW50DQo+PmZvciB0aGlzDQo+PiBkcmFmdD8gSXQgaXMgbWlzc2luZzoN Cj4+IA0KPj4gICAgIDEuIEEgZmlndXJlIHdpdGggdGhlIFJJIGVuY29kaW5nIGxpa2Ugb3RoZXIg T1NQRiBkb2N1bWVudHMNCj4NCj5XaWxsIGFkZCB0d28gZmlndXJlcyBmb3IgRUxDIFRMViBhbmQg UkxTREMgVExWIHJlc3BlY3RpdmVseS4NCg0KQ2FuIHlvdSBjb21lIHVwIHdpdGggYSBiZXR0ZXIg bmFtZSB0aGFuIFJMU0RDPyBJdCBhcHBlYXJzIHRoaXMgd291bGQNCm9idmlhdGUgdGhlIG5lZWQg Zm9yIHRoZSByZWNlbnQgTVNEIHByb3Bvc2FsIGJ1dCB0aGF0IGlzIGEgbXVjaCBiZXR0ZXINCm5h bWUuIA0KDQo+DQo+PiAgICAgMi4gRGlzY3Vzc2lvbiBhcyB0byBwcmVjaXNlbHkgaG93IHRoZSBj YXBhYmlsaXR5IHdvdWxkIGJlIHVzZWQgYnkgYQ0KPj5yb3V0ZXIgaW4NCj4+IGFuIE9TUEYgcm91 dGluZyBkb21haW4uIEZvciBleGFtcGxlLCBtdXN0IGEgcm91dGVyIHJlbW92ZSB0aGUgRUwgaWYg dGhlDQo+PiBuZXh0LWhvcCBkb2VzbuKAmXQgc3VwcG9ydCBpdD8NCj4NCj5UaGlzIGRvY3VtZW50 IG9ubHkgZGVzY3JpYmVzIGhvdyB0aGUgRUxDIGFuZCBSTFNEQyBhcmUgYWR2ZXJ0aXNlZCB2aWEN Cj5PU1BGLiBBcyBmb3IgaG93IHRoZXNlIGNhcGFiaWxpdGllcyB3b3VsZCBiZSB1c2VkIGFyZSBh Y3R1YWxseSBkZXNjcmliZWQNCj5pbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1tcGxzLXNwcmluZy1lbnRyb3B5LWxhYmVsLiBCeQ0KPnRoZSB3YXksIGEgcm91dGVyIGRv ZXNuJ3QgbmVlZCB0byByZW1vdmUgdGhlIEVMIGlmIHRoZSBuZXh0LWhvcCBkb2Vzbid0DQo+c3Vw cG9ydCBpdC4gVGhlIG9ubHkgcmVxdWlyZW1lbnQgb24gdXNpbmcgRUwgaXM6IEFuIGluZ3Jlc3Mg TFNSIGNhbm5vdA0KPmluc2VydCBFTHMgZm9yIHBhY2tldHMgZ29pbmcgaW50byBhIGdpdmVuIHR1 bm5lbCB1bmxlc3MgYW4gZWdyZXNzIExTUiBoYXMNCj5pbmRpY2F0ZWQgdmlhIHNpZ25hbGluZyB0 aGF0IGl0IGNhbiBwcm9jZXNzIEVMcyBvbiB0aGF0IHR1bm5lbC4NCg0KQ2FuIHlvdSBhZGQgYSBz aG9ydCBzZWN0aW9uIHJlZmVyZW5jaW5nIHRoZSBhcHBsaWNhYmxlIHNlY3Rpb24gaW4gdGhpcw0K ZG9jdW1lbnQuIA0KDQoNCj4NCj4+ICAgICAzLiBBIGRpc2N1c3Npb24gb2YgYmFja3dhcmQgY29t cGF0aWJpbGl0eSBmb3IgdGhlIG5ldw0KPj5Sb3V0ZXItSW5mb3JtYXRpb24NCj4+IExTQSBjYXBh YmlsaXR5Lg0KPg0KPklzIGl0IGVub3VnaCB0byBhZGQgdGhlIGZvbGxvd2luZyB0ZXh0Og0KPg0K PiJUbyBiZSBjb21wYXRpYmxlIHdpdGggUkZDNzc3MCwgRUxDIGFuZCBSTFNEQyBUTFZzIFNIT1VM RCBjb250aW51ZSB0byBiZQ0KPmFkdmVydGlzZWQgaW4gdGhlIGZpcnN0IGluc3RhbmNlLCBpLmUu LCAwLCBvZiB0aGUgUm91dGVyIEluZm9ybWF0aW9uIExTQS4iDQoNCkkgd2FzIHRhbGtpbmcgbW9y ZSBvbiB0aGUgbGV2ZWwgb2YgdXNhZ2Ugb2YgdGhlIGNhcGFiaWxpdHkgdGhhbg0KYWR2ZXJ0aXNl bWVudC4gU2luY2UgdGhpcyBpcyBuZXcsIHRoZXJlIHNob3VsZCBiZSBhbnkgUkkgTFNBcw0KY29u c2lkZXJhdGlvbnMuIA0KDQpUaGFua3MsDQpBY2VlICANCg0KDQoNCj4NCj5CZXN0IHJlZ2FyZHMs DQo+WGlhb2h1DQo+DQo+PiBUaGFua3MsDQo+PiBBY2VlDQo+DQoNCg== From nobody Wed Apr 13 07:08:16 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F5E12E2BB for ; Wed, 13 Apr 2016 07:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jakma-org.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 WIKqAlL4xAnJ for ; Wed, 13 Apr 2016 07:08:12 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD9712E294 for ; Wed, 13 Apr 2016 07:08:12 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id u206so80324946wme.1 for ; Wed, 13 Apr 2016 07:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jakma-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=S02ETnbp2SsnPxU+egpfwlrj5DXMd9DK0Np8TleVIVY=; b=otBLn4SBDqoqASI6JhbqMU+RvmviiDvBTX2Vl6rQEW849kyVg3ELpi3QZt/DFoAb3c qPSQREuF9imlnvjTN2yYIv/Hv9K4Xxbe3ZSnpgPLoNdaLB3JYgud7Mf1+0RgvVI4tR/s EFMCy3xGPI8/3VYPH3vFIv+mc80txDysNN7P/R0N73xxUiA1FieRQxZBITVFovOWm+PH HH+h39qjaVvzlEs+7N//2Nm8KmTTDJzmNfIMRqJpWfF60X83nuDJEMdT2lRxgBiLqGDL jxE4bG98adVdg+/xW4kkrKKrIldEzAt7oIW3UxqbwVK8eHx/OKagIcBonktQV9RH36Ts mDcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=S02ETnbp2SsnPxU+egpfwlrj5DXMd9DK0Np8TleVIVY=; b=LsK6djDh7OnhVSJH2dommd8zAHYZkHQJJcVsw9pq5Vr+0j7BsypgX8Y40uwh0dOUow D1BSf7aVa0iWTEImEVsAg3Xd7EvWB/faUxClhsb/D+zbiUBB7/UuZeBOsTo6EJrpNW7/ +sDD60GUDjureA3Os/5YJ/PlK0+D1PgFM1FZ5XiJnShFs/EBn6gQaB+vPyrpwQBvKL0H 1PKuPE3HnhbnQQjD4Jv8hCdnGVPkaFjJnkwNGxaZX2mQ0rR3i1FK16/PmaLM+AyMJ4UX msd5OB4j3XUrPOZd0NJhjdHsC5bfc1tJTo1n/0lS+B8MVLakstbrhZP37t5y3OnFX9XQ 39xA== X-Gm-Message-State: AOPr4FXzJjccd2ZcopC6kIy89FicujkX9hEMUR9wLhUL98TIrZ46/itvk8xc0C14dHhfYA== X-Received: by 10.195.13.135 with SMTP id ey7mr9961100wjd.161.1460556490764; Wed, 13 Apr 2016 07:08:10 -0700 (PDT) Received: from stoner.jakma.org (stoner.jakma.org. [81.168.24.42]) by smtp.gmail.com with ESMTPSA id kj9sm38917575wjb.14.2016.04.13.07.08.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Apr 2016 07:08:10 -0700 (PDT) Date: Wed, 13 Apr 2016 15:08:08 +0100 (BST) From: Paul Jakma To: "Acee Lindem (acee)" In-Reply-To: Message-ID: References: <04479c8fba16697eb3a51ea89d0cd708@zeta2.ch> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) X-Snooper: A life spent reading others private email is a sad and wasted one X-NSA: nitrate toxic DNDO hostage al aqsar fluffy jihad DHS cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt mustard gas x-ray british airways hydrogen washington peroxide cool FEMA emergency four lions encryption ricin table pandemic scanner power sleet catalyst injection acetone X-KEYSCORE: The greatest long-term threats to freedom and democracy are based in Langley and Fort Meade and Cheltenham MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-1471075816-739375895-1460556489=:18471" Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] OSPF WG Minutes from IETF 95 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 14:08:15 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1471075816-739375895-1460556489=:18471 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 11 Apr 2016, Acee Lindem (acee) wrote: > If in 2016 (22 years later), one particular implementation chooses to not > comply to the specification, then there really isn’t anything the WG can > do about it. Part of the issue here was that the stub-router RFC features language that is often used to indicate authoritative changes to behaviour: "3. Maximum Link Metric Section 2 refers to the cost of all non-stub links as MaxLinkMetric, which is a new fixed architectural value introduced in this document. MaxLinkMetric The metric value indicating that a router-LSA link (see Section 2) should not be used for transit traffic. It is defined to be the 16-bit binary value of all ones: 0xffff." Note the "should not". Given that just discouraging traffic but still allowing transit, doesn't require any special metric valie to be called out - any high metric will do, that's just normal behaviour of metrics; and given that having the means to be able to totally disallow transit is desirable (see R-bit in v3, and the H-bit)... It's then not at all impossible to think the above did intend to mean 0xffff to not allow transit. > The draft > https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/ allows a > link to be used exclusively for non-transit traffic. Of course, if you > also didn’t want to use the link for any traffic you simply wouldn’t > advertise it. That won't work, I think. Other hosts won't have a backlink then, and won't be able to calculate a route to the host. The OSPF host may then be unreachable. That's qualitatively different from other hosts still being able to calculate a path to the host it self. For the RFC6987 desired behaviour, any high metric other than 0xffff will universally work. For "no transit, and I really mean it", Quagga will follow the H-bit as soon as it's clear it will be a standard. regards, -- Paul Jakma paul@jakma.org @pjakma Key ID: 64A2FF6A Fortune: Small is beautiful. -- Schumacher's Dictum ---1471075816-739375895-1460556489=:18471-- From nobody Wed Apr 13 08:24:44 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60FB12D13D for ; Wed, 13 Apr 2016 08:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 53mZgj9-9O64 for ; Wed, 13 Apr 2016 08:24:41 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB3A12D8E2 for ; Wed, 13 Apr 2016 08:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5634; q=dns/txt; s=iport; t=1460561074; x=1461770674; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tsPCqfOo0gibnsnBGPE224Uh3sW886wzduC98YHlLUE=; b=em7SRmUmC5Sy3Bg0fJw0QXIQjXnq6DLESDDdn4inp1WytMoFQwcTQkqn iNkAG+vITgWivl5Nn2JABfz8SP85+TnaLA1O+4lDZ6ziugRjXeMz1td2s ZSpofPxO81Pc03oAN24DvACtDByQh/pZYJwRC4KCsfYEPcs8oFbIicpvg k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AxBQDrYw5X/5hdJa1egzdTfQa4N4Idg?= =?us-ascii?q?XQihWwCHIEjORMBAQEBAQEBZSeEQQEBAQMBIxFFEAIBCBgCAiYCAgIwFRACBA4?= =?us-ascii?q?FiCAIDrBVkjsBAQEBAQEBAQEBAQEBAQEBAQEBAQERBHyJcIQ9gwKCVgWTG4RtA?= =?us-ascii?q?YV2iBaPEI8mASEBQIIEGYFKbIh8fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,480,1454976000"; d="scan'208";a="260274518" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Apr 2016 15:24:34 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3DFOXmv030554 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Apr 2016 15:24:33 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Apr 2016 11:24:33 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Wed, 13 Apr 2016 11:24:32 -0400 From: "Acee Lindem (acee)" To: Paul Jakma Thread-Topic: [OSPF] OSPF WG Minutes from IETF 95 Thread-Index: AQHRk+ug+9xkeFSUNUaQhV0sMu+UBZ+E5gwAgANQ+gD//9JIAA== Date: Wed, 13 Apr 2016 15:24:32 +0000 Message-ID: References: <04479c8fba16697eb3a51ea89d0cd708@zeta2.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.202] Content-Type: text/plain; charset="utf-8" Content-ID: <5405BF15C717544694ED1D199DD3221B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] OSPF WG Minutes from IETF 95 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 15:24:43 -0000 DQoNCk9uIDQvMTMvMTYsIDEwOjA4IEFNLCAiUGF1bCBKYWttYSIgPHBhdWxAamFrbWEub3JnPiB3 cm90ZToNCg0KPk9uIE1vbiwgMTEgQXByIDIwMTYsIEFjZWUgTGluZGVtIChhY2VlKSB3cm90ZToN Cj4NCj4+IElmIGluIDIwMTYgKDIyIHllYXJzIGxhdGVyKSwgb25lIHBhcnRpY3VsYXIgaW1wbGVt ZW50YXRpb24gY2hvb3NlcyB0bw0KPj5ub3QNCj4+IGNvbXBseSB0byB0aGUgc3BlY2lmaWNhdGlv biwgdGhlbiB0aGVyZSByZWFsbHkgaXNu4oCZdCBhbnl0aGluZyB0aGUgV0cgY2FuDQo+PiBkbyBh Ym91dCBpdC4NCj4NCj5QYXJ0IG9mIHRoZSBpc3N1ZSBoZXJlIHdhcyB0aGF0IHRoZSBzdHViLXJv dXRlciBSRkMgZmVhdHVyZXMgbGFuZ3VhZ2UNCj50aGF0IGlzIG9mdGVuIHVzZWQgdG8gaW5kaWNh dGUgYXV0aG9yaXRhdGl2ZSBjaGFuZ2VzIHRvIGJlaGF2aW91cjoNCg0KDQo+DQo+IjMuICBNYXhp bXVtIExpbmsgTWV0cmljDQo+DQo+ICAgICBTZWN0aW9uIDIgcmVmZXJzIHRvIHRoZSBjb3N0IG9m IGFsbCBub24tc3R1YiBsaW5rcyBhcyBNYXhMaW5rTWV0cmljLA0KPiAgICAgd2hpY2ggaXMgYSBu ZXcgZml4ZWQgYXJjaGl0ZWN0dXJhbCB2YWx1ZSBpbnRyb2R1Y2VkIGluIHRoaXMNCj4gICAgIGRv Y3VtZW50Lg0KPg0KPiAgICBNYXhMaW5rTWV0cmljDQo+ICAgICAgIFRoZSBtZXRyaWMgdmFsdWUg aW5kaWNhdGluZyB0aGF0IGEgcm91dGVyLUxTQSBsaW5rIChzZWUgU2VjdGlvbiAyKQ0KPiAgICAg ICBzaG91bGQgbm90IGJlIHVzZWQgZm9yIHRyYW5zaXQgdHJhZmZpYy4gIEl0IGlzIGRlZmluZWQg dG8gYmUgdGhlDQo+ICAgICAgIDE2LWJpdCBiaW5hcnkgdmFsdWUgb2YgYWxsIG9uZXM6IDB4ZmZm Zi4iDQo+DQo+Tm90ZSB0aGUgInNob3VsZCBub3QiLg0KPg0KPkdpdmVuIHRoYXQganVzdCBkaXNj b3VyYWdpbmcgdHJhZmZpYyBidXQgc3RpbGwgYWxsb3dpbmcgdHJhbnNpdCwgZG9lc24ndA0KPnJl cXVpcmUgYW55IHNwZWNpYWwgbWV0cmljIHZhbGllIHRvIGJlIGNhbGxlZCBvdXQgLSBhbnkgaGln aCBtZXRyaWMgd2lsbA0KPmRvLCB0aGF0J3MganVzdCBub3JtYWwgYmVoYXZpb3VyIG9mIG1ldHJp Y3M7IGFuZCBnaXZlbiB0aGF0IGhhdmluZyB0aGUNCj5tZWFucyB0byBiZSBhYmxlIHRvIHRvdGFs bHkgZGlzYWxsb3cgdHJhbnNpdCBpcyBkZXNpcmFibGUgKHNlZSBSLWJpdCBpbg0KPnYzLCBhbmQg dGhlIEgtYml0KS4uLiBJdCdzIHRoZW4gbm90IGF0IGFsbCBpbXBvc3NpYmxlIHRvIHRoaW5rIHRo ZSBhYm92ZQ0KPmRpZCBpbnRlbmQgdG8gbWVhbiAweGZmZmYgdG8gbm90IGFsbG93IHRyYW5zaXQu DQoNCkFyZSB5b3UgZmFtaWxpYXIgd2l0aCB0aGUgcmVxdWlyZW1lbnRzIGxhbmd1YWdlPyBXaGls ZSB0aGUgdXNlIG9mIOKAnHNob3VsZA0Kbm904oCdIGlzIHVuZm9ydHVuYXRlLCBpdCBpcyBub3Qg bm9ybWF0aXZlLiBUbyBiZSBub3JtYXRpdmUgaXQgd291bGQgbmVlZCB0bw0KYmUg4oCcU0hPVUxE IE5PVOKAnS4gRnVydGhlcm1vcmUsIFJGQyA2OTg3IGlzIGluZm9ybWF0aW9uYWwgYXMgb3Bwb3Nl ZCB0bw0Kc3RhbmRhcmRzIHRyYWNrLiBGaW5hbGx5LCB0aGUgZG9jdW1lbnQgZ29lcyBvbiB0byBw cmVjaXNlbHkgc3RhdGUgdGhlDQpiZWhhdmlvciAocmVmZXIgdG8gdGhlIGxhc3QgcGFyYWdyYXBo IG9mIHNlY3Rpb24gNCkuDQoNCg0KNC4gIERlcGxveW1lbnQgQ29uc2lkZXJhdGlvbnMNCg0KICAg V2hlbiB1c2luZyBNYXhMaW5rTWV0cmljLCBzb21lIGluY29uc2lzdGVuY3kgbWF5IGJlIHNlZW4g aWYgdGhlDQogICBuZXR3b3JrIGlzIGNvbnN0cnVjdGVkIG9mIHJvdXRlcnMgdGhhdCBwZXJmb3Jt IGFuIGludHJhLWFyZWEgRGlqa3N0cmENCiAgIGNhbGN1bGF0aW9uIGFzIHNwZWNpZmllZCBpbiBb UkZDMTI0N10gKGRpc2NhcmRpbmcgbGluayByZWNvcmRzIGluDQogICByb3V0ZXItTFNBcyB0aGF0 IGhhdmUgYSBNYXhMaW5rTWV0cmljIGNvc3QgdmFsdWUpIGFuZCByb3V0ZXJzIHRoYXQNCiAgIHBl cmZvcm0gaXQgYXMgc3BlY2lmaWVkIGluIFtSRkMxNTgzXSBhbmQgaGlnaGVyIChkbyBub3QgdHJl YXQgbGlua3MNCiAgIHdpdGggTWF4TGlua01ldHJpYyBjb3N0IGFzIHVucmVhY2hhYmxlKS4gIE5v dGUgdGhhdCB0aGlzDQogICBpbmNvbnNpc3RlbmN5IHdpbGwgbm90IGxlYWQgdG8gcm91dGluZyBs b29wcywgYmVjYXVzZSBpZiB0aGVyZSBhcmUNCiAgIHNvbWUgYWx0ZXJuYXRlIHBhdGhzIGluIHRo ZSBuZXR3b3JrLCBib3RoIHR5cGVzIG9mIHJvdXRlcnMgd2lsbCBhZ3JlZQ0KICAgb24gdXNpbmcg dGhlbSByYXRoZXIgdGhhbiB0aGUgcGF0aCB0aHJvdWdoIHRoZSBzdHViIHJvdXRlci4gIElmIHRo ZQ0KICAgcGF0aCB0aHJvdWdoIHRoZSBzdHViIHJvdXRlciBpcyB0aGUgb25seSBvbmUsIHRoZSBy b3V0ZXJzIG9mIHRoZQ0KICAgZmlyc3QgdHlwZSB3aWxsIG5vdCB1c2UgdGhlIHN0dWIgcm91dGVy IGZvciB0cmFuc2l0ICh3aGljaCBpcyB0aGUNCiAgIGRlc2lyZWQgYmVoYXZpb3IpLCB3aGlsZSB0 aGUgcm91dGVycyBvZiB0aGUgc2Vjb25kIHR5cGUgd2lsbCBzdGlsbA0KICAgdXNlIHRoaXMgcGF0 aC4NCg0KICAgT24gdGhlIG90aGVyIGhhbmQsIGNsZWFyaW5nIHRoZSBSLWJpdCB3aWxsIGNvbnNp c3RlbnRseSByZXN1bHQgaW4gdGhlDQogICByb3V0ZXIgbm90IGJlaW5nIHVzZWQgZm9yIHRyYW5z aXQuDQoNCiAgIFRoZSB1c2Ugb2YgTWF4TGlua01ldHJpYyBvciB0aGUgUi1iaXQgaW4gYSBuZXR3 b3JrIGRlcGVuZHMgb24gdGhlDQogICBvYmplY3RpdmVzIG9mIHRoZSBvcGVyYXRvci4gIE9uZSBv ZiB0aGUgcG9zc2libGUgY29uc2lkZXJhdGlvbnMgZm9yDQogICBzZWxlY3Rpbmcgb25lIG9yIHRo ZSBvdGhlciBpcyBpbiB0aGUgZGVzaXJlZCBiZWhhdmlvciBpZiB0aGUgcGF0aA0KICAgdGhyb3Vn aCB0aGUgc3R1YiByb3V0ZXIgaXMgdGhlIG9ubHkgb25lIGF2YWlsYWJsZS4gIFVzaW5nDQogICBN YXhMaW5rTWV0cmljIGFsbG93cyBmb3IgdGhhdCBwYXRoIHRvIGJlIHVzZWQgd2hpbGUgdGhlIFIt Yml0DQogICBkb2Vzbid0Lg0KDQoNCkkgYmVsaWV2ZSB0aGUgYWJvdmUgaXMgY2xlYXIuDQoNCj4N Cj4+IFRoZSBkcmFmdCANCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtb3NwZi1vc3BmdjItaGJpdC8gYWxsb3dzIGENCj4+IGxpbmsgdG8gYmUgdXNlZCBleGNs dXNpdmVseSBmb3Igbm9uLXRyYW5zaXQgdHJhZmZpYy4gT2YgY291cnNlLCBpZiB5b3UNCj4+IGFs c28gZGlkbuKAmXQgd2FudCB0byB1c2UgdGhlIGxpbmsgZm9yIGFueSB0cmFmZmljIHlvdSBzaW1w bHkgd291bGRu4oCZdA0KPj4gYWR2ZXJ0aXNlIGl0Lg0KPg0KPlRoYXQgd29uJ3Qgd29yaywgSSB0 aGluay4NCg0KTm90ZSB0aGF0IEkgc2FpZCDigJxkaWRu4oCZdCB3YW50IHRvIHVzZSB0aGUgbGlu ayBmb3IgYW55IHRyYWZmaWMu4oCdDQoNCg0KDQo+DQo+T3RoZXIgaG9zdHMgd29uJ3QgaGF2ZSBh IGJhY2tsaW5rIHRoZW4sIGFuZCB3b24ndCBiZSBhYmxlIHRvIGNhbGN1bGF0ZSBhDQo+cm91dGUg dG8gdGhlIGhvc3QuIFRoZSBPU1BGIGhvc3QgbWF5IHRoZW4gYmUgdW5yZWFjaGFibGUuIFRoYXQn cw0KPnF1YWxpdGF0aXZlbHkgZGlmZmVyZW50IGZyb20gb3RoZXIgaG9zdHMgc3RpbGwgYmVpbmcg YWJsZSB0byBjYWxjdWxhdGUgYQ0KPnBhdGggdG8gdGhlIGhvc3QgaXQgc2VsZi4NCg0KDQoNCj4N Cj5Gb3IgdGhlIFJGQzY5ODcgZGVzaXJlZCBiZWhhdmlvdXIsIGFueSBoaWdoIG1ldHJpYyBvdGhl ciB0aGFuIDB4ZmZmZg0KPndpbGwgdW5pdmVyc2FsbHkgd29yay4NCg0KWW91IGhhdmUgbWlzaW50 ZXJwcmV0ZWQgaXQuDQoNClRoYW5rcywNCkFjZWUgDQoNCg0KDQo+DQo+Rm9yICJubyB0cmFuc2l0 LCBhbmQgSSByZWFsbHkgbWVhbiBpdCIsIFF1YWdnYSB3aWxsIGZvbGxvdyB0aGUgSC1iaXQgYXMN Cj5zb29uIGFzIGl0J3MgY2xlYXIgaXQgd2lsbCBiZSBhIHN0YW5kYXJkLg0KPg0KPnJlZ2FyZHMs DQo+LS0gDQo+UGF1bCBKYWttYQlwYXVsQGpha21hLm9yZwlAcGpha21hCUtleSBJRDogNjRBMkZG NkENCj5Gb3J0dW5lOg0KPlNtYWxsIGlzIGJlYXV0aWZ1bC4NCj4gCQktLSBTY2h1bWFjaGVyJ3Mg RGljdHVtDQoNCg== From nobody Wed Apr 13 09:39:46 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E34812D5A0; Wed, 13 Apr 2016 09:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 GeZviduJpH0v; Wed, 13 Apr 2016 09:39:44 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D355D12D15D; Wed, 13 Apr 2016 09:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3882; q=dns/txt; s=iport; t=1460565583; x=1461775183; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bkj74Oy00REp6sy6Lp30OkaX5l7ZhQ1UX89zX6BtM8k=; b=MLquwrVnk8wupBXRhJSXVSbsSlNN7shvwE1x9WuIogIJ8Hkkyx7ZyHga zRydFDhxc+ABTEDveWQXBMtd4jPInsY2rtbK/IyWvLFEivFDTXQ2jK6rT 672T86cnxNMrVp+P1oHc2TpFJtk+OtWtndMKswCJNKa5D0Bl4Tt6J5jk2 0=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DAAgAMdQ5X/5ldJa1egzeBUAaubYtYD?= =?us-ascii?q?oFxhg4CgUE4FAEBAQEBAQFlHAuEQQEBAQMBI1YFCwIBCBgqAgIhESUCBA4FDog?= =?us-ascii?q?GAwoIsHSNCg2FIwEBAQEBAQEBAQEBAQEBAQEBAQEPCIYhgXUIgk6CQYR+K4IrB?= =?us-ascii?q?ZMbhDwxAYMjgWaHDoF1gWeEToMohTOGIIErh1sBHgFDg2dsiHx+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,480,1454976000"; d="asc'?scan'208";a="260188723" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Apr 2016 16:39:42 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3DGdgOw027445 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Apr 2016 16:39:42 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Apr 2016 12:39:42 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Wed, 13 Apr 2016 12:39:41 -0400 From: "Carlos Pignataro (cpignata)" To: "akatlas@gmail.com" Thread-Topic: AD review of draft-ietf-ospf-sbfd-disciminator-03 Thread-Index: AQHRlPbLavt/Cp5MbkKMUR/dnaGk9Z+IX0eA Date: Wed, 13 Apr 2016 16:39:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.56] Content-Type: multipart/signed; boundary="Apple-Mail=_BB10C895-F085-4D46-86C4-4084092A34D0"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: OSPF List , "draft-ietf-ospf-sbfd-discriminator@ietf.org" Subject: Re: [OSPF] AD review of draft-ietf-ospf-sbfd-disciminator-03 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 16:39:45 -0000 --Apple-Mail=_BB10C895-F085-4D46-86C4-4084092A34D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alia, Thanks for this review! Please see inline. > On Apr 12, 2016, at 4:06 PM, akatlas@gmail.com wrote: >=20 > First, thanks very much to the authors Manav, Carlos, Sam, and Trilok = for their work on this document. >=20 > As is customary, I have done my AD review before requesting IETF Last = Call. In this case, I have a couple minor comments that I would like = the authors to address during IETF Last Call. >=20 > In addition to IETF Last Call, I am requesting a Routing Directorate = review. I expect that both of these will conclude by April 27 and that = this draft will be on the IESG telechat on May 5. During this period, = it is critical that the authors be extremely responsive and update the = draft as appropriate so that the process runs as smoothly and quickly as = feasible >=20 >=20 > Minor comments: > 1) Draft references RFC 4970 instead of RFC 7770 which obsoleted = it. In addition to updating the reference, please reread RFC 7770 and = be certain that there are no surprises that can come from multiple RI = LSAs being allowed or other nuances. I personally don't see any right = now. Great point. Working copy updated. I also re-read RFC 7770 and I do not = think there=E2=80=99s any additional considerations or implications. >=20 > 2) In Sec 2.1, it specifies "Routers that do not recognize the = S-BFD Discriminator TLV Type MUST ignore the TLV." I don't think that = this document can mandate what routers that don't implement it do. I = went back through RFC 7770 and don't see any description *sigh* for the = expected router behavior if a sub-TLV isn't recognized. This might be a = very useful errata to add to RFC 7770 - unless someone else can find = where the behavior is specified. For this draft, please think about = what "ignoring the TLV" means and what routers that do not know about = this draft are likely to do - and then update this sentence. True, this doc cannot say =E2=80=9CMUST ignore=E2=80=9D. However, RFC = 7770 S2.3 already says =E2=80=9CUnrecognized types are ignored.=E2=80=9D I will change "Routers that do not recognize the S-BFD Discriminator TLV Type MUST = ignore the TLV.=E2=80=9D to: "Routers that do not recognize the S-BFD Discriminator TLV Type will = ignore the TLV [RFC 7770], and therefore will not learn S-BFD = Discriminators via OSPF.=E2=80=9D Changes made in our working copy, and can submit when signaled. Feedback most welcome. Thanks, =E2=80=94 Carlos. >=20 > Thanks! > Alia --Apple-Mail=_BB10C895-F085-4D46-86C4-4084092A34D0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXDnZNAAoJEIXgpQGOZny9xTYQAILg5zA8XHXlpW745eXwfGdN gdr3IBo2NhSGcMfnukhlM00nmoTcNXjHoHvIH8Ck1wJ4eG3XQ9nkOl3RYpbyR3ik 13eDDHvqzoNjvBFeQiGAU71hJkIrB6QJTZjJDaCOoQ5Ehx8GRicdSoNeJc/A0c81 Ghl+5aXa7VnOAk7g02NvHaXxmtN/FE/gHDxAPOQZLpOo9qsAhsU7hXgbRJDS0rhD yStqMFzOVYtsYbpY61HdLfHmwljLY7mqufhKpIy7hm33YAdmZh+jtjcyWpKbJ0b6 PVB8Pe154VdtAUKK1KMkBFmei6ylZXrQksWzedlo4+CYYRSIF8sMgUR0sbqASXy4 GcpobuXDUTMG3LO8WtkpZMdqdSjcsWtKtj8xpuzQ0Zmb4F6zJ6m2I2D3+/McyzXT ZdKZGEqbXFXVoi1QWdyw5fM6ZpDXd66ak/saTUbSIBcv35W1u87dD2h/zkJ+DPjE l/9lqk/JsPw8iBbHztr8y3Le9/qngr6g/5/GDfGJYTtA4d7fwr7Es1wqo0TevScI fL00UZ/1BPrOuGRgfYGRWRcfllwCz2GvnAja31g52DsjVR0LrUOoM7v3hQ0KPPiR NS7q85mTdHF7hCsCWlDivCkYYPL8kkv3HJrMFl52BYueqdE8Q4XvXJ+2HAfpxg5N 70saKZ9vRqeE+cBBGM1H =tI4u -----END PGP SIGNATURE----- --Apple-Mail=_BB10C895-F085-4D46-86C4-4084092A34D0-- From nobody Wed Apr 13 12:08:24 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A32512E417; Wed, 13 Apr 2016 12:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 bomUofBMb7Ev; Wed, 13 Apr 2016 12:08:21 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9256D12E413; Wed, 13 Apr 2016 12:08:21 -0700 (PDT) Received: by mail-ob0-x233.google.com with SMTP id tz8so38710973obc.0; Wed, 13 Apr 2016 12:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=3HWNelOn/aZM5Jz2rLAKmqu/RHPN6rS6eZXV5r8p4aw=; b=vJ0544APfraPe68RtY3EF1GWexQsGWyAS33KSkVbHsvI2ISDoiawbRmhnLaC2I/a6W PGIUZkH3rOUlFvOfso0WOMzjH0dYHb4XdV5YM3ATLMjt8d5W1AHW8BJMRseyMzaXk2dA BIRZAkTMiAmo3GEGtlapKhb0VVeKUPd5J+B3z72v+HPFnSait2mFvuR03+nkiC2tBOvK odbKGwdRP1UQGLXnUwHxHUptF5Z1KkOsBcltN4yUicq63a+Ilj6/2MzDQwGrcknbKbCT Weqze9CQvKfW8Ax8otRqTrpAybr8T0S6Nr7UvtvNS0TeXeEudRcCj7uzJlBRfI0c9GTJ am7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=3HWNelOn/aZM5Jz2rLAKmqu/RHPN6rS6eZXV5r8p4aw=; b=nIJWDf2Prd6Loa7krQmt5H+ye2JHz10rj+LAQ6o5YjaT15v3WrkN446Ja7sKW8PHLz vRNxqd/Hqgrfz25LWyS3XQCz8sD46tEQqt6xR+NB8ynPDwO4lLcntEk3iZmHDX9P2TgH EHOKa77ug/X+10mFnEyUjvJJqb2pMBMWcFgNWNoX+So8jXgwx9Mv9vEfTmXu3pNdKcPA r5a6we6iRWBricNItDoUJcYSwsAkDocsIPdehGPfT3No/gjXJaPuqMo7itCw8fGCrwPj N1rsiL/KBA2qjtOp2jURnbOoUcfFU2lBqRSYZk46CXIWQZIelicNn9ZsDpb3ZqJe1ecf cbiA== X-Gm-Message-State: AOPr4FV7rnqfBHTjC/RTQQTl5H2wkOBQPKHVkPOlf6xTxDlCRWnL+igQWnZvYpVxzCLdfgvPjuu2SRZgMPkdKQ== MIME-Version: 1.0 X-Received: by 10.60.62.6 with SMTP id u6mr5735583oer.35.1460574500941; Wed, 13 Apr 2016 12:08:20 -0700 (PDT) Received: by 10.60.115.168 with HTTP; Wed, 13 Apr 2016 12:08:20 -0700 (PDT) Received: by 10.60.115.168 with HTTP; Wed, 13 Apr 2016 12:08:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Apr 2016 15:08:20 -0400 Message-ID: From: Alia Atlas To: Carlos Pignataro Content-Type: multipart/alternative; boundary=089e015384be4bffd8053062808f Archived-At: Cc: OSPF List , draft-ietf-ospf-sbfd-discriminator@ietf.org Subject: Re: [OSPF] AD review of draft-ietf-ospf-sbfd-disciminator-03 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 19:08:23 -0000 --089e015384be4bffd8053062808f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sounds great. Do submit it. Version numbers are cheap. Thanks, Alia On Apr 13, 2016 12:39 PM, "Carlos Pignataro (cpignata)" wrote: > Hi Alia, > > Thanks for this review! Please see inline. > > > On Apr 12, 2016, at 4:06 PM, akatlas@gmail.com wrote: > > > > First, thanks very much to the authors Manav, Carlos, Sam, and Trilok > for their work on this document. > > > > As is customary, I have done my AD review before requesting IETF Last > Call. In this case, I have a couple minor comments that I would like the > authors to address during IETF Last Call. > > > > In addition to IETF Last Call, I am requesting a Routing Directorate > review. I expect that both of these will conclude by April 27 and that > this draft will be on the IESG telechat on May 5. During this period, it > is critical that the authors be extremely responsive and update the draft > as appropriate so that the process runs as smoothly and quickly as feasib= le > > > > > > Minor comments: > > 1) Draft references RFC 4970 instead of RFC 7770 which obsoleted it. > In addition to updating the reference, please reread RFC 7770 and be > certain that there are no surprises that can come from multiple RI LSAs > being allowed or other nuances. I personally don't see any right now. > > Great point. Working copy updated. I also re-read RFC 7770 and I do not > think there=E2=80=99s any additional considerations or implications. > > > > > 2) In Sec 2.1, it specifies "Routers that do not recognize the S-BFD > Discriminator TLV Type MUST ignore the TLV." I don't think that this > document can mandate what routers that don't implement it do. I went bac= k > through RFC 7770 and don't see any description *sigh* for the expected > router behavior if a sub-TLV isn't recognized. This might be a very usef= ul > errata to add to RFC 7770 - unless someone else can find where the behavi= or > is specified. For this draft, please think about what "ignoring the TLV" > means and what routers that do not know about this draft are likely to do= - > and then update this sentence. > > True, this doc cannot say =E2=80=9CMUST ignore=E2=80=9D. However, RFC 777= 0 S2.3 already > says =E2=80=9CUnrecognized types are ignored.=E2=80=9D > > I will change > "Routers that do not recognize the S-BFD Discriminator TLV Type MUST > ignore the TLV.=E2=80=9D > to: > "Routers that do not recognize the S-BFD Discriminator TLV Type will > ignore the TLV [RFC 7770], and therefore will not learn S-BFD > Discriminators via OSPF.=E2=80=9D > > Changes made in our working copy, and can submit when signaled. > > Feedback most welcome. > > Thanks, > > =E2=80=94 Carlos. > > > > > Thanks! > > Alia > > > --089e015384be4bffd8053062808f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Sounds great.=C2=A0=C2=A0 Do submit it.=C2=A0=C2=A0=C2=A0 Ve= rsion numbers are cheap.

Thanks,
Alia

On Apr 13, 2016 12:39 PM, "Carlos Pignataro= (cpignata)" <cpignata@cisco.= com> wrote:
H= i Alia,

Thanks for this review! Please see inline.

> On Apr 12, 2016, at 4:06 PM, akat= las@gmail.com wrote:
>
> First, thanks very much to the authors Manav, Carlos, Sam, and Trilok = for their work on this document.
>
> As is customary, I have done my AD review before requesting IETF Last = Call.=C2=A0 In this case, I have a couple minor comments that I would like = the authors to address during IETF Last Call.
>
> In addition to IETF Last Call, I am requesting a Routing Directorate r= eview.=C2=A0 I expect that both of these will conclude by April 27 and that= this draft will be on the IESG telechat on May 5.=C2=A0 During this period= , it is critical that the authors be extremely responsive and update the dr= aft as appropriate so that the process runs as smoothly and quickly as feas= ible
>
>
> Minor comments:
>=C2=A0 =C2=A0 1) Draft references RFC 4970 instead of RFC 7770 which ob= soleted it.=C2=A0 In addition to updating the reference, please reread RFC = 7770 and be certain that there are no surprises that can come from multiple= RI LSAs being allowed or other nuances.=C2=A0 I personally don't see a= ny right now.

Great point. Working copy updated. I also re-read RFC 7770 and I do not thi= nk there=E2=80=99s any additional considerations or implications.

>
>=C2=A0 =C2=A0 2) In Sec 2.1, it specifies "Routers that do not rec= ognize the S-BFD Discriminator TLV Type MUST ignore the TLV."=C2=A0 I = don't think that this document can mandate what routers that don't = implement it do.=C2=A0 I went back through RFC 7770 and don't see any d= escription *sigh* for the expected router behavior if a sub-TLV isn't r= ecognized.=C2=A0 This might be a very useful errata to add to RFC 7770 - un= less someone else can find where the behavior is specified.=C2=A0 For this = draft, please think about what "ignoring the TLV" means and what = routers that do not know about this draft are likely to do - and then updat= e this sentence.

True, this doc cannot say =E2=80=9CMUST ignore=E2=80=9D. However, RFC 7770 = S2.3 already says =E2=80=9CUnrecognized types are ignored.=E2=80=9D

I will change
"Routers that do not recognize the S-BFD Discriminator TLV Type MUST i= gnore the TLV.=E2=80=9D
to:
"Routers that do not recognize the S-BFD Discriminator TLV Type will i= gnore the TLV [RFC 7770], and therefore will not learn S-BFD Discriminators= via OSPF.=E2=80=9D

Changes made in our working copy, and can submit when signaled.

Feedback most welcome.

Thanks,

=E2=80=94 Carlos.

>
> Thanks!
> Alia


--089e015384be4bffd8053062808f-- From nobody Wed Apr 13 13:14:29 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A1312D88D for ; Wed, 13 Apr 2016 13:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jakma-org.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 xaFN0M86GCgq for ; Wed, 13 Apr 2016 13:14:26 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F87012D787 for ; Wed, 13 Apr 2016 13:14:26 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id u206so96322795wme.1 for ; Wed, 13 Apr 2016 13:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jakma-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=nszOLKTtz0pQgSAa/mWwW52c2W4xGTz1QelBKz19oWo=; b=s2bXJnCK/TjIvD/tV/7StumdbUa8CU05PDSwnDQXvBh3q2LL3kUj7miaQ+81Nm2Rb0 GA/+UxsPl2F5amxS4OmXkt/pOxUdWT0b0wKGh+HJkhJrN7jSzIlPPDJFZTLKiK9KUx+y iXR/jcj35NjbG7mafWRxntueomefm/CwgSPD5GZ9ZrP4cqsLlm1ANyBEVZ7x26OsuOmz mrfEViOYSUEP8IUAiETJNfdK0j7DUgPqwOtMK3z8/eVXoopggYPEguVt7DIAZ1V3B8fN M7YsBuMTlIe4y2gJdoAXTXDaS0NpUWHeNCe4PH0fKTO/vn3noCP5lDFGxv2pIVxTRb24 6cbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=nszOLKTtz0pQgSAa/mWwW52c2W4xGTz1QelBKz19oWo=; b=d7yq1jZMunlLLG3s+HrRE6sM1fnR4VM5ByYdAzesZYeR3to+bVIdYuk4MqYgkRDWJu bCOYMGO6rJObMtIFJh2+y53ZwlMAuM0Y7wE31dLmTVtfmuFKoVKlzBE/K7yzfSgrb2WV XrkmbD2OOziGtQ9ey2jqi0LTEUtrreuWnUG8badWNEj02orDnsksb7SiVGMSLtkkxoVa 5xwQoNkuhtGP1qTIZRi0tolMXHjMigLJ5u1DGMkYodXaoFtFgPVftmxsb13bONAv2zHY 9DKT2pevsEsJTntVwiPbkaypqAb9qyms/eLoV0xAYHq+1S7pygeXimCnCsIxgm9y9lUD g4ow== X-Gm-Message-State: AOPr4FXZDTi/A67ZMyqPye/diLYKvB+LFE5b+kiwk4sfkna1rQ4Mel0FuD9ImfDtoA5zdQ== X-Received: by 10.28.54.148 with SMTP id y20mr12353649wmh.68.1460578464777; Wed, 13 Apr 2016 13:14:24 -0700 (PDT) Received: from stoner.jakma.org (stoner.jakma.org. [81.168.24.42]) by smtp.gmail.com with ESMTPSA id g78sm29829301wme.21.2016.04.13.13.14.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Apr 2016 13:14:23 -0700 (PDT) Date: Wed, 13 Apr 2016 21:14:21 +0100 (BST) From: Paul Jakma To: "Acee Lindem (acee)" In-Reply-To: Message-ID: References: <04479c8fba16697eb3a51ea89d0cd708@zeta2.ch> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) X-Snooper: A life spent reading others private email is a sad and wasted one X-NSA: nitrate toxic DNDO hostage al aqsar fluffy jihad DHS cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt mustard gas x-ray british airways hydrogen washington peroxide cool FEMA emergency four lions encryption ricin table pandemic scanner power sleet catalyst injection acetone X-KEYSCORE: The greatest long-term threats to freedom and democracy are based in Langley and Fort Meade and Cheltenham MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-1471075816-367225847-1460578463=:13056" Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] OSPF WG Minutes from IETF 95 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 20:14:28 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1471075816-367225847-1460578463=:13056 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 13 Apr 2016, Acee Lindem (acee) wrote: > Are you familiar with the requirements language? While the use of > “should not†is unfortunate, it is not normative. To be normative it > would need to be “SHOULD NOTâ€. Capitals are not required. If one is used to RFC2328, one would not expect normative language to be shouty. > Furthermore, RFC 6987 is informational as opposed to standards track. > Finally, the document goes on to precisely state the behavior (refer > to the last paragraph of section 4). > I believe the above is clear. Sure, 4 reads the other way but "deployment considerations" . I'm not saying how it must be read, just saying it is possible to read the stronger language of 3 another way. I'm not trying to argue, I'm trying to explain why we are here. >> For the RFC6987 desired behaviour, any high metric other than 0xffff >> will universally work. > > You have misinterpreted it. I may have misinterpreted RFC6987, sure. However, it is a fact that the behaviour desired by RFC6987 can be universally achieved with metrics of 0xfffe or lower. That was true before any misinterpretation, and is still true now. 0xffff today will not universally be recognised as meaning "you can still calculate transit paths out of a router using that link". 0xfffe or below will. That is the reality today. regards, -- Paul Jakma paul@jakma.org @pjakma Key ID: 64A2FF6A Fortune: Even a blind pig stumbles upon a few acorns. ---1471075816-367225847-1460578463=:13056-- From nobody Wed Apr 13 15:31:17 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA49912D50A for ; Wed, 13 Apr 2016 15:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 L_QGgcnlLbSD for ; Wed, 13 Apr 2016 15:31:14 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0F912D1AE for ; Wed, 13 Apr 2016 15:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3120; q=dns/txt; s=iport; t=1460586674; x=1461796274; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fl3PNG7LPYGONim58w2MmopViyqCDGcD/UAyz8BWQqw=; b=QVbVzCpYtCGehExyb4ZoBsNeANeGVeHR+ztBaPFv4elMuC3qtofFiBZM rivrjeisCdzF+PjFe+P+24w9JQPjn8uAmJzLeYNH00NFTBn97MzcSJ08X wh3I2Oo/Xp8me4qFd3QKw63VGj4Vncrg0M9Q3xTY8ggnWMgM74Ao8aYq/ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAgBEyA5X/4wNJK1egzeBUAa4OIIPA?= =?us-ascii?q?Q2BcYJegzACHIEiOBQBAQEBAQEBZSeEQQEBAQMBIxFFBQsCAQgYAgImAgICMBU?= =?us-ascii?q?QAgQOBYghCLBckkABAQEBAQEBAQEBAQEBAQEBAQEBF3yJcIQ9gwKCVgEEmAgBj?= =?us-ascii?q?gyBZ4ROgyiFM48mAR4BAUKDZ2yIfH4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,481,1454976000"; d="scan'208";a="96173410" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Apr 2016 22:31:13 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u3DMVDSg010250 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Apr 2016 22:31:13 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Apr 2016 18:31:12 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Wed, 13 Apr 2016 18:31:12 -0400 From: "Acee Lindem (acee)" To: Paul Jakma Thread-Topic: [OSPF] OSPF WG Minutes from IETF 95 Thread-Index: AQHRk+ug+9xkeFSUNUaQhV0sMu+UBZ+E5gwAgANQ+gD//9JIAIAAlAqA///jKQA= Date: Wed, 13 Apr 2016 22:31:12 +0000 Message-ID: References: <04479c8fba16697eb3a51ea89d0cd708@zeta2.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.202] Content-Type: text/plain; charset="utf-8" Content-ID: <36CB72DC44BBD14D9D8EE298646A4203@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] OSPF WG Minutes from IETF 95 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 22:31:16 -0000 DQoNCk9uIDQvMTMvMTYsIDQ6MTQgUE0sICJQYXVsIEpha21hIiA8cGF1bEBqYWttYS5vcmc+IHdy b3RlOg0KDQo+T24gV2VkLCAxMyBBcHIgMjAxNiwgQWNlZSBMaW5kZW0gKGFjZWUpIHdyb3RlOg0K Pg0KPj4gQXJlIHlvdSBmYW1pbGlhciB3aXRoIHRoZSByZXF1aXJlbWVudHMgbGFuZ3VhZ2U/IFdo aWxlIHRoZSB1c2Ugb2YNCj4+IOKAnHNob3VsZCBub3TigJ0gaXMgdW5mb3J0dW5hdGUsIGl0IGlz IG5vdCBub3JtYXRpdmUuIFRvIGJlIG5vcm1hdGl2ZSBpdA0KPj4gd291bGQgbmVlZCB0byBiZSDi gJxTSE9VTEQgTk9U4oCdLg0KPg0KPkNhcGl0YWxzIGFyZSBub3QgcmVxdWlyZWQuDQoNClRoaXMg aXMgbm90IG15IGNvbnZlbnRpb24gLSBwbGVhc2Ugc2VlIFJGQyAyMTE5Lg0KDQoNCj5JZiBvbmUg aXMgdXNlZCB0byBSRkMyMzI4LCBvbmUgd291bGQgbm90DQo+ZXhwZWN0IG5vcm1hdGl2ZSBsYW5n dWFnZSB0byBiZSBzaG91dHkuDQoNCg0KDQoNCj4NCj4+IEZ1cnRoZXJtb3JlLCBSRkMgNjk4NyBp cyBpbmZvcm1hdGlvbmFsIGFzIG9wcG9zZWQgdG8gc3RhbmRhcmRzIHRyYWNrLg0KPj4gRmluYWxs eSwgdGhlIGRvY3VtZW50IGdvZXMgb24gdG8gcHJlY2lzZWx5IHN0YXRlIHRoZSBiZWhhdmlvciAo cmVmZXINCj4+IHRvIHRoZSBsYXN0IHBhcmFncmFwaCBvZiBzZWN0aW9uIDQpLg0KPg0KPj4gSSBi ZWxpZXZlIHRoZSBhYm92ZSBpcyBjbGVhci4NCj4NCj5TdXJlLCA0IHJlYWRzIHRoZSBvdGhlciB3 YXkgYnV0ICJkZXBsb3ltZW50IGNvbnNpZGVyYXRpb25zIiAuIEknbSBub3QNCj5zYXlpbmcgaG93 IGl0IG11c3QgYmUgcmVhZCwganVzdCBzYXlpbmcgaXQgaXMgcG9zc2libGUgdG8gcmVhZCB0aGUN Cj5zdHJvbmdlciBsYW5ndWFnZSBvZiAzIGFub3RoZXIgd2F5Lg0KPg0KPkknbSBub3QgdHJ5aW5n IHRvIGFyZ3VlLCBJJ20gdHJ5aW5nIHRvIGV4cGxhaW4gd2h5IHdlIGFyZSBoZXJlLg0KDQpPbmUg b2YgdGhlIGF1dGhvcnMgb3IgbXlzZWxmIHdpbGwgd3JpdGUgYW4gZXJyYXRhIHRvIGNsYXJpZnkg dGhpcw0KZGVmaW5pdGlvbi4gDQoNCj4NCj4+PiBGb3IgdGhlIFJGQzY5ODcgZGVzaXJlZCBiZWhh dmlvdXIsIGFueSBoaWdoIG1ldHJpYyBvdGhlciB0aGFuIDB4ZmZmZg0KPj4+IHdpbGwgdW5pdmVy c2FsbHkgd29yay4NCj4+DQo+PiBZb3UgaGF2ZSBtaXNpbnRlcnByZXRlZCBpdC4NCj4NCj5JIG1h eSBoYXZlIG1pc2ludGVycHJldGVkIFJGQzY5ODcsIHN1cmUuDQo+DQo+SG93ZXZlciwgaXQgaXMg YSBmYWN0IHRoYXQgdGhlIGJlaGF2aW91ciBkZXNpcmVkIGJ5IFJGQzY5ODcgY2FuIGJlDQo+dW5p dmVyc2FsbHkgYWNoaWV2ZWQgd2l0aCBtZXRyaWNzIG9mIDB4ZmZmZSBvciBsb3dlci4gVGhhdCB3 YXMgdHJ1ZQ0KPmJlZm9yZSBhbnkgbWlzaW50ZXJwcmV0YXRpb24sIGFuZCBpcyBzdGlsbCB0cnVl IG5vdy4NCg0KQnV0IHRoZSBPU1BGIHN0dWIgcm91dGVyIGZ1bmN0aW9uYWxpdHkgaXMgYWNoaWV2 ZWQgdXNpbmcgMHhmZmZmLCBzbyB5b3VyDQpwcm9wb3NhbCBpcyBOT1QgYmFja3dhcmQgY29tcGF0 aWJsZS4NCg0KDQo+DQo+MHhmZmZmIHRvZGF5IHdpbGwgbm90IHVuaXZlcnNhbGx5IGJlIHJlY29n bmlzZWQgYXMgbWVhbmluZyAieW91IGNhbg0KPnN0aWxsIGNhbGN1bGF0ZSB0cmFuc2l0IHBhdGhz IG91dCBvZiBhIHJvdXRlciB1c2luZyB0aGF0IGxpbmsiLg0KDQpUaGVyZSB3aWxsIGFsd2F5cyBi ZSBzb2Z0d2FyZSBidWdzIGFuZCB0aGVzZSBzaG91bGQgYmUgY29ycmVjdGVkLg0KDQo+IDB4ZmZm ZSANCj5vciBiZWxvdyB3aWxsLg0KDQpTZWUgYWJvdmUgLSB0aGlzIGlzIG5vdCBiYWNrd2FyZCBj b21wYXRpYmxlLg0KDQo+DQo+VGhhdCBpcyB0aGUgcmVhbGl0eSB0b2RheS4NCg0KVGhlIHJlYWxp dHkgaXMgdGhhdCB0aGUgc3RhbmRhcmRzIFdJTEwgTk9UIGNoYW5nZSB0byBtYXRjaCB5b3VyDQpp bnRlcnByZXRhdGlvbi4gSWYgeW91IHdhbnQgdG8gY2hhbmdlIHRoZSBzdGFuZGFyZCwgd2UgbG9v ayBmb3J3YXJkIHRvDQp5b3VyIHByb3Bvc2FsIGluIGRyYWZ0IGZvcm0gd2l0aCBiYWNrd2FyZCBj b21wYXRpYmlsaXR5IGZvciB0aGUNCmltcGxlbWVudGF0aW9ucyB3aXRoIHRoZSBjb3JyZWN0IGlu dGVycHJldGF0aW9uLg0KDQpUaGFua3MsDQpBY2VlIA0KDQoNCj4NCj5yZWdhcmRzLA0KPi0tIA0K PlBhdWwgSmFrbWEJcGF1bEBqYWttYS5vcmcJQHBqYWttYQlLZXkgSUQ6IDY0QTJGRjZBDQo+Rm9y dHVuZToNCj5FdmVuIGEgYmxpbmQgcGlnIHN0dW1ibGVzIHVwb24gYSBmZXcgYWNvcm5zLg0KDQo= From nobody Thu Apr 14 01:34:23 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6877912E20D for ; Thu, 14 Apr 2016 01:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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.996, 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 vOpj_6iqIT1k for ; Thu, 14 Apr 2016 01:34:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5469212E255 for ; Thu, 14 Apr 2016 01:34:17 -0700 (PDT) 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 CMD44912; Thu, 14 Apr 2016 08:34:14 +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.235.1; Thu, 14 Apr 2016 09:34:14 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 14 Apr 2016 16:34:06 +0800 From: Xuxiaohu To: "Acee Lindem (acee)" , OSPF WG List Thread-Topic: WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment" Thread-Index: AQHRf/Ho6WRxQA5zQE2bUJRokiTbP5+JUGMw Date: Thu, 14 Apr 2016 08:34:06 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53A022@NKGEML515-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] 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.0A020203.570F5607.0051, 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: 3e63a92653eb7b2b54961c584ceeebaa Archived-At: Subject: Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 08:34:22 -0000 U3VwcG9ydCB0aGUgV0cgYWRvcHRpb24gb2YgdGhpcyBkb2MgKGFzIGEgY28tYXV0aG9yKS4NCg0K QmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogT1NQRiBbbWFpbHRvOm9zcGYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFj ZWUgTGluZGVtIChhY2VlKQ0KPiBTZW50OiBUaHVyc2RheSwgTWFyY2ggMTcsIDIwMTYgMTA6MDkg QU0NCj4gVG86IE9TUEYgV0cgTGlzdA0KPiBTdWJqZWN0OiBbT1NQRl0gV0cgQWRvcHRpb24gUG9s bCBmb3IgIlVzaW5nIE9wZXJhdG9yLWRlZmluZWQgVExWcyBmb3IgQWdpbGUNCj4gU2VydmljZSBE ZXBsb3ltZW50Ig0KPiANCj4gV2XigJl2ZSBkaXNjdXNzZWQgdGhpcyBkcmFmdCBhIG51bWJlciBv ZiB0aW1lcy4gSW4gbXkgb3BpbmlvbiwgaXQgc2VlbXMgbGlrZSBhDQo+IHVzZWZ1bCBtZWNoYW5p c20gaWYgb25lIGVudmlzaW9ucyBhIGdlbmVyYWxpemVkIEFQSSBiZXR3ZWVuIE9TUEYgYW5kIHVz ZXIgYW5kDQo+IHRoaXJkLXBhcnR5IGFwcGxpY2F0aW9ucyB0byBjb252ZXkgYXBwbGljYXRpb24t c3BlY2lmaWMgaW5mb3JtYXRpb24gbGVhcm5lZCBmcm9tDQo+IG90aGVyIE9TUEYgcm91dGVycy4g SW4gbWFueSByZXNwZWN0cywgdGhpcyBoYXMgYWxyZWFkeSBiZWVuIGVudmlzaW9uZWQgZm9yIE9T UEYNCj4gTm9kZSBUYWdzLiBQbGVhc2UgaW5kaWNhdGUgeW91ciBvcGluaW9uIG9uIHRoaXMgZHJh ZnQgYmVmb3JlIE1hcmNoIDMxc3QsIDIwMTYuDQo+IA0KPiBUaGFua3MsDQo+IEFjZWUNCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9TUEYg bWFpbGluZyBsaXN0DQo+IE9TUEZAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vc3BmDQo= From nobody Thu Apr 14 02:09:25 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F9512B00E; Thu, 14 Apr 2016 02:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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.996, 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 ZHVfSpsBs_ny; Thu, 14 Apr 2016 02:09:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47E5212DE72; Thu, 14 Apr 2016 02:09:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHK47978; Thu, 14 Apr 2016 09:09:13 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 14 Apr 2016 10:09:11 +0100 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; Thu, 14 Apr 2016 17:09:04 +0800 From: Xuxiaohu To: "Acee Lindem (acee)" , "draft-ietf-ospf-mpls-elc@ietf.org" Thread-Topic: Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00 Thread-Index: AQHRlBj81Lqya0qQckSeteuSX15/fJ+HehHggABhRACAAU3x0A== Date: Thu, 14 Apr 2016 09:09:03 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53A075@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539826@NKGEML515-MBX.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] 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.0A010201.570F5E39.0097, 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: a599237cdaaf9e338ff22176db06957d Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 09:09:24 -0000 SGkgQWNlZSwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBY2VlIExp bmRlbSAoYWNlZSkgW21haWx0bzphY2VlQGNpc2NvLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBB cHJpbCAxMywgMjAxNiA4OjQxIFBNDQo+IFRvOiBYdXhpYW9odTsgZHJhZnQtaWV0Zi1vc3BmLW1w bHMtZWxjQGlldGYub3JnDQo+IENjOiBPU1BGIFdHIExpc3QNCj4gU3ViamVjdDogUmU6IFNpZ25h bGluZyBFbnRyb3B5IExhYmVsIENhcGFiaWxpdHkgVXNpbmcgT1NQRiAtDQo+IGRyYWZ0LWlldGYt b3NwZi1tcGxzLWVsYy0wMA0KPiANCj4gSGkgVGlnZXIsDQo+IA0KPiBPbiA0LzEzLzE2LCAzOjQx IEFNLCAiWHV4aWFvaHUiIDx4dXhpYW9odUBodWF3ZWkuY29tPiB3cm90ZToNCj4gDQo+ID5IaSBB Y2VlLA0KPiA+DQo+ID5UaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFBsZWFzZSBzZWUgbXkgcmVz cG9uc2UgaW4gbGluZS4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ PiBGcm9tOiBBY2VlIExpbmRlbSAoYWNlZSkgW21haWx0bzphY2VlQGNpc2NvLmNvbV0NCj4gPj4g U2VudDogVHVlc2RheSwgQXByaWwgMTIsIDIwMTYgMTozOSBBTQ0KPiA+PiBUbzogZHJhZnQtaWV0 Zi1vc3BmLW1wbHMtZWxjQGlldGYub3JnDQo+ID4+IENjOiBPU1BGIFdHIExpc3QNCj4gPj4gU3Vi amVjdDogU2lnbmFsaW5nIEVudHJvcHkgTGFiZWwgQ2FwYWJpbGl0eSBVc2luZyBPU1BGIC0NCj4g Pj4gZHJhZnQtaWV0Zi1vc3BmLW1wbHMtZWxjLTAwDQo+ID4+DQo+ID4+IEF1dGhvcnMsDQo+ID4+ DQo+ID4+IFdlIHdpbGwgc29vbiBiZSBwcm9ncmVzc2luZyB0aGUgT1NQRnYyIFNSIGRyYWZ0LiBX aGF0IGlzIHlvdXIgaW50ZW50DQo+ID4+Zm9yIHRoaXMgIGRyYWZ0PyBJdCBpcyBtaXNzaW5nOg0K PiA+Pg0KPiA+PiAgICAgMS4gQSBmaWd1cmUgd2l0aCB0aGUgUkkgZW5jb2RpbmcgbGlrZSBvdGhl ciBPU1BGIGRvY3VtZW50cw0KPiA+DQo+ID5XaWxsIGFkZCB0d28gZmlndXJlcyBmb3IgRUxDIFRM ViBhbmQgUkxTREMgVExWIHJlc3BlY3RpdmVseS4NCj4gDQo+IENhbiB5b3UgY29tZSB1cCB3aXRo IGEgYmV0dGVyIG5hbWUgdGhhbiBSTFNEQz8gSXQgYXBwZWFycyB0aGlzIHdvdWxkIG9idmlhdGUN Cj4gdGhlIG5lZWQgZm9yIHRoZSByZWNlbnQgTVNEIHByb3Bvc2FsIGJ1dCB0aGF0IGlzIGEgbXVj aCBiZXR0ZXIgbmFtZS4NCg0KUkxTREMgaGFzIGJlZW4gcmVwbGFjZWQgYnkgUkxEQyAoUmVhZGFi bGUgTGFiZWwgRGVwdGggQ2FwYWJpbGl0eSkgaW4gdGhlIGxhdGVzdCB2ZXJzaW9uLiBJZiBJIHVu ZGVyc3Rvb2QgaXQgY29ycmVjdGx5LCBNU0QgYW5kIFJMRCBhcmUgdXNlZCB0byBpbmRpY2F0ZSBk aWZmZXJlbnQgdGhpbmdzLCBlLmcuLCB0aGUgZm9ybWVyIGlzIHVzZWQgdG8gaW5kaWNhdGUgaG93 IG1hbnkgbGFiZWxzIHRvIG1heGltdW0gZXh0ZW50IGNvdWxkIGJlIGltcG9zZWQgYnkgdGhlIGlu Z3Jlc3Mgbm9kZSB3aGlsZSB0aGUgbGF0dGVyIGlzIHVzZWQgdG8gaW5kaWNhdGUgaG93IG1hbnkg bGFiZWxzIHRvIG1heGltdW0gZXh0ZW50IGNvdWxkIGJlIHJlYWQgYnkgYSBpbnRlcm1lZGlhdGUg bm9kZS4NCg0KPiA+PiAgICAgMi4gRGlzY3Vzc2lvbiBhcyB0byBwcmVjaXNlbHkgaG93IHRoZSBj YXBhYmlsaXR5IHdvdWxkIGJlIHVzZWQgYnkNCj4gPj5hIHJvdXRlciBpbiAgYW4gT1NQRiByb3V0 aW5nIGRvbWFpbi4gRm9yIGV4YW1wbGUsIG11c3QgYSByb3V0ZXIgcmVtb3ZlDQo+ID4+dGhlIEVM IGlmIHRoZSAgbmV4dC1ob3AgZG9lc27igJl0IHN1cHBvcnQgaXQ/DQo+ID4NCj4gPlRoaXMgZG9j dW1lbnQgb25seSBkZXNjcmliZXMgaG93IHRoZSBFTEMgYW5kIFJMU0RDIGFyZSBhZHZlcnRpc2Vk IHZpYQ0KPiA+T1NQRi4gQXMgZm9yIGhvdyB0aGVzZSBjYXBhYmlsaXRpZXMgd291bGQgYmUgdXNl ZCBhcmUgYWN0dWFsbHkNCj4gPmRlc2NyaWJlZCBpbg0KPiA+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtbXBscy1zcHJpbmctZW50cm9weS1sYWJlbC4gQnkNCj4gPnRoZSB3 YXksIGEgcm91dGVyIGRvZXNuJ3QgbmVlZCB0byByZW1vdmUgdGhlIEVMIGlmIHRoZSBuZXh0LWhv cCBkb2Vzbid0DQo+ID5zdXBwb3J0IGl0LiBUaGUgb25seSByZXF1aXJlbWVudCBvbiB1c2luZyBF TCBpczogQW4gaW5ncmVzcyBMU1IgY2Fubm90DQo+ID5pbnNlcnQgRUxzIGZvciBwYWNrZXRzIGdv aW5nIGludG8gYSBnaXZlbiB0dW5uZWwgdW5sZXNzIGFuIGVncmVzcyBMU1IgaGFzDQo+IGluZGlj YXRlZCB2aWEgc2lnbmFsaW5nIHRoYXQgaXQgY2FuIHByb2Nlc3MgRUxzIG9uIHRoYXQgdHVubmVs Lg0KPiANCj4gQ2FuIHlvdSBhZGQgYSBzaG9ydCBzZWN0aW9uIHJlZmVyZW5jaW5nIHRoZSBhcHBs aWNhYmxlIHNlY3Rpb24gaW4gdGhpcyBkb2N1bWVudC4NCg0KU3VyZS4gRG8geW91IGhhdmUgYW55 IHN1Z2dlc3Qgb24gdGhlIHRleHQgaW4gc3VjaCBzZWN0aW9uPw0KDQo+IA0KPiA+DQo+ID4+ICAg ICAzLiBBIGRpc2N1c3Npb24gb2YgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBmb3IgdGhlIG5ldw0K PiA+PlJvdXRlci1JbmZvcm1hdGlvbiAgTFNBIGNhcGFiaWxpdHkuDQo+ID4NCj4gPklzIGl0IGVu b3VnaCB0byBhZGQgdGhlIGZvbGxvd2luZyB0ZXh0Og0KPiA+DQo+ID4iVG8gYmUgY29tcGF0aWJs ZSB3aXRoIFJGQzc3NzAsIEVMQyBhbmQgUkxTREMgVExWcyBTSE9VTEQgY29udGludWUgdG8NCj4g PmJlIGFkdmVydGlzZWQgaW4gdGhlIGZpcnN0IGluc3RhbmNlLCBpLmUuLCAwLCBvZiB0aGUgUm91 dGVyIEluZm9ybWF0aW9uIExTQS4iDQo+IA0KPiBJIHdhcyB0YWxraW5nIG1vcmUgb24gdGhlIGxl dmVsIG9mIHVzYWdlIG9mIHRoZSBjYXBhYmlsaXR5IHRoYW4gYWR2ZXJ0aXNlbWVudC4NCj4gU2lu Y2UgdGhpcyBpcyBuZXcsIHRoZXJlIHNob3VsZCBiZSBhbnkgUkkgTFNBcyBjb25zaWRlcmF0aW9u cy4NCg0KVGhlIEVMIGNhcGFiaWxpdHkgaXMgdXNlZCBieSBpbmdyZXNzIExTUnMgdG8gZGV0ZXJt aW5lIHdoZXRoZXIgYW4gRUwgY291bGQgYmUgaW5zZXJ0ZWQgaW50byBhIGdpdmVuIExTUCB0dW5u ZWwsIGFuZCB0aGUgUkxEIGNhcGFiaWxpdHkgaXMgdXNlZCBieSBpbmdyZXNzIExTUnMgdG8gZGV0 ZXJtaW5lIHdoZXRoZXIgaXQncyBuZWNlc3NhcnkgdG8gaW5zZXJ0IGFuIEVMIGZvciBhIGdpdmVu IExTUCB0dW5uZWwgaW4gdGhlIGNhc2Ugd2hlcmUgdGhlcmUgaGFzIGFscmVhZHkgYmVlbiBhdCBs ZWFzdCBvbmUgRUwgaW4gdGhlIGxhYmVsIHN0YWNrLiBUaGUgYWJvdmUgaGFzIGJlZW4gbWVudGlv bmVkIGluIHRoZSBJbnRyb2R1Y3Rpb24gc2VjdGlvbi4gSSdtIG5vdCBzdXJlIHRoYXQgSSBmdWxs eSB1bmRlcnN0b29kIHlvdXIgcG9pbnQuIElmIG5vdCwgY291bGQgeW91IGdpdmUgYW55IHN1Z2dl c3Rpb24gb24gdGhlIGRpc2N1c3Npb24gb2YgYmFja3dhcmQgY29tcGF0aWJpbGl0eT8NCg0KQmVz dCByZWdhcmRzLA0KWGlhb2h1IChUaWdlcikNCg0KPiBUaGFua3MsDQo+IEFjZWUNCj4gDQo+IA0K PiANCj4gPg0KPiA+QmVzdCByZWdhcmRzLA0KPiA+WGlhb2h1DQo+ID4NCj4gPj4gVGhhbmtzLA0K PiA+PiBBY2VlDQo+ID4NCg0K From nobody Thu Apr 14 04:21:59 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A2812E420; Thu, 14 Apr 2016 04:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 9Fr8UePkbtNx; Thu, 14 Apr 2016 04:21:56 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438A512E422; Thu, 14 Apr 2016 04:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5708; q=dns/txt; s=iport; t=1460632916; x=1461842516; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ALedy9KWFdJwu0s3vjgufb0hx86JA71wHD2//3rMKM8=; b=NcWHvTHcuYM7chUM74K3bRfwS8hodqa0mJCrmskANGqI95lmtWIQ7sKX M6HIFtrHATKl9MxiiJmc8/aAuTlz/+iFPLLXzl9kVhympH+/CQmF5EDhc nBfWZr19GeNvegpvm7GQ1km+Aam/uVj02nrRzJcDc+7/NmUVOiZZ9Qnr+ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgCAfA9X/4YNJK1egzhTfQa4GoIPA?= =?us-ascii?q?Q2BcSKFbAIcgRg4FAEBAQEBAQFlJ4RBAQEBBCMRRQwEAgEIEQQBAQECAiMDAgI?= =?us-ascii?q?CMBQBCAgCBAENBYgpDq90kkEBAQEBAQEBAQEBAQEBAQEBAQEBAQERBHyIboECh?= =?us-ascii?q?D2DAoJWAQSNUoo5AYV2iBaBZ4ROgyiFM48oAR4BAUKDZ2yIfH4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,484,1454976000"; d="scan'208";a="261297071" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Apr 2016 11:21:55 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3EBLt2x003759 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 11:21:55 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 07:21:54 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Thu, 14 Apr 2016 07:21:54 -0400 From: "Acee Lindem (acee)" To: Xuxiaohu , "draft-ietf-ospf-mpls-elc@ietf.org" Thread-Topic: Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00 Thread-Index: AQHRlBj81Lqya0qQckSeteuSX15/fJ+HehHggABhRACAAU3x0IAALjaA Date: Thu, 14 Apr 2016 11:21:54 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539826@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53A075@NKGEML515-MBX.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53A075@NKGEML515-MBX.china.huawei.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.202] Content-Type: text/plain; charset="utf-8" Content-ID: <31F14A64F21F1C4A982B681FEECC6264@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 11:21:58 -0000 SGkgVGlnZXIsIA0KDQpPbiA0LzE0LzE2LCA1OjA5IEFNLCAiWHV4aWFvaHUiIDx4dXhpYW9odUBo dWF3ZWkuY29tPiB3cm90ZToNCg0KPkhpIEFjZWUsDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4gRnJvbTogQWNlZSBMaW5kZW0gKGFjZWUpIFttYWlsdG86YWNlZUBjaXNjby5j b21dDQo+PiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDEzLCAyMDE2IDg6NDEgUE0NCj4+IFRvOiBY dXhpYW9odTsgZHJhZnQtaWV0Zi1vc3BmLW1wbHMtZWxjQGlldGYub3JnDQo+PiBDYzogT1NQRiBX RyBMaXN0DQo+PiBTdWJqZWN0OiBSZTogU2lnbmFsaW5nIEVudHJvcHkgTGFiZWwgQ2FwYWJpbGl0 eSBVc2luZyBPU1BGIC0NCj4+IGRyYWZ0LWlldGYtb3NwZi1tcGxzLWVsYy0wMA0KPj4gDQo+PiBI aSBUaWdlciwNCj4+IA0KPj4gT24gNC8xMy8xNiwgMzo0MSBBTSwgIlh1eGlhb2h1IiA8eHV4aWFv aHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+PiANCj4+ID5IaSBBY2VlLA0KPj4gPg0KPj4gPlRoYW5r cyBmb3IgeW91ciBjb21tZW50cy4gUGxlYXNlIHNlZSBteSByZXNwb25zZSBpbiBsaW5lLg0KPj4g Pg0KPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+IEZyb206IEFjZWUgTGlu ZGVtIChhY2VlKSBbbWFpbHRvOmFjZWVAY2lzY28uY29tXQ0KPj4gPj4gU2VudDogVHVlc2RheSwg QXByaWwgMTIsIDIwMTYgMTozOSBBTQ0KPj4gPj4gVG86IGRyYWZ0LWlldGYtb3NwZi1tcGxzLWVs Y0BpZXRmLm9yZw0KPj4gPj4gQ2M6IE9TUEYgV0cgTGlzdA0KPj4gPj4gU3ViamVjdDogU2lnbmFs aW5nIEVudHJvcHkgTGFiZWwgQ2FwYWJpbGl0eSBVc2luZyBPU1BGIC0NCj4+ID4+IGRyYWZ0LWll dGYtb3NwZi1tcGxzLWVsYy0wMA0KPj4gPj4NCj4+ID4+IEF1dGhvcnMsDQo+PiA+Pg0KPj4gPj4g V2Ugd2lsbCBzb29uIGJlIHByb2dyZXNzaW5nIHRoZSBPU1BGdjIgU1IgZHJhZnQuIFdoYXQgaXMg eW91ciBpbnRlbnQNCj4+ID4+Zm9yIHRoaXMgIGRyYWZ0PyBJdCBpcyBtaXNzaW5nOg0KPj4gPj4N Cj4+ID4+ICAgICAxLiBBIGZpZ3VyZSB3aXRoIHRoZSBSSSBlbmNvZGluZyBsaWtlIG90aGVyIE9T UEYgZG9jdW1lbnRzDQo+PiA+DQo+PiA+V2lsbCBhZGQgdHdvIGZpZ3VyZXMgZm9yIEVMQyBUTFYg YW5kIFJMU0RDIFRMViByZXNwZWN0aXZlbHkuDQo+PiANCj4+IENhbiB5b3UgY29tZSB1cCB3aXRo IGEgYmV0dGVyIG5hbWUgdGhhbiBSTFNEQz8gSXQgYXBwZWFycyB0aGlzIHdvdWxkDQo+Pm9idmlh dGUNCj4+IHRoZSBuZWVkIGZvciB0aGUgcmVjZW50IE1TRCBwcm9wb3NhbCBidXQgdGhhdCBpcyBh IG11Y2ggYmV0dGVyIG5hbWUuDQo+DQo+UkxTREMgaGFzIGJlZW4gcmVwbGFjZWQgYnkgUkxEQyAo UmVhZGFibGUgTGFiZWwgRGVwdGggQ2FwYWJpbGl0eSkgaW4gdGhlDQo+bGF0ZXN0IHZlcnNpb24u IElmIEkgdW5kZXJzdG9vZCBpdCBjb3JyZWN0bHksIE1TRCBhbmQgUkxEIGFyZSB1c2VkIHRvDQo+ aW5kaWNhdGUgZGlmZmVyZW50IHRoaW5ncywgZS5nLiwgdGhlIGZvcm1lciBpcyB1c2VkIHRvIGlu ZGljYXRlIGhvdyBtYW55DQo+bGFiZWxzIHRvIG1heGltdW0gZXh0ZW50IGNvdWxkIGJlIGltcG9z ZWQgYnkgdGhlIGluZ3Jlc3Mgbm9kZSB3aGlsZSB0aGUNCj5sYXR0ZXIgaXMgdXNlZCB0byBpbmRp Y2F0ZSBob3cgbWFueSBsYWJlbHMgdG8gbWF4aW11bSBleHRlbnQgY291bGQgYmUNCj5yZWFkIGJ5 IGEgaW50ZXJtZWRpYXRlIG5vZGUuDQoNCk9rIC0gdGhpcyB3aWxsIGJlIGNsZWFyZXIgb25jZSB0 aGUgdXNhZ2Ugc2VjdGlvbiBpcyBhZGRlZC4gSSBsaWtlIFJMREMNCmJldHRlciB0aGFuIFJMU0RD LiANCg0KDQo+DQo+PiA+PiAgICAgMi4gRGlzY3Vzc2lvbiBhcyB0byBwcmVjaXNlbHkgaG93IHRo ZSBjYXBhYmlsaXR5IHdvdWxkIGJlIHVzZWQgYnkNCj4+ID4+YSByb3V0ZXIgaW4gIGFuIE9TUEYg cm91dGluZyBkb21haW4uIEZvciBleGFtcGxlLCBtdXN0IGEgcm91dGVyIHJlbW92ZQ0KPj4gPj50 aGUgRUwgaWYgdGhlICBuZXh0LWhvcCBkb2VzbuKAmXQgc3VwcG9ydCBpdD8NCj4+ID4NCj4+ID5U aGlzIGRvY3VtZW50IG9ubHkgZGVzY3JpYmVzIGhvdyB0aGUgRUxDIGFuZCBSTFNEQyBhcmUgYWR2 ZXJ0aXNlZCB2aWENCj4+ID5PU1BGLiBBcyBmb3IgaG93IHRoZXNlIGNhcGFiaWxpdGllcyB3b3Vs ZCBiZSB1c2VkIGFyZSBhY3R1YWxseQ0KPj4gPmRlc2NyaWJlZCBpbg0KPj4gPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1wbHMtc3ByaW5nLWVudHJvcHktbGFiZWwuIEJ5 DQo+PiA+dGhlIHdheSwgYSByb3V0ZXIgZG9lc24ndCBuZWVkIHRvIHJlbW92ZSB0aGUgRUwgaWYg dGhlIG5leHQtaG9wIGRvZXNuJ3QNCj4+ID5zdXBwb3J0IGl0LiBUaGUgb25seSByZXF1aXJlbWVu dCBvbiB1c2luZyBFTCBpczogQW4gaW5ncmVzcyBMU1IgY2Fubm90DQo+PiA+aW5zZXJ0IEVMcyBm b3IgcGFja2V0cyBnb2luZyBpbnRvIGEgZ2l2ZW4gdHVubmVsIHVubGVzcyBhbiBlZ3Jlc3MgTFNS DQo+Pmhhcw0KPj4gaW5kaWNhdGVkIHZpYSBzaWduYWxpbmcgdGhhdCBpdCBjYW4gcHJvY2VzcyBF THMgb24gdGhhdCB0dW5uZWwuDQo+PiANCj4+IENhbiB5b3UgYWRkIGEgc2hvcnQgc2VjdGlvbiBy ZWZlcmVuY2luZyB0aGUgYXBwbGljYWJsZSBzZWN0aW9uIGluIHRoaXMNCj4+ZG9jdW1lbnQuDQo+ DQo+U3VyZS4gRG8geW91IGhhdmUgYW55IHN1Z2dlc3Qgb24gdGhlIHRleHQgaW4gc3VjaCBzZWN0 aW9uPw0KDQpJIGNvdWxkIHdyaXRlIHRoaXMgYnV0IHlvdSB0aGluayB3aXRoIDUgYXV0aG9ycyBm b3IgYSBkcmFmdCB0aGF0IG9ubHkgaGFzDQoxIDEvMiBwYWdlcyBvZiBjb250ZW50IC0gb25lIG9m IHlvdSB3b3VsZCBiZSBhYmxlIHRvIHdyaXRlIHRoaXMuDQoNCg0KDQo+DQo+PiANCj4+ID4NCj4+ ID4+ICAgICAzLiBBIGRpc2N1c3Npb24gb2YgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBmb3IgdGhl IG5ldw0KPj4gPj5Sb3V0ZXItSW5mb3JtYXRpb24gIExTQSBjYXBhYmlsaXR5Lg0KPj4gPg0KPj4g PklzIGl0IGVub3VnaCB0byBhZGQgdGhlIGZvbGxvd2luZyB0ZXh0Og0KPj4gPg0KPj4gPiJUbyBi ZSBjb21wYXRpYmxlIHdpdGggUkZDNzc3MCwgRUxDIGFuZCBSTFNEQyBUTFZzIFNIT1VMRCBjb250 aW51ZSB0bw0KPj4gPmJlIGFkdmVydGlzZWQgaW4gdGhlIGZpcnN0IGluc3RhbmNlLCBpLmUuLCAw LCBvZiB0aGUgUm91dGVyDQo+PkluZm9ybWF0aW9uIExTQS4iDQo+PiANCj4+IEkgd2FzIHRhbGtp bmcgbW9yZSBvbiB0aGUgbGV2ZWwgb2YgdXNhZ2Ugb2YgdGhlIGNhcGFiaWxpdHkgdGhhbg0KPj5h ZHZlcnRpc2VtZW50Lg0KPj4gU2luY2UgdGhpcyBpcyBuZXcsIHRoZXJlIHNob3VsZCBiZSBhbnkg UkkgTFNBcyBjb25zaWRlcmF0aW9ucy4NCj4NCj5UaGUgRUwgY2FwYWJpbGl0eSBpcyB1c2VkIGJ5 IGluZ3Jlc3MgTFNScyB0byBkZXRlcm1pbmUgd2hldGhlciBhbiBFTA0KPmNvdWxkIGJlIGluc2Vy dGVkIGludG8gYSBnaXZlbiBMU1AgdHVubmVsLCBhbmQgdGhlIFJMRCBjYXBhYmlsaXR5IGlzIHVz ZWQNCj5ieSBpbmdyZXNzIExTUnMgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgaXQncyBuZWNlc3Nhcnkg dG8gaW5zZXJ0IGFuIEVMIGZvciBhDQo+Z2l2ZW4gTFNQIHR1bm5lbCBpbiB0aGUgY2FzZSB3aGVy ZSB0aGVyZSBoYXMgYWxyZWFkeSBiZWVuIGF0IGxlYXN0IG9uZSBFTA0KPmluIHRoZSBsYWJlbCBz dGFjay4gVGhlIGFib3ZlIGhhcyBiZWVuIG1lbnRpb25lZCBpbiB0aGUgSW50cm9kdWN0aW9uDQo+ c2VjdGlvbi4gSSdtIG5vdCBzdXJlIHRoYXQgSSBmdWxseSB1bmRlcnN0b29kIHlvdXIgcG9pbnQu IElmIG5vdCwgY291bGQNCj55b3UgZ2l2ZSBhbnkgc3VnZ2VzdGlvbiBvbiB0aGUgZGlzY3Vzc2lv biBvZiBiYWNrd2FyZCBjb21wYXRpYmlsaXR5Pw0KDQpXaGF0IGhhcHBlbnMgaWYgbm90IGFsbCBy b3V0ZXJzIGluIHRoZSBkb21haW4gc3VwcG9ydCBjYXBhYmlsaXR5DQphZHZlcnRpc2VtZW50PyAN Cg0KVGhhbmtzLA0KQWNlZSANCg0KDQo+DQo+QmVzdCByZWdhcmRzLA0KPlhpYW9odSAoVGlnZXIp DQo+DQo+PiBUaGFua3MsDQo+PiBBY2VlDQo+PiANCj4+IA0KPj4gDQo+PiA+DQo+PiA+QmVzdCBy ZWdhcmRzLA0KPj4gPlhpYW9odQ0KPj4gPg0KPj4gPj4gVGhhbmtzLA0KPj4gPj4gQWNlZQ0KPj4g Pg0KPg0KDQo= From nobody Thu Apr 14 06:10:49 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D4512D61A for ; Thu, 14 Apr 2016 06:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 8SE9ZAbWNjra for ; Thu, 14 Apr 2016 06:10:47 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F19512D591 for ; Thu, 14 Apr 2016 06:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2034; q=dns/txt; s=iport; t=1460639447; x=1461849047; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Y5CwdAeyGScPuKdUPiO2vm11BfI837XxkwtNbUGUmOg=; b=WWA4zxw9AJEi0eyK64+3EfAA2r4O2cApidoI8rcUKzXrt5nSl+cVdri7 2nuSFcgurFdlvBIti5RkTpsJVDt0SNmKeruTBwKUL6TeDIDs9LYrnhDuG hDHokazFlAlsKSRLiC284D2AXXyCYzN0AqKDFW6P+TlVJGn7WAMMffYSz M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BnAgDOlQ9X/5RdJa1egziBUAa4GoIPA?= =?us-ascii?q?Q2BcYYOAoE0OBQBAQEBAQEBZSeEQgEBBDo/EAIBCDYQMiUCBA4FiCnCRwEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARWGIYRLihUFkx2EbgGODI8QjygBHgEBQoNnbIhIf?= =?us-ascii?q?gEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,484,1454976000"; d="scan'208";a="261451943" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2016 13:10:46 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3EDAkki015315 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 13:10:46 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 08:10:45 -0500 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.1104.009; Thu, 14 Apr 2016 08:10:46 -0500 From: "Alvaro Retana (aretana)" To: Paul Jakma Thread-Topic: [OSPF] OSPF WG Minutes from IETF 95 Thread-Index: AQHRk3PgRnVqmNZNrEiwg2kB/ZG01J+FBA8AgAA2vgCAAw3sAIAAFVgAgABQ+oCAANjmAA== Date: Thu, 14 Apr 2016 13:10:45 +0000 Message-ID: References: <04479c8fba16697eb3a51ea89d0cd708@zeta2.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <4117771D662DBB46991A544D203E255C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] OSPF WG Minutes from IETF 95 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 13:10:49 -0000 On 4/13/16, 4:14 PM, "OSPF on behalf of Paul Jakma" wrote: [Speaking as WG participant and author of rfc6987.] Paul: Hi! You and I have had a similar conversation off-list... ... >I may have misinterpreted RFC6987, sure. > >However, it is a fact that the behaviour desired by RFC6987 can be >universally achieved with metrics of 0xfffe or lower. That was true >before any misinterpretation, and is still true now. Both MaxLinkMetric and 0xfffe are "very large numbers" (VLN), which means that if we use 0xfffe, or any other VLN (including MaxLinkMetric), then we should get "the same" behavior. I wrote ""the same"" because the result can vary depending on which VLN a router in the network uses with respect to another router that may also want to be a stub. For example, given 2 paths to a destination, if a router uses 0xfffe (or any other VLN which is not MaxLinkMetric) it should become a stub. However, if a router on the second path decides to use MaxLinkMetric, then the first one (the one using 0xfffe) will become transit. We can obviously expand that example to n number of links and n values of VLN and end up with a wide variety of results -- which will not be deterministic unless we know which VLN each router used in each case... When we originally wrote rfc3137 (the precursor of rfc6987), we chose MaxLinkMetric because it guarantees the stub behavior (no other VLN is higher), unless an alternate path does not exist. Clearly we took advantage of how the metric is treated in the current OSPF specification (starting with rfc1583). If we has used 0xfffe (or any other VLN) then the behavior wouldn't have been guaranteed (using the current OSPF spec). >0xffff today will not universally be recognised as meaning "you can >still calculate transit paths out of a router using that link". 0xfffe >or below will. > >That is the reality today. True, but only for pre-rfc1583 routers. Regards, Alvaro. From nobody Thu Apr 14 06:28:32 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E346012E1EC for ; Thu, 14 Apr 2016 06:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 5UnOMmGMXiOA for ; Thu, 14 Apr 2016 06:28:25 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D144912DF64 for ; Thu, 14 Apr 2016 06:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3072; q=dns/txt; s=iport; t=1460640504; x=1461850104; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ufD/zVhJXgmDr4h8eVHFmitvFez2giIYWyX+biU5am4=; b=UpA5HJu3DzL/q+5uEKlzysmpha+vX2bostgRtlRIm/dNS5g1rXn8g9h7 tQRWxEt8LQRbGHU0Tk1i3GXxTpvpO57PjFYI5XJ0qifT27e/h2gBCd8sg jzyZbLZBwBuQkVBTJ5Op7KmAO/eyIueR2UUvFhjN52mDqXnrad4GXc8Ia Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AuBgA9mg9X/5pdJa1egziBUAa4GoIdg?= =?us-ascii?q?XGGDgKBNDkTAQEBAQEBAWUnhEIBAQQ6PxACAQg2EDIlAgQBDQWIKcJKAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBFYYhhEuKFQEEkx2EbgGODIFnh3aFM48oASEBQINnb?= =?us-ascii?q?IhIfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,484,1454976000"; d="scan'208";a="96410569" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2016 13:28:24 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3EDSNYt001297 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 13:28:24 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 08:28:23 -0500 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.1104.009; Thu, 14 Apr 2016 08:28:23 -0500 From: "Alvaro Retana (aretana)" To: "Acee Lindem (acee)" , Paul Jakma Thread-Topic: [OSPF] OSPF WG Minutes from IETF 95 Thread-Index: AQHRk3PgRnVqmNZNrEiwg2kB/ZG01J+FBA8AgAA2vgCAAw3sAIAAFVgAgABQ+oCAACY8AIAAt5cA Date: Thu, 14 Apr 2016 13:28:23 +0000 Message-ID: References: <04479c8fba16697eb3a51ea89d0cd708@zeta2.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <949EE778B472EF43969B58CE91C76B76@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] OSPF WG Minutes from IETF 95 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 13:28:31 -0000 On 4/13/16, 6:31 PM, "OSPF on behalf of Acee Lindem (acee)" wrote: author Acee: Hi! >>Sure, 4 reads the other way but "deployment considerations" . I'm not >>saying how it must be read, just saying it is possible to read the >>stronger language of 3 another way. >> >>I'm not trying to argue, I'm trying to explain why we are here. > >One of the authors or myself will write an errata to clarify this >definition. What do you have in mind? I may be too close to the text myself to tell where we should change something. Even if we interpret the "should not" in Section 3 as if it was "SHOULD NOT", it is still not a "MUST"...and the obvious reason the link would be used is if there isn't another path. There is one part which I think can be clarified (only including the change): NEW> 4. Deployment Considerations ... on using them rather than the path through the stub router. If the path through the stub router is the only one, the routers of the first type will not use the stub router for transit, while the routers of the second type will still use this path, which may result in a routing=20 loop. ... I'm open to other suggestions. Thanks! Alvaro. CURRENT TEXT> 3. Maximum Link Metric Section 2 refers to the cost of all non-stub links as MaxLinkMetric, which is a new fixed architectural value introduced in this document. MaxLinkMetric The metric value indicating that a router-LSA link (see Section 2) should not be used for transit traffic. It is defined to be the 16-bit binary value of all ones: 0xffff. 4. Deployment Considerations When using MaxLinkMetric, some inconsistency may be seen if the network is constructed of routers that perform an intra-area Dijkstra calculation as specified in [RFC1247] (discarding link records in router-LSAs that have a MaxLinkMetric cost value) and routers that perform it as specified in [RFC1583] and higher (do not treat links with MaxLinkMetric cost as unreachable). Note that this inconsistency will not lead to routing loops, because if there are some alternate paths in the network, both types of routers will agree on using them rather than the path through the stub router. If the path through the stub router is the only one, the routers of the first type will not use the stub router for transit (which is the desired behavior), while the routers of the second type will still use this path. On the other hand, clearing the R-bit will consistently result in the router not being used for transit. The use of MaxLinkMetric or the R-bit in a network depends on the objectives of the operator. One of the possible considerations for selecting one or the other is in the desired behavior if the path through the stub router is the only one available. Using MaxLinkMetric allows for that path to be used while the R-bit doesn't. From nobody Thu Apr 14 06:40:28 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACCD12E269 for ; Thu, 14 Apr 2016 06:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 jun41s6D--RI for ; Thu, 14 Apr 2016 06:40:22 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89E0812E2A5 for ; Thu, 14 Apr 2016 06:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5424; q=dns/txt; s=iport; t=1460641222; x=1461850822; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CjgNv9WfPlgB2e5mcQSW6DZNt5H8jJLtuxk2vAE29hM=; b=Nk9rCAEWebm3DW4JUwgHlgln17+IeznB2dGiejy86Qd4YlID2R82JyzO ktVGa6KHj4wLhmAHlUkEG7eP+bEpp3M5uAyGLlWQuO+xdmvBbxzU29fre ZU8I1YgrtxOtQgtBTLSYhqC1kuV7Utdvez/rYV4X3RqWjcambkWPBTJX3 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BoAgCFnQ9X/51dJa1egziBUAa4GoIPA?= =?us-ascii?q?Q2BcYYOAhyBGTgUAQEBAQEBAWUnhEIBAQQjEUUQAgEIGAICJgICAjAVEAIEAQ0?= =?us-ascii?q?FiCmwCZJGAQEBAQEBAQEBAQEBAQEBAQEBAQEBFXyJcIc/glYBBJgLAY4MgWeHd?= =?us-ascii?q?oUzjygBHgEBQoNnbIhIfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,484,1454976000"; d="scan'208";a="91430172" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2016 13:40:09 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u3EDe8Rv020847 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 13:40:09 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.1104.5; Thu, 14 Apr 2016 09:40:08 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Thu, 14 Apr 2016 09:40:08 -0400 From: "Acee Lindem (acee)" To: "Alvaro Retana (aretana)" , Paul Jakma Thread-Topic: [OSPF] OSPF WG Minutes from IETF 95 Thread-Index: AQHRk+ug+9xkeFSUNUaQhV0sMu+UBZ+E5gwAgANQ+gD//9JIAIAAlAqA///jKQCAAT2+gP//wDYA Date: Thu, 14 Apr 2016 13:40:07 +0000 Message-ID: References: <04479c8fba16697eb3a51ea89d0cd708@zeta2.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.202] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] OSPF WG Minutes from IETF 95 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 13:40:26 -0000 PGhhdD5BdXRob3Igb2YgY29tcGxpbWVudCBpbXBsZW1lbnRhdGlvbjwvaGF0Pg0KDQpIaSBBbHZh cm8sIA0KDQpJIGRvbuKAmXQgbmVjZXNzYXJpbHkgYWdyZWUgdGhhdCB0aGUgb25seSBjYXNlIHdo ZXJlIHRoZSBsaW5rcyB3aXRoDQpNYXhMaW5rTWV0cmljIHdpbGwgYmUgdXNlZCBpcyB3aGVuIHRo ZXJlIGlzIG5vIG90aGVyIHBhdGguIE9uZSBjb3VsZCBoYXZlDQphIHNpdHVhdGlvbiB3aGVyZSBh biBhbHRlcm5hdGUgcGF0aCBleGlzdGVkIGJ1dCB0aGUgYWdncmVnYXRlIGNvc3Qgd2FzDQpncmVh dGVyIHRoYW4gNjRLLiBJIGFncmVlIHRoaXMgaXMgaGlnaGx5IHVubGlrZWx5IGluIHJlYWwgZGVw bG95bWVudHMgYnV0DQp2ZXJ5IGxpa2VseSBpbiB0ZXN0IHRvcG9sb2dpZXMuIEhlbmNlLCBJ4oCZ ZCBsZWF2ZSB0aGUgc2VjdGlvbiA0IHRleHQgYXMgaXMNCmFuZCBtb2RpZnkgdGhlIHNlY3Rpb24g MyB0ZXh0Lg0KDQoNCiAgIE1heExpbmtNZXRyaWMNCiAgICAgIFRoZSBtZXRyaWMgdmFsdWUgaW5k aWNhdGluZyB0aGF0IGEgcm91dGVyLUxTQSBsaW5rIChzZWUgU2VjdGlvbiAyKQ0KICAgICAgc2hv dWxkIHN0cm9uZ2x5IGRpc2NvdXJhZ2UgdGhlIHVzYWdlIGZvciB0cmFuc2l0IHRyYWZmaWMuICBJ dCBpcw0KICAgICAgZGVmaW5lZCB0byBiZSB0aGUgMTYtYml0IGJpbmFyeSB2YWx1ZSBvZiBhbGwg b25lczogMHhmZmZmLg0KDQoNClRoYW5rcywNCkFjZWUgDQoNCg0KT24gNC8xNC8xNiwgOToyOCBB TSwgIkFsdmFybyBSZXRhbmEgKGFyZXRhbmEpIiA8YXJldGFuYUBjaXNjby5jb20+IHdyb3RlOg0K DQo+T24gNC8xMy8xNiwgNjozMSBQTSwgIk9TUEYgb24gYmVoYWxmIG9mIEFjZWUgTGluZGVtIChh Y2VlKSINCj48b3NwZi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBhY2VlQGNpc2NvLmNv bT4gd3JvdGU6DQo+DQo+PGhhdD5hdXRob3I8aGF0Pg0KPg0KPkFjZWU6DQo+DQo+SGkhDQo+DQo+ Pj5TdXJlLCA0IHJlYWRzIHRoZSBvdGhlciB3YXkgYnV0ICJkZXBsb3ltZW50IGNvbnNpZGVyYXRp b25zIiAuIEknbSBub3QNCj4+PnNheWluZyBob3cgaXQgbXVzdCBiZSByZWFkLCBqdXN0IHNheWlu ZyBpdCBpcyBwb3NzaWJsZSB0byByZWFkIHRoZQ0KPj4+c3Ryb25nZXIgbGFuZ3VhZ2Ugb2YgMyBh bm90aGVyIHdheS4NCj4+Pg0KPj4+SSdtIG5vdCB0cnlpbmcgdG8gYXJndWUsIEknbSB0cnlpbmcg dG8gZXhwbGFpbiB3aHkgd2UgYXJlIGhlcmUuDQo+Pg0KPj5PbmUgb2YgdGhlIGF1dGhvcnMgb3Ig bXlzZWxmIHdpbGwgd3JpdGUgYW4gZXJyYXRhIHRvIGNsYXJpZnkgdGhpcw0KPj5kZWZpbml0aW9u Lg0KPg0KPldoYXQgZG8geW91IGhhdmUgaW4gbWluZD8NCj4NCj5JIG1heSBiZSB0b28gY2xvc2Ug dG8gdGhlIHRleHQgbXlzZWxmIHRvIHRlbGwgd2hlcmUgd2Ugc2hvdWxkIGNoYW5nZQ0KPnNvbWV0 aGluZy4gIEV2ZW4gaWYgd2UgaW50ZXJwcmV0IHRoZSAic2hvdWxkIG5vdCIgaW4gU2VjdGlvbiAz IGFzIGlmIGl0DQo+d2FzICJTSE9VTEQgTk9UIiwgaXQgaXMgc3RpbGwgbm90IGEgIk1VU1QiLi4u YW5kIHRoZSBvYnZpb3VzIHJlYXNvbiB0aGUNCj5saW5rIHdvdWxkIGJlIHVzZWQgaXMgaWYgdGhl cmUgaXNuJ3QgYW5vdGhlciBwYXRoLg0KPg0KPlRoZXJlIGlzIG9uZSBwYXJ0IHdoaWNoIEkgdGhp bmsgY2FuIGJlIGNsYXJpZmllZCAob25seSBpbmNsdWRpbmcgdGhlDQo+Y2hhbmdlKToNCj4NCj5O RVc+DQo+NC4gIERlcGxveW1lbnQgQ29uc2lkZXJhdGlvbnMNCj4uLi4NCj4gICBvbiB1c2luZyB0 aGVtIHJhdGhlciB0aGFuIHRoZSBwYXRoIHRocm91Z2ggdGhlIHN0dWIgcm91dGVyLiAgSWYgdGhl DQo+ICAgcGF0aCB0aHJvdWdoIHRoZSBzdHViIHJvdXRlciBpcyB0aGUgb25seSBvbmUsIHRoZSBy b3V0ZXJzIG9mIHRoZQ0KPiAgIGZpcnN0IHR5cGUgd2lsbCBub3QgdXNlIHRoZSBzdHViIHJvdXRl ciBmb3IgdHJhbnNpdCwgd2hpbGUgdGhlIHJvdXRlcnMNCj4gICBvZiB0aGUgc2Vjb25kIHR5cGUg d2lsbCBzdGlsbCB1c2UgdGhpcyBwYXRoLCB3aGljaCBtYXkgcmVzdWx0IGluIGENCj5yb3V0aW5n IA0KPiAgIGxvb3AuDQo+Li4uDQo+DQo+DQo+DQo+SSdtIG9wZW4gdG8gb3RoZXIgc3VnZ2VzdGlv bnMuDQo+DQo+VGhhbmtzIQ0KPg0KPkFsdmFyby4NCj4NCj4NCj4NCj5DVVJSRU5UIFRFWFQ+DQo+ My4gIE1heGltdW0gTGluayBNZXRyaWMNCj4NCj4gICBTZWN0aW9uIDIgcmVmZXJzIHRvIHRoZSBj b3N0IG9mIGFsbCBub24tc3R1YiBsaW5rcyBhcyBNYXhMaW5rTWV0cmljLA0KPiAgIHdoaWNoIGlz IGEgbmV3IGZpeGVkIGFyY2hpdGVjdHVyYWwgdmFsdWUgaW50cm9kdWNlZCBpbiB0aGlzIGRvY3Vt ZW50Lg0KPg0KPiAgIE1heExpbmtNZXRyaWMNCj4gICAgICBUaGUgbWV0cmljIHZhbHVlIGluZGlj YXRpbmcgdGhhdCBhIHJvdXRlci1MU0EgbGluayAoc2VlIFNlY3Rpb24gMikNCj4gICAgICBzaG91 bGQgbm90IGJlIHVzZWQgZm9yIHRyYW5zaXQgdHJhZmZpYy4gIEl0IGlzIGRlZmluZWQgdG8gYmUg dGhlDQo+ICAgICAgMTYtYml0IGJpbmFyeSB2YWx1ZSBvZiBhbGwgb25lczogMHhmZmZmLg0KPg0K PjQuICBEZXBsb3ltZW50IENvbnNpZGVyYXRpb25zDQo+DQo+ICAgV2hlbiB1c2luZyBNYXhMaW5r TWV0cmljLCBzb21lIGluY29uc2lzdGVuY3kgbWF5IGJlIHNlZW4gaWYgdGhlDQo+ICAgbmV0d29y ayBpcyBjb25zdHJ1Y3RlZCBvZiByb3V0ZXJzIHRoYXQgcGVyZm9ybSBhbiBpbnRyYS1hcmVhIERp amtzdHJhDQo+ICAgY2FsY3VsYXRpb24gYXMgc3BlY2lmaWVkIGluIFtSRkMxMjQ3XSAoZGlzY2Fy ZGluZyBsaW5rIHJlY29yZHMgaW4NCj4gICByb3V0ZXItTFNBcyB0aGF0IGhhdmUgYSBNYXhMaW5r TWV0cmljIGNvc3QgdmFsdWUpIGFuZCByb3V0ZXJzIHRoYXQNCj4gICBwZXJmb3JtIGl0IGFzIHNw ZWNpZmllZCBpbiBbUkZDMTU4M10gYW5kIGhpZ2hlciAoZG8gbm90IHRyZWF0IGxpbmtzDQo+ICAg d2l0aCBNYXhMaW5rTWV0cmljIGNvc3QgYXMgdW5yZWFjaGFibGUpLiAgTm90ZSB0aGF0IHRoaXMN Cj4gICBpbmNvbnNpc3RlbmN5IHdpbGwgbm90IGxlYWQgdG8gcm91dGluZyBsb29wcywgYmVjYXVz ZSBpZiB0aGVyZSBhcmUNCj4gICBzb21lIGFsdGVybmF0ZSBwYXRocyBpbiB0aGUgbmV0d29yaywg Ym90aCB0eXBlcyBvZiByb3V0ZXJzIHdpbGwgYWdyZWUNCj4gICBvbiB1c2luZyB0aGVtIHJhdGhl ciB0aGFuIHRoZSBwYXRoIHRocm91Z2ggdGhlIHN0dWIgcm91dGVyLiAgSWYgdGhlDQo+ICAgcGF0 aCB0aHJvdWdoIHRoZSBzdHViIHJvdXRlciBpcyB0aGUgb25seSBvbmUsIHRoZSByb3V0ZXJzIG9m IHRoZQ0KPiAgIGZpcnN0IHR5cGUgd2lsbCBub3QgdXNlIHRoZSBzdHViIHJvdXRlciBmb3IgdHJh bnNpdCAod2hpY2ggaXMgdGhlDQo+ICAgZGVzaXJlZCBiZWhhdmlvciksIHdoaWxlIHRoZSByb3V0 ZXJzIG9mIHRoZSBzZWNvbmQgdHlwZSB3aWxsIHN0aWxsDQo+ICAgdXNlIHRoaXMgcGF0aC4NCj4N Cj4gICBPbiB0aGUgb3RoZXIgaGFuZCwgY2xlYXJpbmcgdGhlIFItYml0IHdpbGwgY29uc2lzdGVu dGx5IHJlc3VsdCBpbiB0aGUNCj4gICByb3V0ZXIgbm90IGJlaW5nIHVzZWQgZm9yIHRyYW5zaXQu DQo+DQo+ICAgVGhlIHVzZSBvZiBNYXhMaW5rTWV0cmljIG9yIHRoZSBSLWJpdCBpbiBhIG5ldHdv cmsgZGVwZW5kcyBvbiB0aGUNCj4gICBvYmplY3RpdmVzIG9mIHRoZSBvcGVyYXRvci4gIE9uZSBv ZiB0aGUgcG9zc2libGUgY29uc2lkZXJhdGlvbnMgZm9yDQo+ICAgc2VsZWN0aW5nIG9uZSBvciB0 aGUgb3RoZXIgaXMgaW4gdGhlIGRlc2lyZWQgYmVoYXZpb3IgaWYgdGhlIHBhdGgNCj4gICB0aHJv dWdoIHRoZSBzdHViIHJvdXRlciBpcyB0aGUgb25seSBvbmUgYXZhaWxhYmxlLiAgVXNpbmcNCj4g ICBNYXhMaW5rTWV0cmljIGFsbG93cyBmb3IgdGhhdCBwYXRoIHRvIGJlIHVzZWQgd2hpbGUgdGhl IFItYml0DQo+ICAgZG9lc24ndC4NCj4NCj4NCg0K From nobody Thu Apr 14 07:52:21 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA45312E57A for ; Thu, 14 Apr 2016 07:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 vpA807RRPZB6 for ; Thu, 14 Apr 2016 07:52:19 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A671612E579 for ; Thu, 14 Apr 2016 07:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1426; q=dns/txt; s=iport; t=1460645539; x=1461855139; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QrkENlOQ0VtCZfVmvs9jLgdGYMjm0V1x92WBySPU6eQ=; b=LolROeWcTrbilpzFb/4R1wpdLbpbObHV6rhKOri4Z1tJgp79swoVC8/q z2YwFeIFQCJB2iYYJKmKkvqozsIBHVZerteDRWE+mW05eBzJ39e85XhX+ OGHqnCu2pRMh8+nOtu5kpqqxd+ig+4YEshHlutoG4SOo3oWCSkJVDDJgA s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BnAgBmrg9X/5NdJa1egziBUAa4GoIPA?= =?us-ascii?q?Q2BcYYOAoE3OBQBAQEBAQEBZSeEQgEBBCdSEAIBCEYyJQIEAQ0FiCnCXgEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARWGIYRLihUBBI4KhROEbgGODIFnjSmGIYkHAR4BA?= =?us-ascii?q?UKDZ2yICQc4fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,485,1454976000"; d="scan'208";a="260628932" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2016 14:52:12 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3EEqCHS018712 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 14:52:12 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 09:52:11 -0500 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.1104.009; Thu, 14 Apr 2016 09:52:12 -0500 From: "Alvaro Retana (aretana)" To: "Acee Lindem (acee)" , Paul Jakma Thread-Topic: [OSPF] OSPF WG Minutes from IETF 95 Thread-Index: AQHRk3PgRnVqmNZNrEiwg2kB/ZG01J+FBA8AgAA2vgCAAw3sAIAAFVgAgABQ+oCAACY8AIAAt5cAgABGXID//9EOAA== Date: Thu, 14 Apr 2016 14:52:12 +0000 Message-ID: References: <04479c8fba16697eb3a51ea89d0cd708@zeta2.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.15.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <10259F30EB7A8C458DCDA6ECD59F7F38@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] OSPF WG Minutes from IETF 95 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 14:52:21 -0000 On 4/14/16, 9:40 AM, "Acee Lindem (acee)" wrote: Acee: ... >...I=B9d leave the section 4 text as is >and modify the section 3 text. I agree with your proposal. The reason for proposing a change in 4 is because if only one path exists it may result in a loop (if pre-rfc1583 and current routers are present): <-- 0/0 -- rtr1 -- rtr2 -- rtr3 -- destination --> In this network there's a default route going left and the destination we want to reach is on the right. rtr2 is a pre-rfc1583 router and rtr3 uses rfc6987. If the source is connected to rtr1, rtr1 will decide to use rtr3 as transit (it is the only path). But rtr2 will not and send the packet back to rtr1 (following the default), resulting in a loop. ...so the text below clarifies that it is a possibility. We can file these are independent errata and let the AD deal with them. ;-) In both cases I think the update doesn't change the spirit of the RFC and can just be help for document update. Thanks! Alvaro. >> >>NEW> >>4. Deployment Considerations >>... >> on using them rather than the path through the stub router. If the >> path through the stub router is the only one, the routers of the >> first type will not use the stub router for transit, while the routers >> of the second type will still use this path, which may result in a >>routing=20 >> loop. >>... >> From nobody Thu Apr 14 07:58:17 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9E312E444 for ; Thu, 14 Apr 2016 07:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jakma-org.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 nV2eva5EzuaA for ; Thu, 14 Apr 2016 07:58:13 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 135C712E329 for ; Thu, 14 Apr 2016 07:58:13 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id n3so130324827wmn.0 for ; Thu, 14 Apr 2016 07:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jakma-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=+2DXV5YGJVEJ1yLEjLjM/b8AIDFbvjWgp+px4vHss/c=; b=0yRtRtCspHU2bWQ8QLFMfCNTw9Q01i/53wxeaWkYHUm4oMI/kKtZV6hZpaRYOofl5h EWr0ByQ4lON7xT8ynAzcBwB5U8auoa+x9kaJJxN1q6m7Qf8AZGZfy/YlSpYc3+i1jd6i nq5F0wjeqBg/AzeRkIi8wAtHN/7exIbA80sSts7XtbVm9pBQeVU2il/sEAB7paZdMNsI ErltFty3tQMXCsxCXm7wc/zE/Cq+T8OmiHa6oBqmZiYNlaS5KKKlp/pzrrNCe+q/TA7R V0s4RIRQA6M6y5FguJkn6XHd7qYOS/vDfF7r3GcJIksH5zfRU+bHrxmIbEu/tj8pkip+ t00g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=+2DXV5YGJVEJ1yLEjLjM/b8AIDFbvjWgp+px4vHss/c=; b=GlI3L54qymnMpkc+DaaLPFogzyVCiu+pCGfcuSFQySsxD3AYlst2qxssBEEZDBOGRC 8rzrLbMQIT0czfTfswkwaqphllNnLfKPYSzS2ScYXKA3601yQhMXrbDLEdJKc6KhMvcb ZXv+Ek0bFVz03iIUFdPFmkDxBbb539qaBumHJf0eFnpZt/Y87JSISZ5YG40BwR0O3Vyz +SVI6StHH8K/fo2VQwiftI79XkJJ34qfX6z3kyhFVWr2UxRljuEJ/GWctjLBXu4JHovo 48sF7IGM3/jZ/xcQwljudNyoHj4bBrEUHgkcihuNe0KD+T3zdLCfEI7Ko3KIGajfdo91 DJmA== X-Gm-Message-State: AOPr4FVNjm1HyOZN+jir+E/Nbyg+N0aYUBxNa8lwqXvpttmk09NTQj6SxBORR/NhJOkdyA== X-Received: by 10.194.6.36 with SMTP id x4mr16510476wjx.122.1460645891517; Thu, 14 Apr 2016 07:58:11 -0700 (PDT) Received: from stoner.jakma.org (stoner.jakma.org. [81.168.24.42]) by smtp.gmail.com with ESMTPSA id v6sm33709711wmv.16.2016.04.14.07.58.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Apr 2016 07:58:10 -0700 (PDT) Date: Thu, 14 Apr 2016 15:58:09 +0100 (BST) From: Paul Jakma To: "Acee Lindem (acee)" In-Reply-To: Message-ID: References: <04479c8fba16697eb3a51ea89d0cd708@zeta2.ch> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) X-Snooper: A life spent reading others private email is a sad and wasted one X-NSA: nitrate toxic DNDO hostage al aqsar fluffy jihad DHS cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt mustard gas x-ray british airways hydrogen washington peroxide cool FEMA emergency four lions encryption ricin table pandemic scanner power sleet catalyst injection acetone X-KEYSCORE: The greatest long-term threats to freedom and democracy are based in Langley and Fort Meade and Cheltenham MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] OSPF WG Minutes from IETF 95 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 14:58:16 -0000 On Wed, 13 Apr 2016, Acee Lindem (acee) wrote: > One of the authors or myself will write an errata to clarify this > definition. Great. :) > But the OSPF stub router functionality is achieved using 0xffff, so > your proposal is NOT backward compatible. Why not? Any sufficiently large metric (relative to the cost of the longest path in the network) will induce the desired "transit is still fine" behaviour in the stub-router RFC. It turns out the 0xffff metric was never intended to be special by that RFC - or we wouldn't be having this discussion. It _not_ intended to change SPF behaviour. So, how could using a lower value cause compatibility issues? ?? > The reality is that the standards WILL NOT change to match your > interpretation. Well, not asking you to. ;) I'm just saying Quagga has been shipping for years with "0xffff link metric means its SPF will not follow such a link out of a router when calculating the SPF tree" behaviour. The reason was provide the "absolutely no-transit" type behaviour (as "discouraged, but transit is still OK" behaviour is achievable with many other metrics). I'm not arguing for anything, I'm just saying the existence of such implementations is a reality. For Quagga, it seems the best way forward is: - As/when H-bit clearly is going to be a standard, Quagga can use H-bit + 0xffff link metrics to signal "absolutely no transit", when the administrator desires that behaviour. * This will have the desired effect with all routers that recognise the H-bit, and all Quagga - If the administrator wants "discourage, but transit still OK" then Quagga will just set some large, non-0xffff metric in the links (e.g. 0xfffe). * This will have the desired effect with all routers, Quagga old and new, RFC2328, pre-1583, etc., without any issues (AFAIK). That seems the best thing we can do. It leaves other cases where things might not quite be consistent. For those there'll be an admin option to control the SPF-0xffff-transit behaviour between the longish-standing Quagga "no-transit" behaviour and 1583/2328. That will probably have to default to the "no-transit" behaviour for a while longer, but in time hopefully flip it over to 2328. regards, -- Paul Jakma paul@jakma.org @pjakma Key ID: 64A2FF6A Fortune: Given sufficient time, what you put off doing today will get done by itself. From nobody Thu Apr 14 08:20:49 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB13A12E1F5 for ; Thu, 14 Apr 2016 08:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jakma-org.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 R4VQ0jlzhyLn for ; Thu, 14 Apr 2016 08:20:44 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c: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 4B1F212D9D3 for ; Thu, 14 Apr 2016 08:20:43 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id v188so225195382wme.1 for ; Thu, 14 Apr 2016 08:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jakma-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=xHcv2/iXL18kuTQ3ps70VarmQEyLMHTk9JKVHx6NWUw=; b=Oc93VRcfXJtOnh9zbse2SFA9/mrqHMnBIuG2UDwGWjS5HQ1aPcc9KEACDuoj91V1Fb XIRjwpAzUQiybBEfJX8KlNIvJZmn02gIhOuPMG7gSYkIf5htCr09Ij9WKvpzj5jERTNe wzM3frhhDjUU7jRGAdo0Q2OvfV9F4zdyIcOzKl51UaUAuWAI7rQ4GXBdwSF15TUzf2Vh 5ff3uUdzGFEyKAgcHAaiAOOLZ7SysugylYpiv+dtLPhK0FklxeTWGvE399T513Cipvs1 JlC0xmrB3anaNGfI8muxx4UNqMNk/QpFKMh19tKQeWdhE3JYwPlNXMh2/gySnRd8Cleb DTDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=xHcv2/iXL18kuTQ3ps70VarmQEyLMHTk9JKVHx6NWUw=; b=lU73/qLoHGPA1qtwyODNZkKUTxqKwYEpwtQYifi8XU+Ff5sLR0y3BM3X0gbScE2+HM HYkKbTiEtkGxnrmfXrl48MIU1r9dblJ0+3imZZ5XMYM3MV5HEN6RwgJPpWOKIj/rFjGf AhqxdejReqn8NTPyH6QKRs3gyOw2wK3Wm0zSfJDe2vVySrPgx3q5RwoZrK/JsKEQhKRh el95aSJyCxbAHdIPsKGlxZSNh7zfgeHQbCci4ghitsGFbmtWdoUr+s0F61ysvlrS/mjO Q8JvnCUXJ1tVfiUtJVoOvx9mr+7EbdWH0Ua4m7KtuegIXESEerWRC5IJeM0irh0y06oX Jw8A== X-Gm-Message-State: AOPr4FUbRPIumuF114PAGR2cmdae/4WHkcMIFolGRZr5ue7QJmuFAa5vrpV2uy7CW1i+Pw== X-Received: by 10.195.13.67 with SMTP id ew3mr16557238wjd.6.1460647241768; Thu, 14 Apr 2016 08:20:41 -0700 (PDT) Received: from stoner.jakma.org (stoner.jakma.org. [81.168.24.42]) by smtp.gmail.com with ESMTPSA id j18sm33979330wmd.2.2016.04.14.08.20.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Apr 2016 08:20:40 -0700 (PDT) Date: Thu, 14 Apr 2016 16:20:39 +0100 (BST) From: Paul Jakma To: "Alvaro Retana (aretana)" In-Reply-To: Message-ID: References: <04479c8fba16697eb3a51ea89d0cd708@zeta2.ch> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) X-Snooper: A life spent reading others private email is a sad and wasted one X-NSA: nitrate toxic DNDO hostage al aqsar fluffy jihad DHS cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt mustard gas x-ray british airways hydrogen washington peroxide cool FEMA emergency four lions encryption ricin table pandemic scanner power sleet catalyst injection acetone X-KEYSCORE: The greatest long-term threats to freedom and democracy are based in Langley and Fort Meade and Cheltenham MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] OSPF WG Minutes from IETF 95 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 15:20:47 -0000 Hi Alvaro, On Thu, 14 Apr 2016, Alvaro Retana (aretana) wrote: > Paul: > > Hi! > > You and I have had a similar conversation off-list... Indeed, thanks for your help there. ;) >> However, it is a fact that the behaviour desired by RFC6987 can be >> universally achieved with metrics of 0xfffe or lower. That was true >> before any misinterpretation, and is still true now. > Both MaxLinkMetric and 0xfffe are "very large numbers" (VLN), which > means that if we use 0xfffe, or any other VLN (including > MaxLinkMetric), then we should get "the same" behavior. > I wrote ""the same"" because the result can vary depending on which > VLN a router in the network uses with respect to another router that > may also want to be a stub. For example, given 2 paths to a > destination, if a router uses 0xfffe (or any other VLN which is not > MaxLinkMetric) it should become a stub. However, if a router on the > second path decides to use MaxLinkMetric, then the first one (the one > using 0xfffe) will become transit. We can obviously expand that > example to n number of links and n values of VLN and end up with a > wide variety of results -- which will not be deterministic unless we > know which VLN each router used in each case... Indeed. However, this can happen with consistent use of 0xffff too. If both are 0xffff, then a 3rd party router can still choose /either/ to route via, or both. Etc. So, whether a router will or will not be used for transit will depend on the network topology, when a "transit is still OK" approach is still used. Also, this does not take the original link-metric into account either, right? It could be that the links on the one path originally were 100 the other 1000. Clearly, if both now go stub, you'd want 3rd parties to prefer the "originally 100" one, but that information is lost. So, if this were a consideration, wouldn't it be better to do stub-router with a "Add X to existing cost of all the links" approach? Where X is larger than the largest path cost, but less than the difference to 0xffff? > When we originally wrote rfc3137 (the precursor of rfc6987), we chose > MaxLinkMetric because it guarantees the stub behavior (no other VLN is > higher), unless an alternate path does not exist. Clearly we took > advantage of how the metric is treated in the current OSPF > specification (starting with rfc1583). If we has used 0xfffe (or any > other VLN) then the behavior wouldn't have been guaranteed (using the > current OSPF spec). Ah, ok. Though, you didn't want to guarantee a router wouldn't be used... and as above judging the cost of alternate paths gets tricky with... Anyway. ;) >> 0xffff today will not universally be recognised as meaning "you can >> still calculate transit paths out of a router using that link". >> 0xfffe or below will. >> >> That is the reality today. > > True, but only for pre-rfc1583 routers. Well, Quagga has treated 0xffff links as infinite / strictly-no-transit out of a vertex for 9 years now. regards, -- Paul Jakma paul@jakma.org @pjakma Key ID: 64A2FF6A Fortune: "I don't think they could put him in a mental hospital. On the other hand, if he were already in, I don't think they'd let him out." From nobody Thu Apr 14 08:24:14 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6FDE12E10A for ; Thu, 14 Apr 2016 08:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNQHTa3Kvgnb for ; Thu, 14 Apr 2016 08:24:11 -0700 (PDT) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::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 E9BF112E47C for ; Thu, 14 Apr 2016 08:24:03 -0700 (PDT) Received: by mail-oi0-x244.google.com with SMTP id q133so10281576oib.1 for ; Thu, 14 Apr 2016 08:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=yHZHNLUko5p6QBvymq4+q/IgjP8TCfHC8/RP3PRiUl0=; b=T4E/9klcA3gWk+FaLLqWy8f5bBrnpXvzVb8O0ybN/Sztcf0C3WiotQYDstzF9WVBtg rKnrEaJ0nTpOorOav4FMHODiMYHLqNrKDXKbzGpdlmubFqsBuXdzFEL1awkmJQAOIls3 sdhJj4n+hRlDPOWpsr9Zeh6KIXkxLo5fAVxEe9ZdFxVUlI0q5BK7hCukBBlvSsFPJrwV pWcwcDZNjNU08lGMZX6/Ffzm8JrURx/K58KWcMttf11+76LkYbxMQ2Eddb2WbJv5qipu J2UmEb5VyzpuGEFPfNB7F7FOFcR+1vHrEy7X10/3AO5yTujnpp3JKUMkPerT/T0MOShT Wi3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=yHZHNLUko5p6QBvymq4+q/IgjP8TCfHC8/RP3PRiUl0=; b=iYK3e86tKzy17c4qz+qRvdmJOATqN7+3C7mow3upGqh8/8EnI5qQcnXTsQO46MLCPE MjfubdTsEMPpGsQ/LblPA7sAG3rj8L+WxHyGwc9oYtcCc1UHsYwACLbWhWIsXJhH5YqA TgqTiBDf4c/usDQvGe6sErc+lzBLg6N8eoNVfz8MtQ5j/34OP4XP9qvVurgZWRWAGVTW gkO0/NzV/QkBkpRLD07ytAnDOdb2tzxeKh3K/GPFt/RcMpGzVn3MLviKMMpYwSM4sa95 Jj8wS21DEb5000eZYynHvP9CvwRNG2swQgwL3YqZcxunSXL8PUApKE2VB6Ugv53/NGD/ KK/Q== X-Gm-Message-State: AOPr4FX3MZFxNoA2wHLnmgMnqXKO8NdIxAHUxZ3OI+l7a36yX0x3slchj9K0mCrlXpWR5UTFOnw+QRo8D+mkqw== MIME-Version: 1.0 X-Received: by 10.157.5.106 with SMTP id 97mr7452573otw.127.1460647443258; Thu, 14 Apr 2016 08:24:03 -0700 (PDT) Received: by 10.157.24.14 with HTTP; Thu, 14 Apr 2016 08:24:03 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53A022@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53A022@NKGEML515-MBX.china.huawei.com> Date: Thu, 14 Apr 2016 08:24:03 -0700 Message-ID: From: Padma Pillay-Esnault To: Xuxiaohu Content-Type: multipart/alternative; boundary=94eb2c0479a4ff64c50530737b25 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 15:24:13 -0000 --94eb2c0479a4ff64c50530737b25 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I cannot support this draft. As discussed in the wg last week, the best way to do this is to have the generic definition (genapps) in OSPF as in ISIS. I am in the process of reviving the ospf service distribution draft which has that purpose embedded. Thanks Padma On Thu, Apr 14, 2016 at 1:34 AM, Xuxiaohu wrote: > Support the WG adoption of this doc (as a co-author). > > Best regards, > Xiaohu > > > -----Original Message----- > > From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem > (acee) > > Sent: Thursday, March 17, 2016 10:09 AM > > To: OSPF WG List > > Subject: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for > Agile > > Service Deployment" > > > > We=E2=80=99ve discussed this draft a number of times. In my opinion, it= seems > like a > > useful mechanism if one envisions a generalized API between OSPF and > user and > > third-party applications to convey application-specific information > learned from > > other OSPF routers. In many respects, this has already been envisioned > for OSPF > > Node Tags. Please indicate your opinion on this draft before March 31st= , > 2016. > > > > Thanks, > > Acee > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > --94eb2c0479a4ff64c50530737b25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I cannot support this draft.

As discuss= ed in the wg last week, the best way to do this is to have =C2=A0the generi= c definition (genapps) in OSPF =C2=A0as in ISIS. I am in the process of rev= iving the ospf service distribution draft which has that purpose embedded.<= /div>

Thanks
Padma

<= div class=3D"gmail_extra">
On Thu, Apr 14, 20= 16 at 1:34 AM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
Support the WG adoption of this doc (as a co-a= uthor).

Best regards,
Xiaohu

> -----Original Message-----
> From: OSPF [mailto:ospf-bounc= es@ietf.org] On Behalf Of Acee Lindem (acee)
> Sent: Thursday, March 17, 2016 10:09 = AM
> To: OSPF WG List
> Subject: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs= for Agile
> Service Deployment"
>
> We=E2=80=99ve discussed= this draft a number of times. In my opinion, it seems like a
> useful mechanism if one envisions a generalized API between OSPF and u= ser and
> third-party applications to convey application-specific information le= arned from
> other OSPF routers. In many respects, this has already been envisioned= for OSPF
> Node Tags. Please indicate your opinion on this draft before March 31s= t, 2016.
>
> Thanks,
> Acee
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

--94eb2c0479a4ff64c50530737b25-- From nobody Thu Apr 14 15:36:03 2016 Return-Path: X-Original-To: ospf@ietf.org Delivered-To: ospf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5048212DF26; Thu, 14 Apr 2016 15:36:01 -0700 (PDT) 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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160414223601.6968.81746.idtracker@ietfa.amsl.com> Date: Thu, 14 Apr 2016 15:36:01 -0700 Archived-At: Cc: ospf@ietf.org Subject: [OSPF] I-D Action: draft-ietf-ospf-flowspec-extensions-01.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 22:36:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP of the IETF. Title : OSPF Extensions for Flow Specification Authors : Qiandeng Liang Jianjie You Nan Wu Peng Fan Keyur Patel Acee Lindem Filename : draft-ietf-ospf-flowspec-extensions-01.txt Pages : 19 Date : 2016-04-14 Abstract: Dissemination of the Traffic flow information was first introduced in the BGP protocol [RFC5575]. FlowSpec routes are used to distribute traffic filtering rules that are used to filter Denial-of-Service (DoS) attacks. For the networks that only deploy an IGP (Interior Gateway Protocol) (e.g., OSPF), it is required that the IGP is extended to distribute Flow Specification or FlowSpec routes. This document discusses the use cases for distributing flow specification (FlowSpec) routes using OSPF. Furthermore, this document defines a OSPF FlowSpec Opaque Link State Advertisement (LSA) encoding format that can be used to distribute FlowSpec routes, its validation procedures for imposing the filtering information on the routers, and a capability to indicate the support of FlowSpec functionality. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-flowspec-extensions/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ospf-flowspec-extensions-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-flowspec-extensions-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 Apr 14 19:05:25 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DAE12DEEE for ; Thu, 14 Apr 2016 19:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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.996, 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 bvr55q0tLA6j for ; Thu, 14 Apr 2016 19:05:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6407C12DCB9 for ; Thu, 14 Apr 2016 19:05:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHL28102; Fri, 15 Apr 2016 02:05:19 +0000 (GMT) Received: from SZXEMA415-HUB.china.huawei.com (10.82.72.33) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 15 Apr 2016 03:05:18 +0100 Received: from SZXEMA508-MBX.china.huawei.com ([169.254.7.22]) by SZXEMA415-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0235.001; Fri, 15 Apr 2016 10:05:12 +0800 From: "Wunan (Eric)" To: "Acee Lindem (acee)" Thread-Topic: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment" Thread-Index: AQHRgH9Ub5/WrKyOeUaJiIu3cM0Uxp+JkQrQ Date: Fri, 15 Apr 2016 02:05:12 +0000 Message-ID: <0F26584357FD124DB93F1535E4B0A650841024E2@szxema508-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.105] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.57104C60.0037, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.22, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3cd4dee8c3599a9d0141cab4c8935ea7 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] WG Adoption Poll for "Using Operator-defined TLVs for Agile Service Deployment" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 02:05:24 -0000 SGkgQWNlZSwNCg0KSSB0aGluayB0aGUgbW90aXZhdGlvbiBiZWxvdyBtYWtlcyBzZW5zZS4gQWN0 dWFsbHkgdGhpcyBpcyB0aGUgd2F5IHBlb3BsZSBoYWQgYWxyZWFkeSBiZWVuIGRvaW5nLCBub3Qg b25seSBvcGVyYXRvcnMuDQoNCiJPbmUgbWFqb3IgYmVuZWZpdCBvZiB1c2luZyBhZG1pbmlzdHJh dGl2ZSB0YWdzIHJhdGhlcg0KICAgdGhhbiBJQU5BIGRlZmluZWQgVExWcyBvciBzdWItVExWcyB0 byBpbmRpY2F0ZSBkaWZmZXJlbnQgc2VydmljZXMgaXMNCiAgIHRvIGZhY2lsaXRhdGUgdGhlIHJh cGlkIGRlcGxveW1lbnQgb2YgbmV3IHNlcnZpY2VzIHdpdGhvdXQgYW55IG5lZWQNCiAgIGZvciB0 aGUgc3RhbmRhcmRpemF0aW9uIG9mIHRob3NlIFRMVnMgb3Igc3ViLVRMVnMuICBIb3dldmVyLCB0 aGVyZQ0KICAgYXJlIHNvbWUgc3BlY2lhbCB1c2UgY2FzZXMgd2hlcmUgdGhlIHNlcnZpY2UgdG8g YmUgYWR2ZXJ0aXNlZCBoYXMgb25lDQogICBvciBtb3JlIGF0dHJpYnV0ZXMgd2hpY2ggbmVlZCB0 byBiZSBhZHZlcnRpc2VkIGFzIHdlbGwuICBJbiBzdWNoDQogICBjYXNlLCB0aGUgYWRtaW5pc3Ry YXRpdmUgdGFnIGlzIG5vdCBtdWNoIGFwcGxpY2FibGUgYW55bW9yZSINCg0KUGVyc29uYWxseSBJ IHdpc2ggb25lIG1vcmUgZ2VuZXJhbGl6ZWQgbWVjaGFuaXNtIGNhbiBleGlzdCBpbnN0ZWFkIG9m IG9uZSBOb2RlIHRhZyBhbmQgb25lIHByb3ByaWV0YXJ5IFRMVi4NCkFueXdheSwgSSdkIGxpa2Ug dG8gc2VlIHRoaXMgSS1EIGNhbiBnbyBmdXJ0aGVyIGFuZCAibG90IG9mIHRoaW5ncyB3ZSBjYW4g ZnVydGhlciBpbXByb3ZlIiBhdCB0aGUgc2FtZSB0aW1lLCBhcyBVbWEgbWVudGlvbmVkLg0KDQpS ZWdhcmRzDQpFcmljDQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IEFj ZWUgTGluZGVtIChhY2VlKSBbbWFpbHRvOmFjZWVAY2lzY28uY29tXQ0KPiDlj5HpgIHml7bpl7Q6 IDIwMTblubQz5pyIMTfml6UgMTA6MDkNCj4g5pS25Lu25Lq6OiBPU1BGIFdHIExpc3QNCj4g5Li7 6aKYOiBbT1NQRl0gV0cgQWRvcHRpb24gUG9sbCBmb3IgIlVzaW5nIE9wZXJhdG9yLWRlZmluZWQg VExWcyBmb3IgQWdpbGUgU2VydmljZQ0KPiBEZXBsb3ltZW50Ig0KPiANCj4gV2XigJl2ZSBkaXNj dXNzZWQgdGhpcyBkcmFmdCBhIG51bWJlciBvZiB0aW1lcy4gSW4gbXkgb3BpbmlvbiwgaXQgc2Vl bXMgbGlrZSBhIHVzZWZ1bA0KPiBtZWNoYW5pc20gaWYgb25lIGVudmlzaW9ucyBhIGdlbmVyYWxp emVkIEFQSSBiZXR3ZWVuIE9TUEYgYW5kIHVzZXIgYW5kIHRoaXJkLXBhcnR5DQo+IGFwcGxpY2F0 aW9ucyB0byBjb252ZXkgYXBwbGljYXRpb24tc3BlY2lmaWMgaW5mb3JtYXRpb24gbGVhcm5lZCBm cm9tIG90aGVyIE9TUEYNCj4gcm91dGVycy4gSW4gbWFueSByZXNwZWN0cywgdGhpcyBoYXMgYWxy ZWFkeSBiZWVuIGVudmlzaW9uZWQgZm9yIE9TUEYgTm9kZSBUYWdzLg0KPiBQbGVhc2UgaW5kaWNh dGUgeW91ciBvcGluaW9uIG9uIHRoaXMgZHJhZnQgYmVmb3JlIE1hcmNoIDMxc3QsIDIwMTYuDQo+ IA0KPiBUaGFua3MsDQo+IEFjZWUNCg0K From nobody Fri Apr 15 02:51:28 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C8412E67B for ; Fri, 15 Apr 2016 02:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 B_F9-jeAL9vD for ; Fri, 15 Apr 2016 02:51:26 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13CE12E5C0 for ; Fri, 15 Apr 2016 02:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4024; q=dns/txt; s=iport; t=1460713885; x=1461923485; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dn+tcphC388lkr8qhh+w7ZLN8OvoEsTPbAONOmEzRDY=; b=c3m/NqRtIciSsuKjZTvSbatx6GCuxjRqOoABBjfuSSO4eP4P7WWPFjXZ KqZ98eBT0unFOo/Ohygth/zyPJuhwGYp4zswUvKlzmg5yhC6f0W8FRjVl qKrRwXcgH8k104Yvkf+vDT1PCtp2vJU86cbPlsdP7ZWgBFMpZSgGF5o/1 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgCouBBX/4cNJK1egziBUAa4G4IPA?= =?us-ascii?q?Q2BcYYOAhyBITgUAQEBAQEBAWUnhEEBAQEDASMRRRACAQgYAgImAgICMBUQAgQ?= =?us-ascii?q?OBYghCK9zkhEBAQEBAQEBAQIBAQEBAQEBAQEXfIhugQKHP4JWBZMdhG8Bjg2PE?= =?us-ascii?q?Y8oAR4BAUKBf4FpbIhIfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,486,1454976000"; d="scan'208";a="259974822" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Apr 2016 09:51:24 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3F9pMW2024946 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Apr 2016 09:51:24 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 15 Apr 2016 05:51:23 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Fri, 15 Apr 2016 05:51:23 -0400 From: "Acee Lindem (acee)" To: Paul Jakma Thread-Topic: [OSPF] OSPF WG Minutes from IETF 95 Thread-Index: AQHRk+ug+9xkeFSUNUaQhV0sMu+UBZ+E5gwAgANQ+gD//9JIAIAAlAqA///jKQCAAVbTgIAA+ZOA Date: Fri, 15 Apr 2016 09:51:23 +0000 Message-ID: References: <04479c8fba16697eb3a51ea89d0cd708@zeta2.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.202] Content-Type: text/plain; charset="utf-8" Content-ID: <738F6A93BA4BE5499C537A06C0925F82@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] OSPF WG Minutes from IETF 95 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 09:51:27 -0000 DQoNCk9uIDQvMTQvMTYsIDEwOjU4IEFNLCAiUGF1bCBKYWttYSIgPHBhdWxAamFrbWEub3JnPiB3 cm90ZToNCg0KPk9uIFdlZCwgMTMgQXByIDIwMTYsIEFjZWUgTGluZGVtIChhY2VlKSB3cm90ZToN Cj4NCj4+IE9uZSBvZiB0aGUgYXV0aG9ycyBvciBteXNlbGYgd2lsbCB3cml0ZSBhbiBlcnJhdGEg dG8gY2xhcmlmeSB0aGlzDQo+PiBkZWZpbml0aW9uLg0KPg0KPkdyZWF0LiA6KQ0KPg0KPj4gQnV0 IHRoZSBPU1BGIHN0dWIgcm91dGVyIGZ1bmN0aW9uYWxpdHkgaXMgYWNoaWV2ZWQgdXNpbmcgMHhm ZmZmLCBzbw0KPj4geW91ciBwcm9wb3NhbCBpcyBOT1QgYmFja3dhcmQgY29tcGF0aWJsZS4NCj4N Cj5XaHkgbm90Pw0KPg0KPkFueSBzdWZmaWNpZW50bHkgbGFyZ2UgbWV0cmljIChyZWxhdGl2ZSB0 byB0aGUgY29zdCBvZiB0aGUgbG9uZ2VzdCBwYXRoDQo+aW4gdGhlIG5ldHdvcmspIHdpbGwgaW5k dWNlIHRoZSBkZXNpcmVkICJ0cmFuc2l0IGlzIHN0aWxsIGZpbmUiDQo+YmVoYXZpb3VyIGluIHRo ZSBzdHViLXJvdXRlciBSRkMuDQo+DQo+SXQgdHVybnMgb3V0IHRoZSAweGZmZmYgbWV0cmljIHdh cyBuZXZlciBpbnRlbmRlZCB0byBiZSBzcGVjaWFsIGJ5IHRoYXQNCj5SRkMgLSBvciB3ZSB3b3Vs ZG4ndCBiZSBoYXZpbmcgdGhpcyBkaXNjdXNzaW9uLiBJdCBfbm90XyBpbnRlbmRlZCB0bw0KPmNo YW5nZSBTUEYgYmVoYXZpb3VyLiBTbywgaG93IGNvdWxkIHVzaW5nIGEgbG93ZXIgdmFsdWUgY2F1 c2UNCj5jb21wYXRpYmlsaXR5IGlzc3Vlcz8gPz8NCg0KVXNpbmcgMHhmZmZlLCBpbiBpdHNlbGYs IHdpbGwgbm90IGNhdXNlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgcHJvYmxlbXMuDQpIb3dldmVy LCB5b3XigJlsbCBzdGlsbCBoYXZlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXNzdWVzIGFzIGxv bmcgYXMgdGhlDQppbnRlcnByZXRhdGlvbiBvZiAweGZmZmYgdmFyaWVzIGJldHdlZW4gcm91dGVy IGluIHRoZSBPU1BGIHJvdXRpbmcgZG9tYWluLg0KSW4gcmVhZGluZyB0aGUgcmVzdCBvZiB0aGlz IEUtbWFpbCwgSSBiZWxpZXZlIHRoaXMgaXMgd2VsbCB1bmRlcnN0b29kLg0KDQo+DQo+PiBUaGUg cmVhbGl0eSBpcyB0aGF0IHRoZSBzdGFuZGFyZHMgV0lMTCBOT1QgY2hhbmdlIHRvIG1hdGNoIHlv dXINCj4+IGludGVycHJldGF0aW9uLg0KPg0KPldlbGwsIG5vdCBhc2tpbmcgeW91IHRvLiA7KQ0K Pg0KPkknbSBqdXN0IHNheWluZyBRdWFnZ2EgaGFzIGJlZW4gc2hpcHBpbmcgZm9yIHllYXJzIHdp dGggIjB4ZmZmZiBsaW5rDQo+bWV0cmljIG1lYW5zIGl0cyBTUEYgd2lsbCBub3QgZm9sbG93IHN1 Y2ggYSBsaW5rIG91dCBvZiBhIHJvdXRlciB3aGVuDQo+Y2FsY3VsYXRpbmcgdGhlIFNQRiB0cmVl IiBiZWhhdmlvdXIuIFRoZSByZWFzb24gd2FzIHByb3ZpZGUgdGhlDQo+ImFic29sdXRlbHkgbm8t dHJhbnNpdCIgdHlwZSBiZWhhdmlvdXIgKGFzICJkaXNjb3VyYWdlZCwgYnV0IHRyYW5zaXQgaXMN Cj5zdGlsbCBPSyIgYmVoYXZpb3VyIGlzIGFjaGlldmFibGUgd2l0aCBtYW55IG90aGVyIG1ldHJp Y3MpLg0KPg0KPkknbSBub3QgYXJndWluZyBmb3IgYW55dGhpbmcsIEknbSBqdXN0IHNheWluZyB0 aGUgZXhpc3RlbmNlIG9mIHN1Y2gNCj5pbXBsZW1lbnRhdGlvbnMgaXMgYSByZWFsaXR5Lg0KPg0K PkZvciBRdWFnZ2EsIGl0IHNlZW1zIHRoZSBiZXN0IHdheSBmb3J3YXJkIGlzOg0KPg0KPi0gQXMv d2hlbiBILWJpdCBjbGVhcmx5IGlzIGdvaW5nIHRvIGJlIGEgc3RhbmRhcmQsIFF1YWdnYSBjYW4g dXNlIEgtYml0DQo+ICAgKyAweGZmZmYgbGluayBtZXRyaWNzIHRvIHNpZ25hbCAiYWJzb2x1dGVs eSBubyB0cmFuc2l0Iiwgd2hlbiB0aGUNCj4gICBhZG1pbmlzdHJhdG9yIGRlc2lyZXMgdGhhdCBi ZWhhdmlvdXIuDQo+DQo+ICAgKiBUaGlzIHdpbGwgaGF2ZSB0aGUgZGVzaXJlZCBlZmZlY3Qgd2l0 aCBhbGwgcm91dGVycyB0aGF0IHJlY29nbmlzZQ0KPiAgICAgdGhlIEgtYml0LCBhbmQgYWxsIFF1 YWdnYQ0KPg0KPi0gSWYgdGhlIGFkbWluaXN0cmF0b3Igd2FudHMgImRpc2NvdXJhZ2UsIGJ1dCB0 cmFuc2l0IHN0aWxsIE9LIiB0aGVuDQo+ICAgUXVhZ2dhIHdpbGwganVzdCBzZXQgc29tZSBsYXJn ZSwgbm9uLTB4ZmZmZiBtZXRyaWMgaW4gdGhlIGxpbmtzIChlLmcuDQo+ICAgMHhmZmZlKS4NCj4N Cj4gICAqIFRoaXMgd2lsbCBoYXZlIHRoZSBkZXNpcmVkIGVmZmVjdCB3aXRoIGFsbCByb3V0ZXJz LCBRdWFnZ2Egb2xkIGFuZA0KPiAgICAgbmV3LCBSRkMyMzI4LCBwcmUtMTU4MywgZXRjLiwgd2l0 aG91dCBhbnkgaXNzdWVzIChBRkFJSykuDQo+DQo+VGhhdCBzZWVtcyB0aGUgYmVzdCB0aGluZyB3 ZSBjYW4gZG8uDQo+DQo+SXQgbGVhdmVzIG90aGVyIGNhc2VzIHdoZXJlIHRoaW5ncyBtaWdodCBu b3QgcXVpdGUgYmUgY29uc2lzdGVudC4gRm9yDQo+dGhvc2UgdGhlcmUnbGwgYmUgYW4gYWRtaW4g b3B0aW9uIHRvIGNvbnRyb2wgdGhlIFNQRi0weGZmZmYtdHJhbnNpdA0KPmJlaGF2aW91ciBiZXR3 ZWVuIHRoZSBsb25naXNoLXN0YW5kaW5nIFF1YWdnYSAibm8tdHJhbnNpdCIgYmVoYXZpb3VyIGFu ZA0KPjE1ODMvMjMyOC4gVGhhdCB3aWxsIHByb2JhYmx5IGhhdmUgdG8gZGVmYXVsdCB0byB0aGUg Im5vLXRyYW5zaXQiDQo+YmVoYXZpb3VyIGZvciBhIHdoaWxlIGxvbmdlciwgYnV0IGluIHRpbWUg aG9wZWZ1bGx5IGZsaXAgaXQgb3ZlciB0bw0KPjIzMjguDQoNClRoaXMgc291bmRzIGxpa2UgYSBn b29kIHBsYW4uDQoNClRoYW5rcywNCkFjZWUgDQoNCg0KDQoNCj4NCj5yZWdhcmRzLA0KPi0tIA0K PlBhdWwgSmFrbWEJcGF1bEBqYWttYS5vcmcJQHBqYWttYQlLZXkgSUQ6IDY0QTJGRjZBDQo+Rm9y dHVuZToNCj5HaXZlbiBzdWZmaWNpZW50IHRpbWUsIHdoYXQgeW91IHB1dCBvZmYgZG9pbmcgdG9k YXkgd2lsbCBnZXQgZG9uZSBieQ0KPml0c2VsZi4NCg0K From nobody Fri Apr 15 17:43:16 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9974D12E1A3 for ; Fri, 15 Apr 2016 17:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mc6zZrFHCKMJ for ; Fri, 15 Apr 2016 17:43:14 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 48DAF12E1FC for ; Fri, 15 Apr 2016 17:43:14 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id u206so52821663wme.1 for ; Fri, 15 Apr 2016 17:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=ttnfOvrKSAe/kSdzcjS4TDLvU813zEHHkkwl09uALrg=; b=bYhuR7Oa6NcRrG6EdtfUqBP3OM5rpxGQYryC+JPTbNzNZi3uF9WH4jBK9StDBI2ilC vGn1AwSLRML9F3P+Iz+0oHilBbRfVfBBqkwbMFoE/l+YFN1ICOShON+M8AvZjwrT300w nWvN8NVadWGt8nIj5RKWnVEbuNERVlZ7k+oL49jcw2tnE+w0TmyamE6D+Odkg5BYbfb5 Q+FWkOUsFYKUW4NQd2CXPf4ONJ8w6CACCuPeLIUJ+PTEWSCtHw+tkdmXjdnZN8PbxsRI Ghu6/KrznDGJlw1JsCGPTVKdqcusvAlbKDuwBdG+0fZcK3RXsC/qw8F/bEM8t9mZTxzy S/qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=ttnfOvrKSAe/kSdzcjS4TDLvU813zEHHkkwl09uALrg=; b=irhgbNfPrXIVCC/6vOJWBdUNhWI+Nlm/OzUxQU2O0nV7CHhU8A0QZcOEzPVLDmIBau jHjbtTqZf+xeEG/VzQwtLXFzVRs9v0sDa5ZWUQUmagd6sCS/zwB8LgUTjunSIVyoRy1q XWxB2yL/wGuS+UkHO3bwYLNhteZpURSIBK0rvDd+1A6FhZbzB/XOtR4A3oTiXWcLCljJ 0CaAQWClYyThZ1AqLS9iRkjtYvaavqgRugv8DtnDdvs3QXrQ87/vFg6KbLrIUbAjfRZd qfHXqTTkSbXraiJK08fHEyeeFTc6qPa98dCb7ImBOlP/frG+blsAmRTd1GmzXlMllf7J RoBA== X-Gm-Message-State: AOPr4FW+CiLAPqGD/NbHh+zY1p2FYTBh0ID6e/GuetRxGdXwXjlBPbug2wU4/l3VD884yhESACAOGLlA64oPcQ== MIME-Version: 1.0 X-Received: by 10.194.48.7 with SMTP id h7mr26577873wjn.81.1460767392869; Fri, 15 Apr 2016 17:43:12 -0700 (PDT) Received: by 10.28.51.129 with HTTP; Fri, 15 Apr 2016 17:43:12 -0700 (PDT) Date: Sat, 16 Apr 2016 06:13:12 +0530 Message-ID: From: Tom Sanders To: OSPF List Content-Type: multipart/alternative; boundary=047d7ba975e48d303005308f6902 Archived-At: Subject: [OSPF] Backbone Area X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2016 00:43:15 -0000 --047d7ba975e48d303005308f6902 Content-Type: text/plain; charset=UTF-8 Hi, OSPF requires all areas to be connected via the backbone. I wanted to understand why we have this requirement since IS-IS doesnt mandate such a thing. I understand that all the border routers summarize and inject the summary routes inside the backbone. The backbone then does "distance vector routing" and injects those summaries to other areas. How does having a backbone eliminate loops is something that i dont understand. Can somebody explain that to me? -- Toms. --047d7ba975e48d303005308f6902 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

OSPF requires all areas to be conne= cted via the backbone. I wanted to understand why we have this requirement = since IS-IS doesnt mandate such a thing.

I underst= and that all the border routers summarize and inject the summary routes ins= ide the backbone. The backbone then does "distance vector routing"= ; and injects those summaries to other areas.

How = does having a backbone eliminate loops is something that i dont understand.= Can somebody explain that to me?

--
Toms.
--047d7ba975e48d303005308f6902-- From nobody Sat Apr 16 09:30:40 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C0512DB4D for ; Sat, 16 Apr 2016 09:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 mhJhJ3WBBKz9 for ; Sat, 16 Apr 2016 09:30:37 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13BEF12D738 for ; Sat, 16 Apr 2016 09:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7671; q=dns/txt; s=iport; t=1460824237; x=1462033837; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=hfPt4HzUdbK4K494H4uWs2ObKGZNIikzv0EerZiWp6Q=; b=IvRb4K+cfnfGY2jSKoOWjRmGdWl7dSWUnD/GCNXS9FU+0EmpID9C4xVl /zkETIoEj5fXKSgqEqgKWGDwj8CuHRArJJAjYkzn2HIMgkCwsIsDAyiO0 +86mtLfHYM4rbQGgNW8m4cur01lSp7reLiEQ8gFlLqok786iyfjdTQpqB Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQDoZxJX/5pdJa1cgmtNgVAGrj6JS?= =?us-ascii?q?oIPAQ2BcYYOAhyBCTgUAQEBAQEBAWUnhEEBAQEEI2YCAQgRAwECKAMCAgIfERQ?= =?us-ascii?q?JCAIEARKIFAMSqSWMOQ2FEgEBAQEBAQEBAgEBAQEBAQEBGIpsgkGCHoJgglYFk?= =?us-ascii?q?x6EPzEBjBiBdY8Rh06HXAEeAQFCg2hsiE1+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,492,1454976000"; d="scan'208,217";a="261598110" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Apr 2016 16:30:36 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3GGUZ5I005495 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 16 Apr 2016 16:30:36 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 16 Apr 2016 12:30:35 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Sat, 16 Apr 2016 12:30:35 -0400 From: "Acee Lindem (acee)" To: Tom Sanders , OSPF List Thread-Topic: [OSPF] Backbone Area Thread-Index: AQHRl3j8/GKXlnuG2UKzyRah7IIfop+My6OA Date: Sat, 16 Apr 2016 16:30:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.202] Content-Type: multipart/alternative; boundary="_000_D337DD795B325aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [OSPF] Backbone Area X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2016 16:30:38 -0000 --_000_D337DD795B325aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVG9tLA0KDQpGcm9tOiBPU1BGIDxvc3BmLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9zcGYt Ym91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBUb20gU2FuZGVycyA8dG9tcy5zYW5kZXJz QGdtYWlsLmNvbTxtYWlsdG86dG9tcy5zYW5kZXJzQGdtYWlsLmNvbT4+DQpEYXRlOiBGcmlkYXks IEFwcmlsIDE1LCAyMDE2IGF0IDg6NDMgUE0NClRvOiBPU1BGIFdHIExpc3QgPG9zcGZAaWV0Zi5v cmc8bWFpbHRvOm9zcGZAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW09TUEZdIEJhY2tib25lIEFyZWEN Cg0KSGksDQoNCk9TUEYgcmVxdWlyZXMgYWxsIGFyZWFzIHRvIGJlIGNvbm5lY3RlZCB2aWEgdGhl IGJhY2tib25lLg0KDQpPbmx5IGlmIHRoZSBhcmVhIGlzIGNvbm5lY3RlZCB0byBhbnkgb3RoZXIg YXJlYS4NCg0KSSB3YW50ZWQgdG8gdW5kZXJzdGFuZCB3aHkgd2UgaGF2ZSB0aGlzIHJlcXVpcmVt ZW50IHNpbmNlIElTLUlTIGRvZXNudCBtYW5kYXRlIHN1Y2ggYSB0aGluZy4NCg0KV2l0aCB0aGlz IHJlc3BlY3QsIEkgZG9u4oCZdCBiZWxpZXZlIElTLUlTIG9mZmVycyBhbnkgbW9yZSBmbGV4aWJp bGl0eSAtIHRoZXJlIGFyZSBvbmx5IGxldmVsLTEgcm91dGVycywgbGV2ZWwtMiByb3V0ZXJzLCBh bmQgbGV2ZWwtMS0yIHJvdXRlcnMgaW4gSVMtSVMuDQoNCg0KSSB1bmRlcnN0YW5kIHRoYXQgYWxs IHRoZSBib3JkZXIgcm91dGVycyBzdW1tYXJpemUgYW5kIGluamVjdCB0aGUgc3VtbWFyeSByb3V0 ZXMgaW5zaWRlIHRoZSBiYWNrYm9uZS4gVGhlIGJhY2tib25lIHRoZW4gZG9lcyAiZGlzdGFuY2Ug dmVjdG9yIHJvdXRpbmciIGFuZCBpbmplY3RzIHRob3NlIHN1bW1hcmllcyB0byBvdGhlciBhcmVh cy4NCg0KSG93IGRvZXMgaGF2aW5nIGEgYmFja2JvbmUgZWxpbWluYXRlIGxvb3BzIGlzIHNvbWV0 aGluZyB0aGF0IGkgZG9udCB1bmRlcnN0YW5kLiBDYW4gc29tZWJvZHkgZXhwbGFpbiB0aGF0IHRv IG1lPw0KDQpBbiBBcmVhIEJvcmRlciBSb3V0ZXIgKEFCUikgd2lsbCBvbmx5IHJlbGF5IHN1bW1h cnkgYWR2ZXJ0aXNlbWVudHMgcmVjZWl2ZWQgb24gdGhlIGJhY2tib25lIGFyZWEgdG8gb3RoZXIg YXJlYXMuIEFCUnMgd2lsbCBub3QgcmVsYXkgc3VtbWFyeSBhZHZlcnRpc2VtZW50cyBiZXR3ZWVu IG5vbi1iYWNrYm9uZSBhcmVhcy4gVGhlcmUgYXJlIHN0cmljdCByb3V0ZSBwcmVmZXJlbmNlIHJ1 bGVzIHRvIGVsaW1pbmF0ZSBsb29wcy4gRm9yIGV4YW1wbGUsIGludHJhLWFyZWEgcm91dGVzIGFy ZSBhbHdheXMgcHJlZmVycmVkIG92ZXIgaW50ZXItYXJlYSBvciBleHRlcm5hbCByb3V0ZXMgaXJy ZXNwZWN0aXZlIG9mIHRoZSBjb3N0LiBUaGUgbW9zdCBjb21wbGV4IHByZWZlcmVuY2UgcnVsZXMg YXJlYSBmb3IgZXh0ZXJuYWwgcm91dGVzIHJlYWNoYWJsZSB0aHJvdWdoIG11bHRpcGxlIGFyZWFz LiBSZWZlciB0byBzZWN0aW9uIDE2LjQgaW4gUkZDIDIzMjggZm9yIGFsbCB0aGUgZ29yeSBkZXRh aWxzLiBMZXQgbWUga25vdyBpZiB5b3UgaGF2ZSBzcGVjaWZpYyBxdWVzdGlvbnMuDQoNCkhvcGUg dGhpcyBoZWxwcywNCkFjZWUNCg0KDQoNCg0KLS0NClRvbXMuDQo= --_000_D337DD795B325aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBUb20sJm5i c3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNU SU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0 ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsg Qk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxF RlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xp ZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPk9TUEYgJmx0OzxhIGhyZWY9Im1h aWx0bzpvc3BmLWJvdW5jZXNAaWV0Zi5vcmciPm9zcGYtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7 IG9uIGJlaGFsZiBvZiBUb20gU2FuZGVycyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbXMuc2FuZGVy c0BnbWFpbC5jb20iPnRvbXMuc2FuZGVyc0BnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+RnJpZGF5LCBBcHJpbCAxNSwgMjAx NiBhdCA4OjQzIFBNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3Nw YW4+T1NQRiBXRyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86b3NwZkBpZXRmLm9yZyI+b3NwZkBp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1Ympl Y3Q6IDwvc3Bhbj5bT1NQRl0gQmFja2JvbmUgQXJlYTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RF IiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBN QVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj5IaSwNCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2Pk9TUEYgcmVxdWlyZXMgYWxsIGFyZWFzIHRvIGJlIGNvbm5lY3Rl ZCB2aWEgdGhlIGJhY2tib25lLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+T25seSBpZiB0aGUgYXJl YSBpcyBjb25uZWN0ZWQgdG8gYW55IG90aGVyIGFyZWEuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlk PSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6 ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRp dj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+SSB3YW50ZWQgdG8gdW5kZXJzdGFuZCB3 aHkgd2UgaGF2ZSB0aGlzIHJlcXVpcmVtZW50IHNpbmNlIElTLUlTIGRvZXNudCBtYW5kYXRlIHN1 Y2ggYSB0aGluZy48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N Cjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldpdGggdGhpcyByZXNwZWN0LCBJIGRv buKAmXQgYmVsaWV2ZSBJUy1JUyBvZmZlcnMgYW55IG1vcmUgZmxleGliaWxpdHkgLSB0aGVyZSBh cmUgb25seSBsZXZlbC0xIHJvdXRlcnMsIGxldmVsLTIgcm91dGVycywgYW5kIGxldmVsLTEtMiBy b3V0ZXJzIGluIElTLUlTLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlk PSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRU UklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7 IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBk aXI9Imx0ciI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIHVuZGVyc3RhbmQgdGhhdCBhbGwg dGhlIGJvcmRlciByb3V0ZXJzIHN1bW1hcml6ZSBhbmQgaW5qZWN0IHRoZSBzdW1tYXJ5IHJvdXRl cyBpbnNpZGUgdGhlIGJhY2tib25lLiBUaGUgYmFja2JvbmUgdGhlbiBkb2VzICZxdW90O2Rpc3Rh bmNlIHZlY3RvciByb3V0aW5nJnF1b3Q7IGFuZCBpbmplY3RzIHRob3NlIHN1bW1hcmllcyB0byBv dGhlciBhcmVhcy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkhvdyBkb2VzIGhhdmlu ZyBhIGJhY2tib25lIGVsaW1pbmF0ZSBsb29wcyBpcyBzb21ldGhpbmcgdGhhdCBpIGRvbnQgdW5k ZXJzdGFuZC4gQ2FuIHNvbWVib2R5IGV4cGxhaW4gdGhhdCB0byBtZT88L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PkFuIEFyZWEgQm9yZGVyIFJvdXRlciAoQUJSKSB3aWxsIG9ubHkgcmVsYXkgc3VtbWFy eSBhZHZlcnRpc2VtZW50cyByZWNlaXZlZCBvbiB0aGUgYmFja2JvbmUgYXJlYSB0byBvdGhlciBh cmVhcy4gQUJScyB3aWxsIG5vdCByZWxheSBzdW1tYXJ5IGFkdmVydGlzZW1lbnRzIGJldHdlZW4g bm9uLWJhY2tib25lIGFyZWFzLiBUaGVyZSBhcmUgc3RyaWN0IHJvdXRlIHByZWZlcmVuY2UgcnVs ZXMgdG8gZWxpbWluYXRlIGxvb3BzLiBGb3IgZXhhbXBsZSwNCiBpbnRyYS1hcmVhIHJvdXRlcyBh cmUgYWx3YXlzIHByZWZlcnJlZCBvdmVyIGludGVyLWFyZWEgb3IgZXh0ZXJuYWwgcm91dGVzIGly cmVzcGVjdGl2ZSBvZiB0aGUgY29zdC4gVGhlIG1vc3QgY29tcGxleCBwcmVmZXJlbmNlIHJ1bGVz IGFyZWEgZm9yIGV4dGVybmFsIHJvdXRlcyByZWFjaGFibGUgdGhyb3VnaCBtdWx0aXBsZSBhcmVh cy4gUmVmZXIgdG8gc2VjdGlvbiAxNi40IGluIFJGQyAyMzI4IGZvciBhbGwgdGhlIGdvcnkgZGV0 YWlscy4gTGV0DQogbWUga25vdyBpZiB5b3UgaGF2ZSBzcGVjaWZpYyBxdWVzdGlvbnMuJm5ic3A7 PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Ib3BlIHRoaXMgaGVscHMsPC9kaXY+DQo8 ZGl2PkFjZWUmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8 YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9 IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAg MCAwIDU7Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj4tLSA8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9zaWduYXR1cmUiPlRvbXMuPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D337DD795B325aceeciscocom_-- From nobody Mon Apr 18 01:35:55 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C71112DC50; Mon, 18 Apr 2016 01:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 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.996, 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 f96AyO3o1-MA; Mon, 18 Apr 2016 01:35:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5644C12DC56; Mon, 18 Apr 2016 01:35:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHT80656; Mon, 18 Apr 2016 08:35:47 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 18 Apr 2016 09:35:46 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Mon, 18 Apr 2016 16:35:40 +0800 From: Xuxiaohu To: "Acee Lindem (acee)" , "draft-ietf-ospf-mpls-elc@ietf.org" Thread-Topic: Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00 Thread-Index: AQHRlBj81Lqya0qQckSeteuSX15/fJ+HehHggABhRACAAU3x0IAALjaAgAD0qIA= Date: Mon, 18 Apr 2016 08:35:40 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53AAD6@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D539826@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53A075@NKGEML515-MBX.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] 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.0A020204.57149C64.0076, 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: a599237cdaaf9e338ff22176db06957d Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] Signaling Entropy Label Capability Using OSPF - draft-ietf-ospf-mpls-elc-00 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 08:35:53 -0000 SGkgQWNlZSwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBY2VlIExp bmRlbSAoYWNlZSkgW21haWx0bzphY2VlQGNpc2NvLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIEFw cmlsIDE0LCAyMDE2IDc6MjIgUE0NCj4gVG86IFh1eGlhb2h1OyBkcmFmdC1pZXRmLW9zcGYtbXBs cy1lbGNAaWV0Zi5vcmcNCj4gQ2M6IE9TUEYgV0cgTGlzdA0KPiBTdWJqZWN0OiBSZTogU2lnbmFs aW5nIEVudHJvcHkgTGFiZWwgQ2FwYWJpbGl0eSBVc2luZyBPU1BGIC0NCj4gZHJhZnQtaWV0Zi1v c3BmLW1wbHMtZWxjLTAwDQo+IA0KPiBIaSBUaWdlciwNCj4gDQo+IE9uIDQvMTQvMTYsIDU6MDkg QU0sICJYdXhpYW9odSIgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiANCj4gPkhpIEFj ZWUsDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogQWNl ZSBMaW5kZW0gKGFjZWUpIFttYWlsdG86YWNlZUBjaXNjby5jb21dDQo+ID4+IFNlbnQ6IFdlZG5l c2RheSwgQXByaWwgMTMsIDIwMTYgODo0MSBQTQ0KPiA+PiBUbzogWHV4aWFvaHU7IGRyYWZ0LWll dGYtb3NwZi1tcGxzLWVsY0BpZXRmLm9yZw0KPiA+PiBDYzogT1NQRiBXRyBMaXN0DQo+ID4+IFN1 YmplY3Q6IFJlOiBTaWduYWxpbmcgRW50cm9weSBMYWJlbCBDYXBhYmlsaXR5IFVzaW5nIE9TUEYg LQ0KPiA+PiBkcmFmdC1pZXRmLW9zcGYtbXBscy1lbGMtMDANCj4gPj4NCj4gPj4gSGkgVGlnZXIs DQo+ID4+DQo+ID4+IE9uIDQvMTMvMTYsIDM6NDEgQU0sICJYdXhpYW9odSIgPHh1eGlhb2h1QGh1 YXdlaS5jb20+IHdyb3RlOg0KPiA+Pg0KPiA+PiA+SGkgQWNlZSwNCj4gPj4gPg0KPiA+PiA+VGhh bmtzIGZvciB5b3VyIGNvbW1lbnRzLiBQbGVhc2Ugc2VlIG15IHJlc3BvbnNlIGluIGxpbmUuDQo+ ID4+ID4NCj4gPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gPj4gRnJvbTog QWNlZSBMaW5kZW0gKGFjZWUpIFttYWlsdG86YWNlZUBjaXNjby5jb21dDQo+ID4+ID4+IFNlbnQ6 IFR1ZXNkYXksIEFwcmlsIDEyLCAyMDE2IDE6MzkgQU0NCj4gPj4gPj4gVG86IGRyYWZ0LWlldGYt b3NwZi1tcGxzLWVsY0BpZXRmLm9yZw0KPiA+PiA+PiBDYzogT1NQRiBXRyBMaXN0DQo+ID4+ID4+ IFN1YmplY3Q6IFNpZ25hbGluZyBFbnRyb3B5IExhYmVsIENhcGFiaWxpdHkgVXNpbmcgT1NQRiAt DQo+ID4+ID4+IGRyYWZ0LWlldGYtb3NwZi1tcGxzLWVsYy0wMA0KPiA+PiA+Pg0KPiA+PiA+PiBB dXRob3JzLA0KPiA+PiA+Pg0KPiA+PiA+PiBXZSB3aWxsIHNvb24gYmUgcHJvZ3Jlc3NpbmcgdGhl IE9TUEZ2MiBTUiBkcmFmdC4gV2hhdCBpcyB5b3VyDQo+ID4+ID4+aW50ZW50IGZvciB0aGlzICBk cmFmdD8gSXQgaXMgbWlzc2luZzoNCj4gPj4gPj4NCj4gPj4gPj4gICAgIDEuIEEgZmlndXJlIHdp dGggdGhlIFJJIGVuY29kaW5nIGxpa2Ugb3RoZXIgT1NQRiBkb2N1bWVudHMNCj4gPj4gPg0KPiA+ PiA+V2lsbCBhZGQgdHdvIGZpZ3VyZXMgZm9yIEVMQyBUTFYgYW5kIFJMU0RDIFRMViByZXNwZWN0 aXZlbHkuDQo+ID4+DQo+ID4+IENhbiB5b3UgY29tZSB1cCB3aXRoIGEgYmV0dGVyIG5hbWUgdGhh biBSTFNEQz8gSXQgYXBwZWFycyB0aGlzIHdvdWxkDQo+ID4+b2J2aWF0ZSAgdGhlIG5lZWQgZm9y IHRoZSByZWNlbnQgTVNEIHByb3Bvc2FsIGJ1dCB0aGF0IGlzIGEgbXVjaA0KPiA+PmJldHRlciBu YW1lLg0KPiA+DQo+ID5STFNEQyBoYXMgYmVlbiByZXBsYWNlZCBieSBSTERDIChSZWFkYWJsZSBM YWJlbCBEZXB0aCBDYXBhYmlsaXR5KSBpbg0KPiA+dGhlIGxhdGVzdCB2ZXJzaW9uLiBJZiBJIHVu ZGVyc3Rvb2QgaXQgY29ycmVjdGx5LCBNU0QgYW5kIFJMRCBhcmUgdXNlZA0KPiA+dG8gaW5kaWNh dGUgZGlmZmVyZW50IHRoaW5ncywgZS5nLiwgdGhlIGZvcm1lciBpcyB1c2VkIHRvIGluZGljYXRl IGhvdw0KPiA+bWFueSBsYWJlbHMgdG8gbWF4aW11bSBleHRlbnQgY291bGQgYmUgaW1wb3NlZCBi eSB0aGUgaW5ncmVzcyBub2RlDQo+ID53aGlsZSB0aGUgbGF0dGVyIGlzIHVzZWQgdG8gaW5kaWNh dGUgaG93IG1hbnkgbGFiZWxzIHRvIG1heGltdW0gZXh0ZW50DQo+ID5jb3VsZCBiZSByZWFkIGJ5 IGEgaW50ZXJtZWRpYXRlIG5vZGUuDQo+IA0KPiBPayAtIHRoaXMgd2lsbCBiZSBjbGVhcmVyIG9u Y2UgdGhlIHVzYWdlIHNlY3Rpb24gaXMgYWRkZWQuIEkgbGlrZSBSTERDIGJldHRlciB0aGFuDQo+ IFJMU0RDLg0KDQpPSywgd2lsbCBhZGQgYSB1c2FnZSBhbmQgYXBwbGljYWJpbGl0eSBzZWN0aW9u Lg0KDQo+ID4NCj4gPj4gPj4gICAgIDIuIERpc2N1c3Npb24gYXMgdG8gcHJlY2lzZWx5IGhvdyB0 aGUgY2FwYWJpbGl0eSB3b3VsZCBiZSB1c2VkDQo+ID4+ID4+YnkgYSByb3V0ZXIgaW4gIGFuIE9T UEYgcm91dGluZyBkb21haW4uIEZvciBleGFtcGxlLCBtdXN0IGEgcm91dGVyDQo+ID4+ID4+cmVt b3ZlIHRoZSBFTCBpZiB0aGUgIG5leHQtaG9wIGRvZXNu4oCZdCBzdXBwb3J0IGl0Pw0KPiA+PiA+ DQo+ID4+ID5UaGlzIGRvY3VtZW50IG9ubHkgZGVzY3JpYmVzIGhvdyB0aGUgRUxDIGFuZCBSTFNE QyBhcmUgYWR2ZXJ0aXNlZA0KPiA+PiA+dmlhIE9TUEYuIEFzIGZvciBob3cgdGhlc2UgY2FwYWJp bGl0aWVzIHdvdWxkIGJlIHVzZWQgYXJlIGFjdHVhbGx5DQo+ID4+ID5kZXNjcmliZWQgaW4NCj4g Pj4gPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1wbHMtc3ByaW5nLWVu dHJvcHktbGFiZWwuIEJ5DQo+ID4+ID50aGUgd2F5LCBhIHJvdXRlciBkb2Vzbid0IG5lZWQgdG8g cmVtb3ZlIHRoZSBFTCBpZiB0aGUgbmV4dC1ob3ANCj4gPj4gPmRvZXNuJ3Qgc3VwcG9ydCBpdC4g VGhlIG9ubHkgcmVxdWlyZW1lbnQgb24gdXNpbmcgRUwgaXM6IEFuIGluZ3Jlc3MNCj4gPj4gPkxT UiBjYW5ub3QgaW5zZXJ0IEVMcyBmb3IgcGFja2V0cyBnb2luZyBpbnRvIGEgZ2l2ZW4gdHVubmVs IHVubGVzcw0KPiA+PiA+YW4gZWdyZXNzIExTUg0KPiA+Pmhhcw0KPiA+PiBpbmRpY2F0ZWQgdmlh IHNpZ25hbGluZyB0aGF0IGl0IGNhbiBwcm9jZXNzIEVMcyBvbiB0aGF0IHR1bm5lbC4NCj4gPj4N Cj4gPj4gQ2FuIHlvdSBhZGQgYSBzaG9ydCBzZWN0aW9uIHJlZmVyZW5jaW5nIHRoZSBhcHBsaWNh YmxlIHNlY3Rpb24gaW4NCj4gPj50aGlzIGRvY3VtZW50Lg0KPiA+DQo+ID5TdXJlLiBEbyB5b3Ug aGF2ZSBhbnkgc3VnZ2VzdCBvbiB0aGUgdGV4dCBpbiBzdWNoIHNlY3Rpb24/DQo+IA0KPiBJIGNv dWxkIHdyaXRlIHRoaXMgYnV0IHlvdSB0aGluayB3aXRoIDUgYXV0aG9ycyBmb3IgYSBkcmFmdCB0 aGF0IG9ubHkgaGFzDQo+IDEgMS8yIHBhZ2VzIG9mIGNvbnRlbnQgLSBvbmUgb2YgeW91IHdvdWxk IGJlIGFibGUgdG8gd3JpdGUgdGhpcy4NCg0KRmluZTopDQoNCj4gDQo+ID4NCj4gPj4NCj4gPj4g Pg0KPiA+PiA+PiAgICAgMy4gQSBkaXNjdXNzaW9uIG9mIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkg Zm9yIHRoZSBuZXcNCj4gPj4gPj5Sb3V0ZXItSW5mb3JtYXRpb24gIExTQSBjYXBhYmlsaXR5Lg0K PiA+PiA+DQo+ID4+ID5JcyBpdCBlbm91Z2ggdG8gYWRkIHRoZSBmb2xsb3dpbmcgdGV4dDoNCj4g Pj4gPg0KPiA+PiA+IlRvIGJlIGNvbXBhdGlibGUgd2l0aCBSRkM3NzcwLCBFTEMgYW5kIFJMU0RD IFRMVnMgU0hPVUxEIGNvbnRpbnVlDQo+ID4+ID50byBiZSBhZHZlcnRpc2VkIGluIHRoZSBmaXJz dCBpbnN0YW5jZSwgaS5lLiwgMCwgb2YgdGhlIFJvdXRlcg0KPiA+PkluZm9ybWF0aW9uIExTQS4i DQo+ID4+DQo+ID4+IEkgd2FzIHRhbGtpbmcgbW9yZSBvbiB0aGUgbGV2ZWwgb2YgdXNhZ2Ugb2Yg dGhlIGNhcGFiaWxpdHkgdGhhbg0KPiA+PmFkdmVydGlzZW1lbnQuDQo+ID4+IFNpbmNlIHRoaXMg aXMgbmV3LCB0aGVyZSBzaG91bGQgYmUgYW55IFJJIExTQXMgY29uc2lkZXJhdGlvbnMuDQo+ID4N Cj4gPlRoZSBFTCBjYXBhYmlsaXR5IGlzIHVzZWQgYnkgaW5ncmVzcyBMU1JzIHRvIGRldGVybWlu ZSB3aGV0aGVyIGFuIEVMDQo+ID5jb3VsZCBiZSBpbnNlcnRlZCBpbnRvIGEgZ2l2ZW4gTFNQIHR1 bm5lbCwgYW5kIHRoZSBSTEQgY2FwYWJpbGl0eSBpcw0KPiA+dXNlZCBieSBpbmdyZXNzIExTUnMg dG8gZGV0ZXJtaW5lIHdoZXRoZXIgaXQncyBuZWNlc3NhcnkgdG8gaW5zZXJ0IGFuDQo+ID5FTCBm b3IgYSBnaXZlbiBMU1AgdHVubmVsIGluIHRoZSBjYXNlIHdoZXJlIHRoZXJlIGhhcyBhbHJlYWR5 IGJlZW4gYXQNCj4gPmxlYXN0IG9uZSBFTCBpbiB0aGUgbGFiZWwgc3RhY2suIFRoZSBhYm92ZSBo YXMgYmVlbiBtZW50aW9uZWQgaW4gdGhlDQo+ID5JbnRyb2R1Y3Rpb24gc2VjdGlvbi4gSSdtIG5v dCBzdXJlIHRoYXQgSSBmdWxseSB1bmRlcnN0b29kIHlvdXIgcG9pbnQuDQo+ID5JZiBub3QsIGNv dWxkIHlvdSBnaXZlIGFueSBzdWdnZXN0aW9uIG9uIHRoZSBkaXNjdXNzaW9uIG9mIGJhY2t3YXJk DQo+IGNvbXBhdGliaWxpdHk/DQo+IA0KPiBXaGF0IGhhcHBlbnMgaWYgbm90IGFsbCByb3V0ZXJz IGluIHRoZSBkb21haW4gc3VwcG9ydCBjYXBhYmlsaXR5IGFkdmVydGlzZW1lbnQ/DQoNCklmIGEg Z2l2ZW4gZWdyZXNzIG5vZGUgZG9lc24ndCBzdXBwb3J0IEVMQywgaW5ncmVzcyBub2RlcyBzaG91 bGQgbm90IGluc2VydCBFTCBpbnRvIHRoZSB0dW5uZWxzIHRvd2FyZHMgdGhhdCBlZ3Jlc3Mgbm9k ZS4gSWYgc29tZSByb3V0ZXJzIGRvbid0IHN1cHBvcnQgUkxEQywgdGhlIEVMIGluc2VydGlvbiBh cHByb2FjaCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA1LjQuICAoYS5rLmEuLCBFTHMgYXQgcmVh ZGFibGUgbGFiZWwgc3RhY2sgZGVwdGhzKSBvZiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtbXBscy1zcHJpbmctZW50cm9weS1sYWJlbCkgbWF5IGJlIGltcGFjdGVkIGEg bGl0dGxlIGJpdC4gRm9yIGV4YW1wbGUsIGEgZGVmYXVsdCBSTEQgdmFsdWUgY2FuIGJlIHNldCBm b3IgYWxsIHRob3NlIHJvdXRlcnMgdGhhdCBkb24ndCBhZHZlcnRpc2UgdGhlIFJMREMuIEFueXdh eSwgc2luY2UgdGhpcyBkcmFmdCBpcyBvbmx5IGludGVuZGVkIHRvIGRlc2NyaWJlIGhvdyB0byBh ZHZlcnRpc2UgRUxDIGFuZCBSTERDIHZpYSBPU1BGLCB0aGUgc3BlY2lmaWMgdXNhZ2Ugb2YgdGhl c2UgY2FwYWJpbGl0aWVzIGlzIG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRoaXMgZHJhZnQuIA0K DQpBbnkgZnVydGhlciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuDQoNCkJl c3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IFRoYW5rcywNCj4gQWNlZQ0KPiANCj4gDQo+ID4NCj4g PkJlc3QgcmVnYXJkcywNCj4gPlhpYW9odSAoVGlnZXIpDQo+ID4NCj4gPj4gVGhhbmtzLA0KPiA+ PiBBY2VlDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+ID4NCj4gPj4gPkJlc3QgcmVnYXJkcywNCj4g Pj4gPlhpYW9odQ0KPiA+PiA+DQo+ID4+ID4+IFRoYW5rcywNCj4gPj4gPj4gQWNlZQ0KPiA+PiA+ DQo+ID4NCg0K From nobody Mon Apr 18 09:09:52 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781FD12DFA8; Mon, 18 Apr 2016 09:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.996 X-Spam-Level: X-Spam-Status: No, score=-7.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 u0zji6_C0tEm; Mon, 18 Apr 2016 09:09:48 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E91212DA19; Mon, 18 Apr 2016 09:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1460995788; x=1492531788; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=fcZPYwZr3ct40ymmGR/6O5h5Bfa/ozBydwBivMDv3TY=; b=f0Vzu78P5kZmBA+OirNAwWFJ9qm/nW5jFzWhsbQUou8QSshQ6SAHAS4M PyymoyZ4ZRh6kRND1fPBwZCUOimct2JjXDTS4qbb6o0eDVV49BH8canms hmhOQE3gEN74SD1FNOTzAsrpf9iPlSvCAy7M+l6IM/aOtCHE0xpQL1FCK U=; X-IronPort-AV: E=Sophos;i="5.24,503,1455004800"; d="scan'208,217";a="186274414" Received: from unknown (HELO Ironmsg04-L.qualcomm.com) ([10.53.140.111]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Apr 2016 09:09:45 -0700 X-IronPort-AV: E=McAfee;i="5700,7163,8139"; a="1105112810" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Apr 2016 09:09:44 -0700 Received: from [10.64.160.13] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 18 Apr 2016 09:09:43 -0700 From: Pete Resnick To: General Area Review Team , , Date: Mon, 18 Apr 2016 11:09:42 -0500 Message-ID: <262CC2D9-1F83-45BB-8DA4-0FC70FAE88B4@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_2B7CCF8A-0CEE-4F01-8DEA-A34E58100ED7_=" Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5239) X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Subject: [OSPF] Gen-ART LC review of draft-ietf-ospf-sbfd-discriminator-04 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 16:09:50 -0000 --=_MailMate_2B7CCF8A-0CEE-4F01-8DEA-A34E58100ED7_= Content-Type: text/plain; charset="utf-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-ospf-sbfd-discriminator-04 Reviewer: Pete Resnick Review Date: 2016-04-18 IETF LC End Date: 2016-04-26 IESG Telechat date: 2016-05-05 Summary: This draft is ready for publication as a Proposed Standard RFC. Major issues: None Minor issues: None Nits/editorial comments: Two clarifications, one typo: 2.1: OLD Type - S-BFD Discriminator TLV Type NEW Type - S-BFD Discriminator TLV Type (TBD [to be filled in by IANA]) END OLD Length - Total length of the discriminator (Value field) in octets, not including the optional padding. The Length is a multiple of 4 octets, and consequently specifies how many Discriminators are included in the TLV. NEW Length - Total length of the discriminator(s) that appear in the Value field, in octets. Each discriminator is 4 octets, so the Length is 4 times the number of Discriminators included in the TLV. There is no optional padding for this field. END 2.2: OLD Note that the S-BFD session may be required to pan multiple areas NEW Note that the S-BFD session may be required to span multiple areas END -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --=_MailMate_2B7CCF8A-0CEE-4F01-8DEA-A34E58100ED7_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I am the assigned Gen-ART reviewer for this draft. The Ge= neral Area Review Team (Gen-ART) reviews all IETF documents being process= ed by the IESG for the IETF Chair. Please treat these comments just like = any other last call comments. For more information, please see the FAQ at= <=E2=80=8Bhttp://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-ospf-sbfd-discriminator-04
Reviewer: Pete Resnick
Review Date: 2016-04-18
IETF LC End Date: 2016-04-26
IESG Telechat date: 2016-05-05

Summary: This draft is ready for publication as a Propose= d Standard RFC.

Major issues: None

Minor issues: None

Nits/editorial comments: Two clarifications, one typo:

2.1:

OLD
Type - S-BFD Discriminator TLV Type
NEW
Type - S-BFD Discriminator TLV Type (TBD [to be filled in by IANA]) END

OLD
Length - Total length of the discriminator (Value field) in octets, not including the optional padding. The Length is a multiple of 4
= octets, and consequently specifies how many Discriminators are
included in the TLV.
NEW
Length - Total length of the discriminator(s) that appear in the
Value field, in octets. Each discriminator is 4 octets, so the Length<= br> is 4 times the number of Discriminators included in the TLV. There is<= br> no optional padding for this field.
END

2.2:

OLD
Note that the S-BFD session may be required to pan multiple areas
NEW
Note that the S-BFD session may be required to span multiple areas
= END

--
Pete Resnick http://www.= qualcomm.com/~presnick/
Qualcomm Technologies, Inc. - +1 (858)651-4478

--=_MailMate_2B7CCF8A-0CEE-4F01-8DEA-A34E58100ED7_=-- From nobody Mon Apr 18 10:38:49 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE1012DAE9; Mon, 18 Apr 2016 10:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 DfHZRiCHDPSu; Mon, 18 Apr 2016 10:38:42 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5289612D925; Mon, 18 Apr 2016 10:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7447; q=dns/txt; s=iport; t=1461001122; x=1462210722; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zgNXIwkjgKU55ZEZZUIV0EHOr5PDX4MeVIW1FYpaP6s=; b=DE6ZG6wDEaFlUF76S+8MWCQAyLN3uJmCrOWUcZXMkMowTkMVmAju5dbU ZBTRisb/CaNaGtmrSNOEJBFWYOgU1eL3Pc1RTJshCxuSmoRnAJpGJeVzw wy7xhEMWXFi2J8h4dWq3BC/x0qNWAorlAwNjxunNkbovT3GoJW7SUXJDu M=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAwBRGxVX/5tdJa1aAxaDIlN9BrUwh?= =?us-ascii?q?HMOgXEihWwCgTg4FAEBAQEBAQFlJ4RBAQEBAwEjVgULAgEIDgYEKgICMiUCBA4?= =?us-ascii?q?FDogTCA6qTJE6AQEBAQEBAQEBAQEBAQEBAQEBAQEBDQiGIYF1glaEXwEmgjkrg?= =?us-ascii?q?isFkx6EcAGDJIFmbYgWgWdOhACIXI8qAQ8PAUOBTIIcbAGIO34BAQE?= X-IronPort-AV: E=Sophos;i="5.24,503,1454976000"; d="asc'?scan'208,217";a="93101305" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2016 17:38:40 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u3IHcdm5028797 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Apr 2016 17:38:39 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 18 Apr 2016 13:38:38 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Mon, 18 Apr 2016 13:38:38 -0400 From: "Carlos Pignataro (cpignata)" To: Pete Resnick Thread-Topic: Gen-ART LC review of draft-ietf-ospf-sbfd-discriminator-04 Thread-Index: AQHRmYzEAI6OedVcYkC65TRwJwyDGJ+QQj4A Date: Mon, 18 Apr 2016 17:38:38 +0000 Message-ID: References: <262CC2D9-1F83-45BB-8DA4-0FC70FAE88B4@qti.qualcomm.com> In-Reply-To: <262CC2D9-1F83-45BB-8DA4-0FC70FAE88B4@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.53] Content-Type: multipart/signed; boundary="Apple-Mail=_A6D988E2-6B39-46BA-80B8-FF83BC690422"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-ospf-sbfd-discriminator.all@ietf.org" , "ospf@ietf.org" , General Area Review Team Subject: Re: [OSPF] Gen-ART LC review of draft-ietf-ospf-sbfd-discriminator-04 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 17:38:48 -0000 --Apple-Mail=_A6D988E2-6B39-46BA-80B8-FF83BC690422 Content-Type: multipart/alternative; boundary="Apple-Mail=_09E74D4A-C44D-4054-9D09-AEBAB3897E70" --Apple-Mail=_09E74D4A-C44D-4054-9D09-AEBAB3897E70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Pete, Many thanks for your review. Good catches, I agree with the three editorial suggestions below. I=E2=80=99= ve made these changes in our working copy. Thanks, =E2=80=94 Carlos. > On Apr 18, 2016, at 12:09 PM, Pete Resnick = wrote: >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area = Review Team (Gen-ART) reviews all IETF documents being processed by the = IESG for the IETF Chair. Please treat these comments just like any other = last call comments. For more information, please see the FAQ at = <=E2=80=8Bhttp://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> = . >=20 > Document: draft-ietf-ospf-sbfd-discriminator-04 > Reviewer: Pete Resnick > Review Date: 2016-04-18 > IETF LC End Date: 2016-04-26 > IESG Telechat date: 2016-05-05 >=20 > Summary: This draft is ready for publication as a Proposed Standard = RFC. >=20 > Major issues: None >=20 > Minor issues: None >=20 > Nits/editorial comments: Two clarifications, one typo: >=20 > 2.1: >=20 > OLD > Type - S-BFD Discriminator TLV Type > NEW > Type - S-BFD Discriminator TLV Type (TBD [to be filled in by IANA]) > END >=20 > OLD > Length - Total length of the discriminator (Value field) in octets, > not including the optional padding. The Length is a multiple of 4 > octets, and consequently specifies how many Discriminators are > included in the TLV. > NEW > Length - Total length of the discriminator(s) that appear in the > Value field, in octets. Each discriminator is 4 octets, so the Length > is 4 times the number of Discriminators included in the TLV. There is > no optional padding for this field. > END >=20 > 2.2: >=20 > OLD > Note that the S-BFD session may be required to pan multiple areas > NEW > Note that the S-BFD session may be required to span multiple areas > END >=20 > -- > Pete Resnick http://www.qualcomm.com/~presnick/ = > Qualcomm Technologies, Inc. - +1 (858)651-4478 >=20 --Apple-Mail=_09E74D4A-C44D-4054-9D09-AEBAB3897E70 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Pete,

Many thanks for your review.

Good catches, I agree with the three = editorial suggestions below. I=E2=80=99ve made these changes in our = working copy.

Thanks,

=E2=80=94 Carlos.

On = Apr 18, 2016, at 12:09 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:

I am the = assigned Gen-ART reviewer for this draft. The General Area Review Team = (Gen-ART) reviews all IETF documents being processed by the IESG for the = IETF Chair. Please treat these comments just like any other last call = comments. For more information, please see the FAQ at <=E2=80=8Bhttp://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>= .

Document: = draft-ietf-ospf-sbfd-discriminator-04
Reviewer: Pete Resnick
Review Date: 2016-04-18
IETF LC End Date: 2016-04-26
IESG Telechat date: 2016-05-05

Summary: = This draft is ready for publication as a Proposed Standard RFC.

Major issues: None

Minor issues: None

Nits/editorial= comments: Two clarifications, one typo:

2.1:

OLD
Type - S-BFD Discriminator TLV Type
NEW
Type - S-BFD Discriminator TLV Type (TBD [to be filled in by = IANA])
END

OLD
Length - Total length of the discriminator (Value field) in = octets,
not including the optional padding. The Length is a multiple of 4
octets, and consequently specifies how many Discriminators are
included in the TLV.
NEW
Length - Total length of the discriminator(s) that appear in the
Value field, in octets. Each discriminator is 4 octets, so the = Length
is 4 times the number of Discriminators included in the TLV. There = is
no optional padding for this field.
END

2.2:

OLD
Note that the S-BFD session may be required to pan multiple areas
NEW
Note that the S-BFD session may be required to span multiple areas
END

--
Pete Resnick http://www.qualcomm.com/~presnick/
Qualcomm Technologies, Inc. - +1 (858)651-4478


= --Apple-Mail=_09E74D4A-C44D-4054-9D09-AEBAB3897E70-- --Apple-Mail=_A6D988E2-6B39-46BA-80B8-FF83BC690422 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXFRugAAoJEIXgpQGOZny9NJMQAIHw8YupN46Dc3e9SchqrsjE iWMsINgHBoq9CzK3bg1sA4s9kWVnqkC4nWwOLzzGIop3Kz22nOf9HQTVDf91MtZy vTBaxqhcb9ElJT1mBJ6KkqlEbBzVfcnS55ARvPeCTa8v767fj2mNppBesTWGVBgE qLTsB6oHhEBCp82Q+5BD20B1XqMKL1pwg2EkoYSwzeVsVsqJLr1U0LSN/B2G0wvn yH4RsBrPmUoXYjoqwDeMX+Q4/IoM/WlxWdnB4ABWgEAjVTnd/HK95cQCuFGs4CKQ IDOage5nWqxr0342Qc4KQw6gQGjQNrPqTh9pc2qA+xeFXcQp3zkDqnRaqVkOZ5vm QFjr69FGtCEgw/g8sNZdD/DL75lPcwzz4xiQh/oj8Fms18JQZ5axPwHrf1PfPlFI 7h6qT50ZorX8s7GtY2hjYGvfO1tOSobf0v6MvyxMd9pDK/hdp53UxNTi9vBvkNxl vPmQ3wEUYmLSWEPiuc/zfdMNObyYRSJ5g0PwwHu3Mm79wreuqOoSP4VL+VVf7BgL CQFvQLZJYl6sZ6UIC8CbMGvpW9yC8ktBK0T0XABzla0Swm2s6u+FrY6+xu2iz0C1 rtXne2eG5hAZ8BBTR8ZXyiO0gdd79dIKgjphv1e5dNVnNGV5UAQq42Ji6V+vK2V3 O1pYMLFF2qL65aS/GKxm =TNn6 -----END PGP SIGNATURE----- --Apple-Mail=_A6D988E2-6B39-46BA-80B8-FF83BC690422-- From nobody Sat Apr 23 11:04:24 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DB212D0EE; Sat, 23 Apr 2016 11:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.616 X-Spam-Level: X-Spam-Status: No, score=-13.616 tagged_above=-999 required=5 tests=[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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 qI1sSf1W8HpL; Sat, 23 Apr 2016 11:04:12 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE33512D57E; Sat, 23 Apr 2016 11:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4275; q=dns/txt; s=iport; t=1461434646; x=1462644246; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DumBTjFRnN9+Bf9HqJz/LatUxdLrrGo4dP+5tIWXwpc=; b=QIX//E+W8RwA3Z7u0aoRbpTBM8NABLkdQaWOgE7QWwOlBd/W2go1R24w 7HKmlyKkCqvcbIqIeXOcscAZVYnux28SnKuLjyp9kbcDk1fTrH2qvMIoB n892ViOwUv7p/DPlXYuFNKBqG/mWLhj8ZxWiS0k4HNcGwGvJptmXFxl9x s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BGBQCsuBtX/4UNJK1egmxMU30GtHmCZ?= =?us-ascii?q?IIdgXUehXACHIEDOhIBAQEBAQEBZSeEQQEBAQQjVhACAQgEDQMBAigDAgICMBQ?= =?us-ascii?q?JCAIEAQ0FiCoOrkCQbwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEimyEX4JgglYFm?= =?us-ascii?q?A8BhXqIGYFmhE2IXY8uAScFNoNrbId8fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,523,1454976000"; d="scan'208,217";a="265105159" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Apr 2016 18:04:05 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3NI45bX010227 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 23 Apr 2016 18:04:05 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 23 Apr 2016 14:04:04 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Sat, 23 Apr 2016 14:04:04 -0400 From: "Acee Lindem (acee)" To: "Abhay Roy (akr)" , "draft-ietf-ospf-two-part-metric@ietf.org" Thread-Topic: OSPF 2-Part Metric IPR Poll Thread-Index: AQHRnYeLHtH00PTt/kehl5bV5foRtZ+X2fyA Date: Sat, 23 Apr 2016 18:04:04 +0000 Message-ID: References: <7f0e8ef5-c748-c870-e562-e897687f6ca6@cisco.com> In-Reply-To: <7f0e8ef5-c748-c870-e562-e897687f6ca6@cisco.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_D34130F05C132aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] OSPF 2-Part Metric IPR Poll X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 18:04:16 -0000 --_000_D34130F05C132aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkga25vdyBvZiBubyBJUFIgY2xhaW1zIG90aGVyIHRoYW4gdGhlIG9uZSB0aGF0IGhh cyBhbHJlYWR5IGJlZW4gZGlzY2xvc2VkIGFuZCBpcyBhY2Nlc3NpYmxlIHZpYSB0aGUgZGF0YSB0 cmFja2VyOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8yMjg3Lw0KDQpUaGFua3Ms DQpBY2VlDQoNCkZyb206ICJBYmhheSBSb3kgKGFrcikiIDxha3JAY2lzY28uY29tPG1haWx0bzph a3JAY2lzY28uY29tPj4NCkRhdGU6IFNhdHVyZGF5LCBBcHJpbCAyMywgMjAxNiBhdCAxOjQyIFBN DQpUbzogImRyYWZ0LWlldGYtb3NwZi10d28tcGFydC1tZXRyaWNAaWV0Zi5vcmc8bWFpbHRvOmRy YWZ0LWlldGYtb3NwZi10d28tcGFydC1tZXRyaWNAaWV0Zi5vcmc+IiA8ZHJhZnQtaWV0Zi1vc3Bm LXR3by1wYXJ0LW1ldHJpY0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1vc3BmLXR3by1wYXJ0 LW1ldHJpY0BpZXRmLm9yZz4+DQpDYzogQWNlZSBMaW5kZW0gPGFjZWVAY2lzY28uY29tPG1haWx0 bzphY2VlQGNpc2NvLmNvbT4+DQpTdWJqZWN0OiBPU1BGIDItUGFydCBNZXRyaWMgSVBSIFBvbGwN Cg0KQXV0aG9ycywNCg0KUGxlYXNlIGNvbmZpcm0geW91IGhhdmUgZWl0aGVyIG5vIElQUiwgb3Ig eW91ciBJUFIgZGlzY2xvc3VyZXMgYXJlIHJlcG9ydGVkIGFscmVhZHkuDQoNClJlZ2FyZHMsDQot QWJoYXkNCg0KUFM6IFBsZWFzZSBub3RlLCB3ZSBuZWVkICphbGwqIGF1dGhvcnMgdG8gZXhwbGlj aXRseSBhY2sgYmVmb3JlIHdlIGNhbiBtb3ZlIHRoaXMgZG9jdW1lbnQgZnVydGhlci4NCg0K --_000_D34130F05C132aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSwmbmJzcDs8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkkga25vdyBvZiBubyBJUFIgY2xhaW1zIG90 aGVyIHRoYW4gdGhlIG9uZSB0aGF0IGhhcyBhbHJlYWR5IGJlZW4gZGlzY2xvc2VkIGFuZCBpcyBh Y2Nlc3NpYmxlIHZpYSB0aGUgZGF0YSB0cmFja2VyOiZuYnNwO2h0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvaXByLzIyODcvPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3Ms PC9kaXY+DQo8ZGl2PkFjZWU8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xL X1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9u dC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006 IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAw aW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNi NWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDog M3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+JnF1b3Q7 QWJoYXkgUm95IChha3IpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YWtyQGNpc2NvLmNvbSI+ YWtyQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PkRhdGU6IDwvc3Bhbj5TYXR1cmRheSwgQXByaWwgMjMsIDIwMTYgYXQgMTo0MiBQTTxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1h aWx0bzpkcmFmdC1pZXRmLW9zcGYtdHdvLXBhcnQtbWV0cmljQGlldGYub3JnIj5kcmFmdC1pZXRm LW9zcGYtdHdvLXBhcnQtbWV0cmljQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmRyYWZ0LWlldGYtb3NwZi10d28tcGFydC1tZXRyaWNAaWV0Zi5vcmciPmRyYWZ0LWlldGYt b3NwZi10d28tcGFydC1tZXRyaWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPkFjZWUgTGluZGVtICZsdDs8YSBocmVmPSJtYWls dG86YWNlZUBjaXNjby5jb20iPmFjZWVAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPk9TUEYgMi1QYXJ0IE1ldHJpYyBJ UFIgUG9sbDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJN QUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNi NWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4N CjxkaXYgdGV4dD0iIzAwMDAwMCIgYmdjb2xvcj0iI0ZGRkZGRiI+QXV0aG9ycyw8YnI+DQo8YnI+ DQpQbGVhc2UgY29uZmlybSB5b3UgaGF2ZSBlaXRoZXIgbm8gSVBSLCBvciB5b3VyIElQUiBkaXNj bG9zdXJlcyBhcmUgcmVwb3J0ZWQgYWxyZWFkeS4NCjxicj4NCjxwcmUgY2xhc3M9Im1vei1zaWdu YXR1cmUiIGNvbHM9IjcyIj5SZWdhcmRzLA0KLUFiaGF5DQoNClBTOiBQbGVhc2Ugbm90ZSwgd2Ug bmVlZCAqYWxsKiBhdXRob3JzIHRvIGV4cGxpY2l0bHkgYWNrIGJlZm9yZSB3ZSBjYW4gbW92ZSB0 aGlzIGRvY3VtZW50IGZ1cnRoZXIuIA0KPC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D34130F05C132aceeciscocom_-- From nobody Mon Apr 25 06:33:53 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62D912D14C; Mon, 25 Apr 2016 06:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=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 l4xdM_Yxl4lk; Mon, 25 Apr 2016 06:33:46 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0782.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::782]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9A512B014; Mon, 25 Apr 2016 06:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SODc0tnlWgvePgiYwMwLg5H4cp8WQ4bnCmP6O2pwqeE=; b=TYa/D2JmGHncljj/eC0Y24j919oTVYeDXHCTLM/gyDS74qqcHVSHP0D5bYG2xXIU54ZXErYETSFYEYm29ju1E7Qmqjvud5DAExvwASt/WEXeIGga/0Hpei7KBu+0ZkhL55kz2zXt7fxZ7BPOFTAt6MnQH6Ml3abP8uWw/8PVBAE= Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BLUPR0501MB1714.namprd05.prod.outlook.com (10.163.120.17) with Microsoft SMTP Server (TLS) id 15.1.477.8; Mon, 25 Apr 2016 13:33:21 +0000 Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0477.012; Mon, 25 Apr 2016 13:33:21 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "Acee Lindem (acee)" , "Abhay Roy (akr)" , "draft-ietf-ospf-two-part-metric@ietf.org" Thread-Topic: [OSPF] OSPF 2-Part Metric IPR Poll Thread-Index: AQHRnYeMM+Llh1Oty0SIgWia2mLuTJ+X2fsAgALZBSA= Date: Mon, 25 Apr 2016 13:33:21 +0000 Message-ID: References: <7f0e8ef5-c748-c870-e562-e897687f6ca6@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: 3b856e7e-dbfc-4e3a-d3fd-08d36d0e2b90 x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1714; 5:+qgjjqIVsRx50Ip6ezBhrq9CtnZEsqkjhEn37nq+Qd+6bTSkv7XtyWDp38L0BqlRA0FL+bxJpJaYC6I9nalO7l0lIGAcj2C0aTj1IfvwRhBL4XeUJ4w9MST4MRFh3FyLwFMvTA3tN41qL5PaeA2AOA==; 24:8m07oWwcF5+cYedYJ9ZDCfJaSpFppRyp/+GOgxYGWb9adMmpgb/TBhcYFQRiuZV+guBSF3UeU23XVE+c+023r+Qx5341+K36lU11jX1ytKg=; 7:Cn1tWxC9mJXYouOg3gelcsRdJfCxgjKAyWAMBiYgB4BxSrn5JuLYfGCR7RBelDsk8ILfadEw+0hO0vdXCWSzzQSwdPGQCcz8pBOISCWwDsZL/QyvSFSQszMG+dLvS43fbojvEFQWScI7gKzg698gt0ZboiHuvktwDm2sLi4woVlwmF5jvdIn+F1neC/fF6Te x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1714; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BLUPR0501MB1714; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1714; x-forefront-prvs: 0923977CCA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(19300405004)(3660700001)(2900100001)(3280700002)(92566002)(99286002)(2906002)(5004730100002)(106116001)(66066001)(2501003)(87936001)(16236675004)(189998001)(81166005)(74316001)(76576001)(33656002)(10400500002)(86362001)(4326007)(15975445007)(54356999)(19625215002)(76176999)(50986999)(5001770100001)(586003)(102836003)(6116002)(790700001)(19617315012)(122556002)(9686002)(19580395003)(5003600100002)(19580405001)(11100500001)(3846002)(19609705001)(1096002)(5002640100001)(1220700001)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1714; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR0501MB1715839F3EC606644FB30D03D4620BLUPR0501MB1715_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2016 13:33:21.6003 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1714 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] OSPF 2-Part Metric IPR Poll X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 13:33:53 -0000 --_000_BLUPR0501MB1715839F3EC606644FB30D03D4620BLUPR0501MB1715_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWNlZSBoYXMgcHJvdmlkZWQgdGhlIGxpbmsgZm9yIHRoZSBJUFIgSSBhbSBhd2FyZSBvZi4NCg0K VGhhbmtzLg0KSmVmZnJleQ0KDQpGcm9tOiBBY2VlIExpbmRlbSAoYWNlZSkgW21haWx0bzphY2Vl QGNpc2NvLmNvbV0NClNlbnQ6IFNhdHVyZGF5LCBBcHJpbCAyMywgMjAxNiAyOjA0IFBNDQpUbzog QWJoYXkgUm95IChha3IpIDxha3JAY2lzY28uY29tPjsgZHJhZnQtaWV0Zi1vc3BmLXR3by1wYXJ0 LW1ldHJpY0BpZXRmLm9yZw0KQ2M6IE9TUEYgV0cgTGlzdCA8b3NwZkBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbT1NQRl0gT1NQRiAyLVBhcnQgTWV0cmljIElQUiBQb2xsDQoNCkhpLA0KDQpJIGtu b3cgb2Ygbm8gSVBSIGNsYWltcyBvdGhlciB0aGFuIHRoZSBvbmUgdGhhdCBoYXMgYWxyZWFkeSBi ZWVuIGRpc2Nsb3NlZCBhbmQgaXMgYWNjZXNzaWJsZSB2aWEgdGhlIGRhdGEgdHJhY2tlcjogaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMjI4Ny8NCg0KVGhhbmtzLA0KQWNlZQ0KDQpG cm9tOiAiQWJoYXkgUm95IChha3IpIiA8YWtyQGNpc2NvLmNvbTxtYWlsdG86YWtyQGNpc2NvLmNv bT4+DQpEYXRlOiBTYXR1cmRheSwgQXByaWwgMjMsIDIwMTYgYXQgMTo0MiBQTQ0KVG86ICJkcmFm dC1pZXRmLW9zcGYtdHdvLXBhcnQtbWV0cmljQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW9z cGYtdHdvLXBhcnQtbWV0cmljQGlldGYub3JnPiIgPGRyYWZ0LWlldGYtb3NwZi10d28tcGFydC1t ZXRyaWNAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtb3NwZi10d28tcGFydC1tZXRyaWNAaWV0 Zi5vcmc+Pg0KQ2M6IEFjZWUgTGluZGVtIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNlZUBjaXNj by5jb20+Pg0KU3ViamVjdDogT1NQRiAyLVBhcnQgTWV0cmljIElQUiBQb2xsDQoNCkF1dGhvcnMs DQoNClBsZWFzZSBjb25maXJtIHlvdSBoYXZlIGVpdGhlciBubyBJUFIsIG9yIHlvdXIgSVBSIGRp c2Nsb3N1cmVzIGFyZSByZXBvcnRlZCBhbHJlYWR5Lg0KDQoNClJlZ2FyZHMsDQoNCi1BYmhheQ0K DQoNCg0KUFM6IFBsZWFzZSBub3RlLCB3ZSBuZWVkICphbGwqIGF1dGhvcnMgdG8gZXhwbGljaXRs eSBhY2sgYmVmb3JlIHdlIGNhbiBtb3ZlIHRoaXMgZG9jdW1lbnQgZnVydGhlci4NCg== --_000_BLUPR0501MB1715839F3EC606644FB30D03D4620BLUPR0501MB1715_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30N CnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BY2VlIGhhcyBwcm92aWRlZCB0aGUg bGluayBmb3IgdGhlIElQUiBJIGFtIGF3YXJlIG9mLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLjxicj4NCkplZmZyZXk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBY2VlIExpbmRlbSAoYWNlZSkgW21haWx0bzphY2VlQGNp c2NvLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgQXByaWwgMjMsIDIwMTYgMjow NCBQTTxicj4NCjxiPlRvOjwvYj4gQWJoYXkgUm95IChha3IpICZsdDtha3JAY2lzY28uY29tJmd0 OzsgZHJhZnQtaWV0Zi1vc3BmLXR3by1wYXJ0LW1ldHJpY0BpZXRmLm9yZzxicj4NCjxiPkNjOjwv Yj4gT1NQRiBXRyBMaXN0ICZsdDtvc3BmQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW09TUEZdIE9TUEYgMi1QYXJ0IE1ldHJpYyBJUFIgUG9sbDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPkhpLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkkga25vdyBvZiBubyBJUFIgY2xhaW1zIG90aGVy IHRoYW4gdGhlIG9uZSB0aGF0IGhhcyBhbHJlYWR5IGJlZW4gZGlzY2xvc2VkIGFuZCBpcyBhY2Nl c3NpYmxlIHZpYSB0aGUgZGF0YSB0cmFja2VyOg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9pcHIvMjI4Ny8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzIy ODcvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5BY2VlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mcXVvdDtBYmhheSBSb3kgKGFrcikmcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpha3JAY2lzY28uY29tIj5ha3JAY2lzY28uY29tPC9hPiZn dDs8YnI+DQo8Yj5EYXRlOiA8L2I+U2F0dXJkYXksIEFwcmlsIDIzLCAyMDE2IGF0IDE6NDIgUE08 YnI+DQo8Yj5UbzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW9zcGYtdHdv LXBhcnQtbWV0cmljQGlldGYub3JnIj5kcmFmdC1pZXRmLW9zcGYtdHdvLXBhcnQtbWV0cmljQGll dGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtb3NwZi10d28t cGFydC1tZXRyaWNAaWV0Zi5vcmciPmRyYWZ0LWlldGYtb3NwZi10d28tcGFydC1tZXRyaWNAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+QWNlZSBMaW5kZW0gJmx0OzxhIGhyZWY9Im1h aWx0bzphY2VlQGNpc2NvLmNvbSI+YWNlZUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPlN1Ympl Y3Q6IDwvYj5PU1BGIDItUGFydCBNZXRyaWMgSVBSIFBvbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBp biIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkF1dGhv cnMsPGJyPg0KPGJyPg0KUGxlYXNlIGNvbmZpcm0geW91IGhhdmUgZWl0aGVyIG5vIElQUiwgb3Ig eW91ciBJUFIgZGlzY2xvc3VyZXMgYXJlIHJlcG9ydGVkIGFscmVhZHkuDQo8YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4tQWJoYXk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5QUzogUGxlYXNlIG5vdGUsIHdlIG5lZWQgKmFsbCogYXV0aG9ycyB0 byBleHBsaWNpdGx5IGFjayBiZWZvcmUgd2UgY2FuIG1vdmUgdGhpcyBkb2N1bWVudCBmdXJ0aGVy LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BLUPR0501MB1715839F3EC606644FB30D03D4620BLUPR0501MB1715_-- From nobody Mon Apr 25 07:54:04 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DE812D156; Mon, 25 Apr 2016 07:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.506 X-Spam-Level: X-Spam-Status: No, score=-15.506 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.996, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQOiYrv8Vn_s; Mon, 25 Apr 2016 07:54:01 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D96612D603; Mon, 25 Apr 2016 07:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12573; q=dns/txt; s=iport; t=1461596032; x=1462805632; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=e4RqX2osPowXIF0FSsQM94XiMAroqZnDRTNtqP0iqfc=; b=Uo+2tGMZhBj0imJ+rSX+j73ekEID62vIGXBtXhN2xMrLDUFODF9WGi5p 4SXkN1nLjwc4ePut5WtsSSLK6+eW6TLao/SGIGTFzoALCe/qR5pZ7Lr5/ HkzoCm14b1Ja/QmP79RTqwW52YzsDrd1/iXpGWTVX3ZeMPHLASFHY2foh 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAgCrLh5X/5pdJa1bA4JsTFN9BrR9g?= =?us-ascii?q?mSCDwENgXWGDgIcgRU4FAEBAQEBAQFlJ4RBAQEBBCMKTA4CAgEIEQMBAQEoAwI?= =?us-ascii?q?CAhQcFAkIAgQBDQWIKrB0kFIBAQEBAQEBAQEBAQEBAQEBAQEBAQEVBIpohCkRC?= =?us-ascii?q?wcJCgELCgIPgjmCVgWTHoRxAY4UgWaETYhdjy4BHgEBQoNrbIcpPn8BAQE?= X-IronPort-AV: E=Sophos; i="5.24,533,1454976000"; d="scan'208,217"; a="95363356" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Apr 2016 14:53:51 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3PErppO015460 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Apr 2016 14:53:51 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 25 Apr 2016 10:53:50 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Mon, 25 Apr 2016 10:53:50 -0400 From: "Acee Lindem (acee)" To: "DuBois, Dave" , "Abhay Roy (akr)" , "draft-ietf-ospf-two-part-metric@ietf.org" Thread-Topic: OSPF 2-Part Metric IPR Poll Thread-Index: AQHRnvnVer3C/ZKj/UeSI7iLokPzUZ+axpSA Date: Mon, 25 Apr 2016 14:53:50 +0000 Message-ID: References: <7f0e8ef5-c748-c870-e562-e897687f6ca6@cisco.com> <921B090B7CF74C4C81287D0B8526303D4528881D@AZRC4SAZMSG14.rc4s.com> In-Reply-To: <921B090B7CF74C4C81287D0B8526303D4528881D@AZRC4SAZMSG14.rc4s.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_D343A7A75C1D7aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: OSPF WG List Subject: Re: [OSPF] OSPF 2-Part Metric IPR Poll X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 14:54:03 -0000 --_000_D343A7A75C1D7aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIERhdmUgKE9TUEYgV0cgTGlzdCBhZGRlZCksDQpBY2VlDQoNCkZyb206ICJEdUJvaXMs IERhdmUiIDxEYXZlLkR1Qm9pc0BnZC1tcy5jb208bWFpbHRvOkRhdmUuRHVCb2lzQGdkLW1zLmNv bT4+DQpEYXRlOiBNb25kYXksIEFwcmlsIDI1LCAyMDE2IGF0IDk6NTMgQU0NClRvOiAiQWJoYXkg Um95IChha3IpIiA8YWtyQGNpc2NvLmNvbTxtYWlsdG86YWtyQGNpc2NvLmNvbT4+LCAiZHJhZnQt aWV0Zi1vc3BmLXR3by1wYXJ0LW1ldHJpY0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1vc3Bm LXR3by1wYXJ0LW1ldHJpY0BpZXRmLm9yZz4iIDxkcmFmdC1pZXRmLW9zcGYtdHdvLXBhcnQtbWV0 cmljQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW9zcGYtdHdvLXBhcnQtbWV0cmljQGlldGYu b3JnPj4NCkNjOiBBY2VlIExpbmRlbSA8YWNlZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28u Y29tPj4sICJEdUJvaXMsIERhdmUiIDxEYXZlLkR1Qm9pc0BnZC1tcy5jb208bWFpbHRvOkRhdmUu RHVCb2lzQGdkLW1zLmNvbT4+DQpTdWJqZWN0OiBSRTogT1NQRiAyLVBhcnQgTWV0cmljIElQUiBQ b2xsDQoNCkkgaGF2ZSBubyBJUFIgdG8gcmVwb3J0Lg0KDQpUaGFua3MNCkRhdmUgRHVib2lzDQpH REM0Uw0KT2ZmaWNlIC0gNTA4LTg4MC0yMjQ5DQoNClRoaXMgbWVzc2FnZSBhbmQvb3IgYXR0YWNo bWVudHMgbWF5IGluY2x1ZGUgaW5mb3JtYXRpb24gc3ViamVjdCB0byBHREM0UyBPLk0uIDEuOC42 IGFuZCBHRCBDb3Jwb3JhdGUgUG9saWN5IDA3LTEwNSBhbmQgYXJlIGludGVuZGVkIHRvIGJlIGFj Y2Vzc2VkIG9ubHkgYnkgYXV0aG9yaXplZCByZWNpcGllbnRzLiAgVXNlLCBzdG9yYWdlIGFuZCB0 cmFuc21pc3Npb24gYXJlIGdvdmVybmVkIGJ5IEdlbmVyYWwgRHluYW1pY3MgYW5kIGl0cyBwb2xp Y2llcy4gQ29udHJhY3R1YWwgcmVzdHJpY3Rpb25zIGFwcGx5IHRvIHRoaXJkIHBhcnRpZXMuICBS ZWNpcGllbnRzIHNob3VsZCByZWZlciB0byB0aGUgcG9saWNpZXMgb3IgY29udHJhY3QgdG8gZGV0 ZXJtaW5lIHByb3BlciBoYW5kbGluZy4gIFVuYXV0aG9yaXplZCByZXZpZXcsIHVzZSwgZGlzY2xv c3VyZSBvciBkaXN0cmlidXRpb24gaXMgcHJvaGliaXRlZC4gIElmIHlvdSBhcmUgbm90IGFuIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVzdHJveSBh bGwgY29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0KDQpGcm9tOiBBYmhheSBSb3kgW21h aWx0bzpha3JAY2lzY28uY29tXQ0KU2VudDogU2F0dXJkYXksIEFwcmlsIDIzLCAyMDE2IDE6NDMg UE0NClRvOiBkcmFmdC1pZXRmLW9zcGYtdHdvLXBhcnQtbWV0cmljQGlldGYub3JnPG1haWx0bzpk cmFmdC1pZXRmLW9zcGYtdHdvLXBhcnQtbWV0cmljQGlldGYub3JnPg0KQ2M6IEFjZWUgTGluZGVt DQpTdWJqZWN0OiBPU1BGIDItUGFydCBNZXRyaWMgSVBSIFBvbGwNCg0KQXV0aG9ycywNCg0KUGxl YXNlIGNvbmZpcm0geW91IGhhdmUgZWl0aGVyIG5vIElQUiwgb3IgeW91ciBJUFIgZGlzY2xvc3Vy ZXMgYXJlIHJlcG9ydGVkIGFscmVhZHkuDQoNCg0KUmVnYXJkcywNCg0KLUFiaGF5DQoNCg0KDQpQ UzogUGxlYXNlIG5vdGUsIHdlIG5lZWQgKmFsbCogYXV0aG9ycyB0byBleHBsaWNpdGx5IGFjayBi ZWZvcmUgd2UgY2FuIG1vdmUgdGhpcyBkb2N1bWVudCBmdXJ0aGVyLg0K --_000_D343A7A75C1D7aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <9DB7C407C476FA4BA69F6BB48CEA8DED@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5UaGFua3MgRGF2 ZSAoT1NQRiBXRyBMaXN0IGFkZGVkKSwmbmJzcDs8L2Rpdj4NCjxkaXY+QWNlZTwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0 OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBt ZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJ TkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdI VDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPkZyb206IDwvc3Bhbj4mcXVvdDtEdUJvaXMsIERhdmUmcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpEYXZlLkR1Qm9pc0BnZC1tcy5jb20iPkRhdmUuRHVCb2lzQGdkLW1zLmNvbTwv YT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5N b25kYXksIEFwcmlsIDI1LCAyMDE2IGF0IDk6NTMgQU08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDtBYmhheSBSb3kgKGFrcikmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpha3JAY2lzY28uY29tIj5ha3JAY2lzY28uY29tPC9hPiZndDssICZxdW90 OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW9zcGYtdHdvLXBhcnQtbWV0cmljQGlldGYub3Jn Ij5kcmFmdC1pZXRmLW9zcGYtdHdvLXBhcnQtbWV0cmljQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtb3NwZi10d28tcGFydC1tZXRyaWNAaWV0Zi5vcmci PmRyYWZ0LWlldGYtb3NwZi10d28tcGFydC1tZXRyaWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPkFjZWUgTGluZGVtICZsdDs8 YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20iPmFjZWVAY2lzY28uY29tPC9hPiZndDssICZx dW90O0R1Qm9pcywgRGF2ZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkRhdmUuRHVCb2lzQGdk LW1zLmNvbSI+RGF2ZS5EdUJvaXNAZ2QtbXMuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJFOiBPU1BGIDItUGFydCBNZXRyaWMg SVBSIFBvbGw8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0i TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAj YjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYg eG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hl bWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQx LUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29t L29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRt bDQwIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAy IDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2Ut MToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNv bGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxk aXYgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5JIGhhdmUgbm8gSVBSIHRvIHJlcG9ydC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJn YigzMSwgNzMsIDEyNSk7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4t cmlnaHQ6LjI1aW47bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW4tbGVmdDouMjVpbiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3M8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRhdmUgRHVib2lz PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPjxicj4NCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMUY0OTdEIj5HREM0Uzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OjUuMHB0O21hcmdpbi1yaWdodDouMjVpbjttYXJnaW4tYm90 dG9tOjUuMHB0O21hcmdpbi1sZWZ0Oi4yNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsiPk9mZmljZSAtIDUwOC04ODAtMjI0OTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6NS4wcHQ7bWFyZ2luLXJp Z2h0Oi4yNWluO21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6LjI1aW4iPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJn aW4tcmlnaHQ6LjI1aW47bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW4tbGVmdDouMjVpbiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibHVlIj5UaGlzIG1lc3NhZ2UgYW5k L29yIGF0dGFjaG1lbnRzIG1heSBpbmNsdWRlIGluZm9ybWF0aW9uIHN1YmplY3QgdG8gR0RDNFMg Ty5NLiAxLjguNiBhbmQgR0QgQ29ycG9yYXRlIFBvbGljeSAwNy0xMDUgYW5kIGFyZSBpbnRlbmRl ZCB0byBiZSBhY2Nlc3NlZCBvbmx5IGJ5IGF1dGhvcml6ZWQgcmVjaXBpZW50cy4mbmJzcDsgVXNl LCBzdG9yYWdlIGFuZCB0cmFuc21pc3Npb24gYXJlIGdvdmVybmVkDQogYnkgR2VuZXJhbCBEeW5h bWljcyBhbmQgaXRzIHBvbGljaWVzLiBDb250cmFjdHVhbCByZXN0cmljdGlvbnMgYXBwbHkgdG8g dGhpcmQgcGFydGllcy4mbmJzcDsgUmVjaXBpZW50cyBzaG91bGQgcmVmZXIgdG8gdGhlIHBvbGlj aWVzIG9yIGNvbnRyYWN0IHRvIGRldGVybWluZSBwcm9wZXIgaGFuZGxpbmcuJm5ic3A7IFVuYXV0 aG9yaXplZCByZXZpZXcsIHVzZSwgZGlzY2xvc3VyZSBvciBkaXN0cmlidXRpb24gaXMgcHJvaGli aXRlZC4mbmJzcDsgSWYgeW91IGFyZSBub3QgYW4NCiBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFz ZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0aGUgb3JpZ2lu YWwgbWVzc2FnZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog VGFob21hLCBzYW5zLXNlcmlmOyBjb2xvcjogd2luZG93dGV4dDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNl cmlmOyBjb2xvcjogd2luZG93dGV4dDsiPiBBYmhheSBSb3kgWzxhIGhyZWY9Im1haWx0bzpha3JA Y2lzY28uY29tIj5tYWlsdG86YWtyQGNpc2NvLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4g U2F0dXJkYXksIEFwcmlsIDIzLCAyMDE2IDE6NDMgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9 Im1haWx0bzpkcmFmdC1pZXRmLW9zcGYtdHdvLXBhcnQtbWV0cmljQGlldGYub3JnIj5kcmFmdC1p ZXRmLW9zcGYtdHdvLXBhcnQtbWV0cmljQGlldGYub3JnPC9hPjxicj4NCjxiPkNjOjwvYj4gQWNl ZSBMaW5kZW08YnI+DQo8Yj5TdWJqZWN0OjwvYj4gT1NQRiAyLVBhcnQgTWV0cmljIElQUiBQb2xs PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXV0aG9ycyw8 YnI+DQo8YnI+DQpQbGVhc2UgY29uZmlybSB5b3UgaGF2ZSBlaXRoZXIgbm8gSVBSLCBvciB5b3Vy IElQUiBkaXNjbG9zdXJlcyBhcmUgcmVwb3J0ZWQgYWxyZWFkeS4NCjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPHByZT5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi1BYmhheTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlBTOiBQ bGVhc2Ugbm90ZSwgd2UgbmVlZCAqYWxsKiBhdXRob3JzIHRvIGV4cGxpY2l0bHkgYWNrIGJlZm9y ZSB3ZSBjYW4gbW92ZSB0aGlzIGRvY3VtZW50IGZ1cnRoZXIuIDxvOnA+PC9vOnA+PC9wcmU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_D343A7A75C1D7aceeciscocom_-- From nobody Mon Apr 25 16:32:04 2016 Return-Path: X-Original-To: ospf@ietf.org Delivered-To: ospf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5357C12D151; Mon, 25 Apr 2016 16:32:03 -0700 (PDT) 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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160425233203.30210.63333.idtracker@ietfa.amsl.com> Date: Mon, 25 Apr 2016 16:32:03 -0700 Archived-At: Cc: ospf@ietf.org, ospf-chairs@ietf.org Subject: [OSPF] ospf - New Meeting Session Request for IETF 96 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 23:32:03 -0000 A new meeting session request has just been submitted by Acee Lindem, a Chair of the ospf working group. --------------------------------------------------------- Working Group Name: Open Shortest Path First IGP Area Name: Routing Area Session Requester: Acee Lindem Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: idr bess isis rtgwg rtgarea spring bier pim netmod Second Priority: teas mboned Special Requests: --------------------------------------------------------- From nobody Wed Apr 27 06:11:21 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C44112D173; Wed, 27 Apr 2016 06:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-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 5JOT2DnDgEcK; Wed, 27 Apr 2016 06:11:18 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC37512D17D; Wed, 27 Apr 2016 06:11:17 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u3RDBEcs021234; Wed, 27 Apr 2016 14:11:14 +0100 Received: from 950129200 (jplon-nat11.juniper.net [193.110.55.11]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u3RDBDhV021201 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 27 Apr 2016 14:11:14 +0100 From: "Adrian Farrel" To: Date: Wed, 27 Apr 2016 14:11:13 +0100 Message-ID: <069b01d1a086$46d4d470$d47e7d50$@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: AdGghcVG0QuPS2RxQ6ajDKPyM64Rjw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22286.006 X-TM-AS-Result: No--13.416-10.0-31-10 X-imss-scan-details: No--13.416-10.0-31-10 X-TMASE-MatchedRID: LvJXpWO3uAjzLVZFOZrw3hes/RxhysDbFJFr2qlKix9V84HrPxCfbDMB KS/l5ik348guxdxp7TO00HTgX5ZI96z75DRX+d9kKWuiyZLRI4Bu/Xr6CKXiN/xsP7g8BleLFhM gncTYqyTh7zLZMPEJbrLJMDbAGS4OwyCE4EX8iMOVSBCoZUyqbEH7wsB5444wkzE2kM4b6Hpuh7 UAK5WmX+0P6ZIQeqxyPqcZsIcaC2CdVRGgWj1IHAXysW33GYMpJdXjF5ArCFcLBZEuqIL9Sj4hX W7B+PPhNqz0Lvapr6rKxo315+1VtjB9eXnpC3lIRy+94mWbR+YpWss5kPUFdFpbYq2f4jz+eYaA 2aCxgSsJeHUNn+b9lrhXEYVAE0l4KeLGzKm/w9IuLk8NfSpYetxWLypmYlZz5GbPjpDb1sPE7Fz k7PfDjBdhhvQ7ld2C5tlnPJX7htQO9fZKTjt+z4b9ftid8kBcecvjbu/xDjpOIo0O+5ZV4UacLe +k1sVAc3ZlcRIO231d/5IDJqMHBaoDZpNjSrDVaUe/i9AephMBZBplMxI/zhKCZ+Q6yB8qzlCux iVWkhq+FlZl9V5OTDKHOKZCvLKntJieP4rjvdkHTkHUtPYzxdZKsq3DGpalDYbe/PyX8gSVzyuc mj4bkROmces8inKL0hToAWgDRbky9zgULewwZohaKK0I26FpmyqQJWNsuklI7YhsiSUzzOkI/31 bQ36ScITNzcasX/7s+Reb+uzo944a2rhHAtuZdiLDwvWethjuHZGuwo6K7TDJ9a3KikGo13D6mx i/OuYhJ/ufappeEpGTpe1iiCJqtD9qpBlNF8oLbigRnpKlKSPzRlrdFGDw6dIq3kU8x87MeHyRk 1HQkZgHH98I/M9nflMu2qjc54JFZ6er+YR20Q== Archived-At: Cc: draft-ietf-ospf-sbfd-discriminator.all@ietf.org, rtg-dir@ietf.org, ospf@ietf.org Subject: [OSPF] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 13:11:20 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them before or along with any IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-ospf-sbfd-discriminator-04.txt Reviewer: Adrian Farrel Review Date: 27 April 2016 IETF LC End Date: 26 April 2016 Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: This is a simple document that doesn't require much to implement or understand. It was disappointing, however, to find a large number of small issues and nits. I don't believe any of these are blocking to the utility of the document and if it went for publication in its current state it would not be harmful. But in the interest of making our documents useful and accessible, and for the purpose of eliminating all possible interoperability and deployment, I think it would be valuable to clean up the issues I have listed. Major Issues: No major issues found. Minor Issues: I should like to see some small amount of text on the scaling impact on OSPF. 1. How much additional information will implementations have to store per node/link in the network? 2. What is the expected churn in LSAs introduced by this mechanism (especially when the Reflector is turned on and off)? In the second case there is a security implication as well. Can I DoS the routing system by toggling some BFD Reflectors? Needs text! You *do* have... A change in information in the S-BFD Discriminator TLV MUST NOT trigger any SPF computation at a receiving router. ...which is a help. --- Section 1 has This is achieved by using unique network-wide discriminators to identify the Network Targets (e.g., IP addresses). You may be aware of IPv6 :-) Although 2.1 gives some hints on the size of a discriminator, I had to go back to 5880 to check that *all* discriminators are exactly 4 octets. So saying "e.g., IP addresses" is at best confusing. BTW, draft-ietf-bfd-seamless-base and draft-ietf-bfd-seamless-ip don't give any hints on this. Oh, and what is "network-wide"? I suggest... This is achieved by using four-octet discriminators as defined in [RFC5880] to identify the Network Targets. --- In Section 2 you have Upon receipt of the TLV, a router may decide to ignore this TLV or install the S-BFD discriminator in BFD Target Identifier Table. I think "ignore" is ambiguous. You need to be very clear that "ignore" means: - take no local action - retain the TLV in the opaque LSA - continue to advertise the opaque LSA according to its scope In Section 3 you also have A router not supporting the S-BFD Discriminator TLV will just silently ignore the TLV as specified in [RFC7770]. Am I missing something when I read 7770? I don't find anything about handling unknown TLVs. --- Section 2 para 3 s/superset/union/ ("superset" would allow you to include any other discriminators!) --- Section 2.1 To be totally unambiguous... OLD Length - Total length of the discriminator (Value field) in octets, not including the optional padding. The Length is a multiple of 4 octets, and consequently specifies how many Discriminators are included in the TLV. NEW Length - Total length of all discriminator in the Value field in octets, not including the optional padding. The Length is a multiple of 4 octets, and consequently specifies how many Discriminators are included in the TLV. END However (!) are you sure that you can include optional padding? I think that 7770 uses padding to take the V field up to a 4 octet boundary. Since all of your discriminators are exactly a multiple of 4 octets it seems that there will never be any padding and it would be less confusing to write... NEW Length - Total length of all discriminators in the TLV counted in octets. The Length is a multiple of 4 octets, and consequently specifies how many Discriminators are included in the TLV. END --- At the end of section 2.1 you have S-BFD discriminator is associated with the BFD Target Identifier type, that allows demultiplexing to a specific task or service. This is a wonderfully throw-away statement with no context and no further explanation in the document that I could find. Maybe this is just missing a reference to another document, or maybe it needs some clarification. --- Section 2.2 has The flooding scope for S-BFD Discriminator information advertised through OSPF can be limited to one or more OSPF areas, or can be extended across the entire OSPF routing domain. Note that the S-BFD session may be required to pan multiple areas, in which case the flooding scope may comprise these areas. This could be the case for an ABR, for instance, advertising the S-BFD Discriminator information within the backbone area and/or a subset of its attached IGP area(s). As I understand flooding scope the options for Opaque LSAs (see 5250) are: o Link-state type-9 denotes a link-local scope. o Link-state type-10 denotes an area-local scope. o Link-state type-11 denotes that the LSA is flooded throughout the Autonomous System (AS). Your text seems to imply something different. In particular, you seem to be suggesting that I can have a scope that is greater than one area but less than the whole AS (assuming "whole AS" == "entire OSPF routing domain"). This needs re-writing to clarify what you want to achieve and to bring it in line with 5250. Note that the 4th para of Section 2.2 seems to have this right. === Nits Has Trilok's affiliation changed? -- Capitalise the document title --- Expand acronyms in the Abstract if they do not appear with an asterisk in http://www.rfc-editor.org/materials/abbrev.expansion.txt --- Throughout the text, expand acronyms on first use if they do not appear within http://www.rfc-editor.org/materials/abbrev.expansion.txt with an asterisk. --- Decide whether "discriminator" or "Discriminator" --- In 2.1 you have Value - S-BFD network target discriminator value or values. But there is no "Value" in the figure. --- 2.2 para 2 s/pan/span/ --- 2.2 In the case of domain- wide flooding, i.e., where the originator is sitting in a remote area, the mechanism described in section 5 of [RFC5250] should be used. s/should/SHOULD/? But if you mean should or SHOULD (not MUST), what are the exception cases? --- Thanks, Adrian From nobody Wed Apr 27 06:48:48 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82EEB12D1D3; Wed, 27 Apr 2016 06:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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.996, 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 jV8-zyQCbhUV; Wed, 27 Apr 2016 06:48:40 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 417FB12D152; Wed, 27 Apr 2016 06:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10880; q=dns/txt; s=iport; t=1461764920; x=1462974520; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gCS6tuNkpO1xKA0eXAbCUQmLNoP5Z+v5YCEPc5xdacc=; b=gkxFoIGALqOdj6VM00bIqQFCCFJ6w5JSWedB9uNX4A7xNyHaCX0o0a/6 5HgLC/DAqh09xQRir9/F3xg9HlCU99pXFEoijvEBmxCQw25655TEb/FtB 4/S92f81UUZoCp9z4NHaW55Qw4RK4l/edakI1s2KkWSFLGhkk+j6yY8Zp 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQA0wiBX/4wNJK1UCoM4U30GuWYBD?= =?us-ascii?q?YF1FwuFbQIcgQ84FAEBAQEBAQFlJ4RCAQEEAQEBIBE6CxACAQgUBgImAgICJQs?= =?us-ascii?q?VEAEBBAENBYgqDrJvkTQBAQEBAQEBAQEBAQEBAQEBAQEBAQEVfIhugQKEFQQkg?= =?us-ascii?q?wCCVgWYEAGFe4gbgWdOg3+DKYU0jy8BHgEBQoNrbAEBh24/fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,541,1454976000"; d="scan'208";a="96160230" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2016 13:48:38 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u3RDmcQl021988 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Apr 2016 13:48:38 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 27 Apr 2016 09:48:37 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Wed, 27 Apr 2016 09:48:37 -0400 From: "Acee Lindem (acee)" To: Adrian Farrel , "rtg-ads@ietf.org" Thread-Topic: [OSPF] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt Thread-Index: AdGghcVG0QuPS2RxQ6ajDKPyM64RjwABboyA Date: Wed, 27 Apr 2016 13:48:37 +0000 Message-ID: References: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk> In-Reply-To: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-ospf-sbfd-discriminator.all@ietf.org" , "rtg-dir@ietf.org" , "ospf@ietf.org" Subject: Re: [OSPF] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 13:48:46 -0000 SGkgQWRyaWFuLCANCg0KVGhhbmtzIGZvciB0aGUgdGhvcm91Z2ggcmV2aWV3LiBTZWUgb25lIGlu bGluZS4NCg0KT24gNC8yNy8xNiwgOToxMSBBTSwgIk9TUEYgb24gYmVoYWxmIG9mIEFkcmlhbiBG YXJyZWwiDQo8b3NwZi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBhZHJpYW5Ab2xkZG9n LmNvLnVrPiB3cm90ZToNCg0KPkhlbGxvLA0KPg0KPkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRo ZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0Lg0KPlRoZQ0KPlJv dXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmct cmVsYXRlZCBkcmFmdHMNCj5hcw0KPnRoZXkgcGFzcyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFu ZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBvbiBzcGVjaWFsDQo+cmVxdWVzdC4gVGhlIHB1 cnBvc2Ugb2YgdGhlIHJldmlldyBpcyB0byBwcm92aWRlIGFzc2lzdGFuY2UgdG8gdGhlDQo+Um91 dGluZyBBRHMuDQo+Rm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgRGlyZWN0 b3JhdGUsIHBsZWFzZSBzZWUNCj5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90 cmFjL3dpa2kvUnRnRGlyDQo+DQo+QWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmls eSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0DQo+d291bGQgYmUgaGVscGZ1bCBp ZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBiZWZvcmUgb3IgYWxvbmcgd2l0aCBhbnkgSUVURg0K Pkxhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZlIHRvIHJlc29s dmUgdGhlbSB0aHJvdWdoDQo+ZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQo+ DQo+RG9jdW1lbnQ6IGRyYWZ0LWlldGYtb3NwZi1zYmZkLWRpc2NyaW1pbmF0b3ItMDQudHh0DQo+ IFJldmlld2VyOiBBZHJpYW4gRmFycmVsDQo+IFJldmlldyBEYXRlOiAyNyBBcHJpbCAyMDE2DQo+ IElFVEYgTEMgRW5kIERhdGU6IDI2IEFwcmlsIDIwMTYNCj4gSW50ZW5kZWQgU3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sNCj4NCj5TdW1tYXJ5OiANCj5JIGhhdmUgc29tZSBtaW5vciBjb25jZXJucyBh Ym91dCB0aGlzIGRvY3VtZW50IHRoYXQgSSB0aGluayBzaG91bGQgYmUNCj5yZXNvbHZlZCBiZWZv cmUgcHVibGljYXRpb24uDQo+DQo+Q29tbWVudHM6IA0KPg0KPlRoaXMgaXMgYSBzaW1wbGUgZG9j dW1lbnQgdGhhdCBkb2Vzbid0IHJlcXVpcmUgbXVjaCB0byBpbXBsZW1lbnQgb3INCj51bmRlcnN0 YW5kLiAgSXQgd2FzIGRpc2FwcG9pbnRpbmcsIGhvd2V2ZXIsIHRvIGZpbmQgYSBsYXJnZSBudW1i ZXIgb2YNCj5zbWFsbCBpc3N1ZXMgYW5kIG5pdHMuICBJIGRvbid0IGJlbGlldmUgYW55IG9mIHRo ZXNlIGFyZSBibG9ja2luZyB0bw0KPnRoZSB1dGlsaXR5IG9mIHRoZSBkb2N1bWVudCBhbmQgaWYg aXQgd2VudCBmb3IgcHVibGljYXRpb24gaW4gaXRzDQo+Y3VycmVudCBzdGF0ZSBpdCB3b3VsZCBu b3QgYmUgaGFybWZ1bC4gIEJ1dCBpbiB0aGUgaW50ZXJlc3Qgb2YgbWFraW5nDQo+b3VyIGRvY3Vt ZW50cyB1c2VmdWwgYW5kIGFjY2Vzc2libGUsIGFuZCBmb3IgdGhlIHB1cnBvc2Ugb2YgZWxpbWlu YXRpbmcNCj5hbGwgcG9zc2libGUgaW50ZXJvcGVyYWJpbGl0eSBhbmQgZGVwbG95bWVudCwgSSB0 aGluayBpdCB3b3VsZCBiZQ0KPnZhbHVhYmxlIHRvIGNsZWFuIHVwIHRoZSBpc3N1ZXMgSSBoYXZl IGxpc3RlZC4NCj4NCj5NYWpvciBJc3N1ZXM6IA0KPk5vIG1ham9yIGlzc3VlcyBmb3VuZC4NCj4N Cj5NaW5vciBJc3N1ZXM6IA0KPg0KPkkgc2hvdWxkIGxpa2UgdG8gc2VlIHNvbWUgc21hbGwgYW1v dW50IG9mIHRleHQgb24gdGhlIHNjYWxpbmcgaW1wYWN0IG9uDQo+T1NQRi4gMS4gSG93IG11Y2gg YWRkaXRpb25hbCBpbmZvcm1hdGlvbiB3aWxsIGltcGxlbWVudGF0aW9ucyBoYXZlIHRvDQo+c3Rv cmUgcGVyIG5vZGUvbGluayBpbiB0aGUgbmV0d29yaz8gMi4gV2hhdCBpcyB0aGUgZXhwZWN0ZWQg Y2h1cm4gaW4NCj5MU0FzIGludHJvZHVjZWQgYnkgdGhpcyBtZWNoYW5pc20gKGVzcGVjaWFsbHkg d2hlbiB0aGUgUmVmbGVjdG9yIGlzDQo+dHVybmVkIG9uIGFuZCBvZmYpPw0KPg0KPkluIHRoZSBz ZWNvbmQgY2FzZSB0aGVyZSBpcyBhIHNlY3VyaXR5IGltcGxpY2F0aW9uIGFzIHdlbGwuIENhbiBJ IERvUw0KPnRoZSByb3V0aW5nIHN5c3RlbSBieSB0b2dnbGluZyBzb21lIEJGRCBSZWZsZWN0b3Jz PyBOZWVkcyB0ZXh0IQ0KPg0KPllvdSAqZG8qIGhhdmUuLi4NCj4gICBBIGNoYW5nZSBpbiBpbmZv cm1hdGlvbiBpbiB0aGUgUy1CRkQgRGlzY3JpbWluYXRvciBUTFYgTVVTVCBOT1QNCj4gICB0cmln Z2VyIGFueSBTUEYgY29tcHV0YXRpb24gYXQgYSByZWNlaXZpbmcgcm91dGVyLg0KPi4uLndoaWNo IGlzIGEgaGVscC4NCj4NCj4tLS0NCj4NCj5TZWN0aW9uIDEgaGFzDQo+DQo+ICAgVGhpcyBpcyBh Y2hpZXZlZCBieSB1c2luZyB1bmlxdWUNCj4gICBuZXR3b3JrLXdpZGUgZGlzY3JpbWluYXRvcnMg dG8gaWRlbnRpZnkgdGhlIE5ldHdvcmsgVGFyZ2V0cyAoZS5nLiwgSVANCj4gICBhZGRyZXNzZXMp Lg0KPg0KPllvdSBtYXkgYmUgYXdhcmUgb2YgSVB2NiA6LSkNCj4NCj5BbHRob3VnaCAyLjEgZ2l2 ZXMgc29tZSBoaW50cyBvbiB0aGUgc2l6ZSBvZiBhIGRpc2NyaW1pbmF0b3IsIEkgaGFkIHRvDQo+ Z28gYmFjayB0byA1ODgwIHRvIGNoZWNrIHRoYXQgKmFsbCogZGlzY3JpbWluYXRvcnMgYXJlIGV4 YWN0bHkgNCBvY3RldHMuDQo+U28gc2F5aW5nICJlLmcuLCBJUCBhZGRyZXNzZXMiIGlzIGF0IGJl c3QgY29uZnVzaW5nLg0KPg0KPkJUVywgZHJhZnQtaWV0Zi1iZmQtc2VhbWxlc3MtYmFzZSBhbmQg ZHJhZnQtaWV0Zi1iZmQtc2VhbWxlc3MtaXAgZG9uJ3QNCj5naXZlIGFueSBoaW50cyBvbiB0aGlz Lg0KPg0KPk9oLCBhbmQgd2hhdCBpcyAibmV0d29yay13aWRlIj8NCj4NCj5JIHN1Z2dlc3QuLi4N Cj4NCj4gICBUaGlzIGlzIGFjaGlldmVkIGJ5IHVzaW5nIGZvdXItb2N0ZXQgZGlzY3JpbWluYXRv cnMgYXMgZGVmaW5lZCBpbg0KPiAgIFtSRkM1ODgwXSB0byBpZGVudGlmeSB0aGUgTmV0d29yayBU YXJnZXRzLg0KPg0KPi0tLQ0KPg0KPkluIFNlY3Rpb24gMiB5b3UgaGF2ZQ0KPiAgIFVwb24gcmVj ZWlwdCBvZiB0aGUgVExWLCBhDQo+ICAgcm91dGVyIG1heSBkZWNpZGUgdG8gaWdub3JlIHRoaXMg VExWIG9yIGluc3RhbGwgdGhlIFMtQkZEDQo+ICAgZGlzY3JpbWluYXRvciBpbiBCRkQgVGFyZ2V0 IElkZW50aWZpZXIgVGFibGUuDQo+DQo+SSB0aGluayAiaWdub3JlIiBpcyBhbWJpZ3VvdXMuIFlv dSBuZWVkIHRvIGJlIHZlcnkgY2xlYXIgdGhhdCAiaWdub3JlIg0KPm1lYW5zOg0KPi0gdGFrZSBu byBsb2NhbCBhY3Rpb24NCj4tIHJldGFpbiB0aGUgVExWIGluIHRoZSBvcGFxdWUgTFNBDQo+LSBj b250aW51ZSB0byBhZHZlcnRpc2UgdGhlIG9wYXF1ZSBMU0EgYWNjb3JkaW5nIHRvIGl0cyBzY29w ZQ0KDQoNClNpbmNlIHRoZSBjb250ZW50IG9mIG9wYXF1ZSBMU0FzIGFyZSwgaW4gZmFjdCwgb3Bh cXVlIHRvIHRoZSBPU1BGDQpwcm90b2NvbCwgaW1wbGVtZW50YXRpb25zIHNob3VsZCBub3QgbW9k aWZ5IHRoZSBjb250ZW50cyBvciBmaWx0ZXIgdGhlDQpMU0EuIA0KDQpUaGFua3MsDQpBY2VlDQoN Cj4NCj5JbiBTZWN0aW9uIDMgeW91IGFsc28gaGF2ZQ0KPiAgIEEgcm91dGVyIG5vdCBzdXBwb3J0 aW5nIHRoZSBTLUJGRCBEaXNjcmltaW5hdG9yIFRMViB3aWxsIGp1c3QNCj4gICBzaWxlbnRseSBp Z25vcmUgdGhlIFRMViBhcyBzcGVjaWZpZWQgaW4gW1JGQzc3NzBdLg0KPg0KPkFtIEkgbWlzc2lu ZyBzb21ldGhpbmcgd2hlbiBJIHJlYWQgNzc3MD8gSSBkb24ndCBmaW5kIGFueXRoaW5nIGFib3V0 DQo+aGFuZGxpbmcgdW5rbm93biBUTFZzLg0KPg0KPi0tLQ0KPg0KPlNlY3Rpb24gMiBwYXJhIDMN Cj5zL3N1cGVyc2V0L3VuaW9uLyANCj4oInN1cGVyc2V0IiB3b3VsZCBhbGxvdyB5b3UgdG8gaW5j bHVkZSBhbnkgb3RoZXIgZGlzY3JpbWluYXRvcnMhKQ0KPg0KPi0tLQ0KPg0KPlNlY3Rpb24gMi4x DQo+VG8gYmUgdG90YWxseSB1bmFtYmlndW91cy4uLg0KPk9MRA0KPiAgIExlbmd0aCAtIFRvdGFs IGxlbmd0aCBvZiB0aGUgZGlzY3JpbWluYXRvciAoVmFsdWUgZmllbGQpIGluIG9jdGV0cywNCj4g ICBub3QgaW5jbHVkaW5nIHRoZSBvcHRpb25hbCBwYWRkaW5nLiAgVGhlIExlbmd0aCBpcyBhIG11 bHRpcGxlIG9mIDQNCj4gICBvY3RldHMsIGFuZCBjb25zZXF1ZW50bHkgc3BlY2lmaWVzIGhvdyBt YW55IERpc2NyaW1pbmF0b3JzIGFyZQ0KPiAgIGluY2x1ZGVkIGluIHRoZSBUTFYuDQo+TkVXDQo+ ICAgTGVuZ3RoIC0gVG90YWwgbGVuZ3RoIG9mIGFsbCBkaXNjcmltaW5hdG9yIGluIHRoZSBWYWx1 ZSBmaWVsZCBpbg0KPiAgIG9jdGV0cywgbm90IGluY2x1ZGluZyB0aGUgb3B0aW9uYWwgcGFkZGlu Zy4gIFRoZSBMZW5ndGggaXMgYSBtdWx0aXBsZQ0KPiAgIG9mIDQgb2N0ZXRzLCBhbmQgY29uc2Vx dWVudGx5IHNwZWNpZmllcyBob3cgbWFueSBEaXNjcmltaW5hdG9ycyBhcmUNCj4gICBpbmNsdWRl ZCBpbiB0aGUgVExWLg0KPkVORA0KPg0KPkhvd2V2ZXIgKCEpIGFyZSB5b3Ugc3VyZSB0aGF0IHlv dSBjYW4gaW5jbHVkZSBvcHRpb25hbCBwYWRkaW5nPyBJIHRoaW5rDQo+dGhhdCA3NzcwIHVzZXMg cGFkZGluZyB0byB0YWtlIHRoZSBWIGZpZWxkIHVwIHRvIGEgNCBvY3RldCBib3VuZGFyeS4NCj5T aW5jZSBhbGwgb2YgeW91ciBkaXNjcmltaW5hdG9ycyBhcmUgZXhhY3RseSBhIG11bHRpcGxlIG9m IDQgb2N0ZXRzIGl0DQo+c2VlbXMgdGhhdCB0aGVyZSB3aWxsIG5ldmVyIGJlIGFueSBwYWRkaW5n IGFuZCBpdCB3b3VsZCBiZSBsZXNzDQo+Y29uZnVzaW5nIHRvIHdyaXRlLi4uDQo+DQo+TkVXDQo+ ICAgTGVuZ3RoIC0gVG90YWwgbGVuZ3RoIG9mIGFsbCBkaXNjcmltaW5hdG9ycyBpbiB0aGUgVExW IGNvdW50ZWQgaW4NCj4gICBvY3RldHMuICBUaGUgTGVuZ3RoIGlzIGEgbXVsdGlwbGUgb2YgNCBv Y3RldHMsIGFuZCBjb25zZXF1ZW50bHkNCj4gICBzcGVjaWZpZXMgaG93IG1hbnkgRGlzY3JpbWlu YXRvcnMgYXJlIGluY2x1ZGVkIGluIHRoZSBUTFYuDQo+RU5EDQo+DQo+LS0tDQo+DQo+QXQgdGhl IGVuZCBvZiBzZWN0aW9uIDIuMSB5b3UgaGF2ZQ0KPg0KPiAgIFMtQkZEIGRpc2NyaW1pbmF0b3Ig aXMgYXNzb2NpYXRlZCB3aXRoIHRoZQ0KPiAgIEJGRCBUYXJnZXQgSWRlbnRpZmllciB0eXBlLCB0 aGF0IGFsbG93cyBkZW11bHRpcGxleGluZyB0byBhIHNwZWNpZmljDQo+ICAgdGFzayBvciBzZXJ2 aWNlLg0KPg0KPlRoaXMgaXMgYSB3b25kZXJmdWxseSB0aHJvdy1hd2F5IHN0YXRlbWVudCB3aXRo IG5vIGNvbnRleHQgYW5kIG5vDQo+ZnVydGhlciBleHBsYW5hdGlvbiBpbiB0aGUgZG9jdW1lbnQg dGhhdCBJIGNvdWxkIGZpbmQuIE1heWJlIHRoaXMgaXMNCj5qdXN0IG1pc3NpbmcgYSByZWZlcmVu Y2UgdG8gYW5vdGhlciBkb2N1bWVudCwgb3IgbWF5YmUgaXQgbmVlZHMgc29tZQ0KPmNsYXJpZmlj YXRpb24uDQo+DQo+LS0tDQo+DQo+U2VjdGlvbiAyLjIgaGFzDQo+DQo+ICAgVGhlIGZsb29kaW5n IHNjb3BlIGZvciBTLUJGRCBEaXNjcmltaW5hdG9yIGluZm9ybWF0aW9uIGFkdmVydGlzZWQNCj4g ICB0aHJvdWdoIE9TUEYgY2FuIGJlIGxpbWl0ZWQgdG8gb25lIG9yIG1vcmUgT1NQRiBhcmVhcywg b3IgY2FuIGJlDQo+ICAgZXh0ZW5kZWQgYWNyb3NzIHRoZSBlbnRpcmUgT1NQRiByb3V0aW5nIGRv bWFpbi4NCj4NCj4gICBOb3RlIHRoYXQgdGhlIFMtQkZEIHNlc3Npb24gbWF5IGJlIHJlcXVpcmVk IHRvIHBhbiBtdWx0aXBsZSBhcmVhcywgaW4NCj4gICB3aGljaCBjYXNlIHRoZSBmbG9vZGluZyBz Y29wZSBtYXkgY29tcHJpc2UgdGhlc2UgYXJlYXMuICBUaGlzIGNvdWxkDQo+ICAgYmUgdGhlIGNh c2UgZm9yIGFuIEFCUiwgZm9yIGluc3RhbmNlLCBhZHZlcnRpc2luZyB0aGUgUy1CRkQNCj4gICBE aXNjcmltaW5hdG9yIGluZm9ybWF0aW9uIHdpdGhpbiB0aGUgYmFja2JvbmUgYXJlYSBhbmQvb3Ig YSBzdWJzZXQgb2YNCj4gICBpdHMgYXR0YWNoZWQgSUdQIGFyZWEocykuDQo+DQo+QXMgSSB1bmRl cnN0YW5kIGZsb29kaW5nIHNjb3BlIHRoZSBvcHRpb25zIGZvciBPcGFxdWUgTFNBcyAoc2VlIDUy NTApDQo+YXJlOg0KPg0KPiAgIG8gIExpbmstc3RhdGUgdHlwZS05IGRlbm90ZXMgYSBsaW5rLWxv Y2FsIHNjb3BlLg0KPg0KPiAgIG8gIExpbmstc3RhdGUgdHlwZS0xMCBkZW5vdGVzIGFuIGFyZWEt bG9jYWwgc2NvcGUuDQo+DQo+ICAgbyAgTGluay1zdGF0ZSB0eXBlLTExIGRlbm90ZXMgdGhhdCB0 aGUgTFNBIGlzIGZsb29kZWQgdGhyb3VnaG91dCB0aGUNCj4gICAgICBBdXRvbm9tb3VzIFN5c3Rl bSAoQVMpLg0KPg0KPllvdXIgdGV4dCBzZWVtcyB0byBpbXBseSBzb21ldGhpbmcgZGlmZmVyZW50 LiBJbiBwYXJ0aWN1bGFyLCB5b3Ugc2VlbSB0bw0KPmJlIHN1Z2dlc3RpbmcgdGhhdCBJIGNhbiBo YXZlIGEgc2NvcGUgdGhhdCBpcyBncmVhdGVyIHRoYW4gb25lIGFyZWEgYnV0DQo+bGVzcyB0aGFu IHRoZSB3aG9sZSBBUyAoYXNzdW1pbmcgIndob2xlIEFTIiA9PSAiZW50aXJlIE9TUEYgcm91dGlu Zw0KPmRvbWFpbiIpLg0KPg0KPlRoaXMgbmVlZHMgcmUtd3JpdGluZyB0byBjbGFyaWZ5IHdoYXQg eW91IHdhbnQgdG8gYWNoaWV2ZSBhbmQgdG8gYnJpbmcNCj5pdCBpbiBsaW5lIHdpdGggNTI1MC4N Cj4NCj5Ob3RlIHRoYXQgdGhlIDR0aCBwYXJhIG9mIFNlY3Rpb24gMi4yIHNlZW1zIHRvIGhhdmUg dGhpcyByaWdodC4NCj4NCj49PT0NCj4gICAgICAgICAgICAgICAgICANCj5OaXRzDQo+DQo+SGFz IFRyaWxvaydzIGFmZmlsaWF0aW9uIGNoYW5nZWQ/DQo+LS0NCj5DYXBpdGFsaXNlIHRoZSBkb2N1 bWVudCB0aXRsZQ0KPi0tLQ0KPkV4cGFuZCBhY3JvbnltcyBpbiB0aGUgQWJzdHJhY3QgaWYgdGhl eSBkbyBub3QgYXBwZWFyIHdpdGggYW4gYXN0ZXJpc2sNCj5pbiBodHRwOi8vd3d3LnJmYy1lZGl0 b3Iub3JnL21hdGVyaWFscy9hYmJyZXYuZXhwYW5zaW9uLnR4dA0KPi0tLQ0KPlRocm91Z2hvdXQg dGhlIHRleHQsIGV4cGFuZCBhY3JvbnltcyBvbiBmaXJzdCB1c2UgaWYgdGhleSBkbyBub3QgYXBw ZWFyDQo+d2l0aGluIGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvbWF0ZXJpYWxzL2FiYnJldi5l eHBhbnNpb24udHh0IHdpdGggYW4NCj5hc3Rlcmlzay4NCj4tLS0NCj5EZWNpZGUgd2hldGhlciAi ZGlzY3JpbWluYXRvciIgb3IgIkRpc2NyaW1pbmF0b3IiDQo+LS0tDQo+SW4gMi4xIHlvdSBoYXZl DQo+ICAgVmFsdWUgLSBTLUJGRCBuZXR3b3JrIHRhcmdldCBkaXNjcmltaW5hdG9yIHZhbHVlIG9y IHZhbHVlcy4NCj5CdXQgdGhlcmUgaXMgbm8gIlZhbHVlIiBpbiB0aGUgZmlndXJlLg0KPi0tLQ0K PjIuMiBwYXJhIDINCj5zL3Bhbi9zcGFuLw0KPi0tLQ0KPjIuMg0KPiAgIEluIHRoZSBjYXNlIG9m IGRvbWFpbi0NCj4gICB3aWRlIGZsb29kaW5nLCBpLmUuLCB3aGVyZSB0aGUgb3JpZ2luYXRvciBp cyBzaXR0aW5nIGluIGEgcmVtb3RlDQo+ICAgYXJlYSwgdGhlIG1lY2hhbmlzbSBkZXNjcmliZWQg aW4gc2VjdGlvbiA1IG9mIFtSRkM1MjUwXSBzaG91bGQgYmUNCj4gICB1c2VkLg0KPnMvc2hvdWxk L1NIT1VMRC8/DQo+QnV0IGlmIHlvdSBtZWFuIHNob3VsZCBvciBTSE9VTEQgKG5vdCBNVVNUKSwg d2hhdCBhcmUgdGhlIGV4Y2VwdGlvbg0KPmNhc2VzPw0KPi0tLQ0KPg0KPlRoYW5rcywNCj5BZHJp YW4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pk9TUEYgbWFpbGluZyBsaXN0DQo+T1NQRkBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb3NwZg0KDQo= From nobody Wed Apr 27 09:19:34 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BE512D51F; Wed, 27 Apr 2016 09:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 WWKtZveMIKG6; Wed, 27 Apr 2016 09:19:23 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 820CB12D190; Wed, 27 Apr 2016 09:19:21 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id v145so21317271oie.0; Wed, 27 Apr 2016 09:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=7ajTFKxyQTyyg3qZheSROaqTFS7NQs9Ty5iRItjZRko=; b=xibVQZ2xOzIW+G59JZOBSmQR2FZUcGZKHzFQ2EUXP7oVv15G8GFuzrArefyFsasKYY mxorBulydEbyEFPPKFnE3GlIymLe2qEEwlmTmyh7UvgxLXHF8ns+CMszZl0HcZyJ5Rey H+0JB3Ufgr+1JBjpgc8azedgnRyBMCJyE4Zn7xnCS6Q016A7cjqZnWdyUVVDnOtldbD6 /4yrP8kkAHzFoZHJV5SPmnCIsyX8WwUNKFlmBsGbLTa+JL9SwqZNUgpg3eh0HoZCLSwS g3XdDotvVHz8J/vMb4/+bMcOMTMUJtRxIhroWCqhjPUrIkt2RAHy+1hwtIanjrov61af KNqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=7ajTFKxyQTyyg3qZheSROaqTFS7NQs9Ty5iRItjZRko=; b=JpCTOX1ywb/D6wxrPZrmBxE1xnuTeja9ZxGRM9jnUKZ/OXzH63ZoqFRFSlNQJZlLby eBPSgeHhiWir2jp+643Dpta+y/H8Zxcpr60KcfXgRyZqoJVKkcHjE2xgEAa0z4ZBAA9r bOQZ7NQnF2tzLYCbGIOYrZ7syCn6rt3ZGPGmDTpzAMisEjyr7nrZjF4mbLAK9lNc3DED aypoT66tMs3NVvpYP6kdvk6KMTysKHfW1m1QK+DTrCyvCmJuZ8bFlZEuXZgJstzG+uUX Xqxd64cc9Ok4e7Y4nGryzUWViC7UvHB7JxfJW73eM4+FgXy/RZ2LqGCAA4faK2p0IslM /gMw== X-Gm-Message-State: AOPr4FXLJkixQzXLasZqIBnnP/g9kCAr2C+AHFLnywvBk4FNsyq3lV54D1oddVwjcwAJiNp8aD5N1VP/+OWNvw== MIME-Version: 1.0 X-Received: by 10.157.45.81 with SMTP id v75mr4269589ota.85.1461773960618; Wed, 27 Apr 2016 09:19:20 -0700 (PDT) Received: by 10.60.115.168 with HTTP; Wed, 27 Apr 2016 09:19:20 -0700 (PDT) In-Reply-To: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk> References: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk> Date: Wed, 27 Apr 2016 12:19:20 -0400 Message-ID: From: Alia Atlas To: Adrian Farrel Content-Type: multipart/alternative; boundary=001a113e9f66aa5139053179c542 Archived-At: Cc: "" , "rtg-dir@ietf.org" , draft-ietf-ospf-sbfd-discriminator.all@ietf.org, OSPF List Subject: Re: [OSPF] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 16:19:25 -0000 --001a113e9f66aa5139053179c542 Content-Type: text/plain; charset=UTF-8 Adrian, Thank you very much for the thorough review! Authors & Shepherd, Please go through and update this draft ASAP. It is on the IESG telechat on May 5 and is/will be reviewed very soon. Thanks, Alia On Wed, Apr 27, 2016 at 9:11 AM, Adrian Farrel wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The > Routing Directorate seeks to review all routing or routing-related drafts > as > they pass through IETF last call and IESG review, and sometimes on special > request. The purpose of the review is to provide assistance to the Routing > ADs. > For more information about the Routing Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them before or along with any IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-ospf-sbfd-discriminator-04.txt > Reviewer: Adrian Farrel > Review Date: 27 April 2016 > IETF LC End Date: 26 April 2016 > Intended Status: Standards Track > > Summary: > I have some minor concerns about this document that I think should be > resolved before publication. > > Comments: > > This is a simple document that doesn't require much to implement or > understand. It was disappointing, however, to find a large number of > small issues and nits. I don't believe any of these are blocking to > the utility of the document and if it went for publication in its > current state it would not be harmful. But in the interest of making > our documents useful and accessible, and for the purpose of eliminating > all possible interoperability and deployment, I think it would be > valuable to clean up the issues I have listed. > > Major Issues: > No major issues found. > > Minor Issues: > > I should like to see some small amount of text on the scaling impact on > OSPF. 1. How much additional information will implementations have to > store per node/link in the network? 2. What is the expected churn in > LSAs introduced by this mechanism (especially when the Reflector is > turned on and off)? > > In the second case there is a security implication as well. Can I DoS > the routing system by toggling some BFD Reflectors? Needs text! > > You *do* have... > A change in information in the S-BFD Discriminator TLV MUST NOT > trigger any SPF computation at a receiving router. > ...which is a help. > > --- > > Section 1 has > > This is achieved by using unique > network-wide discriminators to identify the Network Targets (e.g., IP > addresses). > > You may be aware of IPv6 :-) > > Although 2.1 gives some hints on the size of a discriminator, I had to > go back to 5880 to check that *all* discriminators are exactly 4 octets. > So saying "e.g., IP addresses" is at best confusing. > > BTW, draft-ietf-bfd-seamless-base and draft-ietf-bfd-seamless-ip don't > give any hints on this. > > Oh, and what is "network-wide"? > > I suggest... > > This is achieved by using four-octet discriminators as defined in > [RFC5880] to identify the Network Targets. > > --- > > In Section 2 you have > Upon receipt of the TLV, a > router may decide to ignore this TLV or install the S-BFD > discriminator in BFD Target Identifier Table. > > I think "ignore" is ambiguous. You need to be very clear that "ignore" > means: > - take no local action > - retain the TLV in the opaque LSA > - continue to advertise the opaque LSA according to its scope > > In Section 3 you also have > A router not supporting the S-BFD Discriminator TLV will just > silently ignore the TLV as specified in [RFC7770]. > > Am I missing something when I read 7770? I don't find anything about > handling unknown TLVs. > > --- > > Section 2 para 3 > s/superset/union/ > ("superset" would allow you to include any other discriminators!) > > --- > > Section 2.1 > To be totally unambiguous... > OLD > Length - Total length of the discriminator (Value field) in octets, > not including the optional padding. The Length is a multiple of 4 > octets, and consequently specifies how many Discriminators are > included in the TLV. > NEW > Length - Total length of all discriminator in the Value field in > octets, not including the optional padding. The Length is a multiple > of 4 octets, and consequently specifies how many Discriminators are > included in the TLV. > END > > However (!) are you sure that you can include optional padding? I think > that 7770 uses padding to take the V field up to a 4 octet boundary. > Since all of your discriminators are exactly a multiple of 4 octets it > seems that there will never be any padding and it would be less > confusing to write... > > NEW > Length - Total length of all discriminators in the TLV counted in > octets. The Length is a multiple of 4 octets, and consequently > specifies how many Discriminators are included in the TLV. > END > > --- > > At the end of section 2.1 you have > > S-BFD discriminator is associated with the > BFD Target Identifier type, that allows demultiplexing to a specific > task or service. > > This is a wonderfully throw-away statement with no context and no > further explanation in the document that I could find. Maybe this is > just missing a reference to another document, or maybe it needs some > clarification. > > --- > > Section 2.2 has > > The flooding scope for S-BFD Discriminator information advertised > through OSPF can be limited to one or more OSPF areas, or can be > extended across the entire OSPF routing domain. > > Note that the S-BFD session may be required to pan multiple areas, in > which case the flooding scope may comprise these areas. This could > be the case for an ABR, for instance, advertising the S-BFD > Discriminator information within the backbone area and/or a subset of > its attached IGP area(s). > > As I understand flooding scope the options for Opaque LSAs (see 5250) > are: > > o Link-state type-9 denotes a link-local scope. > > o Link-state type-10 denotes an area-local scope. > > o Link-state type-11 denotes that the LSA is flooded throughout the > Autonomous System (AS). > > Your text seems to imply something different. In particular, you seem to > be suggesting that I can have a scope that is greater than one area but > less than the whole AS (assuming "whole AS" == "entire OSPF routing > domain"). > > This needs re-writing to clarify what you want to achieve and to bring > it in line with 5250. > > Note that the 4th para of Section 2.2 seems to have this right. > > === > > Nits > > Has Trilok's affiliation changed? > -- > Capitalise the document title > --- > Expand acronyms in the Abstract if they do not appear with an asterisk > in http://www.rfc-editor.org/materials/abbrev.expansion.txt > --- > Throughout the text, expand acronyms on first use if they do not appear > within http://www.rfc-editor.org/materials/abbrev.expansion.txt with an > asterisk. > --- > Decide whether "discriminator" or "Discriminator" > --- > In 2.1 you have > Value - S-BFD network target discriminator value or values. > But there is no "Value" in the figure. > --- > 2.2 para 2 > s/pan/span/ > --- > 2.2 > In the case of domain- > wide flooding, i.e., where the originator is sitting in a remote > area, the mechanism described in section 5 of [RFC5250] should be > used. > s/should/SHOULD/? > But if you mean should or SHOULD (not MUST), what are the exception > cases? > --- > > Thanks, > Adrian > > --001a113e9f66aa5139053179c542 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adrian,

Thank you very much for the tho= rough review!

Authors & Shepherd,
Please go through and update this draft ASAP.=C2=A0 It is on t= he IESG telechat on May 5
and is/will be reviewed very soon.

Thanks,
Alia

On Wed, Apr 27, 2016 at 9:11 AM, Adri= an Farrel <adrian@olddog.co.uk> wrote:
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 a= s
they pass through IETF last call and IESG review, and sometimes on special<= br> request. The purpose of the review is to provide assistance to the Routing = ADs.
For more information about the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/Rt= gDir

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

Document: draft-ietf-ospf-sbfd-discriminator-04.txt
=C2=A0Reviewer: Adrian Farrel
=C2=A0Review Date: 27 April 2016
=C2=A0IETF LC End Date: 26 April 2016
=C2=A0Intended Status: Standards Track

Summary:
I have some minor concerns about this document that I think should be
resolved before publication.

Comments:

This is a simple document that doesn't require much to implement or
understand.=C2=A0 It was disappointing, however, to find a large number of<= br> small issues and nits.=C2=A0 I don't believe any of these are blocking = to
the utility of the document and if it went for publication in its
current state it would not be harmful.=C2=A0 But in the interest of making<= br> our documents useful and accessible, and for the purpose of eliminating
all possible interoperability and deployment, I think it would be
valuable to clean up the issues I have listed.

Major Issues:
No major issues found.

Minor Issues:

I should like to see some small amount of text on the scaling impact on
OSPF. 1. How much additional information will implementations have to
store per node/link in the network? 2. What is the expected churn in
LSAs introduced by this mechanism (especially when the Reflector is
turned on and off)?

In the second case there is a security implication as well. Can I DoS
the routing system by toggling some BFD Reflectors? Needs text!

You *do* have...
=C2=A0 =C2=A0A change in information in the S-BFD Discriminator TLV MUST NO= T
=C2=A0 =C2=A0trigger any SPF computation at a receiving router.
...which is a help.

---

Section 1 has

=C2=A0 =C2=A0This is achieved by using unique
=C2=A0 =C2=A0network-wide discriminators to identify the Network Targets (e= .g., IP
=C2=A0 =C2=A0addresses).

You may be aware of IPv6 :-)

Although 2.1 gives some hints on the size of a discriminator, I had to
go back to 5880 to check that *all* discriminators are exactly 4 octets. So saying "e.g., IP addresses" is at best confusing.

BTW, draft-ietf-bfd-seamless-base and draft-ietf-bfd-seamless-ip don't<= br> give any hints on this.

Oh, and what is "network-wide"?

I suggest...

=C2=A0 =C2=A0This is achieved by using four-octet discriminators as defined= in
=C2=A0 =C2=A0[RFC5880] to identify the Network Targets.

---

In Section 2 you have
=C2=A0 =C2=A0Upon receipt of the TLV, a
=C2=A0 =C2=A0router may decide to ignore this TLV or install the S-BFD
=C2=A0 =C2=A0discriminator in BFD Target Identifier Table.

I think "ignore" is ambiguous. You need to be very clear that &qu= ot;ignore"
means:
- take no local action
- retain the TLV in the opaque LSA
- continue to advertise the opaque LSA according to its scope

In Section 3 you also have
=C2=A0 =C2=A0A router not supporting the S-BFD Discriminator TLV will just<= br> =C2=A0 =C2=A0silently ignore the TLV as specified in [RFC7770].

Am I missing something when I read 7770? I don't find anything about handling unknown TLVs.

---

Section 2 para 3
s/superset/union/
("superset" would allow you to include any other discriminators!)=

---

Section 2.1
To be totally unambiguous...
OLD
=C2=A0 =C2=A0Length - Total length of the discriminator (Value field) in oc= tets,
=C2=A0 =C2=A0not including the optional padding.=C2=A0 The Length is a mult= iple of 4
=C2=A0 =C2=A0octets, and consequently specifies how many Discriminators are=
=C2=A0 =C2=A0included in the TLV.
NEW
=C2=A0 =C2=A0Length - Total length of all discriminator in the Value field = in
=C2=A0 =C2=A0octets, not including the optional padding.=C2=A0 The Length i= s a multiple
=C2=A0 =C2=A0of 4 octets, and consequently specifies how many Discriminator= s are
=C2=A0 =C2=A0included in the TLV.
END

However (!) are you sure that you can include optional padding? I think
that 7770 uses padding to take the V field up to a 4 octet boundary.
Since all of your discriminators are exactly a multiple of 4 octets it
seems that there will never be any padding and it would be less
confusing to write...

NEW
=C2=A0 =C2=A0Length - Total length of all discriminators in the TLV counted= in
=C2=A0 =C2=A0octets.=C2=A0 The Length is a multiple of 4 octets, and conseq= uently
=C2=A0 =C2=A0specifies how many Discriminators are included in the TLV.
END

---

At the end of section 2.1 you have

=C2=A0 =C2=A0S-BFD discriminator is associated with the
=C2=A0 =C2=A0BFD Target Identifier type, that allows demultiplexing to a sp= ecific
=C2=A0 =C2=A0task or service.

This is a wonderfully throw-away statement with no context and no
further explanation in the document that I could find. Maybe this is
just missing a reference to another document, or maybe it needs some
clarification.

---

Section 2.2 has

=C2=A0 =C2=A0The flooding scope for S-BFD Discriminator information adverti= sed
=C2=A0 =C2=A0through OSPF can be limited to one or more OSPF areas, or can = be
=C2=A0 =C2=A0extended across the entire OSPF routing domain.

=C2=A0 =C2=A0Note that the S-BFD session may be required to pan multiple ar= eas, in
=C2=A0 =C2=A0which case the flooding scope may comprise these areas.=C2=A0 = This could
=C2=A0 =C2=A0be the case for an ABR, for instance, advertising the S-BFD =C2=A0 =C2=A0Discriminator information within the backbone area and/or a su= bset of
=C2=A0 =C2=A0its attached IGP area(s).

As I understand flooding scope the options for Opaque LSAs (see 5250)
are:

=C2=A0 =C2=A0o=C2=A0 Link-state type-9 denotes a link-local scope.

=C2=A0 =C2=A0o=C2=A0 Link-state type-10 denotes an area-local scope.

=C2=A0 =C2=A0o=C2=A0 Link-state type-11 denotes that the LSA is flooded thr= oughout the
=C2=A0 =C2=A0 =C2=A0 Autonomous System (AS).

Your text seems to imply something different. In particular, you seem to be suggesting that I can have a scope that is greater than one area but
less than the whole AS (assuming "whole AS" =3D=3D "entire O= SPF routing
domain").

This needs re-writing to clarify what you want to achieve and to bring
it in line with 5250.

Note that the 4th para of Section 2.2 seems to have this right.

=3D=3D=3D

Nits

Has Trilok's affiliation changed?
--
Capitalise the document title
---
Expand acronyms in the Abstract if they do not appear with an asterisk
in http://www.rfc-editor.org/materials/abbre= v.expansion.txt
---
Throughout the text, expand acronyms on first use if they do not appear
within http://www.rfc-editor.org/materials/a= bbrev.expansion.txt with an
asterisk.
---
Decide whether "discriminator" or "Discriminator"
---
In 2.1 you have
=C2=A0 =C2=A0Value - S-BFD network target discriminator value or values. But there is no "Value" in the figure.
---
2.2 para 2
s/pan/span/
---
2.2
=C2=A0 =C2=A0In the case of domain-
=C2=A0 =C2=A0wide flooding, i.e., where the originator is sitting in a remo= te
=C2=A0 =C2=A0area, the mechanism described in section 5 of [RFC5250] should= be
=C2=A0 =C2=A0used.
s/should/SHOULD/?
But if you mean should or SHOULD (not MUST), what are the exception
cases?
---

Thanks,
Adrian


--001a113e9f66aa5139053179c542-- From nobody Wed Apr 27 10:11:24 2016 Return-Path: X-Original-To: ospf@ietf.org Delivered-To: ospf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A86E12DA39; Wed, 27 Apr 2016 10:11:21 -0700 (PDT) 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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160427171121.25289.68230.idtracker@ietfa.amsl.com> Date: Wed, 27 Apr 2016 10:11:21 -0700 Archived-At: Cc: ospf@ietf.org Subject: [OSPF] I-D Action: draft-ietf-ospf-segment-routing-extensions-08.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 17:11:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP of the IETF. Title : OSPF Extensions for Segment Routing Authors : Peter Psenak Stefano Previdi Clarence Filsfils Hannes Gredler Rob Shakir Wim Henderickx Jeff Tantsura Filename : draft-ietf-ospf-segment-routing-extensions-08.txt Pages : 32 Date : 2016-04-27 Abstract: Segment Routing (SR) allows 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 and OSPF). This draft describes the OSPF extensions required for Segment Routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-segment-routing-extensions-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 Apr 27 11:34:50 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2911B12B03B; Wed, 27 Apr 2016 11:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 rzQDEfRg-oOB; Wed, 27 Apr 2016 11:34:46 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1D84B12B004; Wed, 27 Apr 2016 11:34:43 -0700 (PDT) Received: from [192.168.1.5] (24-247-68-31.dhcp.trcy.mi.charter.com [24.247.68.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 8BB576118C; Wed, 27 Apr 2016 18:34:41 +0000 (UTC) From: Christian Hopps X-Pgp-Agent: GPGMail 2.6b2 Content-Type: multipart/signed; boundary="Apple-Mail=_AA43EA6F-C0B1-4FE8-A33E-22FABBE743C1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 27 Apr 2016 14:34:40 -0400 Message-Id: <4942DD46-2A03-4B3C-B36E-29A05B81177D@chopps.org> To: rtg-ads@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: rtg-dir@ietf.org, draft-ietf-ospf-ttz.all@ietf.org, ospf@ietf.org Subject: [OSPF] RtgDir review: draft-ietf-ospf-ttz-03 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 18:34:49 -0000 --Apple-Mail=_AA43EA6F-C0B1-4FE8-A33E-22FABBE743C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = =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-ospf-ttz-03 Reviewer: Christian Hopps Review Date: April 26, 2016 IETF LC End Date: unknown Intended Status: Experimental Summary: =3D=3D=3D=3D=3D=3D=3D=3D I have some concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. Comments: =3D=3D=3D=3D=3D=3D=3D=3D=3D While I believe that the document is for the most part readable and understandable, I believe it still requires better or more = definitions, clarifications, and/or additional text before becoming an RFC. Major Issues: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [section "2. Terminology"] - An edge router is defined as a router with internal and external = adjacencies. (and referred to this way later in the text as well). Is this the = actual definition or is it instead when a router has links that are and are = not configured as TTZ internal? This makes a big difference b/c the = former case is very dynamic while the latter is static. One could imagine in the = former case that a router is configured to be within a TTZ and then by = virtue of who it becomes adjacent with determines whether it is internal or = edge. While this makes configuration very simple I think it also has a big = impact on the complexity of the protocol interactions. After reading section 11.1 "Configuring TTZ" which proposes "some = options for configuring a TTZ", it certainly seems that the intention is for = links to be determined to be within a TTZ or not based only on = configuration. If this is indeed the case I think this needs to be stated up front and = very clearly, and I would suggest changing all the text in "2. = Terminology" to talk about configuration instead of adjacencies. For example: "TTZ link or TTZ internal link: a link configured to be inside the = TTZ." "TTZ external link: a link not configured to be within a TTZ" "TTZ internal router: a router configured with only TTZ internal = links." "TTZ external router: a router with no configured TTZ internal = links" "TTZ edge router: a router configured with both TTZ internal and TTZ external links." [section "7. Constructing LSAs for TTZ" paragraph 6 and 7] ... "The cost of the link is the cost of the shortest path from this = TTZ edge router to the other TTZ edge router within the TTZ." "In addition, the LSA may contain a third group of links, which are = the stub links for the loopback addresses inside the TTZ to be accessed by = nodes outside of the TTZ." - So basically every SPF from a TTZ internal topology change can lead = to new edge router LSAs being advertised throughout the area to adjust the = "virtual" routing link costs. This is noteworthy because while you've hidden = state using the TTZ, the dynamics of the network haven't gotten simpler = rather they've gotten more complex, as changes are now cascading rather than = being singular. This is an interesting trade-off choosing perpetual = run-time and protocol complexity in order to avoid the one time cost of new area = creation. Would it be worth actually pointing out these costs of using TTZ? [section "7. Constructing LSAs for TTZ" paragraph 8] "To migrate to a TTZ smoothly, a TTZ edge router virtualizes the = TTZ in two steps. At first, the router updates its normal router LSA by adding = a point-to-point link to each of the other edge routers of the TTZ = and a stub link for each of the loopback addresses in the TTZ to be accessed = outside of the TTZ into the LSA. And then it removes the links configured = as TTZ links from its updated router LSA after sending its updated router = LSA and receiving the updated router LSAs originated by the other TTZ edge = routers for MaxLSAAdvTime or after sending its updated router LSA for MaxLSAGenAdvTime (refer to Appendix A)." In order to be sure I understood this I basically broke it apart and = put it together again with possibly incorrect reductions. I ended up with: To migrate to a TTZ smoothly, a TTZ edge router virtualizes the TTZ = in two steps: Step 1: The router updates its router LSA by adding a = point-to-point link to each of the other known edge routers in the TTZ, and also by = adding the stub links advertised by TTZ internal routers. Step 2: After RMaxLSAAdvTime (.1 seconds) or MaxLSAGenAdvTime (.3 = seconds) remove the TTZ links from its router LSA. [section "10. Computation of Routing Table" The text says to ignore *all* links from a TTZ edge routers router = LSA. This presumably works b/c the SPF is also going to use the advertised TTZ = Router LSA instead. Shouldn't the fact that the SPF should using the new TTZ = Router LSA be stated somewhere as well? Minor Issues: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [section: "Introduction" 2nd paragraph] The initial sentence makes an assertion about complexity and time consumption for area creation. The following sentence does not back = this assertion up but merely describes the act of creating a new area. I = found this less than compelling. [section: "2. Terminology"] This need not be addressed here but it's where I had the question: = Can a TTZ edge router be in more than one TTZ? [section "5.1. Overview of Topology-Transparent Zone" 3rd paragraph ] "In addition to having the functions of an OSPF area", is this = actually the case? That is, is a TTZ really a superset of OSPF area = functionality? I'm pretty sure it is not. [section "5.1. Overview of Topology-Transparent Zone" Bullet 1] "o An OSPF TTZ is virtualized as the TTZ edges connected each = other." This is a very important bullet as it actually will describe what a = TTZ really is. As such I'd suggest more precise text here. For example: "o An OSPF TTZ represents a set of TTZ internal routers as a full = mesh of virtual links between the TTZ edge routers." ? [section "5.1. Overview of Topology-Transparent Zone" Bullet 2] "An OSPF TTZ receives the link state information about the topology outside of the TTZ, stores the information in the TTZ and = floods the information through the TTZ to the routers outside of the TTZ." This bullet is a bit clunky to read. Perhaps something more direct = like: "Non-TTZ link state information is handled as normal (i.e., it is not filtered or modified by a TTZ)" If you want to keep the original text then a couple nits: "An OSPF TTZ receives" =3D> "TTZ Routers receive" "stores the information in the TTZ and floods" =3D> "store the = information, and flood" [section: "6.1. General Format of TTZ LSA" paragraph 3] "A TTZ LSA having an optional TTZ Router TLV is called a TTZ Router = LSA. A TTZ LSA containing a TTZ Options TLV is called a TTZ Control LSA." Can these ever be combined? By naming them distinctly like this, it = seems to be exclusive, if this is the case that should probably be more = clearly defined. In general I think more expansion and clarity here is in order. = Instead of talking about LS Type 10/9 with a note about type 10. Why not discuss = each type: - LS Type 9 "Link local scope" when it is used, and what is optional = and mandatory in it. - LS Type 10 "Area scope" when it is used, and what is optional and = mandatory in it. [section "6.3. TTZ Router TLV" paragraph 1] "The format of a TTZ Router TLV is as follows. It contains the contents of a router LSA." Is this trying to say: "It has the same content as a standard OSPF Router LSA (RFC x-ref) = with the following modifications"? [section "6.3. TTZ Router TLV" TLV content] Given the existence of the TLV-Length, is the "# links" field = redundant? What happens if they correctly correlate? [section "6.4. TTZ Options TLV" "flags"] So "exclusive" =3D> "mutually exclusive"? If this is the case these aren't really flags but rather one of 4 = possible values (I believe in the all 0 case the TLV is not advertised?), and = if so it would be much better to simply define the 4 possible values using 2 = bits. What happens if more than one bit is set to 1? [section "7. Constructing LSAs for TTZ" paragraph 3] This text can be read to indicate that for TTZ internal routers the = router's normal Router LSA content is copied into a TTZ Router TLV, does the = router also advertise its Router LSA as normal or is that then suppressed? = It's not clear to me why this information needs copying, and so I'm wondering = if the text is saying that no TTZ Router TLV is included, and that the TTZ = internal router just advertises it's regular OSPF Router LSA. The text could be more explicit. Also some of my confusion stems from = earlier defining a "TTZ Router LSA" as one containing an "optional TTZ Router = TLV". So when the text here refers to the LSA as a TTZ Router LSA one might = assume that the optional TTZ Router TLV must be present. Perhaps this gets back to my want for better separating and defining the LS Types and contents. [section "7. Constructing LSAs for TTZ" paragraph 4 and 9] "After receiving a trigger to migrate to TTZ such as a TTZ LSA with flag M =3D 1, a TTZ edge router originates its normal router LSA for virtualizing a TTZ, which comprises three groups of links in = general." "To roll back from a TTZ smoothly after receiving a trigger to roll back from TTZ, ..." - Triggers are mentioned a few times throughout the text. I think the triggers meaning, rather than being initially implied, should be = explicit defined early and in 1 location. It isn't until section 11.2 that I = thought I understood what triggers were and how they worked. Actually the triggers are defined in section 6.4, but the text = there never actually uses the word "trigger". I suggest that this be changed so = that it is clear what a trigger is prior to the use of the term. [section "8.1. Discover TTZ Neighbors" paragraph 2] "If two ends of the link have different TTZ IDs, no TTZ adjacency = over the link will be "formed"." - In general I'm somewhat confused about the actual definition of a = TTZ adjacency. How does it compare to a normal protocol adjacency. In = the above case you would have a protocol adjacency I believe, but no TTZ = adjacency? How is this link advertised if the router is a TTZ edge router? [section "8.1. Discover TTZ Neighbors" paragraph 5] The text talks about when (Z=3D=3D0 and there is a TTZ LSA with T=3D1) = or Z=3D=3D1. Where are all the places that T=3D1 is showing up? What about the case when = an adjacency is forming when M=3D1 instead of T=3D1? [section "8.1. Discover TTZ Neighbors" paragraph 7] Since the diagram state Zs are the same, it no longer applies to the = rest of section 8. Is it worthwhile to have a new diagram here for clarity? [section "8.1. Discover TTZ Neighbors" paragraph 8] Here's a mention of "triggers B to migrate", I think you probably = should state explicitly what this means, which I *think* is: "A also sends a D-LSA containing a TTZ Control TLV with M=3D1 to B, = triggering it to migrate." Although this now makes me wonder what does B do on receiving M=3D1 = if it had not received or been configured for T=3D1 yet? [section "8.1. Discover TTZ Neighbors" paragraph 9] I would break this paragraph up to make clear that 2 distinct things = are happening based on 2 different events. So: "When B receives the D-LSA from A and determines they have the same TTZ ID but its Z=3D0 and A's Z=3D1, B sends A all the TTZ LSAs it has = and starts to migrate to TTZ after receiving A's D-LSA with M=3D1. After migration to TTZ, B updates and advertises its LSAs as needed." becomes: "When B receives the D-LSA from A and determines they have the same TTZ ID but its Z=3D0 and A's Z=3D1, B sends A all the TTZ LSAs it = has." "When B receives the D-LSA from A with M=3D1 it starts to migrate to = TTZ. After migration to TTZ, B updates and advertises its LSAs as needed." Does "starts to migrate" here simply means B starts setting it's M=3D1 = as well? What exactly is happening for B to go from "starts to migrate" to = "After migration"? I believe this is indicated by Z=3D0 transitioning to Z=3D1= (is the TTZ Control TLV with M=3D1 also removed from the D-LSA?) What LSAs are being updated and advertised by B here? [section "8.1. Discover TTZ Neighbors" paragraph 10] "After receiving B's D-LSA with Z=3D1, A updates and sends B its = D-LSA by removing the Options TLV. It also updates and advertises its LSAs as needed." What LSAs are being updated and advertised by A here? [section "8.1. Discover TTZ Neighbors" in general] Are D-LSA sent periodically, if so how often, if not when precisely = are they sent? What happens when B changes its TTZ ID or doesn't send a D-LSA? [section "8.1. Discover TTZ Neighbors" Broadcast and NBMA part (i.e., = paragraph 11+)] [section "8.1. Discover TTZ Neighbors" paragraph 12] So the mis-configured router behavior is dependent on when the = mis-configured router is introduced? If introduced prior to any adjacency formation = then its presence will keep all routers from becoming TTZ adjacent, otherwise = only itself will not have become TTZ adjacent? What does mis-configured mean, a different TTZ ID? What about the = lack of the receipt of a D-LSA on the link? How long does the DR wait for receipt = of a D-LSA from each neighbor before deciding it won't be receiving one = and the neighbor is not configured on this link as part of TTZ? [section "8.1. Discover TTZ Neighbors" last paragraph] Is this just saying: "routers only TTZ discover after forming a = normal adjacency"? [section "9.1. Advertisement of LSAs within TTZ" paragraph 2] "Any network LSA generated for a broadcast or NBMA network in a TTZ = is advertised within the TTZ." [nit: And not outside? This is explicit for the router LSA.] What happens when a DR has a mis-configured router on a broadcast = network and thus is not forming a TTZ adjacency with it? It still has a normal = adjacency right? So it no has a network LSA that includes both TTZ and non-TTZ = routers where does it advertise this network LSA? [section "11.2. Smooth Migration to TTZ" paragraph 5] I was confused by many mentions earlier in the document to a router = migrating to a TTZ. I think what paragraph 5 in section 11.2 is saying (in too = many words) is this: "Migrating to a TTZ" means a router advertises a TTZ Control TLV with = M=3D1. A router "Migrates to a TTZ" either when configured to do so or when it receives a TTZ Control TLV with M=3D1. If this is the case then I think something like the above text should = occur earlier in the document. [section "11.3. Adding a Router into TTZ" paragraph 3] I don't understand the intent of this paragraph. Is it just saying = that if TTZ is configured on a link between 2 non-adjacent routers, when they eventually become adjacent they will also form a TTZ adjacency? [section "13. Security Considerations"] This seems a bit weak or perhaps just wrong. Perhaps better would be = to say that TTZ relies on the OSPF security mechanisms in place and has the = same security threat surface? Nits: =3D=3D=3D=3D=3D [section: "2. Terminology" 3rd item] "TTZ external router: a router outside of a TTZ without any TTZ internal link." =3D> "TTZ external router: a router outside of a TTZ that has no TTZ internal links." [section: "2. Terminology" 4th item] Move below 5th item that it references [section "4. Requirements" 1st paragraph] - "*A* Topology-Transparent Zone" - "for *a* TTZ" [section "5.1. Overview of Topology-Transparent Zone" 1st paragraph ] Define and use TTZ ID, rather than just "(ID)" as that is what the = rest of the document refers to this as, and is more specific anyway. [section "5.2. Some Details on TTZ" paragraph 4] "Note that none of the TTZ internal routers can be an ABR." =3D> "Note that by definition a TTZ internal router cannot also be an = ABR." [section "6.4. TTZ Options TLV" paragraph 2] "as needed" =3D> "as described below"? [section "6.5. Link Scope TTZ LSA" diagram and paragraph 1] "Options TLV" =3D> "TTZ Options TLV" (and all other uses?) [section "8. Establishing Adjacencies"] "This section describes the adjacencies in different cases." =3D> "This section describes the TTZ adjacencies." [section "8.1. Discover TTZ Neighbors" multiple paragraphs] "discover TTZ each other" =3D> "TTZ discover each other" [various section "8.1. Discover TTZ Neighbors" ...] Text uses =3D and =3D=3D but in both cases it = means equality check, not assignment, pick and use one consistently in the document. On the use of parenthesis, the text is using parenthesis as a form of grouping as one might in mathematics which I'm not sure is proper. Parenthesis in writing are generally used as an aside. Probably the = clearest way to indicate the logical grouping would be to use a list, e.g., When one of the following conditions is met. - Z =3D 0 and there is a TTZ Options LSA with T =3D 1 - Z =3D 1 ... [section "9.1. Advertisement of LSAs within TTZ" paragraph 1] "advertised within" =3D> "advertised only within" [section "11.1. Configuring TTZ" last paragraph] "the above one" =3D> "option 1" [section "11.3. Adding a Router into TTZ" paragraph 1] "When a non TTZ router (say R1) is connected via a P2P link to a TTZ router (say T1) working as TTZ and there is a normal adjacency between them over the link, a user can configure TTZ on two ends of the link to add R1 into the TTZ to which T1 belongs. They discover TTZ each other with the TTZ as described in section 8." =3D> "When a non TTZ router (say R1) is connected via a P2P link to a = migrated TTZ router (say T1), and there is a normal adjacency between them over = the link, a user can configure TTZ on both ends of the link to add R1 into the = TTZ to which T1 belongs. They TTZ discover each other as described in = section 8." [section "11.3. Adding a Router into TTZ" paragraph 2] "When a number of non TTZ routers are connected via a broadcast link to a TTZ router (say T1) working as TTZ and there are normal adjacencies among them, a user configures TTZ on the connection to the link on every router to add the non TTZ routers into the TTZ to which T1 belongs. The DR for the link "forms" TTZ adjacencies with the other routers connected to the link if they all have the same TTZ ID configured for the link. This is determined through the discovery process described in section 8." =3D> "When non TTZ routers are connected via a broadcast or NBMA link to a migrated TTZ router (say T1), and there are normal adjacencies among = them, a user configures TTZ on the connection to the link on every router to = add the non TTZ routers into the TTZ to which T1 belongs. The DR for the link = "forms" TTZ adjacencies with the other routers connected to the link if they = all have the same TTZ ID configured for the link. This is determined through = the TTZ discovery process described in section 8." [section "12.2. Implementation Experience"] Convert IETF 90 to (or include) a date. [section "14. IANA Considerations"] While not requested in the text, a new registry needs to be created = for the management of TTZ TLV types and so information regarding this new = registry in addition to the initial seed values is required. --Apple-Mail=_AA43EA6F-C0B1-4FE8-A33E-22FABBE743C1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXIQZAAAoJEC4dgw7XuDAlFmMP/iA1d6+Bzj4tq8Ya1T27Uxy9 jbthZiXkRqUlStqeSkYwJnmpE+JidjEHhznhlKFW4B2ulZ1Kyj8l8AlhADqdSbdB F+p/JaRqsD8YxxTS0S6pNhj7suquucg4RAStz4VSJT4gRk63b/4lzUJOumZuNSmA MDUzRV/L5ud/Weo8ykaJt4ydzIKwL371j/GgouJatVypz9M3QrQE3bEGx7NpX+sY ZJlehaHqgyYPJsni4NI+G0wK2OzdCFOPXgGtLObVj/OVjYk5vYrp2i7pdzyIgpl0 b8eOFJrPwRUmxj7VAspYhSSlz0cyN5ctRDIZLJPmIdC3BYbZV95yU7j1/QLtto0l N5vLvoJsorFCIM563cCNDKP9wLA518/zzHmzCkXu0NcTw//Q4DIv1Pf9aWo26KEa co3vXuVsyndO8Nh4T9F+jurPP77xho47vnHMCqmFkf9MBWfwD4sia0cIjMuXEt9N NK18XmOXuSdG2KWl/i/aHLq9HHox4exjgGyi7iH/i25VzxD+z8zro2YSmtHzeole 54FyeB1sEyp09b5Ip6zcYZiVeuQEFF+FidRbl45h5xP1e+VwQbjYwlI4z0shqsyF fOWdgUXPAAjt6RQWp5puHiy99vRBvAYBMKx8iwjry+MBK4DHwwrBRUw8hZNKbazS PTbrmjtTeUpn9d6WphFD =aii+ -----END PGP SIGNATURE----- --Apple-Mail=_AA43EA6F-C0B1-4FE8-A33E-22FABBE743C1-- From nobody Wed Apr 27 11:49:24 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B8112D53F; Wed, 27 Apr 2016 11:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 sbUMGe_dQAov; Wed, 27 Apr 2016 11:49:16 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7524312D534; Wed, 27 Apr 2016 11:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31012; q=dns/txt; s=iport; t=1461782956; x=1462992556; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rH24F/kBDiEwJXdDDM3ffRIc6/IH5dKMjNratTorZLI=; b=afwuHSCejYYQ/lbSlZfFYnByT30RgY5t3BAEANpg3kRUooB2uNPpex8N KCyAAoD1vbMTyEsLdiJOorTAuG0w5QEWmqaR2dKkbObFvJymQ9bRbgCb1 VUT8kSrma7qekv76kxHcX7Kxa9eR+pvMygOK18RR3Y4fKFizOgCP8//B0 0=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DWAgB5CCFX/4UNJK1UCoM4U30GuWYOg?= =?us-ascii?q?XUXAQqFbQKBMzgUAQEBAQEBAWUnhEEBAQEDAQEBASBLCwULAgEIFAQgCgICJws?= =?us-ascii?q?lAQEEDgUOiBQIDrFxkSsBAQEBAQEBAQEBAQEBAQEBAQEBAQENCIYhgXWBVIECh?= =?us-ascii?q?BUERIJgK4IrBZMfhHEBgyeBZ22IG4FnToN/gymFNIYkiQsBDw8BQ4NrbAEBh24?= =?us-ascii?q?/fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,542,1454976000"; d="asc'?scan'208,217";a="266163739" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2016 18:49:15 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3RInEdC021482 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Apr 2016 18:49:14 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 27 Apr 2016 14:49:13 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Wed, 27 Apr 2016 14:49:13 -0400 From: "Carlos Pignataro (cpignata)" To: Adrian Farrel Thread-Topic: [OSPF] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt Thread-Index: AdGghcVG0QuPS2RxQ6ajDKPyM64RjwAUT+OA Date: Wed, 27 Apr 2016 18:49:13 +0000 Message-ID: References: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk> In-Reply-To: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.49.220] Content-Type: multipart/signed; boundary="Apple-Mail=_08D97DD0-416C-475B-A688-8AF18C8487DB"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "" , "draft-ietf-ospf-sbfd-discriminator.all@ietf.org" , "ospf@ietf.org" , "" Subject: Re: [OSPF] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 18:49:20 -0000 --Apple-Mail=_08D97DD0-416C-475B-A688-8AF18C8487DB Content-Type: multipart/alternative; boundary="Apple-Mail=_6E9438C2-5966-491C-BDE0-649B62BD6399" --Apple-Mail=_6E9438C2-5966-491C-BDE0-649B62BD6399 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Adrian, Many thanks for the thorough review! Please see inline. Will post a new = revision momentarily. > On Apr 27, 2016, at 9:11 AM, Adrian Farrel = wrote: >=20 > Hello, >=20 > I have been selected as the Routing Directorate reviewer for this = draft. The > Routing Directorate seeks to review all routing or routing-related = drafts as > they pass through IETF last call and IESG review, and sometimes on = special > request. The purpose of the review is to provide assistance to the = Routing ADs. > For more information about the Routing Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >=20 > Although these comments are primarily for the use of the Routing ADs, = it > would be helpful if you could consider them before or along with any = IETF > Last Call comments that you receive, and strive to resolve them = through > discussion or by updating the draft. >=20 > Document: draft-ietf-ospf-sbfd-discriminator-04.txt > Reviewer: Adrian Farrel > Review Date: 27 April 2016 > IETF LC End Date: 26 April 2016 > Intended Status: Standards Track >=20 > Summary: > I have some minor concerns about this document that I think should be > resolved before publication. >=20 > Comments: >=20 > This is a simple document that doesn't require much to implement or > understand. It was disappointing, however, to find a large number of > small issues and nits. I don't believe any of these are blocking to > the utility of the document and if it went for publication in its > current state it would not be harmful. But in the interest of making > our documents useful and accessible, and for the purpose of = eliminating > all possible interoperability and deployment, I think it would be > valuable to clean up the issues I have listed. >=20 > Major Issues: > No major issues found. >=20 > Minor Issues: >=20 > I should like to see some small amount of text on the scaling impact = on > OSPF. 1. How much additional information will implementations have to > store per node/link in the network? 2. What is the expected churn in > LSAs introduced by this mechanism (especially when the Reflector is > turned on and off)? >=20 > In the second case there is a security implication as well. Can I DoS > the routing system by toggling some BFD Reflectors? Needs text! >=20 > You *do* have... > A change in information in the S-BFD Discriminator TLV MUST NOT > trigger any SPF computation at a receiving router. > ...which is a help. I don=E2=80=99t disagree with this comment theoretically, but at the = same time, trying to find the right words=E2=80=A6 if any. We talk about = SPF computation churn as you mention, but documents don=E2=80=99t = describe implications of say, changing an IP address on a node. This = usage is not too dissimilar from other RI uses, and I could not find = scaling text to contrast against either. There is no reason for S-BFD discriminators to change =E2=80=94 = frequently, or at all. The information that nodes may store is the discriminators, or they may = choose to not store it. An S-BFD reflector is not expected to be = constantly configured on/off/on/off, and if its configuration state is = toggled continuously maliciously, there=E2=80=99s really a lot worst = things than this extra advertisement. Most of that does not seem to be needed explicitly in the document. So, net-net, I do not see the need to update this. >=20 > --- >=20 > Section 1 has >=20 > This is achieved by using unique > network-wide discriminators to identify the Network Targets (e.g., = IP > addresses). >=20 Yes, this can be improved, see below. > You may be aware of IPv6 :-) >=20 > Although 2.1 gives some hints on the size of a discriminator, I had to > go back to 5880 to check that *all* discriminators are exactly 4 = octets. > So saying "e.g., IP addresses" is at best confusing. >=20 > BTW, draft-ietf-bfd-seamless-base and draft-ietf-bfd-seamless-ip don't > give any hints on this. >=20 https://tools.ietf.org/html/draft-ietf-bfd-seamless-base-09#section-2 = =E2=80=9C o S-BFD discriminator - a BFD discriminator allocated for a local entity and is being listened by an SBFDReflector. " > Oh, and what is "network-wide"? >=20 > I suggest... >=20 > This is achieved by using four-octet discriminators as defined in > [RFC5880] to identify the Network Targets. >=20 This suggestion drops a key-most consideration, =E2=80=9Cunique=E2=80=9D. https://tools.ietf.org/html/draft-ietf-bfd-seamless-base-09#section-4.1 = I=E2=80=99ll reword to: This is achieved by using four-octet discriminators, unique within an administrative domain, to identify the Network Targets. > --- >=20 > In Section 2 you have > Upon receipt of the TLV, a > router may decide to ignore this TLV or install the S-BFD > discriminator in BFD Target Identifier Table. >=20 > I think "ignore" is ambiguous. You need to be very clear that "ignore" > means: > - take no local action > - retain the TLV in the opaque LSA > - continue to advertise the opaque LSA according to its scope >=20 The =E2=80=9Cignore=E2=80=9D is in reference of what follows, which is = install the discriminator. In this case, ignore means =E2=80=98or = don=E2=80=99t install it=E2=80=99. I agree this can be improved :-) I=E2=80=99ll just remove =E2=80=9Cto = ignore this TLV or=E2=80=9D, since may install it (or may not). > In Section 3 you also have > A router not supporting the S-BFD Discriminator TLV will just > silently ignore the TLV as specified in [RFC7770]. >=20 > Am I missing something when I read 7770? I don't find anything about > handling unknown TLVs. >=20 https://tools.ietf.org/html/rfc7770#section-2.3 = " Unrecognized types are ignored. " > --- >=20 > Section 2 para 3 > s/superset/union/ > ("superset" would allow you to include any other discriminators!) >=20 OK. > --- >=20 > Section 2.1 > To be totally unambiguous... > OLD > Length - Total length of the discriminator (Value field) in octets, > not including the optional padding. The Length is a multiple of 4 > octets, and consequently specifies how many Discriminators are > included in the TLV. > NEW > Length - Total length of all discriminator in the Value field in > octets, not including the optional padding. The Length is a = multiple > of 4 octets, and consequently specifies how many Discriminators are > included in the TLV. > END >=20 > However (!) are you sure that you can include optional padding? I = think > that 7770 uses padding to take the V field up to a 4 octet boundary. > Since all of your discriminators are exactly a multiple of 4 octets it > seems that there will never be any padding and it would be less > confusing to write... >=20 > NEW > Length - Total length of all discriminators in the TLV counted in > octets. The Length is a multiple of 4 octets, and consequently > specifies how many Discriminators are included in the TLV. > END >=20 Indeed, and we had fixed this one in our working copy. This is what we = have: Length - Total length of the discriminator(s) that appear in the Value field, in octets. Each discriminator is 4 octets, so the Length is 4 times the number of discriminators included in the TLV. There is no optional padding for this field. > --- >=20 > At the end of section 2.1 you have >=20 > S-BFD discriminator is associated with the > BFD Target Identifier type, that allows demultiplexing to a specific > task or service. >=20 > This is a wonderfully throw-away statement with no context and no > further explanation in the document that I could find. Maybe this is > just missing a reference to another document, or maybe it needs some > clarification. >=20 Old, and should have been removed. Good catch!!! Removed. > --- >=20 > Section 2.2 has >=20 > The flooding scope for S-BFD Discriminator information advertised > through OSPF can be limited to one or more OSPF areas, or can be > extended across the entire OSPF routing domain. >=20 > Note that the S-BFD session may be required to pan multiple areas, = in > which case the flooding scope may comprise these areas. This could > be the case for an ABR, for instance, advertising the S-BFD > Discriminator information within the backbone area and/or a subset = of > its attached IGP area(s). >=20 > As I understand flooding scope the options for Opaque LSAs (see 5250) > are: >=20 > o Link-state type-9 denotes a link-local scope. >=20 > o Link-state type-10 denotes an area-local scope. >=20 > o Link-state type-11 denotes that the LSA is flooded throughout the > Autonomous System (AS). >=20 > Your text seems to imply something different. In particular, you seem = to > be suggesting that I can have a scope that is greater than one area = but > less than the whole AS (assuming "whole AS" =3D=3D "entire OSPF = routing > domain"). >=20 > This needs re-writing to clarify what you want to achieve and to bring > it in line with 5250. >=20 > Note that the 4th para of Section 2.2 seems to have this right. >=20 You are right. Seems like removing the first two paragraphs of that = section suffice to remove the problem, and keep the goal in a concise = form. > =3D=3D=3D >=20 > Nits >=20 All nits incorporated =E2=80=94 thanks! With only one comment below. > Has Trilok's affiliation changed? Updated. > -- > Capitalise the document title > --- > Expand acronyms in the Abstract if they do not appear with an asterisk > in http://www.rfc-editor.org/materials/abbrev.expansion.txt > --- > Throughout the text, expand acronyms on first use if they do not = appear > within http://www.rfc-editor.org/materials/abbrev.expansion.txt with = an > asterisk. > --- > Decide whether "discriminator" or "Discriminator" > --- > In 2.1 you have > Value - S-BFD network target discriminator value or values. > But there is no "Value" in the figure. > --- > 2.2 para 2 > s/pan/span/ > --- > 2.2 > In the case of domain- > wide flooding, i.e., where the originator is sitting in a remote > area, the mechanism described in section 5 of [RFC5250] should be > used. > s/should/SHOULD/? > But if you mean should or SHOULD (not MUST), what are the exception > cases? The intention is not to close the door for future exception cases, = without listing them here necessarily. I am personally OK with should or SHOULD, and tempted to leave = =E2=80=9Cshould=E2=80=9D, but happy to take guidance on this. Thanks, =E2=80=94 Carlos. > --- >=20 > Thanks, > Adrian >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail=_6E9438C2-5966-491C-BDE0-649B62BD6399 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Adrian,

Many thanks for the thorough review! Please see inline. Will = post a new revision momentarily.

On = Apr 27, 2016, at 9:11 AM, Adrian Farrel <adrian@olddog.co.uk>= wrote:

Hello,

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

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

Document: draft-ietf-ospf-sbfd-discriminator-04.txt
Reviewer: Adrian Farrel
Review Date: 27 = April 2016
IETF LC End Date: 26 April 2016
= Intended Status: Standards Track

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

Comments:

This = is a simple document that doesn't require much to implement or
understand.  It was disappointing, however, to find a = large number of
small issues and nits.  I don't = believe any of these are blocking to
the utility of the = document and if it went for publication in its
current = state it would not be harmful.  But in the interest of making
our documents useful and accessible, and for the purpose of = eliminating
all possible interoperability and deployment, = I think it would be
valuable to clean up the issues I = have listed.

Major Issues:
No = major issues found.

Minor Issues:

I should like to see some small amount of text = on the scaling impact on
OSPF. 1. How much additional = information will implementations have to
store per = node/link in the network? 2. What is the expected churn in
LSAs introduced by this mechanism (especially when the = Reflector is
turned on and off)?

In the second case there is a security implication as well. = Can I DoS
the routing system by toggling some BFD = Reflectors? Needs text!

You *do* have...
  A change in information in the S-BFD = Discriminator TLV MUST NOT
  trigger any SPF = computation at a receiving router.
...which is a help.

I = don=E2=80=99t disagree with this comment theoretically, but at the same = time, trying to find the right words=E2=80=A6 if any. We talk about SPF = computation churn as you mention, but documents don=E2=80=99t describe = implications of say, changing an IP address on a node. This usage is not = too dissimilar from other RI uses, and I could not find scaling text to = contrast against either.

There is no = reason for S-BFD discriminators to change =E2=80=94 frequently, or at = all.

The information that nodes may = store is the discriminators, or they may choose to not store it. An = S-BFD reflector is not expected to be constantly configured = on/off/on/off, and if its configuration state is toggled continuously = maliciously, there=E2=80=99s really a lot worst things than this extra = advertisement.

Most of that does not = seem to be needed explicitly in the document.

So, net-net, I do not see the need to update = this.


---

Section 1 has

  This = is achieved by using unique
  network-wide = discriminators to identify the Network Targets (e.g., IP
=   addresses).


Yes, = this can be improved, see below.

You may be = aware of IPv6 :-)

Although 2.1 gives some = hints on the size of a discriminator, I had to
go back to = 5880 to check that *all* discriminators are exactly 4 octets.
So saying "e.g., IP addresses" is at best confusing.

BTW, draft-ietf-bfd-seamless-base and = draft-ietf-bfd-seamless-ip don't
give any hints on = this.


=E2=80=9C
   o =  S-BFD discriminator - a BFD discriminator allocated for a = local
      entity and is being = listened by an SBFDReflector.
"

Oh, and what is "network-wide"?

I = suggest...

  This is achieved by = using four-octet discriminators as defined in
=   [RFC5880] to identify the Network Targets.


This = suggestion drops a key-most consideration, =E2=80=9Cunique=E2=80=9D.
=

I=E2=80=99ll reword = to:

  This is achieved by using = four-octet discriminators, unique within
  an = administrative domain, to identify the Network Targets.

---

In Section 2 = you have
  Upon receipt of the TLV, a
  router may decide to ignore this TLV or install = the S-BFD
  discriminator in BFD Target = Identifier Table.

I think "ignore" is = ambiguous. You need to be very clear that "ignore"
means:- take no local action
- retain the TLV in the = opaque LSA
- continue to advertise the opaque LSA = according to its scope


The = =E2=80=9Cignore=E2=80=9D is in reference of what follows, which is = install the discriminator. In this case, ignore means =E2=80=98or = don=E2=80=99t install it=E2=80=99.

I = agree this can be improved :-) I=E2=80=99ll just remove =E2=80=9Cto = ignore this TLV or=E2=80=9D, since may install it (or may not).

In Section 3 you also have
  A = router not supporting the S-BFD Discriminator TLV will just
=   silently ignore the TLV as specified in [RFC7770].

Am I missing something when I read 7770? I = don't find anything about
handling unknown TLVs.


"=
   Unrecognized types are = ignored.
"

---

Section 2 para 3
s/superset/union/  
("superset" would allow you to include any other = discriminators!)


OK.

---

Section 2.1
To be totally unambiguous...
OLD
  Length - Total length of the = discriminator (Value field) in octets,
  not = including the optional padding.  The Length is a multiple of 4
  octets, and consequently specifies how many = Discriminators are
  included in the TLV.
NEW
  Length - Total length of all = discriminator in the Value field in
  octets, = not including the optional padding.  The Length is a multiple
  of 4 octets, and consequently specifies how many = Discriminators are
  included in the TLV.
END

However (!) are you sure = that you can include optional padding? I think
that 7770 = uses padding to take the V field up to a 4 octet boundary.
Since all of your discriminators are exactly a multiple of 4 = octets it
seems that there will never be any padding and = it would be less
confusing to write...

NEW
  Length - Total length of all = discriminators in the TLV counted in
  octets. =  The Length is a multiple of 4 octets, and consequently
  specifies how many Discriminators are included = in the TLV.
END


Indeed,= and we had fixed this one in our working copy. This is what we = have:

<t>
Length = - Total length of the discriminator(s) that appear in the
Value field, in octets. Each discriminator is 4 octets, so = the Length
is 4 times the number of discriminators = included in the TLV. There is
no optional padding for this = field.
</t>


---

At the end of section 2.1 = you have

  S-BFD discriminator = is associated with the
  BFD Target Identifier = type, that allows demultiplexing to a specific
=   task or service.

This is a = wonderfully throw-away statement with no context and no
further explanation in the document that I could find. Maybe = this is
just missing a reference to another document, or = maybe it needs some
clarification.


Old, = and should have been removed. Good catch!!! Removed.

---

Section 2.2 has

  The flooding scope for S-BFD = Discriminator information advertised
  through = OSPF can be limited to one or more OSPF areas, or can be
=   extended across the entire OSPF routing domain.

  Note that the S-BFD session may = be required to pan multiple areas, in
  which = case the flooding scope may comprise these areas.  This could
  be the case for an ABR, for instance, = advertising the S-BFD
  Discriminator = information within the backbone area and/or a subset of
=   its attached IGP area(s).

As I = understand flooding scope the options for Opaque LSAs (see 5250)
are:

  o =  Link-state type-9 denotes a link-local scope.

  o  Link-state type-10 denotes an area-local = scope.

  o  Link-state = type-11 denotes that the LSA is flooded throughout the
=      Autonomous System (AS).

Your text seems to imply something different. In particular, = you seem to
be suggesting that I can have a scope that is = greater than one area but
less than the whole AS (assuming = "whole AS" =3D=3D "entire OSPF routing
domain").

This needs re-writing to clarify what you want = to achieve and to bring
it in line with 5250.

Note that the 4th para of Section 2.2 seems to = have this right.


You = are right. Seems like removing the first two paragraphs of that section = suffice to remove the problem, and keep the goal in a concise = form.

=3D=3D=3D

Nits


All nits incorporated =E2=80=94 thanks! With only = one comment below.

Has Trilok's affiliation = changed?

Updated.

--
Capitalise the document title
---
Expand acronyms in the Abstract if they do not appear with an = asterisk
in http://www.rfc-editor.org/materials/abbrev.expansion.txt---
Throughout the text, expand acronyms on = first use if they do not appear
within http://www.rfc-editor.org/materials/abbrev.expansion.txt = with an
asterisk.
---
Decide = whether "discriminator" or "Discriminator"
---
In 2.1 you have
  Value - S-BFD = network target discriminator value or values.
But there is = no "Value" in the figure.
---
2.2 para 2
s/pan/span/
---
2.2
=   In the case of domain-
  wide = flooding, i.e., where the originator is sitting in a remote
=   area, the mechanism described in section 5 of [RFC5250] = should be
  used.
s/should/SHOULD/?
But if you mean should or = SHOULD (not MUST), what are the exception
cases?

The = intention is not to close the door for future exception cases, without = listing them here necessarily.

I am = personally OK with should or SHOULD, and tempted to leave =E2=80=9Cshould=E2= =80=9D, but happy to take guidance on this.

Thanks,

=E2=80=94= Carlos.

---

Thanks,
Adrian

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

= --Apple-Mail=_6E9438C2-5966-491C-BDE0-649B62BD6399-- --Apple-Mail=_08D97DD0-416C-475B-A688-8AF18C8487DB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXIQmpAAoJEIXgpQGOZny9ifoP/jGEbPJ4tK2f1mVGr98tP8Fw JuVVX6Rz4eJkLqe4JO5+pECsLL4/LgT7jqiXudgZyhRY8tvUyruCu1IfwPiZG0+z LdkBtMucyKGrm3l03iqw7HBMWEK4i6/QB7krAa71ulxCZA9WwtunFo0NEEaNQmkD R2K1C3ysadL/C/Zgyl/R+CfgNC/3QlO3hWVpJcbmUCL14xvh7jTFhke/ZaeoAQbd HgBC9dvuoAQTA4IHqFW+wo/VmeBOgxvB1b09UUDbjcaBupyKL7zK50XdE2Hgmh0M Fsa4NKvaREDfgqdxPdPmv6BKCe3Naf/E/GJfDM5U3I6QLPPPrOOTydsDRoWDJer7 0/k+Nb/wE3rDtk5dUMU9zZs20wyOzyLtpz4KeHbPKu2kbj1iiGpnLvTkIGUlf+lu jI48XFgGOjjgSMTrcn0DDkm0RBArPY/FHi9rnVOgRM4av/72E+NwlnRcFNUH29ud T/H8tPnKNgHZQU7qQcBLv3yinyiDa+oPNDeJitVOruCqx1w/VqJdtvEjNCOV3IbJ 6goxPWXO/I9DGX+fMhYQoL1KOH9AgMfxu2lYVeLuPeDjDFovQfc43h+HJligw8HC FEeZja05Jlnl3+jm5UvxjoTHN+gOERxfOxAATth9smV+08NDNPsgOlLQDhaiOhA+ y5zyFdtnKup0N2WT6mhm =yurq -----END PGP SIGNATURE----- --Apple-Mail=_08D97DD0-416C-475B-A688-8AF18C8487DB-- From nobody Wed Apr 27 11:55:20 2016 Return-Path: X-Original-To: ospf@ietf.org Delivered-To: ospf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8A912DB62; Wed, 27 Apr 2016 11:55:16 -0700 (PDT) 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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160427185516.25245.16859.idtracker@ietfa.amsl.com> Date: Wed, 27 Apr 2016 11:55:16 -0700 Archived-At: Cc: ospf@ietf.org Subject: [OSPF] I-D Action: draft-ietf-ospf-sbfd-discriminator-05.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 18:55:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP of the IETF. Title : OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators Authors : Carlos Pignataro Manav Bhatia Sam Aldrin Trilok Ranganath Filename : draft-ietf-ospf-sbfd-discriminator-05.txt Pages : 7 Date : 2016-04-27 Abstract: This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood the Seamless Bidirectional Forwarding Detection (S-BFD) discriminator values associated with a target network identifier. This mechanism is applicable to both OSPFv2 and OSPFv3. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-sbfd-discriminator/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ospf-sbfd-discriminator-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-sbfd-discriminator-05 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 Apr 27 13:17:11 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B0512B045; Wed, 27 Apr 2016 13:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 cbqrxi3Piq8c; Wed, 27 Apr 2016 13:17:03 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54A2212B02F; Wed, 27 Apr 2016 13:17:03 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id k142so61722367oib.1; Wed, 27 Apr 2016 13:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=T3yHnCvy5OSxiuBrfDfIo5D9EmOEtDFtPPQ6KcJ8utA=; b=EgaNvQxyy+XQmV9ceLAN2IhA8WiObZc2ojbid6sRfMaehFmcDV8W1Fgvg7iz5UYo6S dfst1/ydJi/Ostj4e3CC4RsL5SZMa2MdZjIt2ATWImaqOd+D7jb0PAom6NNkk8+4WHhu d/fEt3E6szXjSuWpvfLhyIAixqslDhg/ZaI3rfRLSzeFmsymxDXnM1r1IWdGTRt7Iz2t BdhLvjB0KZXBCjqOYpoCB644hpORZU/ezIWZwxoV9D0RPBruSS5n5SWokdck3khHKoYY +P3+LpZal7pCQCimEpwftih9dDTr0bafZI+l/sxDqFZImO9+s+Zt7aTNTZwFCbi2IeiB 0OxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=T3yHnCvy5OSxiuBrfDfIo5D9EmOEtDFtPPQ6KcJ8utA=; b=I/jXU0gX5CM1UjoU1u0yxEj39CSwuwvkw/CN8yDbkZj4nSibDx2K0XfqlYrWOPkAA1 doWZW5ArbdCn0NyKCBBU1lDDLp2lXIhOMMLs3DGuYQ5BhGsZd71uTm9P2jm5RW845N6A ATQjDIbmk8Z/z5dV5Xbyd7sqg/OCV8rvY7f3oT1kOWYq4zck9qSZqz7JjB+kVNc5Q9o6 oaCCJgpArd28S42YNy34TscHh4DLehQ5UKz6ckXAIj3AWBaXymn/9oXS8CTFD+676K37 ZYg1p6l/HN6LYlw/FR6HLJPwM6VbAT3hOZimx2HFIPKv4bWvnj31hAH9zQn5xTfIo52P XJTg== X-Gm-Message-State: AOPr4FWiL18mYXwUKvscfsMcdxYhqGlGDQ2l7gvDg4f7bx0m+RssxFJiAQjcxYdfrBsA1dQYh3oEPAV/jXJVmg== MIME-Version: 1.0 X-Received: by 10.157.45.81 with SMTP id v75mr4878494ota.85.1461788222435; Wed, 27 Apr 2016 13:17:02 -0700 (PDT) Received: by 10.60.115.168 with HTTP; Wed, 27 Apr 2016 13:17:02 -0700 (PDT) In-Reply-To: <4942DD46-2A03-4B3C-B36E-29A05B81177D@chopps.org> References: <4942DD46-2A03-4B3C-B36E-29A05B81177D@chopps.org> Date: Wed, 27 Apr 2016 16:17:02 -0400 Message-ID: From: Alia Atlas To: Christian Hopps Content-Type: multipart/alternative; boundary=001a113e9f66bc410405317d17e4 Archived-At: Cc: "" , "rtg-dir@ietf.org" , draft-ietf-ospf-ttz.all@ietf.org, OSPF List Subject: Re: [OSPF] RtgDir review: draft-ietf-ospf-ttz-03 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2016 20:17:07 -0000 --001a113e9f66bc410405317d17e4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Chris, Thank you very much for doing your detailed review and raising these concerning points. Authors & Shepherd, Please address these points and let me know when a revised I-D has been submitted. I will do my AD review after that. Thanks, Alia On Wed, Apr 27, 2016 at 2:34 PM, Christian Hopps wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and sometimes > on special request. The purpose of the review is to provide assistance to > the Routing ADs. For more information about the Routing Directorate, plea= se > see =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 Las= t > Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-ospf-ttz-03 > Reviewer: Christian Hopps > Review Date: April 26, 2016 > IETF LC End Date: unknown > Intended Status: Experimental > > Summary: > =3D=3D=3D=3D=3D=3D=3D=3D > > I have some concerns about this document and recommend that the > Routing ADs discuss these issues further with the authors. > > Comments: > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > While I believe that the document is for the most part readable and > understandable, I believe it still requires better or more definition= s, > clarifications, and/or additional text before becoming an RFC. > > Major Issues: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > [section "2. Terminology"] > > - An edge router is defined as a router with internal and external > adjacencies. > (and referred to this way later in the text as well). Is this the > actual > definition or is it instead when a router has links that are and are > not > configured as TTZ internal? This makes a big difference b/c the forme= r > case > is very dynamic while the latter is static. One could imagine in the > former > case that a router is configured to be within a TTZ and then by virtu= e > of > who it becomes adjacent with determines whether it is internal or edg= e. > While this makes configuration very simple I think it also has a big > impact > on the complexity of the protocol interactions. > > After reading section 11.1 "Configuring TTZ" which proposes "some > options > for configuring a TTZ", it certainly seems that the intention is for > links > to be determined to be within a TTZ or not based only on > configuration. If > this is indeed the case I think this needs to be stated up front and > very > clearly, and I would suggest changing all the text in "2. Terminology= " > to > talk about configuration instead of adjacencies. For example: > > "TTZ link or TTZ internal link: a link configured to be inside the > TTZ." > > "TTZ external link: a link not configured to be within a TTZ" > > "TTZ internal router: a router configured with only TTZ internal > links." > > "TTZ external router: a router with no configured TTZ internal links" > > "TTZ edge router: a router configured with both TTZ internal and TTZ > external links." > > [section "7. Constructing LSAs for TTZ" paragraph 6 and 7] > > ... "The cost of the link is the cost of the shortest path from this > TTZ edge > router to the other TTZ edge router within the TTZ." > > "In addition, the LSA may contain a third group of links, which are th= e > stub > links for the loopback addresses inside the TTZ to be accessed by node= s > outside of the TTZ." > > - So basically every SPF from a TTZ internal topology change can lead > to new > edge router LSAs being advertised throughout the area to adjust the > "virtual" > routing link costs. This is noteworthy because while you've hidden sta= te > using the TTZ, the dynamics of the network haven't gotten simpler rath= er > they've gotten more complex, as changes are now cascading rather than > being > singular. This is an interesting trade-off choosing perpetual run-time > and > protocol complexity in order to avoid the one time cost of new area > creation. > Would it be worth actually pointing out these costs of using TTZ? > > [section "7. Constructing LSAs for TTZ" paragraph 8] > > "To migrate to a TTZ smoothly, a TTZ edge router virtualizes the TTZ > in two > steps. At first, the router updates its normal router LSA by adding = a > point-to-point link to each of the other edge routers of the TTZ and > a stub > link for each of the loopback addresses in the TTZ to be accessed > outside > of the TTZ into the LSA. And then it removes the links configured as > TTZ > links from its updated router LSA after sending its updated router > LSA and > receiving the updated router LSAs originated by the other TTZ edge > routers > for MaxLSAAdvTime or after sending its updated router LSA for > MaxLSAGenAdvTime (refer to Appendix A)." > > In order to be sure I understood this I basically broke it apart and > put it together > again with possibly incorrect reductions. I ended up with: > > To migrate to a TTZ smoothly, a TTZ edge router virtualizes the TTZ > in two steps: > > Step 1: The router updates its router LSA by adding a point-to-point > link > to each of the other known edge routers in the TTZ, and also by > adding the > stub links advertised by TTZ internal routers. > > Step 2: After RMaxLSAAdvTime (.1 seconds) or MaxLSAGenAdvTime (.3 > seconds) > remove the TTZ links from its router LSA. > > [section "10. Computation of Routing Table" > > The text says to ignore *all* links from a TTZ edge routers router LSA= . > This > presumably works b/c the SPF is also going to use the advertised TTZ > Router > LSA instead. Shouldn't the fact that the SPF should using the new TTZ > Router > LSA be stated somewhere as well? > > Minor Issues: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > [section: "Introduction" 2nd paragraph] > > The initial sentence makes an assertion about complexity and time > consumption for area creation. The following sentence does not back > this > assertion up but merely describes the act of creating a new area. I > found > this less than compelling. > > [section: "2. Terminology"] > > This need not be addressed here but it's where I had the question: Ca= n > a > TTZ edge router be in more than one TTZ? > > [section "5.1. Overview of Topology-Transparent Zone" 3rd paragraph ] > > "In addition to having the functions of an OSPF area", is this > actually the > case? That is, is a TTZ really a superset of OSPF area functionality? > I'm > pretty sure it is not. > > [section "5.1. Overview of Topology-Transparent Zone" Bullet 1] > > "o An OSPF TTZ is virtualized as the TTZ edges connected each other." > > This is a very important bullet as it actually will describe what a TT= Z > really is. As such I'd suggest more precise text here. For example: > > "o An OSPF TTZ represents a set of TTZ internal routers as a full mesh > of > virtual links between the TTZ edge routers." > > ? > > [section "5.1. Overview of Topology-Transparent Zone" Bullet 2] > > "An OSPF TTZ receives the link state information about the > topology outside of the TTZ, stores the information in the TTZ and > floods the > information through the TTZ to the routers outside of the TTZ." > > This bullet is a bit clunky to read. Perhaps something more direct lik= e: > > "Non-TTZ link state information is handled as normal (i.e., it is not > filtered or modified by a TTZ)" > > If you want to keep the original text then a couple nits: > > "An OSPF TTZ receives" =3D> "TTZ Routers receive" > > "stores the information in the TTZ and floods" =3D> "store the > information, and flood" > > [section: "6.1. General Format of TTZ LSA" paragraph 3] > > "A TTZ LSA having an optional TTZ Router TLV is called a TTZ Router > LSA. A TTZ > LSA containing a TTZ Options TLV is called a TTZ Control LSA." > > Can these ever be combined? By naming them distinctly like this, it > seems to > be exclusive, if this is the case that should probably be more clearly > defined. > > In general I think more expansion and clarity here is in order. Instea= d > of > talking about LS Type 10/9 with a note about type 10. Why not discuss > each type: > - LS Type 9 "Link local scope" when it is used, and what is optional > and mandatory in it. > - LS Type 10 "Area scope" when it is used, and what is optional and > mandatory in it. > > [section "6.3. TTZ Router TLV" paragraph 1] > > "The format of a TTZ Router TLV is as follows. It contains the > contents of a router LSA." > > Is this trying to say: > > "It has the same content as a standard OSPF Router LSA (RFC x-ref) wit= h > the > following modifications"? > > [section "6.3. TTZ Router TLV" TLV content] > > Given the existence of the TLV-Length, is the "# links" field > redundant? What > happens if they correctly correlate? > > [section "6.4. TTZ Options TLV" "flags"] > > So "exclusive" =3D> "mutually exclusive"? > > If this is the case these aren't really flags but rather one of 4 > possible > values (I believe in the all 0 case the TLV is not advertised?), and i= f > so it > would be much better to simply define the 4 possible values using 2 > bits. > > What happens if more than one bit is set to 1? > > [section "7. Constructing LSAs for TTZ" paragraph 3] > > This text can be read to indicate that for TTZ internal routers the > router's > normal Router LSA content is copied into a TTZ Router TLV, does the > router > also advertise its Router LSA as normal or is that then suppressed? > It's not > clear to me why this information needs copying, and so I'm wondering i= f > the > text is saying that no TTZ Router TLV is included, and that the TTZ > internal > router just advertises it's regular OSPF Router LSA. > > The text could be more explicit. Also some of my confusion stems from > earlier > defining a "TTZ Router LSA" as one containing an "optional TTZ Router > TLV". > So when the text here refers to the LSA as a TTZ Router LSA one might > assume > that the optional TTZ Router TLV must be present. > > Perhaps this gets back to my want for better separating and defining > the LS Types and contents. > > [section "7. Constructing LSAs for TTZ" paragraph 4 and 9] > > "After receiving a trigger to migrate to TTZ such as a TTZ LSA with > flag M =3D 1, a TTZ edge router originates its normal router LSA for > virtualizing a TTZ, which comprises three groups of links in general." > > "To roll back from a TTZ smoothly after receiving a trigger to roll > back from TTZ, ..." > > - Triggers are mentioned a few times throughout the text. I think the > triggers meaning, rather than being initially implied, should be > explicit > defined early and in 1 location. It isn't until section 11.2 that I > thought > I understood what triggers were and how they worked. > > Actually the triggers are defined in section 6.4, but the text there > never > actually uses the word "trigger". I suggest that this be changed so > that it > is clear what a trigger is prior to the use of the term. > > [section "8.1. Discover TTZ Neighbors" paragraph 2] > > "If two ends of the link have different TTZ IDs, no TTZ adjacency over > the link will be "formed"." > > - In general I'm somewhat confused about the actual definition of a TT= Z > adjacency. How does it compare to a normal protocol adjacency. In th= e > above > case you would have a protocol adjacency I believe, but no TTZ > adjacency? > How is this link advertised if the router is a TTZ edge router? > > [section "8.1. Discover TTZ Neighbors" paragraph 5] > > The text talks about when (Z=3D=3D0 and there is a TTZ LSA with T=3D1)= or > Z=3D=3D1. Where > are all the places that T=3D1 is showing up? What about the case when = an > adjacency is forming when M=3D1 instead of T=3D1? > > [section "8.1. Discover TTZ Neighbors" paragraph 7] > > Since the diagram state Zs are the same, it no longer applies to the > rest of > section 8. Is it worthwhile to have a new diagram here for clarity? > > [section "8.1. Discover TTZ Neighbors" paragraph 8] > > Here's a mention of "triggers B to migrate", I think you probably shou= ld > state explicitly what this means, which I *think* is: > > "A also sends a D-LSA containing a TTZ Control TLV with M=3D1 to B, > triggering > it to migrate." > > Although this now makes me wonder what does B do on receiving M=3D1 if= it > had > not received or been configured for T=3D1 yet? > > [section "8.1. Discover TTZ Neighbors" paragraph 9] > > I would break this paragraph up to make clear that 2 distinct things a= re > happening based on 2 different events. So: > > "When B receives the D-LSA from A and determines they have the same > TTZ ID but its Z=3D0 and A's Z=3D1, B sends A all the TTZ LSAs it has = and > starts to migrate to TTZ after receiving A's D-LSA with M=3D1. After > migration to TTZ, B updates and advertises its LSAs as needed." > > becomes: > > "When B receives the D-LSA from A and determines they have the same > TTZ ID but its Z=3D0 and A's Z=3D1, B sends A all the TTZ LSAs it has.= " > > "When B receives the D-LSA from A with M=3D1 it starts to migrate to T= TZ. > After > migration to TTZ, B updates and advertises its LSAs as needed." > > Does "starts to migrate" here simply means B starts setting it's M=3D1= as > well? > > What exactly is happening for B to go from "starts to migrate" to "Aft= er > migration"? I believe this is indicated by Z=3D0 transitioning to Z=3D= 1 (is > the > TTZ Control TLV with M=3D1 also removed from the D-LSA?) > > What LSAs are being updated and advertised by B here? > > [section "8.1. Discover TTZ Neighbors" paragraph 10] > > "After receiving B's D-LSA with Z=3D1, A updates and sends B its D-LSA > by removing the Options TLV. It also updates and advertises its LSAs > as needed." > > What LSAs are being updated and advertised by A here? > > [section "8.1. Discover TTZ Neighbors" in general] > > Are D-LSA sent periodically, if so how often, if not when precisely ar= e > they > sent? > > What happens when B changes its TTZ ID or doesn't send a D-LSA? > > [section "8.1. Discover TTZ Neighbors" Broadcast and NBMA part (i.e., > paragraph 11+)] > > [section "8.1. Discover TTZ Neighbors" paragraph 12] > > So the mis-configured router behavior is dependent on when the > mis-configured > router is introduced? If introduced prior to any adjacency formation > then its > presence will keep all routers from becoming TTZ adjacent, otherwise > only > itself will not have become TTZ adjacent? > > What does mis-configured mean, a different TTZ ID? What about the lack > of the > receipt of a D-LSA on the link? How long does the DR wait for receipt > of a > D-LSA from each neighbor before deciding it won't be receiving one and > the > neighbor is not configured on this link as part of TTZ? > > [section "8.1. Discover TTZ Neighbors" last paragraph] > > Is this just saying: "routers only TTZ discover after forming a normal > adjacency"? > > [section "9.1. Advertisement of LSAs within TTZ" paragraph 2] > > "Any network LSA generated for a broadcast or NBMA network in a TTZ is > advertised within the TTZ." > > [nit: And not outside? This is explicit for the router LSA.] > > What happens when a DR has a mis-configured router on a broadcast > network and > thus is not forming a TTZ adjacency with it? It still has a normal > adjacency > right? So it no has a network LSA that includes both TTZ and non-TTZ > routers > where does it advertise this network LSA? > > [section "11.2. Smooth Migration to TTZ" paragraph 5] > > I was confused by many mentions earlier in the document to a router > migrating > to a TTZ. I think what paragraph 5 in section 11.2 is saying (in too > many > words) is this: > > "Migrating to a TTZ" means a router advertises a TTZ Control TLV with > M=3D1. A > router "Migrates to a TTZ" either when configured to do so or when it > receives a TTZ Control TLV with M=3D1. > > If this is the case then I think something like the above text should > occur > earlier in the document. > > [section "11.3. Adding a Router into TTZ" paragraph 3] > > I don't understand the intent of this paragraph. Is it just saying tha= t > if > TTZ is configured on a link between 2 non-adjacent routers, when they > eventually become adjacent they will also form a TTZ adjacency? > > [section "13. Security Considerations"] > > This seems a bit weak or perhaps just wrong. Perhaps better would be t= o > say > that TTZ relies on the OSPF security mechanisms in place and has the > same > security threat surface? > > Nits: > =3D=3D=3D=3D=3D > > [section: "2. Terminology" 3rd item] > > "TTZ external router: a router outside of a TTZ without any TTZ > internal link." > > =3D> > > "TTZ external router: a router outside of a TTZ that has no TTZ > internal links." > > [section: "2. Terminology" 4th item] > > Move below 5th item that it references > > [section "4. Requirements" 1st paragraph] > > - "*A* Topology-Transparent Zone" > - "for *a* TTZ" > > [section "5.1. Overview of Topology-Transparent Zone" 1st paragraph ] > > Define and use TTZ ID, rather than just "(ID)" as that is what the > rest of > the document refers to this as, and is more specific anyway. > > [section "5.2. Some Details on TTZ" paragraph 4] > > "Note that none of the TTZ internal routers can be an ABR." > > =3D> > > "Note that by definition a TTZ internal router cannot also be an ABR." > > [section "6.4. TTZ Options TLV" paragraph 2] > > "as needed" =3D> "as described below"? > > > [section "6.5. Link Scope TTZ LSA" diagram and paragraph 1] > > "Options TLV" =3D> "TTZ Options TLV" (and all other uses?) > > [section "8. Establishing Adjacencies"] > > "This section describes the adjacencies in different cases." > > =3D> > > "This section describes the TTZ adjacencies." > > [section "8.1. Discover TTZ Neighbors" multiple paragraphs] > > "discover TTZ each other" =3D> "TTZ discover each other" > > [various section "8.1. Discover TTZ Neighbors" ...] > > Text uses =3D and =3D=3D but in both cases it = means > equality check, not assignment, pick and use one consistently in the > document. > > On the use of parenthesis, the text is using parenthesis as a form of > grouping as one might in mathematics which I'm not sure is proper. > Parenthesis in writing are generally used as an aside. Probably the > clearest > way to indicate the logical grouping would be to use a list, e.g., > > When one of the following conditions is met. > > - Z =3D 0 and there is a TTZ Options LSA with T =3D 1 > - Z =3D 1 > > ... > > [section "9.1. Advertisement of LSAs within TTZ" paragraph 1] > > "advertised within" =3D> "advertised only within" > > [section "11.1. Configuring TTZ" last paragraph] > > "the above one" =3D> "option 1" > > [section "11.3. Adding a Router into TTZ" paragraph 1] > > "When a non TTZ router (say R1) is connected via a P2P link to a TTZ > router (say T1) working as TTZ and there is a normal adjacency > between them over the link, a user can configure TTZ on two ends of > the link to add R1 into the TTZ to which T1 belongs. They discover > TTZ each other with the TTZ as described in section 8." > > =3D> > > "When a non TTZ router (say R1) is connected via a P2P link to a > migrated TTZ > router (say T1), and there is a normal adjacency between them over the > link, > a user can configure TTZ on both ends of the link to add R1 into the > TTZ to > which T1 belongs. They TTZ discover each other as described in section > 8." > > [section "11.3. Adding a Router into TTZ" paragraph 2] > > "When a number of non TTZ routers are connected via a broadcast link > to a TTZ router (say T1) working as TTZ and there are normal > adjacencies among them, a user configures TTZ on the connection to > the link on every router to add the non TTZ routers into the TTZ to > which T1 belongs. The DR for the link "forms" TTZ adjacencies with > the other routers connected to the link if they all have the same TTZ > ID configured for the link. This is determined through the discovery > process described in section 8." > > =3D> > > "When non TTZ routers are connected via a broadcast or NBMA link to a > migrated TTZ router (say T1), and there are normal adjacencies among > them, a > user configures TTZ on the connection to the link on every router to > add the > non TTZ routers into the TTZ to which T1 belongs. The DR for the link > "forms" > TTZ adjacencies with the other routers connected to the link if they > all have > the same TTZ ID configured for the link. This is determined through th= e > TTZ discovery process described in section 8." > > [section "12.2. Implementation Experience"] > > Convert IETF 90 to (or include) a date. > > [section "14. IANA Considerations"] > > While not requested in the text, a new registry needs to be created fo= r > the > management of TTZ TLV types and so information regarding this new > registry in > addition to the initial seed values is required. > > --001a113e9f66bc410405317d17e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Chris,

Thank you very much for doing= your detailed review and raising these concerning points.

Authors & Shepherd,
Please address these points and = let me know when a revised I-D has been submitted.
I will do my A= D review after that.

Thanks,
Alia
<= /div>

On Wed, Apr = 27, 2016 at 2:34 PM, Christian Hopps <chopps@chopps.org> wro= te:
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, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing 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 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-ospf-ttz-03
Reviewer: Christian Hopps
Review Date: April 26, 2016
IETF LC End Date: unknown
Intended Status: Experimental

Summary:
=3D=3D=3D=3D=3D=3D=3D=3D

=C2=A0 =C2=A0 I have some concerns about this document and recommend that t= he
=C2=A0 =C2=A0 Routing ADs discuss these issues further with the authors.
Comments:
=3D=3D=3D=3D=3D=3D=3D=3D=3D

=C2=A0 =C2=A0 While I believe that the document is for the most part readab= le and
=C2=A0 =C2=A0 understandable, I believe it still requires better or more de= finitions,
=C2=A0 =C2=A0 clarifications, and/or additional text before becoming an RFC= .

Major Issues:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

[section "2.=C2=A0 Terminology"]

=C2=A0 =C2=A0 - An edge router is defined as a router with internal and ext= ernal adjacencies.
=C2=A0 =C2=A0 (and referred to this way later in the text as well). Is this= the actual
=C2=A0 =C2=A0 definition or is it instead when a router has links that are = and are not
=C2=A0 =C2=A0 configured as TTZ internal? This makes a big difference b/c t= he former case
=C2=A0 =C2=A0 is very dynamic while the latter is static. One could imagine= in the former
=C2=A0 =C2=A0 case that a router is configured to be within a TTZ and then = by virtue of
=C2=A0 =C2=A0 who it becomes adjacent with determines whether it is interna= l or edge.
=C2=A0 =C2=A0 While this makes configuration very simple I think it also ha= s a big impact
=C2=A0 =C2=A0 on the complexity of the protocol interactions.

=C2=A0 =C2=A0 After reading section 11.1 "Configuring TTZ" which = proposes "some options
=C2=A0 =C2=A0 for configuring a TTZ", it certainly seems that the inte= ntion is for links
=C2=A0 =C2=A0 to be determined to be within a TTZ or not based only on conf= iguration. If
=C2=A0 =C2=A0 this is indeed the case I think this needs to be stated up fr= ont and very
=C2=A0 =C2=A0 clearly, and I would suggest changing all the text in "2= . Terminology" to
=C2=A0 =C2=A0 talk about configuration instead of adjacencies. For example:=

=C2=A0 =C2=A0 "TTZ link or TTZ internal link: a link configured to be = inside the TTZ."

=C2=A0 =C2=A0 "TTZ external link: a link not configured to be within a= TTZ"

=C2=A0 =C2=A0 "TTZ internal router: a router configured with only TTZ = internal links."

=C2=A0 =C2=A0 "TTZ external router: a router with no configured TTZ in= ternal links"

=C2=A0 =C2=A0 "TTZ edge router: a router configured with both TTZ inte= rnal and TTZ
=C2=A0 =C2=A0 external links."

[section "7.=C2=A0 Constructing LSAs for TTZ" paragraph 6 and 7]<= br>
=C2=A0 =C2=A0... "The cost of the link is the cost of the shortest pat= h from this TTZ edge
=C2=A0 =C2=A0router to the other TTZ edge router within the TTZ."

=C2=A0 =C2=A0"In addition, the LSA may contain a third group of links,= which are the stub
=C2=A0 =C2=A0links for the loopback addresses inside the TTZ to be accessed= by nodes
=C2=A0 =C2=A0outside of the TTZ."

=C2=A0 =C2=A0- So basically every SPF from a TTZ internal topology change c= an lead to new
=C2=A0 =C2=A0edge router LSAs being advertised throughout the area to adjus= t the "virtual"
=C2=A0 =C2=A0routing link costs. This is noteworthy because while you'v= e hidden state
=C2=A0 =C2=A0using the TTZ, the dynamics of the network haven't gotten = simpler rather
=C2=A0 =C2=A0they've gotten more complex, as changes are now cascading = rather than being
=C2=A0 =C2=A0singular. This is an interesting trade-off choosing perpetual = run-time and
=C2=A0 =C2=A0protocol complexity in order to avoid the one time cost of new= area creation.
=C2=A0 =C2=A0Would it be worth actually pointing out these costs of using T= TZ?

[section "7.=C2=A0 Constructing LSAs for TTZ" paragraph 8]

=C2=A0 =C2=A0 =C2=A0"To migrate to a TTZ smoothly, a TTZ edge router v= irtualizes the TTZ in two
=C2=A0 =C2=A0 =C2=A0steps. At first, the router updates its normal router L= SA by adding a
=C2=A0 =C2=A0 =C2=A0point-to-point link to each of the other edge routers o= f the TTZ and a stub
=C2=A0 =C2=A0 =C2=A0link for each of the loopback addresses in the TTZ to b= e accessed outside
=C2=A0 =C2=A0 =C2=A0of the TTZ into the LSA. And then it removes the links = configured as TTZ
=C2=A0 =C2=A0 =C2=A0links from its updated router LSA after sending its upd= ated router LSA and
=C2=A0 =C2=A0 =C2=A0receiving the updated router LSAs originated by the oth= er TTZ edge routers
=C2=A0 =C2=A0 =C2=A0for MaxLSAAdvTime or after sending its updated router L= SA for
=C2=A0 =C2=A0 =C2=A0MaxLSAGenAdvTime (refer to Appendix A)."

=C2=A0 =C2=A0In order to be sure I understood this I basically broke it apa= rt and put it together
=C2=A0 =C2=A0again with possibly incorrect reductions. I ended up with:

=C2=A0 =C2=A0 =C2=A0To migrate to a TTZ smoothly, a TTZ edge router virtual= izes the TTZ in two steps:

=C2=A0 =C2=A0 =C2=A0Step 1: The router updates its router LSA by adding a p= oint-to-point link
=C2=A0 =C2=A0 =C2=A0to each of the other known edge routers in the TTZ, and= also by adding the
=C2=A0 =C2=A0 =C2=A0stub links advertised by TTZ internal routers.

=C2=A0 =C2=A0 =C2=A0Step 2: After RMaxLSAAdvTime (.1 seconds) or MaxLSAGenA= dvTime (.3 seconds)
=C2=A0 =C2=A0 =C2=A0remove the TTZ links from its router LSA.

[section "10.=C2=A0 Computation of Routing Table"

=C2=A0 =C2=A0The text says to ignore *all* links from a TTZ edge routers ro= uter LSA. This
=C2=A0 =C2=A0presumably works b/c the SPF is also going to use the advertis= ed TTZ Router
=C2=A0 =C2=A0LSA instead. Shouldn't the fact that the SPF should using = the new TTZ Router
=C2=A0 =C2=A0LSA be stated somewhere as well?

Minor Issues:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

[section: "Introduction" 2nd paragraph]

=C2=A0 =C2=A0 The initial sentence makes an assertion about complexity and = time
=C2=A0 =C2=A0 consumption for area creation. The following sentence does no= t back this
=C2=A0 =C2=A0 assertion up but merely describes the act of creating a new a= rea. I found
=C2=A0 =C2=A0 this less than compelling.

[section: "2. Terminology"]

=C2=A0 =C2=A0 This need not be addressed here but it's where I had the = question: Can a
=C2=A0 =C2=A0 TTZ edge router be in more than one TTZ?

[section "5.1.=C2=A0 Overview of Topology-Transparent Zone" 3rd p= aragraph ]

=C2=A0 =C2=A0 "In addition to having the functions of an OSPF area&quo= t;, is this actually the
=C2=A0 =C2=A0 case? That is, is a TTZ really a superset of OSPF area functi= onality? I'm
=C2=A0 =C2=A0 pretty sure it is not.

[section "5.1.=C2=A0 Overview of Topology-Transparent Zone" Bulle= t 1]

=C2=A0 =C2=A0"o=C2=A0 An OSPF TTZ is virtualized as the TTZ edges conn= ected each other."

=C2=A0 =C2=A0This is a very important bullet as it actually will describe w= hat a TTZ
=C2=A0 =C2=A0really is. As such I'd suggest more precise text here. For= example:

=C2=A0 =C2=A0"o An OSPF TTZ represents a set of TTZ internal routers a= s a full mesh of
=C2=A0 =C2=A0virtual links between the TTZ edge routers."

=C2=A0 =C2=A0?

[section "5.1.=C2=A0 Overview of Topology-Transparent Zone" Bulle= t 2]

=C2=A0 =C2=A0"An OSPF TTZ receives the link state information about th= e
=C2=A0 =C2=A0topology outside of the TTZ, stores the information in the TTZ= and floods the
=C2=A0 =C2=A0information through the TTZ to the routers outside of the TTZ.= "

=C2=A0 =C2=A0This bullet is a bit clunky to read. Perhaps something more di= rect like:

=C2=A0 =C2=A0"Non-TTZ link state information is handled as normal (i.e= ., it is not
=C2=A0 =C2=A0filtered or modified by a TTZ)"

=C2=A0 =C2=A0If you want to keep the original text then a couple nits:

=C2=A0 =C2=A0"An OSPF TTZ receives" =3D> "TTZ Routers rec= eive"

=C2=A0 =C2=A0"stores the information in the TTZ and floods" =3D&g= t; "store the information, and flood"

[section: "6.1.=C2=A0 General Format of TTZ LSA" paragraph 3]

=C2=A0 =C2=A0"A TTZ LSA having an optional TTZ Router TLV is called a = TTZ Router LSA. A TTZ
=C2=A0 =C2=A0LSA containing a TTZ Options TLV is called a TTZ Control LSA.&= quot;

=C2=A0 =C2=A0Can these ever be combined? By naming them distinctly like thi= s, it seems to
=C2=A0 =C2=A0be exclusive, if this is the case that should probably be more= clearly
=C2=A0 =C2=A0defined.

=C2=A0 =C2=A0In general I think more expansion and clarity here is in order= . Instead of
=C2=A0 =C2=A0talking about LS Type 10/9 with a note about type 10. Why not = discuss each type:
=C2=A0 =C2=A0- LS Type 9 "Link local scope" when it is used, and = what is optional and mandatory in it.
=C2=A0 =C2=A0- LS Type 10 "Area scope" when it is used, and what = is optional and mandatory in it.

[section "6.3.=C2=A0 TTZ Router TLV" paragraph 1]

=C2=A0 =C2=A0"The format of a TTZ Router TLV is as follows.=C2=A0 It c= ontains the
=C2=A0 =C2=A0contents of a router LSA."

=C2=A0 =C2=A0Is this trying to say:

=C2=A0 =C2=A0"It has the same content as a standard OSPF Router LSA (R= FC x-ref) with the
=C2=A0 =C2=A0following modifications"?

[section "6.3.=C2=A0 TTZ Router TLV" TLV content]

=C2=A0 =C2=A0Given the existence of the TLV-Length, is the "# links&qu= ot; field redundant? What
=C2=A0 =C2=A0happens if they correctly correlate?

[section "6.4.=C2=A0 TTZ Options TLV" "flags"]

=C2=A0 =C2=A0So "exclusive" =3D> "mutually exclusive"= ;?

=C2=A0 =C2=A0If this is the case these aren't really flags but rather o= ne of 4 possible
=C2=A0 =C2=A0values (I believe in the all 0 case the TLV is not advertised?= ), and if so it
=C2=A0 =C2=A0would be much better to simply define the 4 possible values us= ing 2 bits.

=C2=A0 =C2=A0What happens if more than one bit is set to 1?

[section "7.=C2=A0 Constructing LSAs for TTZ" paragraph 3]

=C2=A0 =C2=A0This text can be read to indicate that for TTZ internal router= s the router's
=C2=A0 =C2=A0normal Router LSA content is copied into a TTZ Router TLV, doe= s the router
=C2=A0 =C2=A0also advertise its Router LSA as normal or is that then suppre= ssed? It's not
=C2=A0 =C2=A0clear to me why this information needs copying, and so I'm= wondering if the
=C2=A0 =C2=A0text is saying that no TTZ Router TLV is included, and that th= e TTZ internal
=C2=A0 =C2=A0router just advertises it's regular OSPF Router LSA.

=C2=A0 =C2=A0The text could be more explicit. Also some of my confusion ste= ms from earlier
=C2=A0 =C2=A0defining a "TTZ Router LSA" as one containing an &qu= ot;optional TTZ Router TLV".
=C2=A0 =C2=A0So when the text here refers to the LSA as a TTZ Router LSA on= e might assume
=C2=A0 =C2=A0that the optional TTZ Router TLV must be present.

=C2=A0 =C2=A0Perhaps this gets back to my want for better separating and de= fining
=C2=A0 =C2=A0the LS Types and contents.

[section "7.=C2=A0 Constructing LSAs for TTZ" paragraph 4 and 9]<= br>
=C2=A0 =C2=A0"After receiving a trigger to migrate to TTZ such as a TT= Z LSA with
=C2=A0 =C2=A0flag M =3D 1, a TTZ edge router originates its normal router L= SA for
=C2=A0 =C2=A0virtualizing a TTZ, which comprises three groups of links in g= eneral."

=C2=A0 =C2=A0"To roll back from a TTZ smoothly after receiving a trigg= er to roll
=C2=A0 =C2=A0back from TTZ, ..."

=C2=A0 =C2=A0- Triggers are mentioned a few times throughout the text. I th= ink the
=C2=A0 =C2=A0 =C2=A0triggers meaning, rather than being initially implied, = should be explicit
=C2=A0 =C2=A0 =C2=A0defined early and in 1 location. It isn't until sec= tion 11.2 that I thought
=C2=A0 =C2=A0 =C2=A0I understood what triggers were and how they worked.
=C2=A0 =C2=A0 =C2=A0Actually the triggers are defined in section 6.4, but t= he text there never
=C2=A0 =C2=A0 =C2=A0actually uses the word "trigger". I suggest t= hat this be changed so that it
=C2=A0 =C2=A0 =C2=A0is clear what a trigger is prior to the use of the term= .

[section "8.1.=C2=A0 Discover TTZ Neighbors" paragraph 2]

=C2=A0 =C2=A0"If two ends of the link have different TTZ IDs, no TTZ a= djacency over
=C2=A0 =C2=A0the link will be "formed"."

=C2=A0 =C2=A0- In general I'm somewhat confused about the actual defini= tion of a TTZ
=C2=A0 =C2=A0 =C2=A0adjacency. How does it compare to a normal protocol adj= acency. In the above
=C2=A0 =C2=A0 =C2=A0case you would have a protocol adjacency I believe, but= no TTZ adjacency?
=C2=A0 =C2=A0 =C2=A0How is this link advertised if the router is a TTZ edge= router?

[section "8.1.=C2=A0 Discover TTZ Neighbors" paragraph 5]

=C2=A0 =C2=A0The text talks about when (Z=3D=3D0 and there is a TTZ LSA wit= h T=3D1) or Z=3D=3D1. Where
=C2=A0 =C2=A0are all the places that T=3D1 is showing up? What about the ca= se when an
=C2=A0 =C2=A0adjacency is forming when M=3D1 instead of T=3D1?

[section "8.1.=C2=A0 Discover TTZ Neighbors" paragraph 7]

=C2=A0 =C2=A0Since the diagram state Zs are the same, it no longer applies = to the rest of
=C2=A0 =C2=A0section 8. Is it worthwhile to have a new diagram here for cla= rity?

[section "8.1.=C2=A0 Discover TTZ Neighbors" paragraph 8]

=C2=A0 =C2=A0Here's a mention of "triggers B to migrate", I t= hink you probably should
=C2=A0 =C2=A0state explicitly what this means, which I *think* is:

=C2=A0 =C2=A0"A also sends a D-LSA containing a TTZ Control TLV with M= =3D1 to B, triggering
=C2=A0 =C2=A0it to migrate."

=C2=A0 =C2=A0Although this now makes me wonder what does B do on receiving = M=3D1 if it had
=C2=A0 =C2=A0not received or been configured for T=3D1 yet?

[section "8.1.=C2=A0 Discover TTZ Neighbors" paragraph 9]

=C2=A0 =C2=A0I would break this paragraph up to make clear that 2 distinct = things are
=C2=A0 =C2=A0happening based on 2 different events. So:

=C2=A0 =C2=A0"When B receives the D-LSA from A and determines they hav= e the same
=C2=A0 =C2=A0TTZ ID but its Z=3D0 and A's Z=3D1, B sends A all the TTZ = LSAs it has and
=C2=A0 =C2=A0starts to migrate to TTZ after receiving A's D-LSA with M= =3D1.=C2=A0 After
=C2=A0 =C2=A0migration to TTZ, B updates and advertises its LSAs as needed.= "

=C2=A0 =C2=A0becomes:

=C2=A0 =C2=A0"When B receives the D-LSA from A and determines they hav= e the same
=C2=A0 =C2=A0TTZ ID but its Z=3D0 and A's Z=3D1, B sends A all the TTZ = LSAs it has."

=C2=A0 =C2=A0"When B receives the D-LSA from A with M=3D1 it starts to= migrate to TTZ. After
=C2=A0 =C2=A0migration to TTZ, B updates and advertises its LSAs as needed.= "

=C2=A0 =C2=A0Does "starts to migrate" here simply means B starts = setting it's M=3D1 as
=C2=A0 =C2=A0well?

=C2=A0 =C2=A0What exactly is happening for B to go from "starts to mig= rate" to "After
=C2=A0 =C2=A0migration"? I believe this is indicated by Z=3D0 transiti= oning to Z=3D1 (is the
=C2=A0 =C2=A0TTZ Control TLV with M=3D1 also removed from the D-LSA?)

=C2=A0 =C2=A0What LSAs are being updated and advertised by B here?

[section "8.1.=C2=A0 Discover TTZ Neighbors" paragraph 10]

=C2=A0 =C2=A0"After receiving B's D-LSA with Z=3D1, A updates and = sends B its D-LSA
=C2=A0 =C2=A0by removing the Options TLV.=C2=A0 It also updates and adverti= ses its LSAs
=C2=A0 =C2=A0as needed."

=C2=A0 =C2=A0What LSAs are being updated and advertised by A here?

[section "8.1.=C2=A0 Discover TTZ Neighbors" in general]

=C2=A0 =C2=A0Are D-LSA sent periodically, if so how often, if not when prec= isely are they
=C2=A0 =C2=A0sent?

=C2=A0 =C2=A0What happens when B changes its TTZ ID or doesn't send a D= -LSA?

[section "8.1.=C2=A0 Discover TTZ Neighbors" Broadcast and NBMA p= art (i.e., paragraph 11+)]

[section "8.1.=C2=A0 Discover TTZ Neighbors" paragraph 12]

=C2=A0 =C2=A0So the mis-configured router behavior is dependent on when the= mis-configured
=C2=A0 =C2=A0router is introduced? If introduced prior to any adjacency for= mation then its
=C2=A0 =C2=A0presence will keep all routers from becoming TTZ adjacent, oth= erwise only
=C2=A0 =C2=A0itself will not have become TTZ adjacent?

=C2=A0 =C2=A0What does mis-configured mean, a different TTZ ID? What about = the lack of the
=C2=A0 =C2=A0receipt of a D-LSA on the link? How long does the DR wait for = receipt of a
=C2=A0 =C2=A0D-LSA from each neighbor before deciding it won't be recei= ving one and the
=C2=A0 =C2=A0neighbor is not configured on this link as part of TTZ?

[section "8.1.=C2=A0 Discover TTZ Neighbors" last paragraph]

=C2=A0 =C2=A0Is this just saying: "routers only TTZ discover after for= ming a normal
=C2=A0 =C2=A0adjacency"?

[section "9.1.=C2=A0 Advertisement of LSAs within TTZ" paragraph = 2]

=C2=A0 =C2=A0"Any network LSA generated for a broadcast or NBMA networ= k in a TTZ is
=C2=A0 =C2=A0advertised within the TTZ."

=C2=A0 =C2=A0[nit: And not outside? This is explicit for the router LSA.]
=C2=A0 =C2=A0What happens when a DR has a mis-configured router on a broadc= ast network and
=C2=A0 =C2=A0thus is not forming a TTZ adjacency with it? It still has a no= rmal adjacency
=C2=A0 =C2=A0right? So it no has a network LSA that includes both TTZ and n= on-TTZ routers
=C2=A0 =C2=A0where does it advertise this network LSA?

[section "11.2.=C2=A0 Smooth Migration to TTZ" paragraph 5]

=C2=A0 =C2=A0I was confused by many mentions earlier in the document to a r= outer migrating
=C2=A0 =C2=A0to a TTZ. I think what paragraph 5 in section 11.2 is saying (= in too many
=C2=A0 =C2=A0words) is this:

=C2=A0 =C2=A0"Migrating to a TTZ" means a router advertises a TTZ= Control TLV with M=3D1. A
=C2=A0 =C2=A0router "Migrates to a TTZ" either when configured to= do so or when it
=C2=A0 =C2=A0receives a TTZ Control TLV with M=3D1.

=C2=A0 =C2=A0If this is the case then I think something like the above text= should occur
=C2=A0 =C2=A0earlier in the document.

[section "11.3.=C2=A0 Adding a Router into TTZ" paragraph 3]

=C2=A0 =C2=A0I don't understand the intent of this paragraph. Is it jus= t saying that if
=C2=A0 =C2=A0TTZ is configured on a link between 2 non-adjacent routers, wh= en they
=C2=A0 =C2=A0eventually become adjacent they will also form a TTZ adjacency= ?

[section "13.=C2=A0 Security Considerations"]

=C2=A0 =C2=A0This seems a bit weak or perhaps just wrong. Perhaps better wo= uld be to say
=C2=A0 =C2=A0that TTZ relies on the OSPF security mechanisms in place and h= as the same
=C2=A0 =C2=A0security threat surface?

Nits:
=3D=3D=3D=3D=3D

[section: "2. Terminology" 3rd item]

=C2=A0 =C2=A0"TTZ external router: a router outside of a TTZ without a= ny TTZ
=C2=A0 =C2=A0internal link."

=C2=A0 =C2=A0=3D>

=C2=A0 =C2=A0"TTZ external router: a router outside of a TTZ that has = no TTZ
=C2=A0 =C2=A0internal links."

[section: "2. Terminology" 4th item]

=C2=A0 =C2=A0Move below 5th item that it references

[section "4. Requirements" 1st paragraph]

=C2=A0 =C2=A0 - "*A* Topology-Transparent Zone"
=C2=A0 =C2=A0 - "for *a* TTZ"

[section "5.1.=C2=A0 Overview of Topology-Transparent Zone" 1st p= aragraph ]

=C2=A0 =C2=A0 Define and use TTZ ID, rather than just "(ID)" as t= hat is what the rest of
=C2=A0 =C2=A0 the document refers to this as, and is more specific anyway.<= br>
[section "5.2.=C2=A0 Some Details on TTZ" paragraph 4]

=C2=A0 =C2=A0"Note that none of the TTZ internal routers can be an ABR= ."

=C2=A0 =C2=A0=3D>

=C2=A0 =C2=A0"Note that by definition a TTZ internal router cannot als= o be an ABR."

[section "6.4.=C2=A0 TTZ Options TLV" paragraph 2]

=C2=A0 =C2=A0"as needed" =3D> "as described below"?<= br>

[section "6.5.=C2=A0 Link Scope TTZ LSA" diagram and paragraph 1]=

=C2=A0 =C2=A0"Options TLV" =3D> "TTZ Options TLV" (a= nd all other uses?)

[section "8.=C2=A0 Establishing Adjacencies"]

=C2=A0 =C2=A0"This section describes the adjacencies in different case= s."

=C2=A0 =C2=A0=3D>

=C2=A0 =C2=A0"This section describes the TTZ adjacencies."

[section "8.1.=C2=A0 Discover TTZ Neighbors" multiple paragraphs]=

=C2=A0 =C2=A0"discover TTZ each other" =3D> "TTZ discover= each other"

[various section "8.1.=C2=A0 Discover TTZ Neighbors" ...]

=C2=A0 =C2=A0Text uses <bit>=3D<value> and <bit>=3D=3D<= ;value> but in both cases it means
=C2=A0 =C2=A0equality check, not assignment, pick and use one consistently = in the
=C2=A0 =C2=A0document.

=C2=A0 =C2=A0On the use of parenthesis, the text is using parenthesis as a = form of
=C2=A0 =C2=A0grouping as one might in mathematics which I'm not sure is= proper.
=C2=A0 =C2=A0Parenthesis in writing are generally used as an aside. Probabl= y the clearest
=C2=A0 =C2=A0way to indicate the logical grouping would be to use a list, e= .g.,

=C2=A0 =C2=A0When one of the following conditions is met.

=C2=A0 =C2=A0 =C2=A0- Z =3D 0 and there is a TTZ Options LSA with T =3D 1 =C2=A0 =C2=A0 =C2=A0- Z =3D 1

=C2=A0 =C2=A0...

[section "9.1.=C2=A0 Advertisement of LSAs within TTZ" paragraph = 1]

=C2=A0 =C2=A0"advertised within" =3D> "advertised only wi= thin"

[section "11.1.=C2=A0 Configuring TTZ" last paragraph]

=C2=A0 =C2=A0"the above one" =3D> "option 1"

[section "11.3.=C2=A0 Adding a Router into TTZ" paragraph 1]

=C2=A0 =C2=A0"When a non TTZ router (say R1) is connected via a P2P li= nk to a TTZ
=C2=A0 =C2=A0router (say T1) working as TTZ and there is a normal adjacency=
=C2=A0 =C2=A0between them over the link, a user can configure TTZ on two en= ds of
=C2=A0 =C2=A0the link to add R1 into the TTZ to which T1 belongs.=C2=A0 The= y discover
=C2=A0 =C2=A0TTZ each other with the TTZ as described in section 8."
=C2=A0 =C2=A0=3D>

=C2=A0 =C2=A0"When a non TTZ router (say R1) is connected via a P2P li= nk to a migrated TTZ
=C2=A0 =C2=A0router (say T1), and there is a normal adjacency between them = over the link,
=C2=A0 =C2=A0a user can configure TTZ on both ends of the link to add R1 in= to the TTZ to
=C2=A0 =C2=A0which T1 belongs. They TTZ discover each other as described in= section 8."

[section "11.3.=C2=A0 Adding a Router into TTZ" paragraph 2]

=C2=A0 =C2=A0"When a number of non TTZ routers are connected via a bro= adcast link
=C2=A0 =C2=A0to a TTZ router (say T1) working as TTZ and there are normal =C2=A0 =C2=A0adjacencies among them, a user configures TTZ on the connectio= n to
=C2=A0 =C2=A0the link on every router to add the non TTZ routers into the T= TZ to
=C2=A0 =C2=A0which T1 belongs.=C2=A0 The DR for the link "forms" = TTZ adjacencies with
=C2=A0 =C2=A0the other routers connected to the link if they all have the s= ame TTZ
=C2=A0 =C2=A0ID configured for the link.=C2=A0 This is determined through t= he discovery
=C2=A0 =C2=A0process described in section 8."

=C2=A0 =C2=A0=3D>

=C2=A0 =C2=A0"When non TTZ routers are connected via a broadcast or NB= MA link to a
=C2=A0 =C2=A0migrated TTZ router (say T1), and there are normal adjacencies= among them, a
=C2=A0 =C2=A0user configures TTZ on the connection to the link on every rou= ter to add the
=C2=A0 =C2=A0non TTZ routers into the TTZ to which T1 belongs. The DR for t= he link "forms"
=C2=A0 =C2=A0TTZ adjacencies with the other routers connected to the link i= f they all have
=C2=A0 =C2=A0the same TTZ ID configured for the link. This is determined th= rough the
=C2=A0 =C2=A0TTZ discovery process described in section 8."

[section "12.2.=C2=A0 Implementation Experience"]

=C2=A0 =C2=A0Convert IETF 90 to (or include) a date.

[section "14.=C2=A0 IANA Considerations"]

=C2=A0 =C2=A0While not requested in the text, a new registry needs to be cr= eated for the
=C2=A0 =C2=A0management of TTZ TLV types and so information regarding this = new registry in
=C2=A0 =C2=A0addition to the initial seed values is required.


--001a113e9f66bc410405317d17e4-- From nobody Wed Apr 27 22:31:56 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AD512D5B8 for ; Wed, 27 Apr 2016 22:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=ionosnetworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wr8XKIsFs5ev for ; Wed, 27 Apr 2016 22:31:52 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 095D512D1E5 for ; Wed, 27 Apr 2016 22:31:52 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id m188so19358191vka.1 for ; Wed, 27 Apr 2016 22:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ionosnetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=S/AeBiL0l0TntLHWLx1+0k7H2xG3h6lNsfGGbCFOUlg=; b=fm/URFz6YQi1o8LNVkhjh16iXa6wUymNjzfM0vAYSn5qqmaSos7EJyc9D6DclDV01e HAc1wEpuhbfduYGuWrlHsoEnnPwP1a+Hwry4mhcaJRjovT4ob1IPnmrM+ryMAPN/t0yO eF+bsnT+YCcEu6EN5gFwjpkmtmQj3beOYGCHutQSLZGncbj5PKybJ/4TILQjMRvbzN/l eBh3A82sRc8EN+llWAdjWrnyvGXLlFvjmFxvrDPBeUp4f7lYEIbnpDmNjDC+YWoQKNCf uzuQ9k+hSzK/bao5T0z6lXY05pn6XhUhJyg1hQ/Yah31Ilct6ozjmLm3XwWMQVrwvJeH g05A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=S/AeBiL0l0TntLHWLx1+0k7H2xG3h6lNsfGGbCFOUlg=; b=mJKacPil1vhXt4Z6qrB6xRog0/uHhTAtGyUPtjFbOv8IfdbeFKqAoQX1NDHA2yOEm2 DswesaReJrF4E69IXCICF+3FgpRkv4ew6ZrwASE6mgiAUMVEJj4dK+ZrM2FSPGOA34pc mvyit4vAC4q0TF8+XgGOZcfQtNZhLFnAewwPBX54afuqff1W+GtFung+FafgZzP/R73a lxzMqLS9H4kylao8ZgHNfNEyoTTDM8he26ButsuAISe/HFBYUuL3DJs4sZKY5oi/+Yjs rui+2XCOw5xZ4Y6tp0QhbHhRF3LI9GGezrnkjk8VIbFh6da52nx1PkrlrjthwBK4dHdN JQng== X-Gm-Message-State: AOPr4FUGYn6Iv17NsFv9b/dRTqAqlnUDeeIHBiCa3RneJNkUAVpTwxSKSP0pKbNweqBTR+CNV6kDYNG4g1uAcw== MIME-Version: 1.0 X-Received: by 10.159.39.194 with SMTP id b60mr6443757uab.151.1461821511026; Wed, 27 Apr 2016 22:31:51 -0700 (PDT) Received: by 10.31.129.73 with HTTP; Wed, 27 Apr 2016 22:31:50 -0700 (PDT) In-Reply-To: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk> References: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk> Date: Thu, 28 Apr 2016 11:01:50 +0530 Message-ID: From: Manav Bhatia To: Adrian Farrel Content-Type: multipart/alternative; boundary=94eb2c048150e3ed0a053184d7a1 Archived-At: Cc: "" , "rtg-dir@ietf.org" , draft-ietf-ospf-sbfd-discriminator.all@ietf.org, OSPF WG List Subject: Re: [OSPF] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 05:31:54 -0000 --94eb2c048150e3ed0a053184d7a1 Content-Type: text/plain; charset=UTF-8 Hi Adrian, Thanks for the extensive review. I have a minor comment on a minor issue that you raised. > Minor Issues: > > I should like to see some small amount of text on the scaling impact on > OSPF. 1. How much additional information will implementations have to > store per node/link in the network? 2. What is the expected churn in > LSAs introduced by this mechanism (especially when the Reflector is > turned on and off)? > Isnt this implementation specific? This is what will differentiate one vendor implementation from the other. I am not sure how we can quantify this -- any ideas? This is akin to saying that IS-IS, in contrast to OSPFv2, is more attuned for partial SPF runs because the node information is cleanly separated from the reachability information. However, this isnt entirely true. While i concede that node information is mixed with prefix information in OSPFv2, there still are ways in which clever implementations could separate the two and do exactly what IS-IS does. I took this rather circuitous approach to drive home the point that scalability, churn, overheads on the system are in many cases dependent on the protocol implementation and by that token outside the scope of the IETF drafts. > You *do* have... > A change in information in the S-BFD Discriminator TLV MUST NOT > trigger any SPF computation at a receiving router. > ...which is a help. > I would be alarmed if an implementation in an absence of this pedantic note triggered SPF runs each time an S-BFD disc changed ! I mean if you understand the idea being discussed then you also understand that a change in this TLV has no bearing on the reachability anywhere. And that knowledge should be enough to prevent SPF runs in most cases ! I know that we have added this note but if we need to explicitly spell such things out in all standards then we clearly have bigger problems ! :-) Cheers, Manav > --94eb2c048150e3ed0a053184d7a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adrian,

Thanks for the ex= tensive review. I have a minor comment on a minor issue that you raised.


Minor Issues:

I should like to see some small amou= nt of text on the scaling impact on
OSPF. 1. How much additional informa= tion will implementations have to
store per node/link in the network? 2.= What is the expected churn in
LSAs introduced by this mechanism (especi= ally when the Reflector is
turned on and off)?

=
Isnt this implementation specific? This is what will differentia= te one vendor implementation from the other.=C2=A0

I am not sure how we can quantify this -- any ideas?

<= div>This is akin to saying that IS-IS, in contrast to OSPFv2, is more attun= ed for partial SPF runs because the node information is cleanly separated f= rom the reachability information. However, this isnt entirely true. While i= concede that node information is mixed with prefix information in OSPFv2, = there still are ways in which clever implementations could separate the two= and do exactly what IS-IS does.=C2=A0

I took this= rather circuitous approach to drive home the point that scalability, churn= , overheads on the system are in many cases dependent on the protocol imple= mentation and by that token outside the scope of the IETF drafts.


You *do* have...
=C2=A0 =C2=A0A change i= n information in the S-BFD Discriminator TLV MUST NOT
=C2=A0 =C2=A0trigg= er any SPF computation at a receiving router.
...which is a help.

I would be alarmed if an implementation in an= absence of this pedantic note triggered SPF runs each time an S-BFD disc c= hanged ! I mean if you understand the idea being discussed then you also un= derstand that a change in this TLV has no bearing on the reachability anywh= ere. And that knowledge should be enough to prevent SPF runs in most cases = !=C2=A0

I know that we have added this note but if= we need to explicitly spell such things out in all standards then we clear= ly have bigger problems ! :-)

Cheers, Manav
<= /div>



--94eb2c048150e3ed0a053184d7a1-- From nobody Wed Apr 27 23:32:49 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7058112D11D; Wed, 27 Apr 2016 23:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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.996, 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 lMzrWeTJ7yE3; Wed, 27 Apr 2016 23:32:45 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC2BE12B027; Wed, 27 Apr 2016 23:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17040; q=dns/txt; s=iport; t=1461825165; x=1463034765; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kIuPWJ3OJr8UwbBB7YRjDUmR9c3wYsHI3TECJhoNnIo=; b=FdrINMg4l9bAJBVFuMZfkdi8tmmjUGRoZd6C4uPCnImqHcKh3OnnHics rGeAxY14ydf/O2ou+bYyjvwGktSbbmBaHvKzCCASkHV0LKZIrTyeIghnA IddvMASl9phCFYNiekuqaL1yyhnPMFBh+IMSrX4gCQtjMas9vp24yDqtu I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQAvriFX/5RdJa1egmxMU30GtHqEc?= =?us-ascii?q?wENgXYihW0CHIEUOBQBAQEBAQEBZSeEQQEBAQQjCkwQAgEIEQQBASgDAgICMBQ?= =?us-ascii?q?JCAIEAQ0FCIgiDrFokR0BAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYhhEuEVB+CS?= =?us-ascii?q?oJWBYVojTeEcQGFe4VjgjGPGI8vAR4BAUKDa2yIN38BAQE?= X-IronPort-AV: E=Sophos; i="5.24,545,1454976000"; d="scan'208,217"; a="98732771" 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; 28 Apr 2016 06:32:40 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3S6WeWJ008403 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 06:32:40 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Apr 2016 01:32:40 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Thu, 28 Apr 2016 01:32:39 -0500 From: "Les Ginsberg (ginsberg)" To: Manav Bhatia , Adrian Farrel Thread-Topic: [RTG-DIR] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt Thread-Index: AQHRoQ9WY8DoqBN170GaQg+1of41EZ+e6t5A Date: Thu, 28 Apr 2016 06:32:39 +0000 Message-ID: <2ed8fd52aff748878d16a7086035ecf2@XCH-ALN-001.cisco.com> References: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.14.223] Content-Type: multipart/alternative; boundary="_000_2ed8fd52aff748878d16a7086035ecf2XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "" , "rtg-dir@ietf.org" , "draft-ietf-ospf-sbfd-discriminator.all@ietf.org" , OSPF WG List Subject: Re: [OSPF] [RTG-DIR] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 06:32:46 -0000 --_000_2ed8fd52aff748878d16a7086035ecf2XCHALN001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWRyaWFuIOKAkw0KDQpBcyBhbiBpbnRlcmVzdGVkIGJ5c3RhbmRlciAoZ2l2ZW4gSSBhbSBjby1h dXRob3Igb24gdGhlIGNvbXBhbmlvbiBJUy1JUyBTLUJGRCBkcmFmdCkgSSBzaGFyZSB0aGUgY29u Y2VybnMgZXhwcmVzc2VkIGJ5IENhcmxvcyBhbmQgTWFuYXYuDQoNCkNodXJuaW5nIFMtQkZEIGRp c2NyaW1pbmF0b3IgYXNzaWdubWVudHMgaXMgYWJvdXQgYXMgbGlrZWx5IGFzIGNodXJuaW5nIElQ L0lQdjYgYWRkcmVzcyBhc3NpZ25tZW50cyBvbiBhIG5vZGUg4oCTIGl0IGlzIHNpbXBseSBub3Qg c29tZXRoaW5nIHRoYXQgYW55IGRlcGxveW1lbnQgd291bGQgYmUgbGlrZWx5IHRvIGRvLg0KSUdQ IGRyYWZ0cyBwYXkgY2xvc2UgYXR0ZW50aW9uIHRvIGNodXJuIGZvciBhZHZlcnRpc2VtZW50cyBv ZiBpbmZvcm1hdGlvbiB3aGljaCBpcyBleHBlY3RlZCB0byBiZSBkeW5hbWljIC0gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pc2lzLXRlLW1ldHJpYy1leHRlbnNp b25zLyBpcyBhIGdvb2QgZXhhbXBsZSBvZiB0aGlzLiBCdXQgdGhlcmUgaXMgbm8gcmVhc29uIHRv IGV4cGVjdCBhIHNpbWlsYXIgaXNzdWUgd2l0aCBTLUJGRCBkaXNjcmltaW5hdG9ycy4gVGhlcmVm b3JlLCBmb3IgdGhlIHNhbWUgcmVhc29ucyB0aGF0IGJhc2UgcHJvdG9jb2wgc3BlY2lmaWNhdGlv bnMgZG8gbm90IGRpc2N1c3MgdGhlIGltcGFjdCBvZiBjaHVybiBpbiBhZHZlcnRpc2luZyBwcmVm aXggcmVhY2hhYmlsaXR5IHdlIHNhdyBubyByZWFzb24gdG8gZGlzY3VzcyBpdCBpbiB0aGUgY29u dGV4dCBvZiBhZHZlcnRpc2luZyBTLUJGRCBkaXNjcmltaW5hdG9ycy4NCg0KSXQgd291bGQgYmUg aGVscGZ1bCBpZiB5b3UgcHJvdmlkZWQgc29tZSBjb250ZXh0IGFzIHRvICB3aHkgeW91IGhhdmUg cmFpc2VkIHRoaXMgcG9pbnQuDQpUaGFueC4NCg0KICAgTGVzDQoNCkZyb206IHJ0Zy1kaXIgW21h aWx0bzpydGctZGlyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYW5hdiBCaGF0aWEN ClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjcsIDIwMTYgMTA6MzIgUE0NClRvOiBBZHJpYW4gRmFy cmVsDQpDYzogPHJ0Zy1hZHNAaWV0Zi5vcmc+OyBydGctZGlyQGlldGYub3JnOyBkcmFmdC1pZXRm LW9zcGYtc2JmZC1kaXNjcmltaW5hdG9yLmFsbEBpZXRmLm9yZzsgT1NQRiBXRyBMaXN0DQpTdWJq ZWN0OiBSZTogW1JURy1ESVJdIFJ0ZyBEaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb3NwZi1zYmZk LWRpc2NyaW1pbmF0b3ItMDQudHh0DQoNCkhpIEFkcmlhbiwNCg0KVGhhbmtzIGZvciB0aGUgZXh0 ZW5zaXZlIHJldmlldy4gSSBoYXZlIGEgbWlub3IgY29tbWVudCBvbiBhIG1pbm9yIGlzc3VlIHRo YXQgeW91IHJhaXNlZC4NCg0KDQpNaW5vciBJc3N1ZXM6DQoNCkkgc2hvdWxkIGxpa2UgdG8gc2Vl IHNvbWUgc21hbGwgYW1vdW50IG9mIHRleHQgb24gdGhlIHNjYWxpbmcgaW1wYWN0IG9uDQpPU1BG LiAxLiBIb3cgbXVjaCBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHdpbGwgaW1wbGVtZW50YXRpb25z IGhhdmUgdG8NCnN0b3JlIHBlciBub2RlL2xpbmsgaW4gdGhlIG5ldHdvcms/IDIuIFdoYXQgaXMg dGhlIGV4cGVjdGVkIGNodXJuIGluDQpMU0FzIGludHJvZHVjZWQgYnkgdGhpcyBtZWNoYW5pc20g KGVzcGVjaWFsbHkgd2hlbiB0aGUgUmVmbGVjdG9yIGlzDQp0dXJuZWQgb24gYW5kIG9mZik/DQoN CklzbnQgdGhpcyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYz8gVGhpcyBpcyB3aGF0IHdpbGwgZGlm ZmVyZW50aWF0ZSBvbmUgdmVuZG9yIGltcGxlbWVudGF0aW9uIGZyb20gdGhlIG90aGVyLg0KDQpJ IGFtIG5vdCBzdXJlIGhvdyB3ZSBjYW4gcXVhbnRpZnkgdGhpcyAtLSBhbnkgaWRlYXM/DQoNClRo aXMgaXMgYWtpbiB0byBzYXlpbmcgdGhhdCBJUy1JUywgaW4gY29udHJhc3QgdG8gT1NQRnYyLCBp cyBtb3JlIGF0dHVuZWQgZm9yIHBhcnRpYWwgU1BGIHJ1bnMgYmVjYXVzZSB0aGUgbm9kZSBpbmZv cm1hdGlvbiBpcyBjbGVhbmx5IHNlcGFyYXRlZCBmcm9tIHRoZSByZWFjaGFiaWxpdHkgaW5mb3Jt YXRpb24uIEhvd2V2ZXIsIHRoaXMgaXNudCBlbnRpcmVseSB0cnVlLiBXaGlsZSBpIGNvbmNlZGUg dGhhdCBub2RlIGluZm9ybWF0aW9uIGlzIG1peGVkIHdpdGggcHJlZml4IGluZm9ybWF0aW9uIGlu IE9TUEZ2MiwgdGhlcmUgc3RpbGwgYXJlIHdheXMgaW4gd2hpY2ggY2xldmVyIGltcGxlbWVudGF0 aW9ucyBjb3VsZCBzZXBhcmF0ZSB0aGUgdHdvIGFuZCBkbyBleGFjdGx5IHdoYXQgSVMtSVMgZG9l cy4NCg0KSSB0b29rIHRoaXMgcmF0aGVyIGNpcmN1aXRvdXMgYXBwcm9hY2ggdG8gZHJpdmUgaG9t ZSB0aGUgcG9pbnQgdGhhdCBzY2FsYWJpbGl0eSwgY2h1cm4sIG92ZXJoZWFkcyBvbiB0aGUgc3lz dGVtIGFyZSBpbiBtYW55IGNhc2VzIGRlcGVuZGVudCBvbiB0aGUgcHJvdG9jb2wgaW1wbGVtZW50 YXRpb24gYW5kIGJ5IHRoYXQgdG9rZW4gb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIElFVEYgZHJh ZnRzLg0KDQoNCllvdSAqZG8qIGhhdmUuLi4NCiAgIEEgY2hhbmdlIGluIGluZm9ybWF0aW9uIGlu IHRoZSBTLUJGRCBEaXNjcmltaW5hdG9yIFRMViBNVVNUIE5PVA0KICAgdHJpZ2dlciBhbnkgU1BG IGNvbXB1dGF0aW9uIGF0IGEgcmVjZWl2aW5nIHJvdXRlci4NCi4uLndoaWNoIGlzIGEgaGVscC4N Cg0KSSB3b3VsZCBiZSBhbGFybWVkIGlmIGFuIGltcGxlbWVudGF0aW9uIGluIGFuIGFic2VuY2Ug b2YgdGhpcyBwZWRhbnRpYyBub3RlIHRyaWdnZXJlZCBTUEYgcnVucyBlYWNoIHRpbWUgYW4gUy1C RkQgZGlzYyBjaGFuZ2VkICEgSSBtZWFuIGlmIHlvdSB1bmRlcnN0YW5kIHRoZSBpZGVhIGJlaW5n IGRpc2N1c3NlZCB0aGVuIHlvdSBhbHNvIHVuZGVyc3RhbmQgdGhhdCBhIGNoYW5nZSBpbiB0aGlz IFRMViBoYXMgbm8gYmVhcmluZyBvbiB0aGUgcmVhY2hhYmlsaXR5IGFueXdoZXJlLiBBbmQgdGhh dCBrbm93bGVkZ2Ugc2hvdWxkIGJlIGVub3VnaCB0byBwcmV2ZW50IFNQRiBydW5zIGluIG1vc3Qg Y2FzZXMgIQ0KDQpJIGtub3cgdGhhdCB3ZSBoYXZlIGFkZGVkIHRoaXMgbm90ZSBidXQgaWYgd2Ug bmVlZCB0byBleHBsaWNpdGx5IHNwZWxsIHN1Y2ggdGhpbmdzIG91dCBpbiBhbGwgc3RhbmRhcmRz IHRoZW4gd2UgY2xlYXJseSBoYXZlIGJpZ2dlciBwcm9ibGVtcyAhIDotKQ0KDQpDaGVlcnMsIE1h bmF2DQoNCg0KDQo= --_000_2ed8fd52aff748878d16a7086035ecf2XCHALN001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWRyaWFuIOKAkzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+QXMgYW4gaW50ZXJlc3RlZCBieXN0YW5kZXIgKGdpdmVuIEkgYW0gY28tYXV0aG9yIG9u IHRoZSBjb21wYW5pb24gSVMtSVMgUy1CRkQgZHJhZnQpIEkgc2hhcmUgdGhlIGNvbmNlcm5zIGV4 cHJlc3NlZCBieSBDYXJsb3MgYW5kIE1hbmF2LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2h1cm5pbmcgUy1CRkQgZGlz Y3JpbWluYXRvciBhc3NpZ25tZW50cyBpcyBhYm91dCBhcyBsaWtlbHkgYXMgY2h1cm5pbmcgSVAv SVB2NiBhZGRyZXNzIGFzc2lnbm1lbnRzIG9uIGEgbm9kZSDigJMgaXQgaXMgc2ltcGx5IG5vdCBz b21ldGhpbmcgdGhhdCBhbnkgZGVwbG95bWVudA0KIHdvdWxkIGJlIGxpa2VseSB0byBkby4gPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklHUCBkcmFmdHMgcGF5IGNsb3NlIGF0dGVudGlv biB0byBjaHVybiBmb3IgYWR2ZXJ0aXNlbWVudHMgb2YgaW5mb3JtYXRpb24gd2hpY2ggaXMgZXhw ZWN0ZWQgdG8gYmUgZHluYW1pYyAtDQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWlzaXMtdGUtbWV0cmljLWV4dGVuc2lvbnMvIj4NCmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaXNpcy10ZS1tZXRyaWMtZXh0ZW5z aW9ucy88L2E+IGlzIGEgZ29vZCBleGFtcGxlIG9mIHRoaXMuIEJ1dCB0aGVyZSBpcyBubyByZWFz b24gdG8gZXhwZWN0IGEgc2ltaWxhciBpc3N1ZSB3aXRoIFMtQkZEIGRpc2NyaW1pbmF0b3JzLiBU aGVyZWZvcmUsIGZvciB0aGUgc2FtZSByZWFzb25zIHRoYXQgYmFzZSBwcm90b2NvbCBzcGVjaWZp Y2F0aW9ucyBkbyBub3QgZGlzY3Vzcw0KIHRoZSBpbXBhY3Qgb2YgY2h1cm4gaW4gYWR2ZXJ0aXNp bmcgcHJlZml4IHJlYWNoYWJpbGl0eSB3ZSBzYXcgbm8gcmVhc29uIHRvIGRpc2N1c3MgaXQgaW4g dGhlIGNvbnRleHQgb2YgYWR2ZXJ0aXNpbmcgUy1CRkQgZGlzY3JpbWluYXRvcnMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5JdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBwcm92aWRlZCBzb21lIGNvbnRleHQgYXMgdG8g Jm5ic3A7d2h5IHlvdSBoYXZlIHJhaXNlZCB0aGlzIHBvaW50LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UaGFueC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBMZXM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcnRnLWRpciBbbWFpbHRvOnJ0Zy1kaXIt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWFuYXYgQmhhdGlhPGJyPg0K PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMjcsIDIwMTYgMTA6MzIgUE08YnI+DQo8Yj5U bzo8L2I+IEFkcmlhbiBGYXJyZWw8YnI+DQo8Yj5DYzo8L2I+ICZsdDtydGctYWRzQGlldGYub3Jn Jmd0OzsgcnRnLWRpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1vc3BmLXNiZmQtZGlzY3JpbWluYXRv ci5hbGxAaWV0Zi5vcmc7IE9TUEYgV0cgTGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1JU Ry1ESVJdIFJ0ZyBEaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb3NwZi1zYmZkLWRpc2NyaW1pbmF0 b3ItMDQudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5IaSBBZHJpYW4sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhlIGV4dGVuc2l2ZSByZXZpZXcuIEkg aGF2ZSBhIG1pbm9yIGNvbW1lbnQgb24gYSBtaW5vciBpc3N1ZSB0aGF0IHlvdSByYWlzZWQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KTWlub3IgSXNzdWVzOjxicj4NCjxicj4NCkkgc2hvdWxkIGxp a2UgdG8gc2VlIHNvbWUgc21hbGwgYW1vdW50IG9mIHRleHQgb24gdGhlIHNjYWxpbmcgaW1wYWN0 IG9uPGJyPg0KT1NQRi4gMS4gSG93IG11Y2ggYWRkaXRpb25hbCBpbmZvcm1hdGlvbiB3aWxsIGlt cGxlbWVudGF0aW9ucyBoYXZlIHRvPGJyPg0Kc3RvcmUgcGVyIG5vZGUvbGluayBpbiB0aGUgbmV0 d29yaz8gMi4gV2hhdCBpcyB0aGUgZXhwZWN0ZWQgY2h1cm4gaW48YnI+DQpMU0FzIGludHJvZHVj ZWQgYnkgdGhpcyBtZWNoYW5pc20gKGVzcGVjaWFsbHkgd2hlbiB0aGUgUmVmbGVjdG9yIGlzPGJy Pg0KdHVybmVkIG9uIGFuZCBvZmYpPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXNudCB0aGlzIGltcGxlbWVudGF0aW9uIHNwZWNp ZmljPyBUaGlzIGlzIHdoYXQgd2lsbCBkaWZmZXJlbnRpYXRlIG9uZSB2ZW5kb3IgaW1wbGVtZW50 YXRpb24gZnJvbSB0aGUgb3RoZXIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90IHN1cmUgaG93IHdlIGNhbiBxdWFudGlm eSB0aGlzIC0tIGFueSBpZGVhcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBha2luIHRvIHNheWluZyB0aGF0IElTLUlTLCBpbiBj b250cmFzdCB0byBPU1BGdjIsIGlzIG1vcmUgYXR0dW5lZCBmb3IgcGFydGlhbCBTUEYgcnVucyBi ZWNhdXNlIHRoZSBub2RlIGluZm9ybWF0aW9uIGlzIGNsZWFubHkgc2VwYXJhdGVkIGZyb20gdGhl IHJlYWNoYWJpbGl0eSBpbmZvcm1hdGlvbi4gSG93ZXZlciwgdGhpcyBpc250IGVudGlyZWx5IHRy dWUuIFdoaWxlIGkgY29uY2VkZSB0aGF0IG5vZGUNCiBpbmZvcm1hdGlvbiBpcyBtaXhlZCB3aXRo IHByZWZpeCBpbmZvcm1hdGlvbiBpbiBPU1BGdjIsIHRoZXJlIHN0aWxsIGFyZSB3YXlzIGluIHdo aWNoIGNsZXZlciBpbXBsZW1lbnRhdGlvbnMgY291bGQgc2VwYXJhdGUgdGhlIHR3byBhbmQgZG8g ZXhhY3RseSB3aGF0IElTLUlTIGRvZXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdG9vayB0aGlzIHJhdGhlciBjaXJjdWl0b3Vz IGFwcHJvYWNoIHRvIGRyaXZlIGhvbWUgdGhlIHBvaW50IHRoYXQgc2NhbGFiaWxpdHksIGNodXJu LCBvdmVyaGVhZHMgb24gdGhlIHN5c3RlbSBhcmUgaW4gbWFueSBjYXNlcyBkZXBlbmRlbnQgb24g dGhlIHByb3RvY29sIGltcGxlbWVudGF0aW9uIGFuZCBieSB0aGF0IHRva2VuIG91dHNpZGUgdGhl IHNjb3BlIG9mIHRoZSBJRVRGIGRyYWZ0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KWW91ICpkbyogaGF2ZS4uLjxicj4N CiZuYnNwOyAmbmJzcDtBIGNoYW5nZSBpbiBpbmZvcm1hdGlvbiBpbiB0aGUgUy1CRkQgRGlzY3Jp bWluYXRvciBUTFYgTVVTVCBOT1Q8YnI+DQombmJzcDsgJm5ic3A7dHJpZ2dlciBhbnkgU1BGIGNv bXB1dGF0aW9uIGF0IGEgcmVjZWl2aW5nIHJvdXRlci48YnI+DQouLi53aGljaCBpcyBhIGhlbHAu PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIHdvdWxkIGJlIGFsYXJtZWQgaWYgYW4gaW1wbGVtZW50YXRpb24gaW4gYW4gYWJzZW5j ZSBvZiB0aGlzIHBlZGFudGljIG5vdGUgdHJpZ2dlcmVkIFNQRiBydW5zIGVhY2ggdGltZSBhbiBT LUJGRCBkaXNjIGNoYW5nZWQgISBJIG1lYW4gaWYgeW91IHVuZGVyc3RhbmQgdGhlIGlkZWEgYmVp bmcgZGlzY3Vzc2VkIHRoZW4geW91IGFsc28gdW5kZXJzdGFuZCB0aGF0IGEgY2hhbmdlIGluIHRo aXMgVExWIGhhcyBubw0KIGJlYXJpbmcgb24gdGhlIHJlYWNoYWJpbGl0eSBhbnl3aGVyZS4gQW5k IHRoYXQga25vd2xlZGdlIHNob3VsZCBiZSBlbm91Z2ggdG8gcHJldmVudCBTUEYgcnVucyBpbiBt b3N0IGNhc2VzICEmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBrbm93IHRoYXQgd2UgaGF2ZSBhZGRlZCB0aGlzIG5vdGUgYnV0IGlm IHdlIG5lZWQgdG8gZXhwbGljaXRseSBzcGVsbCBzdWNoIHRoaW5ncyBvdXQgaW4gYWxsIHN0YW5k YXJkcyB0aGVuIHdlIGNsZWFybHkgaGF2ZSBiaWdnZXIgcHJvYmxlbXMgISA6LSk8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLCBNYW5h djxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2ed8fd52aff748878d16a7086035ecf2XCHALN001ciscocom_-- From nobody Thu Apr 28 02:21:01 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9A612D16B; Thu, 28 Apr 2016 02:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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.996, 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 mcHkFADp-mgm; Thu, 28 Apr 2016 02:20:56 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C08F12D5F6; Thu, 28 Apr 2016 02:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11821; q=dns/txt; s=iport; t=1461835256; x=1463044856; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wyA4Tbh//BFXd7RX4XBJdAaXe5GQBheGpVyNk9yDiV8=; b=HZY3jzcxNohTwgeKqbILBQH6LTvo/aXzc4416ug0Oie7WCdrStC7BGke ZDxtPy4EU8IopGOqOa86L7tlyk3dqz+sZJOY+X8P7QjRQaz1+LA+whf5G 1bTyxNw17YBaom0kQhQS2zxVOUoQs/wgCU+GI3RdXBqga7/k/jaSogfyG 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BXBQCp1CFX/5JdJa1egmxMgVAGtHqFA?= =?us-ascii?q?YF2hg8CHIENOhIBAQEBAQEBZSeEQQEBAQQjVhACAQgRAwECKAMCAgIwFAkIAgQ?= =?us-ascii?q?BDQWIKrINkRgBAQEBAQEBAQEBAQEBAQEBAQEBAQEVimyEXYJgglYFmBABjhaPE?= =?us-ascii?q?Y8vAScHNINrbIg3fwEBAQ?= X-IronPort-AV: E=Sophos; i="5.24,546,1454976000"; d="scan'208,217"; a="96497754" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Apr 2016 09:20:55 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u3S9KsDe011761 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 09:20:55 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Apr 2016 05:20:53 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Thu, 28 Apr 2016 05:20:54 -0400 From: "Acee Lindem (acee)" To: Manav Bhatia , Adrian Farrel Thread-Topic: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt Thread-Index: AQHRoS9D661ZC0oqxEWFSHtLIzbuCQ== Date: Thu, 28 Apr 2016 09:20:54 +0000 Message-ID: References: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D3474D175DE2Faceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "" , "rtg-dir@ietf.org" , "draft-ietf-ospf-sbfd-discriminator.all@ietf.org" , OSPF WG List Subject: Re: [OSPF] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 09:20:58 -0000 --_000_D3474D175DE2Faceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFuYXYsDQoNCkZyb206IE1hbmF2IEJoYXRpYSA8bWFuYXZAaW9ub3NuZXR3b3Jrcy5jb208 bWFpbHRvOm1hbmF2QGlvbm9zbmV0d29ya3MuY29tPj4NCkRhdGU6IFRodXJzZGF5LCBBcHJpbCAy OCwgMjAxNiBhdCAxOjMxIEFNDQpUbzogQWRyaWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51 azxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az4+DQpDYzogIjxydGctYWRzQGlldGYub3JnPG1h aWx0bzpydGctYWRzQGlldGYub3JnPj4iIDxydGctYWRzQGlldGYub3JnPG1haWx0bzpydGctYWRz QGlldGYub3JnPj4sIFJvdXRpbmcgRGlyZWN0b3JhdGUgPHJ0Zy1kaXJAaWV0Zi5vcmc8bWFpbHRv OnJ0Zy1kaXJAaWV0Zi5vcmc+PiwgImRyYWZ0LWlldGYtb3NwZi1zYmZkLWRpc2NyaW1pbmF0b3Iu YWxsQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW9zcGYtc2JmZC1kaXNjcmltaW5hdG9yLmFs bEBpZXRmLm9yZz4iIDxkcmFmdC1pZXRmLW9zcGYtc2JmZC1kaXNjcmltaW5hdG9yLmFsbEBpZXRm Lm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1vc3BmLXNiZmQtZGlzY3JpbWluYXRvci5hbGxAaWV0Zi5v cmc+PiwgT1NQRiBXRyBMaXN0IDxvc3BmQGlldGYub3JnPG1haWx0bzpvc3BmQGlldGYub3JnPj4N ClN1YmplY3Q6IFJlOiBSdGcgRGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLW9zcGYtc2JmZC1kaXNj cmltaW5hdG9yLTA0LnR4dA0KDQpIaSBBZHJpYW4sDQoNClRoYW5rcyBmb3IgdGhlIGV4dGVuc2l2 ZSByZXZpZXcuIEkgaGF2ZSBhIG1pbm9yIGNvbW1lbnQgb24gYSBtaW5vciBpc3N1ZSB0aGF0IHlv dSByYWlzZWQuDQoNCg0KTWlub3IgSXNzdWVzOg0KDQpJIHNob3VsZCBsaWtlIHRvIHNlZSBzb21l IHNtYWxsIGFtb3VudCBvZiB0ZXh0IG9uIHRoZSBzY2FsaW5nIGltcGFjdCBvbg0KT1NQRi4gMS4g SG93IG11Y2ggYWRkaXRpb25hbCBpbmZvcm1hdGlvbiB3aWxsIGltcGxlbWVudGF0aW9ucyBoYXZl IHRvDQpzdG9yZSBwZXIgbm9kZS9saW5rIGluIHRoZSBuZXR3b3JrPyAyLiBXaGF0IGlzIHRoZSBl eHBlY3RlZCBjaHVybiBpbg0KTFNBcyBpbnRyb2R1Y2VkIGJ5IHRoaXMgbWVjaGFuaXNtIChlc3Bl Y2lhbGx5IHdoZW4gdGhlIFJlZmxlY3RvciBpcw0KdHVybmVkIG9uIGFuZCBvZmYpPw0KDQpJc250 IHRoaXMgaW1wbGVtZW50YXRpb24gc3BlY2lmaWM/IFRoaXMgaXMgd2hhdCB3aWxsIGRpZmZlcmVu dGlhdGUgb25lIHZlbmRvciBpbXBsZW1lbnRhdGlvbiBmcm9tIHRoZSBvdGhlci4NCg0KSSBhbSBu b3Qgc3VyZSBob3cgd2UgY2FuIHF1YW50aWZ5IHRoaXMgLS0gYW55IGlkZWFzPw0KDQpUaGlzIGlz IGFraW4gdG8gc2F5aW5nIHRoYXQgSVMtSVMsIGluIGNvbnRyYXN0IHRvIE9TUEZ2MiwgaXMgbW9y ZSBhdHR1bmVkIGZvciBwYXJ0aWFsIFNQRiBydW5zIGJlY2F1c2UgdGhlIG5vZGUgaW5mb3JtYXRp b24gaXMgY2xlYW5seSBzZXBhcmF0ZWQgZnJvbSB0aGUgcmVhY2hhYmlsaXR5IGluZm9ybWF0aW9u LiBIb3dldmVyLCB0aGlzIGlzbnQgZW50aXJlbHkgdHJ1ZS4gV2hpbGUgaSBjb25jZWRlIHRoYXQg bm9kZSBpbmZvcm1hdGlvbiBpcyBtaXhlZCB3aXRoIHByZWZpeCBpbmZvcm1hdGlvbiBpbiBPU1BG djIsIHRoZXJlIHN0aWxsIGFyZSB3YXlzIGluIHdoaWNoIGNsZXZlciBpbXBsZW1lbnRhdGlvbnMg Y291bGQgc2VwYXJhdGUgdGhlIHR3byBhbmQgZG8gZXhhY3RseSB3aGF0IElTLUlTIGRvZXMuDQoN CkkgdG9vayB0aGlzIHJhdGhlciBjaXJjdWl0b3VzIGFwcHJvYWNoIHRvIGRyaXZlIGhvbWUgdGhl IHBvaW50IHRoYXQgc2NhbGFiaWxpdHksIGNodXJuLCBvdmVyaGVhZHMgb24gdGhlIHN5c3RlbSBh cmUgaW4gbWFueSBjYXNlcyBkZXBlbmRlbnQgb24gdGhlIHByb3RvY29sIGltcGxlbWVudGF0aW9u IGFuZCBieSB0aGF0IHRva2VuIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBJRVRGIGRyYWZ0cy4N Cg0KSSBiZWxpZXZlIHdoYXQgaXMgYmVpbmcgcmVxdWVzdGVkIGlzIGEgZGlzY3Vzc2lvbiBvZiBo b3cgb2Z0ZW4gdGhlIFMtQkZEIFRMViBpcyBsaWtlbHkgdG8gY2hhbmdlLCB0aGUgZWZmZWN0cyBv biBmbG9vZGluZywgYW5kLCBpZiByZXF1aXJlZCwgcmVjb21tZW5kYXRpb25zIGZvciBhbnkgcmF0 ZS1saW1pdGluZyBvciBvdGhlciBtZWFzdXJlcyB0byBwcmV2ZW50IGNodXJuLg0KDQpUaGFua3Ms DQpBY2VlDQoNCg0KDQoNCg0KWW91ICpkbyogaGF2ZS4uLg0KICAgQSBjaGFuZ2UgaW4gaW5mb3Jt YXRpb24gaW4gdGhlIFMtQkZEIERpc2NyaW1pbmF0b3IgVExWIE1VU1QgTk9UDQogICB0cmlnZ2Vy IGFueSBTUEYgY29tcHV0YXRpb24gYXQgYSByZWNlaXZpbmcgcm91dGVyLg0KLi4ud2hpY2ggaXMg YSBoZWxwLg0KDQpJIHdvdWxkIGJlIGFsYXJtZWQgaWYgYW4gaW1wbGVtZW50YXRpb24gaW4gYW4g YWJzZW5jZSBvZiB0aGlzIHBlZGFudGljIG5vdGUgdHJpZ2dlcmVkIFNQRiBydW5zIGVhY2ggdGlt ZSBhbiBTLUJGRCBkaXNjIGNoYW5nZWQgISBJIG1lYW4gaWYgeW91IHVuZGVyc3RhbmQgdGhlIGlk ZWEgYmVpbmcgZGlzY3Vzc2VkIHRoZW4geW91IGFsc28gdW5kZXJzdGFuZCB0aGF0IGEgY2hhbmdl IGluIHRoaXMgVExWIGhhcyBubyBiZWFyaW5nIG9uIHRoZSByZWFjaGFiaWxpdHkgYW55d2hlcmUu IEFuZCB0aGF0IGtub3dsZWRnZSBzaG91bGQgYmUgZW5vdWdoIHRvIHByZXZlbnQgU1BGIHJ1bnMg aW4gbW9zdCBjYXNlcyAhDQoNCkkga25vdyB0aGF0IHdlIGhhdmUgYWRkZWQgdGhpcyBub3RlIGJ1 dCBpZiB3ZSBuZWVkIHRvIGV4cGxpY2l0bHkgc3BlbGwgc3VjaCB0aGluZ3Mgb3V0IGluIGFsbCBz dGFuZGFyZHMgdGhlbiB3ZSBjbGVhcmx5IGhhdmUgYmlnZ2VyIHByb2JsZW1zICEgOi0pDQoNCkNo ZWVycywgTWFuYXYNCg0KDQoNCg== --_000_D3474D175DE2Faceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <66685F98B4755B409A7E3B4CFDEDE401@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBNYW5hdiw8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04i Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQt YWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JE RVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDog MGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBC T1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+TWFuYXYgQmhhdGlhICZsdDs8YSBocmVm PSJtYWlsdG86bWFuYXZAaW9ub3NuZXR3b3Jrcy5jb20iPm1hbmF2QGlvbm9zbmV0d29ya3MuY29t PC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFu PlRodXJzZGF5LCBBcHJpbCAyOCwgMjAxNiBhdCAxOjMxIEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+QWRyaWFuIEZhcnJlbCAmbHQ7PGEgaHJlZj0ibWFp bHRvOmFkcmlhbkBvbGRkb2cuY28udWsiPmFkcmlhbkBvbGRkb2cuY28udWs8L2E+Jmd0Ozxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90OyZsdDs8YSBo cmVmPSJtYWlsdG86cnRnLWFkc0BpZXRmLm9yZyI+cnRnLWFkc0BpZXRmLm9yZzwvYT4mZ3Q7JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cnRnLWFkc0BpZXRmLm9yZyI+cnRnLWFkc0BpZXRmLm9y ZzwvYT4mZ3Q7LCBSb3V0aW5nIERpcmVjdG9yYXRlICZsdDs8YSBocmVmPSJtYWlsdG86cnRnLWRp ckBpZXRmLm9yZyI+cnRnLWRpckBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWls dG86ZHJhZnQtaWV0Zi1vc3BmLXNiZmQtZGlzY3JpbWluYXRvci5hbGxAaWV0Zi5vcmciPmRyYWZ0 LWlldGYtb3NwZi1zYmZkLWRpc2NyaW1pbmF0b3IuYWxsQGlldGYub3JnPC9hPiZxdW90Ow0KICZs dDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1vc3BmLXNiZmQtZGlzY3JpbWluYXRvci5hbGxA aWV0Zi5vcmciPmRyYWZ0LWlldGYtb3NwZi1zYmZkLWRpc2NyaW1pbmF0b3IuYWxsQGlldGYub3Jn PC9hPiZndDssIE9TUEYgV0cgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9zcGZAaWV0Zi5vcmci Pm9zcGZAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5TdWJqZWN0OiA8L3NwYW4+UmU6IFJ0ZyBEaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb3NwZi1z YmZkLWRpc2NyaW1pbmF0b3ItMDQudHh0PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxl PSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjow IDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj5IaSBBZHJpYW4s PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MgZm9yIHRoZSBleHRlbnNpdmUg cmV2aWV3LiBJIGhhdmUgYSBtaW5vciBjb21tZW50IG9uIGEgbWlub3IgaXNzdWUgdGhhdCB5b3Ug cmFpc2VkLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJh Ij4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdC13aWR0aDox cHg7Ym9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTtib3JkZXItbGVmdC1zdHlsZTpz b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxicj4NCk1pbm9yIElzc3Vlczo8YnI+DQo8YnI+DQpJ IHNob3VsZCBsaWtlIHRvIHNlZSBzb21lIHNtYWxsIGFtb3VudCBvZiB0ZXh0IG9uIHRoZSBzY2Fs aW5nIGltcGFjdCBvbjxicj4NCk9TUEYuIDEuIEhvdyBtdWNoIGFkZGl0aW9uYWwgaW5mb3JtYXRp b24gd2lsbCBpbXBsZW1lbnRhdGlvbnMgaGF2ZSB0bzxicj4NCnN0b3JlIHBlciBub2RlL2xpbmsg aW4gdGhlIG5ldHdvcms/IDIuIFdoYXQgaXMgdGhlIGV4cGVjdGVkIGNodXJuIGluPGJyPg0KTFNB cyBpbnRyb2R1Y2VkIGJ5IHRoaXMgbWVjaGFuaXNtIChlc3BlY2lhbGx5IHdoZW4gdGhlIFJlZmxl Y3RvciBpczxicj4NCnR1cm5lZCBvbiBhbmQgb2ZmKT88YnI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5Jc250IHRoaXMgaW1wbGVtZW50YXRpb24gc3BlY2lmaWM/IFRo aXMgaXMgd2hhdCB3aWxsIGRpZmZlcmVudGlhdGUgb25lIHZlbmRvciBpbXBsZW1lbnRhdGlvbiBm cm9tIHRoZSBvdGhlci4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgYW0g bm90IHN1cmUgaG93IHdlIGNhbiBxdWFudGlmeSB0aGlzIC0tIGFueSBpZGVhcz88L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoaXMgaXMgYWtpbiB0byBzYXlpbmcgdGhhdCBJUy1JUywg aW4gY29udHJhc3QgdG8gT1NQRnYyLCBpcyBtb3JlIGF0dHVuZWQgZm9yIHBhcnRpYWwgU1BGIHJ1 bnMgYmVjYXVzZSB0aGUgbm9kZSBpbmZvcm1hdGlvbiBpcyBjbGVhbmx5IHNlcGFyYXRlZCBmcm9t IHRoZSByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24uIEhvd2V2ZXIsIHRoaXMgaXNudCBlbnRpcmVs eSB0cnVlLiBXaGlsZSBpIGNvbmNlZGUgdGhhdCBub2RlIGluZm9ybWF0aW9uDQogaXMgbWl4ZWQg d2l0aCBwcmVmaXggaW5mb3JtYXRpb24gaW4gT1NQRnYyLCB0aGVyZSBzdGlsbCBhcmUgd2F5cyBp biB3aGljaCBjbGV2ZXIgaW1wbGVtZW50YXRpb25zIGNvdWxkIHNlcGFyYXRlIHRoZSB0d28gYW5k IGRvIGV4YWN0bHkgd2hhdCBJUy1JUyBkb2VzLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+SSB0b29rIHRoaXMgcmF0aGVyIGNpcmN1aXRvdXMgYXBwcm9hY2ggdG8gZHJpdmUg aG9tZSB0aGUgcG9pbnQgdGhhdCBzY2FsYWJpbGl0eSwgY2h1cm4sIG92ZXJoZWFkcyBvbiB0aGUg c3lzdGVtIGFyZSBpbiBtYW55IGNhc2VzIGRlcGVuZGVudCBvbiB0aGUgcHJvdG9jb2wgaW1wbGVt ZW50YXRpb24gYW5kIGJ5IHRoYXQgdG9rZW4gb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIElFVEYg ZHJhZnRzLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgYmVsaWV2ZSB3 aGF0IGlzIGJlaW5nIHJlcXVlc3RlZCBpcyBhIGRpc2N1c3Npb24gb2YgaG93IG9mdGVuIHRoZSBT LUJGRCBUTFYgaXMgbGlrZWx5IHRvIGNoYW5nZSwgdGhlIGVmZmVjdHMgb24gZmxvb2RpbmcsIGFu ZCwgaWYgcmVxdWlyZWQsIHJlY29tbWVuZGF0aW9ucyBmb3IgYW55IHJhdGUtbGltaXRpbmcgb3Ig b3RoZXIgbWVhc3VyZXMgdG8gcHJldmVudCBjaHVybi4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QWNlZTwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9M S19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJV VElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFE RElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0i bHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3Rl Ij4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQtd2lkdGg6MXB4O2JvcmRl ci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7Ym9yZGVyLWxlZnQtc3R5bGU6c29saWQ7cGFk ZGluZy1sZWZ0OjFleCI+DQo8YnI+DQpZb3UgKmRvKiBoYXZlLi4uPGJyPg0KJm5ic3A7ICZuYnNw O0EgY2hhbmdlIGluIGluZm9ybWF0aW9uIGluIHRoZSBTLUJGRCBEaXNjcmltaW5hdG9yIFRMViBN VVNUIE5PVDxicj4NCiZuYnNwOyAmbmJzcDt0cmlnZ2VyIGFueSBTUEYgY29tcHV0YXRpb24gYXQg YSByZWNlaXZpbmcgcm91dGVyLjxicj4NCi4uLndoaWNoIGlzIGEgaGVscC48YnI+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIHdvdWxkIGJlIGFsYXJtZWQgaWYgYW4g aW1wbGVtZW50YXRpb24gaW4gYW4gYWJzZW5jZSBvZiB0aGlzIHBlZGFudGljIG5vdGUgdHJpZ2dl cmVkIFNQRiBydW5zIGVhY2ggdGltZSBhbiBTLUJGRCBkaXNjIGNoYW5nZWQgISBJIG1lYW4gaWYg eW91IHVuZGVyc3RhbmQgdGhlIGlkZWEgYmVpbmcgZGlzY3Vzc2VkIHRoZW4geW91IGFsc28gdW5k ZXJzdGFuZCB0aGF0IGEgY2hhbmdlIGluIHRoaXMgVExWIGhhcyBubyBiZWFyaW5nIG9uIHRoZQ0K IHJlYWNoYWJpbGl0eSBhbnl3aGVyZS4gQW5kIHRoYXQga25vd2xlZGdlIHNob3VsZCBiZSBlbm91 Z2ggdG8gcHJldmVudCBTUEYgcnVucyBpbiBtb3N0IGNhc2VzICEmbmJzcDs8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2Pkkga25vdyB0aGF0IHdlIGhhdmUgYWRkZWQgdGhpcyBub3RlIGJ1 dCBpZiB3ZSBuZWVkIHRvIGV4cGxpY2l0bHkgc3BlbGwgc3VjaCB0aGluZ3Mgb3V0IGluIGFsbCBz dGFuZGFyZHMgdGhlbiB3ZSBjbGVhcmx5IGhhdmUgYmlnZ2VyIHByb2JsZW1zICEgOi0pPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5DaGVlcnMsIE1hbmF2PC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAg MCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGJy Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D3474D175DE2Faceeciscocom_-- From nobody Thu Apr 28 02:25:27 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A451112D5F6; Thu, 28 Apr 2016 02:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 0zE710rwLz1A; Thu, 28 Apr 2016 02:25:23 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203D712D197; Thu, 28 Apr 2016 02:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22483; q=dns/txt; s=iport; t=1461835523; x=1463045123; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UJYHreoblsmEnhVkhdzIqRUdqPlkR+0iaegBk48IcuU=; b=TB3krjorur/xuFaQmmCGdEWXrhGOA65O+e3yT6Xuv7TtIWRzVDyo9pMJ a1zCVPTjKcwvh9RcvdUN7QjISbQyTpNm0Na1DZR6R9kwtOCT5hoLodFHR PVHYqV8ayrqJzdh8xGWbr9BSnz7ppRqiLxXhrIx92c3t0PRs61PnNuPew 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAgC/1iFX/40NJK1egmxMU30GtHqEc?= =?us-ascii?q?wENgXYihW0CHIENOBQBAQEBAQEBZSeEQQEBAQQjCkwQAgEIEQMBAQEoAwICAjA?= =?us-ascii?q?UCQgCBAENBR+ICw6xb5EYAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSKbIRUCRaCS?= =?us-ascii?q?oJWBYVojTeEcQGFe4VjgjiPEY8vAR4BAUKDa2yIN38BAQE?= X-IronPort-AV: E=Sophos;i="5.24,546,1454976000"; d="scan'208,217";a="266313796" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2016 09:25:09 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u3S9P9uF009269 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 09:25:09 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.1104.5; Thu, 28 Apr 2016 05:25:08 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Thu, 28 Apr 2016 05:25:08 -0400 From: "Acee Lindem (acee)" To: "Les Ginsberg (ginsberg)" , Manav Bhatia , Adrian Farrel Thread-Topic: [RTG-DIR] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt Thread-Index: AQHRoQ9D661ZC0oqxEWFSHtLIzbuCZ+fMHSA///tHgA= Date: Thu, 28 Apr 2016 09:25:08 +0000 Message-ID: References: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk> <2ed8fd52aff748878d16a7086035ecf2@XCH-ALN-001.cisco.com> In-Reply-To: <2ed8fd52aff748878d16a7086035ecf2@XCH-ALN-001.cisco.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_D3474E595DE46aceeciscocom_" MIME-Version: 1.0 Archived-At: Cc: "" , "rtg-dir@ietf.org" , "draft-ietf-ospf-sbfd-discriminator.all@ietf.org" , OSPF WG List Subject: Re: [OSPF] [RTG-DIR] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 09:25:25 -0000 --_000_D3474E595DE46aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTGVzLA0KDQpGcm9tOiAiTGVzIEdpbnNiZXJnIChnaW5zYmVyZykiIDxnaW5zYmVyZ0BjaXNj by5jb208bWFpbHRvOmdpbnNiZXJnQGNpc2NvLmNvbT4+DQpEYXRlOiBUaHVyc2RheSwgQXByaWwg MjgsIDIwMTYgYXQgMjozMiBBTQ0KVG86IE1hbmF2IEJoYXRpYSA8bWFuYXZAaW9ub3NuZXR3b3Jr cy5jb208bWFpbHRvOm1hbmF2QGlvbm9zbmV0d29ya3MuY29tPj4sIEFkcmlhbiBGYXJyZWwgPGFk cmlhbkBvbGRkb2cuY28udWs8bWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWs+Pg0KQ2M6ICI8cnRn LWFkc0BpZXRmLm9yZzxtYWlsdG86cnRnLWFkc0BpZXRmLm9yZz4+IiA8cnRnLWFkc0BpZXRmLm9y ZzxtYWlsdG86cnRnLWFkc0BpZXRmLm9yZz4+LCBSb3V0aW5nIERpcmVjdG9yYXRlIDxydGctZGly QGlldGYub3JnPG1haWx0bzpydGctZGlyQGlldGYub3JnPj4sICJkcmFmdC1pZXRmLW9zcGYtc2Jm ZC1kaXNjcmltaW5hdG9yLmFsbEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1vc3BmLXNiZmQt ZGlzY3JpbWluYXRvci5hbGxAaWV0Zi5vcmc+IiA8ZHJhZnQtaWV0Zi1vc3BmLXNiZmQtZGlzY3Jp bWluYXRvci5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtb3NwZi1zYmZkLWRpc2NyaW1p bmF0b3IuYWxsQGlldGYub3JnPj4sIE9TUEYgV0cgTGlzdCA8b3NwZkBpZXRmLm9yZzxtYWlsdG86 b3NwZkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW1JURy1ESVJdIFJ0ZyBEaXIgcmV2aWV3IG9m IGRyYWZ0LWlldGYtb3NwZi1zYmZkLWRpc2NyaW1pbmF0b3ItMDQudHh0DQoNCkFkcmlhbiDigJMN Cg0KQXMgYW4gaW50ZXJlc3RlZCBieXN0YW5kZXIgKGdpdmVuIEkgYW0gY28tYXV0aG9yIG9uIHRo ZSBjb21wYW5pb24gSVMtSVMgUy1CRkQgZHJhZnQpIEkgc2hhcmUgdGhlIGNvbmNlcm5zIGV4cHJl c3NlZCBieSBDYXJsb3MgYW5kIE1hbmF2Lg0KDQpDaHVybmluZyBTLUJGRCBkaXNjcmltaW5hdG9y IGFzc2lnbm1lbnRzIGlzIGFib3V0IGFzIGxpa2VseSBhcyBjaHVybmluZyBJUC9JUHY2IGFkZHJl c3MgYXNzaWdubWVudHMgb24gYSBub2RlIOKAkyBpdCBpcyBzaW1wbHkgbm90IHNvbWV0aGluZyB0 aGF0IGFueSBkZXBsb3ltZW50IHdvdWxkIGJlIGxpa2VseSB0byBkby4NCklHUCBkcmFmdHMgcGF5 IGNsb3NlIGF0dGVudGlvbiB0byBjaHVybiBmb3IgYWR2ZXJ0aXNlbWVudHMgb2YgaW5mb3JtYXRp b24gd2hpY2ggaXMgZXhwZWN0ZWQgdG8gYmUgZHluYW1pYyAtIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaXNpcy10ZS1tZXRyaWMtZXh0ZW5zaW9ucy8gaXMgYSBn b29kIGV4YW1wbGUgb2YgdGhpcy4gQnV0IHRoZXJlIGlzIG5vIHJlYXNvbiB0byBleHBlY3QgYSBz aW1pbGFyIGlzc3VlIHdpdGggUy1CRkQgZGlzY3JpbWluYXRvcnMuIFRoZXJlZm9yZSwgZm9yIHRo ZSBzYW1lIHJlYXNvbnMgdGhhdCBiYXNlIHByb3RvY29sIHNwZWNpZmljYXRpb25zIGRvIG5vdCBk aXNjdXNzIHRoZSBpbXBhY3Qgb2YgY2h1cm4gaW4gYWR2ZXJ0aXNpbmcgcHJlZml4IHJlYWNoYWJp bGl0eSB3ZSBzYXcgbm8gcmVhc29uIHRvIGRpc2N1c3MgaXQgaW4gdGhlIGNvbnRleHQgb2YgYWR2 ZXJ0aXNpbmcgUy1CRkQgZGlzY3JpbWluYXRvcnMuDQoNCkV4cGxhaW5pbmcgd2h5IFMtQkZEIGNo dXJuIGlzIG5vdCBsaWtlbHkgYSBjb25jZXJuIGFuZCB0aGF0IGFyZWEgb3IgQVMgZmxvb2Rpbmcg d2lsbCBub3QgYmUgaW1wYWN0ZWQgd291bGQgcHJvYmFibHkgc2F0aXNmeSB0aGUgY29tbWVudC4g SG93ZXZlciwgSSB3b27igJl0IHNwZWFrIGZvciBBZHJpYW4uDQoNClRoYW5rcywNCkFjZWUNCg0K DQoNCkl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IHByb3ZpZGVkIHNvbWUgY29udGV4dCBhcyB0 byAgd2h5IHlvdSBoYXZlIHJhaXNlZCB0aGlzIHBvaW50Lg0KVGhhbnguDQoNCiAgIExlcw0KDQpG cm9tOiBydGctZGlyIFttYWlsdG86cnRnLWRpci1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgTWFuYXYgQmhhdGlhDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDI3LCAyMDE2IDEwOjMyIFBN DQpUbzogQWRyaWFuIEZhcnJlbA0KQ2M6IDxydGctYWRzQGlldGYub3JnPG1haWx0bzpydGctYWRz QGlldGYub3JnPj47IHJ0Zy1kaXJAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1kaXJAaWV0Zi5vcmc+OyBk cmFmdC1pZXRmLW9zcGYtc2JmZC1kaXNjcmltaW5hdG9yLmFsbEBpZXRmLm9yZzxtYWlsdG86ZHJh ZnQtaWV0Zi1vc3BmLXNiZmQtZGlzY3JpbWluYXRvci5hbGxAaWV0Zi5vcmc+OyBPU1BGIFdHIExp c3QNClN1YmplY3Q6IFJlOiBbUlRHLURJUl0gUnRnIERpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1v c3BmLXNiZmQtZGlzY3JpbWluYXRvci0wNC50eHQNCg0KSGkgQWRyaWFuLA0KDQpUaGFua3MgZm9y IHRoZSBleHRlbnNpdmUgcmV2aWV3LiBJIGhhdmUgYSBtaW5vciBjb21tZW50IG9uIGEgbWlub3Ig aXNzdWUgdGhhdCB5b3UgcmFpc2VkLg0KDQoNCk1pbm9yIElzc3VlczoNCg0KSSBzaG91bGQgbGlr ZSB0byBzZWUgc29tZSBzbWFsbCBhbW91bnQgb2YgdGV4dCBvbiB0aGUgc2NhbGluZyBpbXBhY3Qg b24NCk9TUEYuIDEuIEhvdyBtdWNoIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gd2lsbCBpbXBsZW1l bnRhdGlvbnMgaGF2ZSB0bw0Kc3RvcmUgcGVyIG5vZGUvbGluayBpbiB0aGUgbmV0d29yaz8gMi4g V2hhdCBpcyB0aGUgZXhwZWN0ZWQgY2h1cm4gaW4NCkxTQXMgaW50cm9kdWNlZCBieSB0aGlzIG1l Y2hhbmlzbSAoZXNwZWNpYWxseSB3aGVuIHRoZSBSZWZsZWN0b3IgaXMNCnR1cm5lZCBvbiBhbmQg b2ZmKT8NCg0KSXNudCB0aGlzIGltcGxlbWVudGF0aW9uIHNwZWNpZmljPyBUaGlzIGlzIHdoYXQg d2lsbCBkaWZmZXJlbnRpYXRlIG9uZSB2ZW5kb3IgaW1wbGVtZW50YXRpb24gZnJvbSB0aGUgb3Ro ZXIuDQoNCkkgYW0gbm90IHN1cmUgaG93IHdlIGNhbiBxdWFudGlmeSB0aGlzIC0tIGFueSBpZGVh cz8NCg0KVGhpcyBpcyBha2luIHRvIHNheWluZyB0aGF0IElTLUlTLCBpbiBjb250cmFzdCB0byBP U1BGdjIsIGlzIG1vcmUgYXR0dW5lZCBmb3IgcGFydGlhbCBTUEYgcnVucyBiZWNhdXNlIHRoZSBu b2RlIGluZm9ybWF0aW9uIGlzIGNsZWFubHkgc2VwYXJhdGVkIGZyb20gdGhlIHJlYWNoYWJpbGl0 eSBpbmZvcm1hdGlvbi4gSG93ZXZlciwgdGhpcyBpc250IGVudGlyZWx5IHRydWUuIFdoaWxlIGkg Y29uY2VkZSB0aGF0IG5vZGUgaW5mb3JtYXRpb24gaXMgbWl4ZWQgd2l0aCBwcmVmaXggaW5mb3Jt YXRpb24gaW4gT1NQRnYyLCB0aGVyZSBzdGlsbCBhcmUgd2F5cyBpbiB3aGljaCBjbGV2ZXIgaW1w bGVtZW50YXRpb25zIGNvdWxkIHNlcGFyYXRlIHRoZSB0d28gYW5kIGRvIGV4YWN0bHkgd2hhdCBJ Uy1JUyBkb2VzLg0KDQpJIHRvb2sgdGhpcyByYXRoZXIgY2lyY3VpdG91cyBhcHByb2FjaCB0byBk cml2ZSBob21lIHRoZSBwb2ludCB0aGF0IHNjYWxhYmlsaXR5LCBjaHVybiwgb3ZlcmhlYWRzIG9u IHRoZSBzeXN0ZW0gYXJlIGluIG1hbnkgY2FzZXMgZGVwZW5kZW50IG9uIHRoZSBwcm90b2NvbCBp bXBsZW1lbnRhdGlvbiBhbmQgYnkgdGhhdCB0b2tlbiBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUg SUVURiBkcmFmdHMuDQoNCg0KWW91ICpkbyogaGF2ZS4uLg0KICAgQSBjaGFuZ2UgaW4gaW5mb3Jt YXRpb24gaW4gdGhlIFMtQkZEIERpc2NyaW1pbmF0b3IgVExWIE1VU1QgTk9UDQogICB0cmlnZ2Vy IGFueSBTUEYgY29tcHV0YXRpb24gYXQgYSByZWNlaXZpbmcgcm91dGVyLg0KLi4ud2hpY2ggaXMg YSBoZWxwLg0KDQpJIHdvdWxkIGJlIGFsYXJtZWQgaWYgYW4gaW1wbGVtZW50YXRpb24gaW4gYW4g YWJzZW5jZSBvZiB0aGlzIHBlZGFudGljIG5vdGUgdHJpZ2dlcmVkIFNQRiBydW5zIGVhY2ggdGlt ZSBhbiBTLUJGRCBkaXNjIGNoYW5nZWQgISBJIG1lYW4gaWYgeW91IHVuZGVyc3RhbmQgdGhlIGlk ZWEgYmVpbmcgZGlzY3Vzc2VkIHRoZW4geW91IGFsc28gdW5kZXJzdGFuZCB0aGF0IGEgY2hhbmdl IGluIHRoaXMgVExWIGhhcyBubyBiZWFyaW5nIG9uIHRoZSByZWFjaGFiaWxpdHkgYW55d2hlcmUu IEFuZCB0aGF0IGtub3dsZWRnZSBzaG91bGQgYmUgZW5vdWdoIHRvIHByZXZlbnQgU1BGIHJ1bnMg aW4gbW9zdCBjYXNlcyAhDQoNCkkga25vdyB0aGF0IHdlIGhhdmUgYWRkZWQgdGhpcyBub3RlIGJ1 dCBpZiB3ZSBuZWVkIHRvIGV4cGxpY2l0bHkgc3BlbGwgc3VjaCB0aGluZ3Mgb3V0IGluIGFsbCBz dGFuZGFyZHMgdGhlbiB3ZSBjbGVhcmx5IGhhdmUgYmlnZ2VyIHByb2JsZW1zICEgOi0pDQoNCkNo ZWVycywgTWFuYXYNCg0KDQoNCg== --_000_D3474E595DE46aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <304830CD1AA44047A29B793658848C9B@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBMZXMsJm5i c3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNU SU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0 ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsg Qk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxF RlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xp ZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPiZxdW90O0xlcyBHaW5zYmVyZyAo Z2luc2JlcmcpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Z2luc2JlcmdAY2lzY28uY29tIj5n aW5zYmVyZ0BjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5EYXRlOiA8L3NwYW4+VGh1cnNkYXksIEFwcmlsIDI4LCAyMDE2IGF0IDI6MzIgQU08YnI+ DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5NYW5hdiBCaGF0aWEg Jmx0OzxhIGhyZWY9Im1haWx0bzptYW5hdkBpb25vc25ldHdvcmtzLmNvbSI+bWFuYXZAaW9ub3Nu ZXR3b3Jrcy5jb208L2E+Jmd0OywgQWRyaWFuIEZhcnJlbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFk cmlhbkBvbGRkb2cuY28udWsiPmFkcmlhbkBvbGRkb2cuY28udWs8L2E+Jmd0Ozxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90OyZsdDs8YSBocmVmPSJt YWlsdG86cnRnLWFkc0BpZXRmLm9yZyI+cnRnLWFkc0BpZXRmLm9yZzwvYT4mZ3Q7JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86cnRnLWFkc0BpZXRmLm9yZyI+cnRnLWFkc0BpZXRmLm9yZzwvYT4m Z3Q7LCBSb3V0aW5nIERpcmVjdG9yYXRlICZsdDs8YSBocmVmPSJtYWlsdG86cnRnLWRpckBpZXRm Lm9yZyI+cnRnLWRpckBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJh ZnQtaWV0Zi1vc3BmLXNiZmQtZGlzY3JpbWluYXRvci5hbGxAaWV0Zi5vcmciPmRyYWZ0LWlldGYt b3NwZi1zYmZkLWRpc2NyaW1pbmF0b3IuYWxsQGlldGYub3JnPC9hPiZxdW90Ow0KICZsdDs8YSBo cmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1vc3BmLXNiZmQtZGlzY3JpbWluYXRvci5hbGxAaWV0Zi5v cmciPmRyYWZ0LWlldGYtb3NwZi1zYmZkLWRpc2NyaW1pbmF0b3IuYWxsQGlldGYub3JnPC9hPiZn dDssIE9TUEYgV0cgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9zcGZAaWV0Zi5vcmciPm9zcGZA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJq ZWN0OiA8L3NwYW4+UkU6IFtSVEctRElSXSBSdGcgRGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLW9z cGYtc2JmZC1kaXNjcmltaW5hdG9yLTA0LnR4dDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBz dHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJH SU46MCAwIDAgNTsiPg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZt bCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxu czp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRw Oi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29u dGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0N Ci8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsiPkFkcmlhbiDigJM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJn YigzMSwgNzMsIDEyNSk7Ij5BcyBhbiBpbnRlcmVzdGVkIGJ5c3RhbmRlciAoZ2l2ZW4gSSBhbSBj by1hdXRob3Igb24gdGhlIGNvbXBhbmlvbiBJUy1JUyBTLUJGRCBkcmFmdCkgSSBzaGFyZSB0aGUg Y29uY2VybnMgZXhwcmVzc2VkIGJ5IENhcmxvcyBhbmQgTWFuYXYuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUp OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Q2h1cm5pbmcgUy1CRkQgZGlzY3JpbWluYXRv ciBhc3NpZ25tZW50cyBpcyBhYm91dCBhcyBsaWtlbHkgYXMgY2h1cm5pbmcgSVAvSVB2NiBhZGRy ZXNzIGFzc2lnbm1lbnRzIG9uIGEgbm9kZSDigJMgaXQgaXMgc2ltcGx5IG5vdCBzb21ldGhpbmcg dGhhdCBhbnkNCiBkZXBsb3ltZW50IHdvdWxkIGJlIGxpa2VseSB0byBkby4gPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyI+SUdQIGRyYWZ0cyBwYXkgY2xvc2UgYXR0ZW50aW9uIHRvIGNodXJuIGZvciBhZHZl cnRpc2VtZW50cyBvZiBpbmZvcm1hdGlvbiB3aGljaCBpcyBleHBlY3RlZCB0byBiZSBkeW5hbWlj IC0NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt aXNpcy10ZS1tZXRyaWMtZXh0ZW5zaW9ucy8iPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1pc2lzLXRlLW1ldHJpYy1leHRlbnNpb25zLzwvYT4gaXMgYSBnb29k IGV4YW1wbGUgb2YgdGhpcy4gQnV0IHRoZXJlIGlzIG5vIHJlYXNvbiB0byBleHBlY3QgYSBzaW1p bGFyIGlzc3VlIHdpdGggUy1CRkQgZGlzY3JpbWluYXRvcnMuIFRoZXJlZm9yZSwgZm9yIHRoZSBz YW1lIHJlYXNvbnMgdGhhdCBiYXNlIHByb3RvY29sIHNwZWNpZmljYXRpb25zIGRvIG5vdCBkaXNj dXNzDQogdGhlIGltcGFjdCBvZiBjaHVybiBpbiBhZHZlcnRpc2luZyBwcmVmaXggcmVhY2hhYmls aXR5IHdlIHNhdyBubyByZWFzb24gdG8gZGlzY3VzcyBpdCBpbiB0aGUgY29udGV4dCBvZiBhZHZl cnRpc2luZyBTLUJGRCBkaXNjcmltaW5hdG9ycy48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ RXhwbGFpbmluZyB3aHkgUy1CRkQgY2h1cm4gaXMgbm90IGxpa2VseSBhIGNvbmNlcm4gYW5kIHRo YXQgYXJlYSBvciBBUyBmbG9vZGluZyB3aWxsIG5vdCBiZSBpbXBhY3RlZCB3b3VsZCBwcm9iYWJs eSBzYXRpc2Z5IHRoZSBjb21tZW50LiBIb3dldmVyLCBJIHdvbuKAmXQgc3BlYWsgZm9yIEFkcmlh bi4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxk aXY+QWNlZTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3Bh biBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09L X0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNv bGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2IHhtbG5zOnY9InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3Nv ZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNl LzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0K PGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyI+SXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgcHJvdmlkZWQgc29tZSBjb250ZXh0IGFz IHRvICZuYnNwO3doeSB5b3UgaGF2ZSByYWlzZWQgdGhpcyBwb2ludC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEy NSk7Ij5UaGFueC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 Ij4mbmJzcDsmbmJzcDsgTGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNh bnMtc2VyaWY7Ij4gcnRnLWRpciBbPGEgaHJlZj0ibWFpbHRvOnJ0Zy1kaXItYm91bmNlc0BpZXRm Lm9yZyI+bWFpbHRvOnJ0Zy1kaXItYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPk1hbmF2IEJoYXRpYTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDI3 LCAyMDE2IDEwOjMyIFBNPGJyPg0KPGI+VG86PC9iPiBBZHJpYW4gRmFycmVsPGJyPg0KPGI+Q2M6 PC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1hZHNAaWV0Zi5vcmciPnJ0Zy1hZHNAaWV0Zi5v cmc8L2E+Jmd0OzsgPGEgaHJlZj0ibWFpbHRvOnJ0Zy1kaXJAaWV0Zi5vcmciPg0KcnRnLWRpckBp ZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW9zcGYtc2JmZC1kaXNjcmlt aW5hdG9yLmFsbEBpZXRmLm9yZyI+DQpkcmFmdC1pZXRmLW9zcGYtc2JmZC1kaXNjcmltaW5hdG9y LmFsbEBpZXRmLm9yZzwvYT47IE9TUEYgV0cgTGlzdDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W1JURy1ESVJdIFJ0ZyBEaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb3NwZi1zYmZkLWRpc2NyaW1p bmF0b3ItMDQudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IaSBBZHJpYW4sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhlIGV4dGVuc2l2ZSByZXZpZXcu IEkgaGF2ZSBhIG1pbm9yIGNvbW1lbnQgb24gYSBtaW5vciBpc3N1ZSB0aGF0IHlvdSByYWlzZWQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KTWlub3IgSXNzdWVzOjxicj4NCjxicj4NCkkgc2hvdWxk IGxpa2UgdG8gc2VlIHNvbWUgc21hbGwgYW1vdW50IG9mIHRleHQgb24gdGhlIHNjYWxpbmcgaW1w YWN0IG9uPGJyPg0KT1NQRi4gMS4gSG93IG11Y2ggYWRkaXRpb25hbCBpbmZvcm1hdGlvbiB3aWxs IGltcGxlbWVudGF0aW9ucyBoYXZlIHRvPGJyPg0Kc3RvcmUgcGVyIG5vZGUvbGluayBpbiB0aGUg bmV0d29yaz8gMi4gV2hhdCBpcyB0aGUgZXhwZWN0ZWQgY2h1cm4gaW48YnI+DQpMU0FzIGludHJv ZHVjZWQgYnkgdGhpcyBtZWNoYW5pc20gKGVzcGVjaWFsbHkgd2hlbiB0aGUgUmVmbGVjdG9yIGlz PGJyPg0KdHVybmVkIG9uIGFuZCBvZmYpPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXNudCB0aGlzIGltcGxlbWVudGF0aW9uIHNw ZWNpZmljPyBUaGlzIGlzIHdoYXQgd2lsbCBkaWZmZXJlbnRpYXRlIG9uZSB2ZW5kb3IgaW1wbGVt ZW50YXRpb24gZnJvbSB0aGUgb3RoZXIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90IHN1cmUgaG93IHdlIGNhbiBxdWFu dGlmeSB0aGlzIC0tIGFueSBpZGVhcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBha2luIHRvIHNheWluZyB0aGF0IElTLUlTLCBp biBjb250cmFzdCB0byBPU1BGdjIsIGlzIG1vcmUgYXR0dW5lZCBmb3IgcGFydGlhbCBTUEYgcnVu cyBiZWNhdXNlIHRoZSBub2RlIGluZm9ybWF0aW9uIGlzIGNsZWFubHkgc2VwYXJhdGVkIGZyb20g dGhlIHJlYWNoYWJpbGl0eSBpbmZvcm1hdGlvbi4gSG93ZXZlciwgdGhpcyBpc250IGVudGlyZWx5 IHRydWUuIFdoaWxlIGkgY29uY2VkZSB0aGF0IG5vZGUNCiBpbmZvcm1hdGlvbiBpcyBtaXhlZCB3 aXRoIHByZWZpeCBpbmZvcm1hdGlvbiBpbiBPU1BGdjIsIHRoZXJlIHN0aWxsIGFyZSB3YXlzIGlu IHdoaWNoIGNsZXZlciBpbXBsZW1lbnRhdGlvbnMgY291bGQgc2VwYXJhdGUgdGhlIHR3byBhbmQg ZG8gZXhhY3RseSB3aGF0IElTLUlTIGRvZXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdG9vayB0aGlzIHJhdGhlciBjaXJjdWl0 b3VzIGFwcHJvYWNoIHRvIGRyaXZlIGhvbWUgdGhlIHBvaW50IHRoYXQgc2NhbGFiaWxpdHksIGNo dXJuLCBvdmVyaGVhZHMgb24gdGhlIHN5c3RlbSBhcmUgaW4gbWFueSBjYXNlcyBkZXBlbmRlbnQg b24gdGhlIHByb3RvY29sIGltcGxlbWVudGF0aW9uIGFuZCBieSB0aGF0IHRva2VuIG91dHNpZGUg dGhlIHNjb3BlIG9mIHRoZSBJRVRGIGRyYWZ0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KWW91ICpkbyogaGF2ZS4uLjxi cj4NCiZuYnNwOyAmbmJzcDtBIGNoYW5nZSBpbiBpbmZvcm1hdGlvbiBpbiB0aGUgUy1CRkQgRGlz Y3JpbWluYXRvciBUTFYgTVVTVCBOT1Q8YnI+DQombmJzcDsgJm5ic3A7dHJpZ2dlciBhbnkgU1BG IGNvbXB1dGF0aW9uIGF0IGEgcmVjZWl2aW5nIHJvdXRlci48YnI+DQouLi53aGljaCBpcyBhIGhl bHAuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIHdvdWxkIGJlIGFsYXJtZWQgaWYgYW4gaW1wbGVtZW50YXRpb24gaW4gYW4gYWJz ZW5jZSBvZiB0aGlzIHBlZGFudGljIG5vdGUgdHJpZ2dlcmVkIFNQRiBydW5zIGVhY2ggdGltZSBh biBTLUJGRCBkaXNjIGNoYW5nZWQgISBJIG1lYW4gaWYgeW91IHVuZGVyc3RhbmQgdGhlIGlkZWEg YmVpbmcgZGlzY3Vzc2VkIHRoZW4geW91IGFsc28gdW5kZXJzdGFuZCB0aGF0IGEgY2hhbmdlIGlu IHRoaXMgVExWIGhhcyBubw0KIGJlYXJpbmcgb24gdGhlIHJlYWNoYWJpbGl0eSBhbnl3aGVyZS4g QW5kIHRoYXQga25vd2xlZGdlIHNob3VsZCBiZSBlbm91Z2ggdG8gcHJldmVudCBTUEYgcnVucyBp biBtb3N0IGNhc2VzICEmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBrbm93IHRoYXQgd2UgaGF2ZSBhZGRlZCB0aGlzIG5vdGUgYnV0 IGlmIHdlIG5lZWQgdG8gZXhwbGljaXRseSBzcGVsbCBzdWNoIHRoaW5ncyBvdXQgaW4gYWxsIHN0 YW5kYXJkcyB0aGVuIHdlIGNsZWFybHkgaGF2ZSBiaWdnZXIgcHJvYmxlbXMgISA6LSk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLCBN YW5hdjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D3474E595DE46aceeciscocom_-- From nobody Thu Apr 28 06:00:20 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD0512D6C9; Thu, 28 Apr 2016 06:00:15 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 olQ6fhPoNWRM; Thu, 28 Apr 2016 06:00:11 -0700 (PDT) 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 92E4112D6C6; Thu, 28 Apr 2016 06:00:07 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u3SD00gR029543; Thu, 28 Apr 2016 14:00:00 +0100 Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u3SCxwXI029469 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 28 Apr 2016 13:59:59 +0100 From: "Adrian Farrel" To: "'Acee Lindem \(acee\)'" , "'Manav Bhatia'" , "'Adrian Farrel'" References: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk> In-Reply-To: Date: Thu, 28 Apr 2016 13:59:57 +0100 Message-ID: <094e01d1a14d$dee2e320$9ca8a960$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_094F_01D1A156.40AACD90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFw1kCCaiIwUNLtEKxshcWR2bdBZAEdXWDpAeZ8YfygSM8KEA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22288.006 X-TM-AS-Result: No--21.737-10.0-31-10 X-imss-scan-details: No--21.737-10.0-31-10 X-TMASE-MatchedRID: pS5owHKhBO0TfAqiYFP7Botbv1rdjkQ67yWPaQc4INT/9J/619DRE3Z4 tIf0VHEEdZFyrfGoFQKhI3awKlxWqNB/8y3gYF9v1FnWYpN8q2HomPrNi98UBBRZ/9wBMhGsADL /rI2baks8Yar5brBvC4k+6F8uUgJCTAoAs2mBYBtswYo64ufkVTRsfGqPls+VbuBZJ8qsrITBJy 85Q6g8Nmun1oUp8bDuONMIq6tJjPVCBQieSpAGz4zb2GR6Ttd3hEIiqNvBrmNrEoFtNYg0C3G0Q /1vTGSPJYhudvYhR94VaPu7cbODbdXLNRKQZEdgzGZPOh8RY45Xug5Vc1us7XzlhuYw8JsTrWVw Ou7Bu1u56+06pUqc5u2MkBhwR/oCxeit2rvNhiUzSlmIs9AhOiyZvBThPVi1auHKE5Laxl/PnMA i6bw5xBi/iQ1k2aZOg1j35+66aZM1+m+DoPpuz5U7Bltw5qVLI9yVcHNDU7baqqH/oHw+kW63OW BILoNo+wxScAVbogf80Dc+R0jowlSd3xC25FnoxqZyCOmsQ/NpWLGvOMNoU3oZ5YK74mUQ7/+9s wuISRWd8KCdlHrmBehzKJYil63oaWbbDm4LdIZ3vIzA7XyIiCEF1RdqrHVdtdx2lXHjF1Ii/B2g ujrEHzB6EdCmNDGVVbEDP0uzojXyTBeqcpWTVlRe8joruKtpIFb2VdwQdkDROhK+RFWo5lthOgN FYwZakNCK/RB7QjECSHHGjA3FAhfyTevQtfkQkdcpJKX5Jwr8BlbXy+O/WnKuL8SC59l3YCowKS vpI+95QzetarMsxEgF6uuiHQ764dAvvfy6ufaeAiCmPx4NwGmRqNBHmBve1kTfEkyaZdxFGCd0S 0NCslehZ2s367dV/8NPq2Jx6+q4e9hqenrZzY/pMkAjLyvVSwwcGKLTYEc= Archived-At: Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-ospf-sbfd-discriminator.all@ietf.org, 'OSPF WG List' Subject: Re: [OSPF] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 13:00:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_094F_01D1A156.40AACD90 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Acee has it right. =20 While (of course) stuff can be done in implementations to mitigate the = effects, the protocol extensions here increase the size of LSA and = increase the amount of flooding. Since the LSAs have to be stored (in = some form), it is reasonable to describe the amount of extra information = that reflects across a network - maybe express it as "LSA data" and = leave it up to an implementation to choose how to store it. Since the = number of LSA updates impacts the routing plane processing and bits on = the wire, it is reasonable to ask what impact that might have. =20 I am interested to hear whether turning Reflectors on and off could be a = feature that could cause LSAs to flap and so create flooding ripples in = the network. =20 Adrian =20 From: Acee Lindem (acee) [mailto:acee@cisco.com]=20 Sent: 28 April 2016 10:21 To: Manav Bhatia; Adrian Farrel Cc: ; rtg-dir@ietf.org; = draft-ietf-ospf-sbfd-discriminator.all@ietf.org; OSPF WG List Subject: Re: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt =20 Hi Manav, =20 From: Manav Bhatia Date: Thursday, April 28, 2016 at 1:31 AM To: Adrian Farrel Cc: "" , Routing Directorate = , "draft-ietf-ospf-sbfd-discriminator.all@ietf.org" = , OSPF WG List = Subject: Re: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt =20 Hi Adrian, =20 Thanks for the extensive review. I have a minor comment on a minor issue = that you raised. =20 Minor Issues: I should like to see some small amount of text on the scaling impact on OSPF. 1. How much additional information will implementations have to store per node/link in the network? 2. What is the expected churn in LSAs introduced by this mechanism (especially when the Reflector is turned on and off)? =20 Isnt this implementation specific? This is what will differentiate one = vendor implementation from the other.=20 =20 I am not sure how we can quantify this -- any ideas? =20 This is akin to saying that IS-IS, in contrast to OSPFv2, is more = attuned for partial SPF runs because the node information is cleanly = separated from the reachability information. However, this isnt entirely = true. While i concede that node information is mixed with prefix = information in OSPFv2, there still are ways in which clever = implementations could separate the two and do exactly what IS-IS does.=20 =20 I took this rather circuitous approach to drive home the point that = scalability, churn, overheads on the system are in many cases dependent = on the protocol implementation and by that token outside the scope of = the IETF drafts. =20 I believe what is being requested is a discussion of how often the S-BFD = TLV is likely to change, the effects on flooding, and, if required, = recommendations for any rate-limiting or other measures to prevent = churn.=20 =20 Thanks, Acee =20 =20 =20 =20 You *do* have... A change in information in the S-BFD Discriminator TLV MUST NOT trigger any SPF computation at a receiving router. ...which is a help. =20 I would be alarmed if an implementation in an absence of this pedantic = note triggered SPF runs each time an S-BFD disc changed ! I mean if you = understand the idea being discussed then you also understand that a = change in this TLV has no bearing on the reachability anywhere. And that = knowledge should be enough to prevent SPF runs in most cases !=20 =20 I know that we have added this note but if we need to explicitly spell = such things out in all standards then we clearly have bigger problems ! = :-) =20 Cheers, Manav =20 =20 =20 ------=_NextPart_000_094F_01D1A156.40AACD90 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Acee has it = right.

 

While (of course) stuff can be = done in implementations to mitigate the effects, the protocol extensions = here increase the size of LSA and increase the amount of flooding. Since = the LSAs have to be stored (in some form), it is reasonable to describe = the amount of extra information that reflects across a network - maybe = express it as "LSA data" and leave it up to an implementation = to choose how to store it. Since the number of LSA updates impacts the = routing plane processing and bits on the wire, it is reasonable to ask = what impact that might have.

 

I am interested to hear = whether turning Reflectors on and off could be a feature that could = cause LSAs to flap and so create flooding ripples in the = network.

 

Adrian

 

From: Acee Lindem = (acee) [mailto:acee@cisco.com]
Sent: 28 April 2016 = 10:21
To: Manav Bhatia; Adrian Farrel
Cc: = <rtg-ads@ietf.org>; rtg-dir@ietf.org; = draft-ietf-ospf-sbfd-discriminator.all@ietf.org; OSPF WG = List
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt

 

Hi = Manav,

 

From: Manav Bhatia <manav@ionosnetworks.com>Date: Thursday, April 28, 2016 at 1:31 AM
To: Adrian = Farrel <adrian@olddog.co.uk>
Cc:= "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, Routing = Directorate <rtg-dir@ietf.org>, "draft-iet= f-ospf-sbfd-discriminator.all@ietf.org" <draft-iet= f-ospf-sbfd-discriminator.all@ietf.org>, OSPF WG List <ospf@ietf.org>
Subject: = Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt

 

Hi = Adrian,

 

Thanks for the extensive = review. I have a minor comment on a minor issue that you = raised.

 


Minor Issues:

I = should like to see some small amount of text on the scaling impact = on
OSPF. 1. How much additional information will implementations have = to
store per node/link in the network? 2. What is the expected churn = in
LSAs introduced by this mechanism (especially when the Reflector = is
turned on and off)?

 

Isnt this implementation = specific? This is what will differentiate one vendor implementation from = the other. 

 

I am not sure how we can = quantify this -- any ideas?

 

This is akin to saying that = IS-IS, in contrast to OSPFv2, is more attuned for partial SPF runs = because the node information is cleanly separated from the reachability = information. However, this isnt entirely true. While i concede that node = information is mixed with prefix information in OSPFv2, there still are = ways in which clever implementations could separate the two and do = exactly what IS-IS does. 

 

I took this rather circuitous = approach to drive home the point that scalability, churn, overheads on = the system are in many cases dependent on the protocol implementation = and by that token outside the scope of the IETF = drafts.

 

I believe what is being = requested is a discussion of how often the S-BFD TLV is likely to = change, the effects on flooding, and, if required, recommendations for = any rate-limiting or other measures to prevent = churn. 

 

Thanks,

Acee

 

 

 

<= p class=3DMsoNormal> 


You *do* = have...
   A change in information in the S-BFD = Discriminator TLV MUST NOT
   trigger any SPF computation = at a receiving router.
...which is a = help.

 

I would be alarmed if an = implementation in an absence of this pedantic note triggered SPF runs = each time an S-BFD disc changed ! I mean if you understand the idea = being discussed then you also understand that a change in this TLV has = no bearing on the reachability anywhere. And that knowledge should be = enough to prevent SPF runs in most cases = ! 

 

I know that we have added = this note but if we need to explicitly spell such things out in all = standards then we clearly have bigger problems ! = :-)

 

Cheers, = Manav

 

 

 

<= /blockquote> ------=_NextPart_000_094F_01D1A156.40AACD90-- From nobody Thu Apr 28 09:19:30 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8ED12D923; Thu, 28 Apr 2016 09:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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.996, 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 Xh0WG-CDFs7w; Thu, 28 Apr 2016 09:19:22 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB7C612D93A; Thu, 28 Apr 2016 09:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27531; q=dns/txt; s=iport; t=1461860108; x=1463069708; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rF6JPUhdlRj2rc6XA7IKIv91K6al/rYV9Rx66WTubA0=; b=V9q2umirh5ZJgGAtmpkCBXmIyXeZ0RbGa+w+bfFSR4Bu/dgY85ILNrvB XP2LNwB3EnSkf/gvzLe3OBborDVLIMyjCetV0iUCuaVx86x+4y6PqyOMU VXxuK626ilF39qVQ65XeB1peEvp1agSr5iSvyRADHRJweDsvvK08BCX+h g=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APBgAoNiJX/5FdJa1egmxMgVAGuX+Bd?= =?us-ascii?q?oYPAoEnORMBAQEBAQEBZSeEQQEBAQMBI1YFCwIBCBEDAQEBASAHAwICMhQJCAI?= =?us-ascii?q?EDgUOiBQIsjaRIgEBAQEBAQEBAQEBAQEBAQEBAQEBAQ0IhiGBdYJWhF0Wgkorg?= =?us-ascii?q?isFh3aLKYRxAYMngWeJCI8Rjy8BIgI+g2tshml/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,547,1454976000"; d="asc'?scan'208,217";a="101656484" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Apr 2016 16:15:07 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u3SGF7PI013546 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 16:15:07 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Apr 2016 12:15:06 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Thu, 28 Apr 2016 12:15:06 -0400 From: "Carlos Pignataro (cpignata)" To: Adrian Farrel Thread-Topic: Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt Thread-Index: AQHRoQ9JJPZzPVazJE6j7eBXSSMiMJ+fX3YAgAA9NICAADaFgA== Date: Thu, 28 Apr 2016 16:15:06 +0000 Message-ID: <40BAEA74-73C5-4CA9-B581-FD0864DCDFF8@cisco.com> References: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk> <094e01d1a14d$dee2e320$9ca8a960$@olddog.co.uk> In-Reply-To: <094e01d1a14d$dee2e320$9ca8a960$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.48.179] Content-Type: multipart/signed; boundary="Apple-Mail=_C7984BEA-F2F0-48B5-AB20-ECCFE642A953"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "" , Manav Bhatia , "" , OSPF WG List , "draft-ietf-ospf-sbfd-discriminator.all@ietf.org" Subject: Re: [OSPF] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 16:19:25 -0000 --Apple-Mail=_C7984BEA-F2F0-48B5-AB20-ECCFE642A953 Content-Type: multipart/alternative; boundary="Apple-Mail=_E8AE7BC4-903C-44D8-BB06-40C19D29393B" --Apple-Mail=_E8AE7BC4-903C-44D8-BB06-40C19D29393B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Adrian, I would not oppose to making a clarification similar to the following, = if the WG things its useful: The S-BFD Discriminators are expected to be quite static. S-BFD = Discriminators may change when enabling the S-BFD functionality or via = an explicit configuration event. These will result in a change in the = information advertised in the S-BFD Discriminator TLV in OSPF, but are = not expected to happen with any regularity. [I expect that text needs (a lot of) wordsmithing, and might not be = useful or desired at all, but just to make the discussion more real] Thanks, =E2=80=94 Carlos. > On Apr 28, 2016, at 8:59 AM, Adrian Farrel = wrote: >=20 > Acee has it right. >=20 > While (of course) stuff can be done in implementations to mitigate the = effects, the protocol extensions here increase the size of LSA and = increase the amount of flooding. Since the LSAs have to be stored (in = some form), it is reasonable to describe the amount of extra information = that reflects across a network - maybe express it as "LSA data" and = leave it up to an implementation to choose how to store it. Since the = number of LSA updates impacts the routing plane processing and bits on = the wire, it is reasonable to ask what impact that might have. >=20 > I am interested to hear whether turning Reflectors on and off could be = a feature that could cause LSAs to flap and so create flooding ripples = in the network. >=20 > Adrian >=20 > From: Acee Lindem (acee) [mailto:acee@cisco.com] > Sent: 28 April 2016 10:21 > To: Manav Bhatia; Adrian Farrel > Cc: ; rtg-dir@ietf.org; = draft-ietf-ospf-sbfd-discriminator.all@ietf.org; OSPF WG List > Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt >=20 > Hi Manav, >=20 > From: Manav Bhatia > > Date: Thursday, April 28, 2016 at 1:31 AM > To: Adrian Farrel > > Cc: ">" >, Routing Directorate >, = "draft-ietf-ospf-sbfd-discriminator.all@ietf.org = " = >, OSPF WG List = > > Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt >=20 >> Hi Adrian, >>=20 >> Thanks for the extensive review. I have a minor comment on a minor = issue that you raised. >>=20 >>>=20 >>> Minor Issues: >>>=20 >>> I should like to see some small amount of text on the scaling impact = on >>> OSPF. 1. How much additional information will implementations have = to >>> store per node/link in the network? 2. What is the expected churn in >>> LSAs introduced by this mechanism (especially when the Reflector is >>> turned on and off)? >>=20 >> Isnt this implementation specific? This is what will differentiate = one vendor implementation from the other. >>=20 >> I am not sure how we can quantify this -- any ideas? >>=20 >> This is akin to saying that IS-IS, in contrast to OSPFv2, is more = attuned for partial SPF runs because the node information is cleanly = separated from the reachability information. However, this isnt entirely = true. While i concede that node information is mixed with prefix = information in OSPFv2, there still are ways in which clever = implementations could separate the two and do exactly what IS-IS does. >>=20 >> I took this rather circuitous approach to drive home the point that = scalability, churn, overheads on the system are in many cases dependent = on the protocol implementation and by that token outside the scope of = the IETF drafts. >=20 > I believe what is being requested is a discussion of how often the = S-BFD TLV is likely to change, the effects on flooding, and, if = required, recommendations for any rate-limiting or other measures to = prevent churn. >=20 > Thanks, > Acee >=20 >=20 >=20 >>=20 >>>=20 >>> You *do* have... >>> A change in information in the S-BFD Discriminator TLV MUST NOT >>> trigger any SPF computation at a receiving router. >>> ...which is a help. >>=20 >> I would be alarmed if an implementation in an absence of this = pedantic note triggered SPF runs each time an S-BFD disc changed ! I = mean if you understand the idea being discussed then you also understand = that a change in this TLV has no bearing on the reachability anywhere. = And that knowledge should be enough to prevent SPF runs in most cases ! >>=20 >> I know that we have added this note but if we need to explicitly = spell such things out in all standards then we clearly have bigger = problems ! :-) >>=20 >> Cheers, Manav --Apple-Mail=_E8AE7BC4-903C-44D8-BB06-40C19D29393B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Adrian,

I = would not oppose to making a clarification similar to the following, if = the WG things its useful:

The S-BFD Discriminators are = expected to be quite static. S-BFD Discriminators may change when = enabling the S-BFD functionality or via an explicit configuration event. = These will result in a change in the information advertised in the S-BFD = Discriminator TLV in OSPF, but are not expected to happen with any = regularity.

[I expect that text needs (a lot of) wordsmithing, and might = not be useful or desired at all, but just to make the discussion more = real]

Thanks,

=E2=80=94 Carlos.

On = Apr 28, 2016, at 8:59 AM, Adrian Farrel <adrian@olddog.co.uk>= wrote:

Acee has it right.
 
While (of course) stuff = can be done in implementations to mitigate the effects, the protocol = extensions here increase the size of LSA and increase the amount of = flooding. Since the LSAs have to be stored (in some form), it is = reasonable to describe the amount of extra information that reflects = across a network - maybe express it as "LSA data" and leave it up to an = implementation to choose how to store it. Since the number of LSA = updates impacts the routing plane processing and bits on the wire, it is = reasonable to ask what impact that might have.
 
I am interested to hear = whether turning Reflectors on and off could be a feature that could = cause LSAs to flap and so create flooding ripples in the network.
 
Adrian
 
From: Acee Lindem (acee) [mailto:acee@cisco.com] 
Sent: 28 = April 2016 10:21
To: Manav Bhatia; Adrian = Farrel
Cc: <rtg-ads@ietf.org>; rtg-dir@ietf.org; draft-ietf-ospf-sbfd-discriminator.all@ietf.org; OSPF WG = List
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt
 
Hi Manav,
 
From: Manav Bhatia <manav@ionosnetworks.com>
Date: Thursday, April 28, = 2016 at 1:31 AM
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, = Routing Directorate <rtg-dir@ietf.org>, "draft-ietf-ospf-sbfd-discriminator.all@ietf.org" <draft-ietf-ospf-sbfd-discriminator.all@ietf.org>, OSPF = WG List <ospf@ietf.org>
Subject: Re: Rtg Dir review of = draft-ietf-ospf-sbfd-discriminator-04.txt
 
Hi Adrian,
 
Thanks for the extensive = review. I have a minor comment on a minor issue that you raised.
 

Minor Issues:

I = should like to see some small amount of text on the scaling impact on
OSPF. 1. How much additional information will implementations = have to
store per node/link in the network? 2. What is the = expected churn in
LSAs introduced by this mechanism = (especially when the Reflector is
turned on and off)?
 
Isnt this implementation = specific? This is what will differentiate one vendor implementation from = the other. 
 
I am not sure how we can quantify this -- any ideas?
 
This is akin to saying = that IS-IS, in contrast to OSPFv2, is more attuned for partial SPF runs = because the node information is cleanly separated from the reachability = information. However, this isnt entirely true. While i concede that node = information is mixed with prefix information in OSPFv2, there still are = ways in which clever implementations could separate the two and do = exactly what IS-IS does. 
 
I took this rather = circuitous approach to drive home the point that scalability, churn, = overheads on the system are in many cases dependent on the protocol = implementation and by that token outside the scope of the IETF = drafts.
 
I believe what is being requested is a discussion of how = often the S-BFD TLV is likely to change, the effects on flooding, and, = if required, recommendations for any rate-limiting or other measures to = prevent churn. 
 
Thanks,
Acee
 
 
 
 

You *do* = have...
   A change in information in the S-BFD = Discriminator TLV MUST NOT
   trigger any SPF = computation at a receiving router.
...which is a help.
 
I would be alarmed if an = implementation in an absence of this pedantic note triggered SPF runs = each time an S-BFD disc changed ! I mean if you understand the idea = being discussed then you also understand that a change in this TLV has = no bearing on the reachability anywhere. And that knowledge should be = enough to prevent SPF runs in most cases ! 
 
I know that we have added = this note but if we need to explicitly spell such things out in all = standards then we clearly have bigger problems ! :-)
 
Cheers, = Manav
<= /div>

= --Apple-Mail=_E8AE7BC4-903C-44D8-BB06-40C19D29393B-- --Apple-Mail=_C7984BEA-F2F0-48B5-AB20-ECCFE642A953 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJXIjcJAAoJEIXgpQGOZny9ppIP/1KXyHrcwC15LKLoLBirNxAV bZcqfWMrvAk9t85EWMlqu74JBSY87vsKzoeUMWuVYxoa3Wy6xU4AFqca4NeitYJv S3Qow/L0XampRBpilFjNw5oOc1Xf3YFisLi0xELPZaoDuhwRG+8B1ai+gYUp549n GSY2DDdpTfVylx5sBBQpgDWod2b8xlt7fms4DMRX0Xwa42hHScOSBxb5SO1KktdJ v6Dn77u7KbUnt9EAEkhESFo3auNt8YkMhW8Ys+0yy7p+a/c9sGM99B/P+Mk6gkMR c4Ge5AgYXt4bGLSlSLxfLG9qcd70OZFhRcRn0srL1gfSxlmnmWJGcn4LjZCA2y3n JuWD2ydUP4LYt1J/S6Q1k/PlBaYEZtnefI3smYcTPWRgpKrP1YF0VU5jp5Eia23w yV35LwDq+n3S/kYgSI4+uJd5piyZtGbNitytmq54ddqeXuuOgG2rm6E7P+njnm57 OrKx2+v86cj4irjF4FUR1/TRzaAPRt8cH2dZlOG4U8KhMfcKRX/LaWjMERzQrRe+ 6p8dd9SIJERmNX55VT1W6JBqYulgPv2SdMz9E9cCk8jGIySOLECuEIMQ42MuecR9 LOYtRRvbs9ggPuO1CMTDnJcSaps4PMRAARFydVq/QxvYoDfhwJ996/Uw7b16QKNX ICZ/NWHS0Mff+G6fXpt5 =jron -----END PGP SIGNATURE----- --Apple-Mail=_C7984BEA-F2F0-48B5-AB20-ECCFE642A953-- From nobody Thu Apr 28 09:33:23 2016 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9941D12D945; Thu, 28 Apr 2016 09:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 T4IWxVcjR1Bm; Thu, 28 Apr 2016 09:33:20 -0700 (PDT) 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 92C0912D9A7; Thu, 28 Apr 2016 09:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35422; q=dns/txt; s=iport; t=1461860985; x=1463070585; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=i7oyEoYedCIlBp7LLUh0/F7+wQEjaJdwlMUivJ3EIDk=; b=APIgiWSPkraVNWFvxYd7rPYNwUD5OISDRJ+ADpfOPcRNfi7fY22bQ73d 1PFYd9WLQs9meqGl0nPSQChZRYsbAtJqVr/jaPvVxIhTprxMLgbPHveWU 2da6mphLdgv5rbZduOQ4+4mBZ4haZX+/bl6SdHgtCMG0kkGXK8lWpNvPw c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARBgBzOSJX/4cNJK1egmxMU30GuX+Bd?= =?us-ascii?q?oYPAhyBDDkTAQEBAQEBAWUnhEEBAQEEIwpMEAIBCBEDAQEBIQcDAgICMBQJCAI?= =?us-ascii?q?EAQ0FCIghAbIwkSUBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGES4RdFoJKglYFh?= =?us-ascii?q?3aLKYRxAY4PgW6ETYhdjy8BIgE/g2tshmkBfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,547,1454976000"; d="scan'208,217";a="267439212" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2016 16:29:44 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3SGTiAW000984 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 16:29:44 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Apr 2016 11:29:43 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Thu, 28 Apr 2016 11:29:43 -0500 From: "Les Ginsberg (ginsberg)" To: "adrian@olddog.co.uk" , "Acee Lindem (acee)" , "'Manav Bhatia'" Thread-Topic: [RTG-DIR] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt Thread-Index: AQHRoQ9WY8DoqBN170GaQg+1of41EZ+fcDoAgAA9M4D//9v2QA== Date: Thu, 28 Apr 2016 16:29:43 +0000 Message-ID: <985d48e2657a44b8965144f029a88970@XCH-ALN-001.cisco.com> References: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk> <094e01d1a14d$dee2e320$9ca8a960$@olddog.co.uk> In-Reply-To: <094e01d1a14d$dee2e320$9ca8a960$@olddog.co.uk> 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: [171.69.35.101] Content-Type: multipart/alternative; boundary="_000_985d48e2657a44b8965144f029a88970XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-ospf-sbfd-discriminator.all@ietf.org" , 'OSPF WG List' Subject: Re: [OSPF] [RTG-DIR] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 16:33:22 -0000 --_000_985d48e2657a44b8965144f029a88970XCHALN001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnksIHdoaWxlIEkgcmVzcGVjdCB5b3UgYm90aCBJIGRvbuKAmXQgYWdyZWUuDQoNCkJhc2Ug cHJvdG9jb2wgc3BlY2lmaWNhdGlvbnMgaGF2ZSBjb250cm9scyBvbiB0aGUgcmF0ZSBvZiBnZW5l cmF0aW9uIG9mIExTQXMg4oCTIHRob3NlIGFwcGx5IGhlcmUgYXMgdGhleSBkbyB0byBhbGwgcHJv dG9jb2wgYWR2ZXJ0aXNlbWVudHMuDQoNCkEg4oCcQkZEIFJlZmxlY3RvcuKAnSBpcyBkZWZpbmVk IGluIFMtQkZEIEJhc2UgZHJhZnQgYXM6DQoNCuKAnFNCRkRSZWZsZWN0b3IgLSBhbiBTLUJGRCBz ZXNzaW9uIG9uIGEgbmV0d29yayBub2RlIHRoYXQgbGlzdGVucw0KICAgICAgZm9yIGluY29taW5n IFMtQkZEIGNvbnRyb2wgcGFja2V0cyB0byBsb2NhbCBlbnRpdGllcyBhbmQgZ2VuZXJhdGVzDQog ICAgICByZXNwb25zZSBTLUJGRCBjb250cm9sIHBhY2tldHMu4oCdDQoNCkFzIGZhciBhcyBhZHZl cnRpc2VtZW50cyBvZiBTLUJGRCBkaXNjcmltaW5hdG9ycyBpdCB3b3VsZCBub3QgbWF0dGVyIHdo ZXRoZXIgdGhlIFJlZmxlY3RvciBmbGFwcyDigJMgaXQgd291bGQgcmVxdWlyZSBhIGNoYW5nZSBp biB0aGUgYXNzaWdubWVudCBvZiBTLUJGRCBEaXNjcmltaW5hdG9yIG9uIHRoYXQgbm9kZSDigJMg d2hpY2ggaXMgYXMgbGlrZWx5IGFzIHJlY29uZmlndXJhdGlvbiBvZiBhIG5vZGUgYWRkcmVzcy4N ClBsZWFzZSAgZXhwbGFpbiB3aHkgdGhpcyByYXJlIGV2ZW50IHJlcHJlc2VudHMgc29tZXRoaW5n IHdoaWNoIGlzIG9mIGNvbmNlcm4gdG8gdGhlIG9wZXJhdGlvbiBvZiBhbiBJR1AuDQoNCkkgZG8g bm90IGxpa2UgY2x1dHRlcmluZyBub3JtYXRpdmUgc3BlY2lmaWNhdGlvbnMgd2l0aCBkaXNjdXNz aW9ucyBvZiBwb2ludHMgdGhhdCBkbyBub3QgcmVmbGVjdCByZWFsIG9wZXJhdGlvbmFsIGNvbmNl cm5zIOKAkyBzbyB0aGUgYXJndW1lbnQg4oCcd2hhdCBoYXJtIGNvdWxkIGl0IGRvIHRvIGRpc2N1 c3MgdGhpc+KAnSBkb2VzbuKAmXQgY2FycnkgbXVjaCB3ZWlnaHQgd2l0aCBtZS4NCg0KICAgTGVz DQoNCkZyb206IHJ0Zy1kaXIgW21haWx0bzpydGctZGlyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBBZHJpYW4gRmFycmVsDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMjgsIDIwMTYgNjow MCBBTQ0KVG86IEFjZWUgTGluZGVtIChhY2VlKTsgJ01hbmF2IEJoYXRpYSc7ICdBZHJpYW4gRmFy cmVsJw0KQ2M6IHJ0Zy1hZHNAaWV0Zi5vcmc7IHJ0Zy1kaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYt b3NwZi1zYmZkLWRpc2NyaW1pbmF0b3IuYWxsQGlldGYub3JnOyAnT1NQRiBXRyBMaXN0Jw0KU3Vi amVjdDogUmU6IFtSVEctRElSXSBSdGcgRGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLW9zcGYtc2Jm ZC1kaXNjcmltaW5hdG9yLTA0LnR4dA0KDQpBY2VlIGhhcyBpdCByaWdodC4NCg0KV2hpbGUgKG9m IGNvdXJzZSkgc3R1ZmYgY2FuIGJlIGRvbmUgaW4gaW1wbGVtZW50YXRpb25zIHRvIG1pdGlnYXRl IHRoZSBlZmZlY3RzLCB0aGUgcHJvdG9jb2wgZXh0ZW5zaW9ucyBoZXJlIGluY3JlYXNlIHRoZSBz aXplIG9mIExTQSBhbmQgaW5jcmVhc2UgdGhlIGFtb3VudCBvZiBmbG9vZGluZy4gU2luY2UgdGhl IExTQXMgaGF2ZSB0byBiZSBzdG9yZWQgKGluIHNvbWUgZm9ybSksIGl0IGlzIHJlYXNvbmFibGUg dG8gZGVzY3JpYmUgdGhlIGFtb3VudCBvZiBleHRyYSBpbmZvcm1hdGlvbiB0aGF0IHJlZmxlY3Rz IGFjcm9zcyBhIG5ldHdvcmsgLSBtYXliZSBleHByZXNzIGl0IGFzICJMU0EgZGF0YSIgYW5kIGxl YXZlIGl0IHVwIHRvIGFuIGltcGxlbWVudGF0aW9uIHRvIGNob29zZSBob3cgdG8gc3RvcmUgaXQu IFNpbmNlIHRoZSBudW1iZXIgb2YgTFNBIHVwZGF0ZXMgaW1wYWN0cyB0aGUgcm91dGluZyBwbGFu ZSBwcm9jZXNzaW5nIGFuZCBiaXRzIG9uIHRoZSB3aXJlLCBpdCBpcyByZWFzb25hYmxlIHRvIGFz ayB3aGF0IGltcGFjdCB0aGF0IG1pZ2h0IGhhdmUuDQoNCkkgYW0gaW50ZXJlc3RlZCB0byBoZWFy IHdoZXRoZXIgdHVybmluZyBSZWZsZWN0b3JzIG9uIGFuZCBvZmYgY291bGQgYmUgYSBmZWF0dXJl IHRoYXQgY291bGQgY2F1c2UgTFNBcyB0byBmbGFwIGFuZCBzbyBjcmVhdGUgZmxvb2Rpbmcgcmlw cGxlcyBpbiB0aGUgbmV0d29yay4NCg0KQWRyaWFuDQoNCkZyb206IEFjZWUgTGluZGVtIChhY2Vl KSBbbWFpbHRvOmFjZWVAY2lzY28uY29tXQ0KU2VudDogMjggQXByaWwgMjAxNiAxMDoyMQ0KVG86 IE1hbmF2IEJoYXRpYTsgQWRyaWFuIEZhcnJlbA0KQ2M6IDxydGctYWRzQGlldGYub3JnPG1haWx0 bzpydGctYWRzQGlldGYub3JnPj47IHJ0Zy1kaXJAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1kaXJAaWV0 Zi5vcmc+OyBkcmFmdC1pZXRmLW9zcGYtc2JmZC1kaXNjcmltaW5hdG9yLmFsbEBpZXRmLm9yZzxt YWlsdG86ZHJhZnQtaWV0Zi1vc3BmLXNiZmQtZGlzY3JpbWluYXRvci5hbGxAaWV0Zi5vcmc+OyBP U1BGIFdHIExpc3QNClN1YmplY3Q6IFJlOiBSdGcgRGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLW9z cGYtc2JmZC1kaXNjcmltaW5hdG9yLTA0LnR4dA0KDQpIaSBNYW5hdiwNCg0KRnJvbTogTWFuYXYg QmhhdGlhIDxtYW5hdkBpb25vc25ldHdvcmtzLmNvbTxtYWlsdG86bWFuYXZAaW9ub3NuZXR3b3Jr cy5jb20+Pg0KRGF0ZTogVGh1cnNkYXksIEFwcmlsIDI4LCAyMDE2IGF0IDE6MzEgQU0NClRvOiBB ZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNv LnVrPj4NCkNjOiAiPHJ0Zy1hZHNAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1hZHNAaWV0Zi5vcmc+PiIg PHJ0Zy1hZHNAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1hZHNAaWV0Zi5vcmc+PiwgUm91dGluZyBEaXJl Y3RvcmF0ZSA8cnRnLWRpckBpZXRmLm9yZzxtYWlsdG86cnRnLWRpckBpZXRmLm9yZz4+LCAiZHJh ZnQtaWV0Zi1vc3BmLXNiZmQtZGlzY3JpbWluYXRvci5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0 LWlldGYtb3NwZi1zYmZkLWRpc2NyaW1pbmF0b3IuYWxsQGlldGYub3JnPiIgPGRyYWZ0LWlldGYt b3NwZi1zYmZkLWRpc2NyaW1pbmF0b3IuYWxsQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW9z cGYtc2JmZC1kaXNjcmltaW5hdG9yLmFsbEBpZXRmLm9yZz4+LCBPU1BGIFdHIExpc3QgPG9zcGZA aWV0Zi5vcmc8bWFpbHRvOm9zcGZAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFJ0ZyBEaXIgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtb3NwZi1zYmZkLWRpc2NyaW1pbmF0b3ItMDQudHh0DQoNCkhpIEFk cmlhbiwNCg0KVGhhbmtzIGZvciB0aGUgZXh0ZW5zaXZlIHJldmlldy4gSSBoYXZlIGEgbWlub3Ig Y29tbWVudCBvbiBhIG1pbm9yIGlzc3VlIHRoYXQgeW91IHJhaXNlZC4NCg0KDQpNaW5vciBJc3N1 ZXM6DQoNCkkgc2hvdWxkIGxpa2UgdG8gc2VlIHNvbWUgc21hbGwgYW1vdW50IG9mIHRleHQgb24g dGhlIHNjYWxpbmcgaW1wYWN0IG9uDQpPU1BGLiAxLiBIb3cgbXVjaCBhZGRpdGlvbmFsIGluZm9y bWF0aW9uIHdpbGwgaW1wbGVtZW50YXRpb25zIGhhdmUgdG8NCnN0b3JlIHBlciBub2RlL2xpbmsg aW4gdGhlIG5ldHdvcms/IDIuIFdoYXQgaXMgdGhlIGV4cGVjdGVkIGNodXJuIGluDQpMU0FzIGlu dHJvZHVjZWQgYnkgdGhpcyBtZWNoYW5pc20gKGVzcGVjaWFsbHkgd2hlbiB0aGUgUmVmbGVjdG9y IGlzDQp0dXJuZWQgb24gYW5kIG9mZik/DQoNCklzbnQgdGhpcyBpbXBsZW1lbnRhdGlvbiBzcGVj aWZpYz8gVGhpcyBpcyB3aGF0IHdpbGwgZGlmZmVyZW50aWF0ZSBvbmUgdmVuZG9yIGltcGxlbWVu dGF0aW9uIGZyb20gdGhlIG90aGVyLg0KDQpJIGFtIG5vdCBzdXJlIGhvdyB3ZSBjYW4gcXVhbnRp ZnkgdGhpcyAtLSBhbnkgaWRlYXM/DQoNClRoaXMgaXMgYWtpbiB0byBzYXlpbmcgdGhhdCBJUy1J UywgaW4gY29udHJhc3QgdG8gT1NQRnYyLCBpcyBtb3JlIGF0dHVuZWQgZm9yIHBhcnRpYWwgU1BG IHJ1bnMgYmVjYXVzZSB0aGUgbm9kZSBpbmZvcm1hdGlvbiBpcyBjbGVhbmx5IHNlcGFyYXRlZCBm cm9tIHRoZSByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24uIEhvd2V2ZXIsIHRoaXMgaXNudCBlbnRp cmVseSB0cnVlLiBXaGlsZSBpIGNvbmNlZGUgdGhhdCBub2RlIGluZm9ybWF0aW9uIGlzIG1peGVk IHdpdGggcHJlZml4IGluZm9ybWF0aW9uIGluIE9TUEZ2MiwgdGhlcmUgc3RpbGwgYXJlIHdheXMg aW4gd2hpY2ggY2xldmVyIGltcGxlbWVudGF0aW9ucyBjb3VsZCBzZXBhcmF0ZSB0aGUgdHdvIGFu ZCBkbyBleGFjdGx5IHdoYXQgSVMtSVMgZG9lcy4NCg0KSSB0b29rIHRoaXMgcmF0aGVyIGNpcmN1 aXRvdXMgYXBwcm9hY2ggdG8gZHJpdmUgaG9tZSB0aGUgcG9pbnQgdGhhdCBzY2FsYWJpbGl0eSwg Y2h1cm4sIG92ZXJoZWFkcyBvbiB0aGUgc3lzdGVtIGFyZSBpbiBtYW55IGNhc2VzIGRlcGVuZGVu dCBvbiB0aGUgcHJvdG9jb2wgaW1wbGVtZW50YXRpb24gYW5kIGJ5IHRoYXQgdG9rZW4gb3V0c2lk ZSB0aGUgc2NvcGUgb2YgdGhlIElFVEYgZHJhZnRzLg0KDQpJIGJlbGlldmUgd2hhdCBpcyBiZWlu ZyByZXF1ZXN0ZWQgaXMgYSBkaXNjdXNzaW9uIG9mIGhvdyBvZnRlbiB0aGUgUy1CRkQgVExWIGlz IGxpa2VseSB0byBjaGFuZ2UsIHRoZSBlZmZlY3RzIG9uIGZsb29kaW5nLCBhbmQsIGlmIHJlcXVp cmVkLCByZWNvbW1lbmRhdGlvbnMgZm9yIGFueSByYXRlLWxpbWl0aW5nIG9yIG90aGVyIG1lYXN1 cmVzIHRvIHByZXZlbnQgY2h1cm4uDQoNClRoYW5rcywNCkFjZWUNCg0KDQoNCg0KDQpZb3UgKmRv KiBoYXZlLi4uDQogICBBIGNoYW5nZSBpbiBpbmZvcm1hdGlvbiBpbiB0aGUgUy1CRkQgRGlzY3Jp bWluYXRvciBUTFYgTVVTVCBOT1QNCiAgIHRyaWdnZXIgYW55IFNQRiBjb21wdXRhdGlvbiBhdCBh IHJlY2VpdmluZyByb3V0ZXIuDQouLi53aGljaCBpcyBhIGhlbHAuDQoNCkkgd291bGQgYmUgYWxh cm1lZCBpZiBhbiBpbXBsZW1lbnRhdGlvbiBpbiBhbiBhYnNlbmNlIG9mIHRoaXMgcGVkYW50aWMg bm90ZSB0cmlnZ2VyZWQgU1BGIHJ1bnMgZWFjaCB0aW1lIGFuIFMtQkZEIGRpc2MgY2hhbmdlZCAh IEkgbWVhbiBpZiB5b3UgdW5kZXJzdGFuZCB0aGUgaWRlYSBiZWluZyBkaXNjdXNzZWQgdGhlbiB5 b3UgYWxzbyB1bmRlcnN0YW5kIHRoYXQgYSBjaGFuZ2UgaW4gdGhpcyBUTFYgaGFzIG5vIGJlYXJp bmcgb24gdGhlIHJlYWNoYWJpbGl0eSBhbnl3aGVyZS4gQW5kIHRoYXQga25vd2xlZGdlIHNob3Vs ZCBiZSBlbm91Z2ggdG8gcHJldmVudCBTUEYgcnVucyBpbiBtb3N0IGNhc2VzICENCg0KSSBrbm93 IHRoYXQgd2UgaGF2ZSBhZGRlZCB0aGlzIG5vdGUgYnV0IGlmIHdlIG5lZWQgdG8gZXhwbGljaXRs eSBzcGVsbCBzdWNoIHRoaW5ncyBvdXQgaW4gYWxsIHN0YW5kYXJkcyB0aGVuIHdlIGNsZWFybHkg aGF2ZSBiaWdnZXIgcHJvYmxlbXMgISA6LSkNCg0KQ2hlZXJzLCBNYW5hdg0KDQoNCg0K --_000_985d48e2657a44b8965144f029a88970XCHALN001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5C YWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U29ycnksIHdoaWxlIEkgcmVzcGVjdCB5 b3UgYm90aCBJIGRvbuKAmXQgYWdyZWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CYXNlIHByb3RvY29sIHNwZWNpZmlj YXRpb25zIGhhdmUgY29udHJvbHMgb24gdGhlIHJhdGUgb2YgZ2VuZXJhdGlvbiBvZiBMU0FzIOKA kyB0aG9zZSBhcHBseSBoZXJlIGFzIHRoZXkgZG8gdG8gYWxsIHByb3RvY29sIGFkdmVydGlzZW1l bnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+QSDigJxCRkQgUmVmbGVjdG9y4oCdIGlzIGRlZmluZWQgaW4gUy1CRkQg QmFzZSBkcmFmdCBhczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnFNCRkRSZWZsZWN0b3IgLSBhbiBTLUJGRCBzZXNz aW9uIG9uIGEgbmV0d29yayBub2RlIHRoYXQgbGlzdGVuczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZm9yIGluY29taW5nIFMtQkZE IGNvbnRyb2wgcGFja2V0cyB0byBsb2NhbCBlbnRpdGllcyBhbmQgZ2VuZXJhdGVzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXNw b25zZSBTLUJGRCBjb250cm9sIHBhY2tldHMu4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBmYXIgYXMgYWR2ZXJ0 aXNlbWVudHMgb2YgUy1CRkQgZGlzY3JpbWluYXRvcnMgaXQgd291bGQgbm90IG1hdHRlciB3aGV0 aGVyIHRoZSBSZWZsZWN0b3IgZmxhcHMg4oCTIGl0IHdvdWxkIHJlcXVpcmUgYSBjaGFuZ2UgaW4g dGhlIGFzc2lnbm1lbnQgb2YgUy1CRkQgRGlzY3JpbWluYXRvcg0KIG9uIHRoYXQgbm9kZSDigJMg d2hpY2ggaXMgYXMgbGlrZWx5IGFzIHJlY29uZmlndXJhdGlvbiBvZiBhIG5vZGUgYWRkcmVzcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGxlYXNlJm5ic3A7IGV4cGxhaW4gd2h5IHRo aXMgcmFyZSBldmVudCByZXByZXNlbnRzIHNvbWV0aGluZyB3aGljaCBpcyBvZiBjb25jZXJuIHRv IHRoZSBvcGVyYXRpb24gb2YgYW4gSUdQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkbyBub3QgbGlrZSBjbHV0dGVy aW5nIG5vcm1hdGl2ZSBzcGVjaWZpY2F0aW9ucyB3aXRoIGRpc2N1c3Npb25zIG9mIHBvaW50cyB0 aGF0IGRvIG5vdCByZWZsZWN0IHJlYWwgb3BlcmF0aW9uYWwgY29uY2VybnMg4oCTIHNvIHRoZSBh cmd1bWVudCDigJx3aGF0IGhhcm0gY291bGQNCiBpdCBkbyB0byBkaXNjdXNzIHRoaXPigJ0gZG9l c27igJl0IGNhcnJ5IG11Y2ggd2VpZ2h0IHdpdGggbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsg TGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0Zy1kaXIg W21haWx0bzpydGctZGlyLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFk cmlhbiBGYXJyZWw8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDI4LCAyMDE2IDY6 MDAgQU08YnI+DQo8Yj5Ubzo8L2I+IEFjZWUgTGluZGVtIChhY2VlKTsgJ01hbmF2IEJoYXRpYSc7 ICdBZHJpYW4gRmFycmVsJzxicj4NCjxiPkNjOjwvYj4gcnRnLWFkc0BpZXRmLm9yZzsgcnRnLWRp ckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1vc3BmLXNiZmQtZGlzY3JpbWluYXRvci5hbGxAaWV0Zi5v cmc7ICdPU1BGIFdHIExpc3QnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbUlRHLURJUl0gUnRn IERpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vc3BmLXNiZmQtZGlzY3JpbWluYXRvci0wNC50eHQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFjZWUgaGFzIGl0 IHJpZ2h0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGlsZSAob2YgY291 cnNlKSBzdHVmZiBjYW4gYmUgZG9uZSBpbiBpbXBsZW1lbnRhdGlvbnMgdG8gbWl0aWdhdGUgdGhl IGVmZmVjdHMsIHRoZSBwcm90b2NvbCBleHRlbnNpb25zIGhlcmUgaW5jcmVhc2UgdGhlIHNpemUg b2YgTFNBIGFuZCBpbmNyZWFzZQ0KIHRoZSBhbW91bnQgb2YgZmxvb2RpbmcuIFNpbmNlIHRoZSBM U0FzIGhhdmUgdG8gYmUgc3RvcmVkIChpbiBzb21lIGZvcm0pLCBpdCBpcyByZWFzb25hYmxlIHRv IGRlc2NyaWJlIHRoZSBhbW91bnQgb2YgZXh0cmEgaW5mb3JtYXRpb24gdGhhdCByZWZsZWN0cyBh Y3Jvc3MgYSBuZXR3b3JrIC0gbWF5YmUgZXhwcmVzcyBpdCBhcyAmcXVvdDtMU0EgZGF0YSZxdW90 OyBhbmQgbGVhdmUgaXQgdXAgdG8gYW4gaW1wbGVtZW50YXRpb24gdG8gY2hvb3NlIGhvdyB0byBz dG9yZQ0KIGl0LiBTaW5jZSB0aGUgbnVtYmVyIG9mIExTQSB1cGRhdGVzIGltcGFjdHMgdGhlIHJv dXRpbmcgcGxhbmUgcHJvY2Vzc2luZyBhbmQgYml0cyBvbiB0aGUgd2lyZSwgaXQgaXMgcmVhc29u YWJsZSB0byBhc2sgd2hhdCBpbXBhY3QgdGhhdCBtaWdodCBoYXZlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5JIGFtIGludGVyZXN0ZWQgdG8gaGVhciB3aGV0aGVyIHR1cm5p bmcgUmVmbGVjdG9ycyBvbiBhbmQgb2ZmIGNvdWxkIGJlIGEgZmVhdHVyZSB0aGF0IGNvdWxkIGNh dXNlIExTQXMgdG8gZmxhcCBhbmQgc28gY3JlYXRlIGZsb29kaW5nIHJpcHBsZXMgaW4NCiB0aGUg bmV0d29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWRyaWFuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBY2Vl IExpbmRlbSAoYWNlZSkgWzxhIGhyZWY9Im1haWx0bzphY2VlQGNpc2NvLmNvbSI+bWFpbHRvOmFj ZWVAY2lzY28uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyOCBBcHJpbCAyMDE2IDEwOjIx PGJyPg0KPGI+VG86PC9iPiBNYW5hdiBCaGF0aWE7IEFkcmlhbiBGYXJyZWw8YnI+DQo8Yj5DYzo8 L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86cnRnLWFkc0BpZXRmLm9yZyI+cnRnLWFkc0BpZXRmLm9y ZzwvYT4mZ3Q7OyA8YSBocmVmPSJtYWlsdG86cnRnLWRpckBpZXRmLm9yZyI+DQpydGctZGlyQGll dGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtb3NwZi1zYmZkLWRpc2NyaW1p bmF0b3IuYWxsQGlldGYub3JnIj4NCmRyYWZ0LWlldGYtb3NwZi1zYmZkLWRpc2NyaW1pbmF0b3Iu YWxsQGlldGYub3JnPC9hPjsgT1NQRiBXRyBMaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBS dGcgRGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLW9zcGYtc2JmZC1kaXNjcmltaW5hdG9yLTA0LnR4 dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkhpIE1hbmF2LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+TWFuYXYgQmhhdGlhICZsdDs8YSBocmVmPSJtYWlsdG86bWFuYXZA aW9ub3NuZXR3b3Jrcy5jb20iPm1hbmF2QGlvbm9zbmV0d29ya3MuY29tPC9hPiZndDs8YnI+DQo8 Yj5EYXRlOiA8L2I+VGh1cnNkYXksIEFwcmlsIDI4LCAyMDE2IGF0IDE6MzEgQU08YnI+DQo8Yj5U bzogPC9iPkFkcmlhbiBGYXJyZWwgJmx0OzxhIGhyZWY9Im1haWx0bzphZHJpYW5Ab2xkZG9nLmNv LnVrIj5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90OyZs dDs8YSBocmVmPSJtYWlsdG86cnRnLWFkc0BpZXRmLm9yZyI+cnRnLWFkc0BpZXRmLm9yZzwvYT4m Z3Q7JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cnRnLWFkc0BpZXRmLm9yZyI+cnRnLWFkc0Bp ZXRmLm9yZzwvYT4mZ3Q7LCBSb3V0aW5nIERpcmVjdG9yYXRlICZsdDs8YSBocmVmPSJtYWlsdG86 cnRnLWRpckBpZXRmLm9yZyI+cnRnLWRpckBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVm PSJtYWlsdG86ZHJhZnQtaWV0Zi1vc3BmLXNiZmQtZGlzY3JpbWluYXRvci5hbGxAaWV0Zi5vcmci PmRyYWZ0LWlldGYtb3NwZi1zYmZkLWRpc2NyaW1pbmF0b3IuYWxsQGlldGYub3JnPC9hPiZxdW90 Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1vc3BmLXNiZmQtZGlzY3JpbWluYXRv ci5hbGxAaWV0Zi5vcmciPmRyYWZ0LWlldGYtb3NwZi1zYmZkLWRpc2NyaW1pbmF0b3IuYWxsQGll dGYub3JnPC9hPiZndDssIE9TUEYgV0cgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9zcGZAaWV0 Zi5vcmciPm9zcGZAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogUnRn IERpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vc3BmLXNiZmQtZGlzY3JpbWluYXRvci0wNC50eHQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0IiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05f QkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+SGkgQWRyaWFuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPlRoYW5rcyBmb3IgdGhlIGV4dGVuc2l2ZSByZXZpZXcuIEkgaGF2 ZSBhIG1pbm9yIGNvbW1lbnQgb24gYSBtaW5vciBpc3N1ZSB0aGF0IHlvdSByYWlzZWQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PGJyPg0KTWlub3IgSXNzdWVzOjxicj4NCjxicj4NCkkgc2hvdWxkIGxpa2UgdG8gc2VlIHNvbWUg c21hbGwgYW1vdW50IG9mIHRleHQgb24gdGhlIHNjYWxpbmcgaW1wYWN0IG9uPGJyPg0KT1NQRi4g MS4gSG93IG11Y2ggYWRkaXRpb25hbCBpbmZvcm1hdGlvbiB3aWxsIGltcGxlbWVudGF0aW9ucyBo YXZlIHRvPGJyPg0Kc3RvcmUgcGVyIG5vZGUvbGluayBpbiB0aGUgbmV0d29yaz8gMi4gV2hhdCBp cyB0aGUgZXhwZWN0ZWQgY2h1cm4gaW48YnI+DQpMU0FzIGludHJvZHVjZWQgYnkgdGhpcyBtZWNo YW5pc20gKGVzcGVjaWFsbHkgd2hlbiB0aGUgUmVmbGVjdG9yIGlzPGJyPg0KdHVybmVkIG9uIGFu ZCBvZmYpPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5Jc250IHRoaXMgaW1wbGVtZW50YXRpb24gc3BlY2lmaWM/IFRo aXMgaXMgd2hhdCB3aWxsIGRpZmZlcmVudGlhdGUgb25lIHZlbmRvciBpbXBsZW1lbnRhdGlvbiBm cm9tIHRoZSBvdGhlci4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JIGFtIG5vdCBzdXJlIGhvdyB3ZSBjYW4gcXVhbnRp ZnkgdGhpcyAtLSBhbnkgaWRlYXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhpcyBpcyBha2luIHRvIHNheWluZyB0aGF0IElT LUlTLCBpbiBjb250cmFzdCB0byBPU1BGdjIsIGlzIG1vcmUgYXR0dW5lZCBmb3IgcGFydGlhbCBT UEYgcnVucyBiZWNhdXNlIHRoZSBub2RlIGluZm9ybWF0aW9uIGlzIGNsZWFubHkgc2VwYXJhdGVk DQogZnJvbSB0aGUgcmVhY2hhYmlsaXR5IGluZm9ybWF0aW9uLiBIb3dldmVyLCB0aGlzIGlzbnQg ZW50aXJlbHkgdHJ1ZS4gV2hpbGUgaSBjb25jZWRlIHRoYXQgbm9kZSBpbmZvcm1hdGlvbiBpcyBt aXhlZCB3aXRoIHByZWZpeCBpbmZvcm1hdGlvbiBpbiBPU1BGdjIsIHRoZXJlIHN0aWxsIGFyZSB3 YXlzIGluIHdoaWNoIGNsZXZlciBpbXBsZW1lbnRhdGlvbnMgY291bGQgc2VwYXJhdGUgdGhlIHR3 byBhbmQgZG8gZXhhY3RseSB3aGF0IElTLUlTIGRvZXMuJm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SSB0b29rIHRoaXMg cmF0aGVyIGNpcmN1aXRvdXMgYXBwcm9hY2ggdG8gZHJpdmUgaG9tZSB0aGUgcG9pbnQgdGhhdCBz Y2FsYWJpbGl0eSwgY2h1cm4sIG92ZXJoZWFkcyBvbiB0aGUgc3lzdGVtIGFyZSBpbiBtYW55IGNh c2VzIGRlcGVuZGVudCBvbiB0aGUNCiBwcm90b2NvbCBpbXBsZW1lbnRhdGlvbiBhbmQgYnkgdGhh dCB0b2tlbiBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgSUVURiBkcmFmdHMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgYmVsaWV2 ZSB3aGF0IGlzIGJlaW5nIHJlcXVlc3RlZCBpcyBhIGRpc2N1c3Npb24gb2YgaG93IG9mdGVuIHRo ZSBTLUJGRCBUTFYgaXMgbGlrZWx5IHRvIGNoYW5nZSwgdGhlIGVmZmVjdHMgb24gZmxvb2Rpbmcs IGFuZCwgaWYgcmVxdWlyZWQsIHJlY29tbWVuZGF0aW9ucw0KIGZvciBhbnkgcmF0ZS1saW1pdGlu ZyBvciBvdGhlciBtZWFzdXJlcyB0byBwcmV2ZW50IGNodXJuLiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoYW5rcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5B Y2VlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCIgaWQ9Ik1BQ19PVVRM T09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCllvdSAqZG8qIGhhdmUuLi48YnI+DQombmJz cDsgJm5ic3A7QSBjaGFuZ2UgaW4gaW5mb3JtYXRpb24gaW4gdGhlIFMtQkZEIERpc2NyaW1pbmF0 b3IgVExWIE1VU1QgTk9UPGJyPg0KJm5ic3A7ICZuYnNwO3RyaWdnZXIgYW55IFNQRiBjb21wdXRh dGlvbiBhdCBhIHJlY2VpdmluZyByb3V0ZXIuPGJyPg0KLi4ud2hpY2ggaXMgYSBoZWxwLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5JIHdvdWxkIGJlIGFsYXJtZWQgaWYgYW4gaW1wbGVtZW50YXRpb24gaW4gYW4gYWJz ZW5jZSBvZiB0aGlzIHBlZGFudGljIG5vdGUgdHJpZ2dlcmVkIFNQRiBydW5zIGVhY2ggdGltZSBh biBTLUJGRCBkaXNjIGNoYW5nZWQgISBJIG1lYW4gaWYgeW91IHVuZGVyc3RhbmQNCiB0aGUgaWRl YSBiZWluZyBkaXNjdXNzZWQgdGhlbiB5b3UgYWxzbyB1bmRlcnN0YW5kIHRoYXQgYSBjaGFuZ2Ug aW4gdGhpcyBUTFYgaGFzIG5vIGJlYXJpbmcgb24gdGhlIHJlYWNoYWJpbGl0eSBhbnl3aGVyZS4g QW5kIHRoYXQga25vd2xlZGdlIHNob3VsZCBiZSBlbm91Z2ggdG8gcHJldmVudCBTUEYgcnVucyBp biBtb3N0IGNhc2VzICEmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JIGtub3cgdGhhdCB3ZSBoYXZlIGFkZGVkIHRoaXMg bm90ZSBidXQgaWYgd2UgbmVlZCB0byBleHBsaWNpdGx5IHNwZWxsIHN1Y2ggdGhpbmdzIG91dCBp biBhbGwgc3RhbmRhcmRzIHRoZW4gd2UgY2xlYXJseSBoYXZlIGJpZ2dlciBwcm9ibGVtcyAhIDot KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPkNoZWVycywgTWFuYXY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_985d48e2657a44b8965144f029a88970XCHALN001ciscocom_-- From nobody Fri Apr 29 16:33:30 2016 Return-Path: X-Original-To: ospf@ietf.org Delivered-To: ospf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0596A12D56D; Fri, 29 Apr 2016 16:33:29 -0700 (PDT) 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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160429233329.4801.37389.idtracker@ietfa.amsl.com> Date: Fri, 29 Apr 2016 16:33:29 -0700 Archived-At: Cc: ospf@ietf.org Subject: [OSPF] I-D Action: draft-ietf-ospf-sbfd-discriminator-06.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.17 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2016 23:33:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP of the IETF. Title : OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators Authors : Carlos Pignataro Manav Bhatia Sam Aldrin Trilok Ranganath Filename : draft-ietf-ospf-sbfd-discriminator-06.txt Pages : 7 Date : 2016-04-29 Abstract: This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood the Seamless Bidirectional Forwarding Detection (S-BFD) discriminator values associated with a target network identifier. This mechanism is applicable to both OSPFv2 and OSPFv3. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-sbfd-discriminator/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ospf-sbfd-discriminator-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-sbfd-discriminator-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/