From nobody Tue Sep 5 08:08:41 2017 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 CB9DF132D5B; Tue, 5 Sep 2017 08:08:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ospf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150462411281.14362.2311589371278707535@ietfa.amsl.com> Date: Tue, 05 Sep 2017 08:08:32 -0700 Archived-At: Subject: [OSPF] I-D Action: draft-ietf-ospf-ospfv3-segment-routing-extensions-10.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 15:08:33 -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 WG of the IETF. Title : OSPFv3 Extensions for Segment Routing Authors : Peter Psenak Stefano Previdi Clarence Filsfils Hannes Gredler Rob Shakir Wim Henderickx Jeff Tantsura Filename : draft-ietf-ospf-ospfv3-segment-routing-extensions-10.txt Pages : 36 Date : 2017-09-05 Abstract: Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the OSPFv3 extensions that are required for Segment Routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-segment-routing-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-extensions-10 https://datatracker.ietf.org/doc/html/draft-ietf-ospf-ospfv3-segment-routing-extensions-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-ospfv3-segment-routing-extensions-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Sep 10 23:25:57 2017 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 A8731124319; Sun, 10 Sep 2017 23:25:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ospf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150511114864.9780.1980388912536335550@ietfa.amsl.com> Date: Sun, 10 Sep 2017 23:25:48 -0700 Archived-At: Subject: [OSPF] I-D Action: draft-ietf-ospf-encapsulation-cap-07.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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 Sep 2017 06:25:49 -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 WG of the IETF. Title : Advertising Tunnel Encapsulation Capabilities in OSPF Authors : Xiaohu Xu Bruno Decraene Robert Raszuk Luis M. Contreras Luay Jalil Filename : draft-ietf-ospf-encapsulation-cap-07.txt Pages : 9 Date : 2017-09-10 Abstract: Networks use tunnels for a variety of reasons. A large variety of tunnel types are defined and the ingress tunnel router needs to select a type of tunnel which is supported by the egress tunnel router and itself. This document defines how to advertise the tunnel encapsulation capabilities of egress tunnel routers in OSPF Router Information Link State Advertisement (LSAs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ospf-encapsulation-cap-07 https://datatracker.ietf.org/doc/html/draft-ietf-ospf-encapsulation-cap-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-encapsulation-cap-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Sep 10 23:40:43 2017 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 52E52126BF3 for ; Sun, 10 Sep 2017 23:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3giPuFFhdD5v for ; Sun, 10 Sep 2017 23:40:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B19F9132193 for ; Sun, 10 Sep 2017 23:40:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOI22525; Mon, 11 Sep 2017 06:40:37 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 11 Sep 2017 07:40:37 +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; Mon, 11 Sep 2017 14:40:30 +0800 From: Xuxiaohu To: "ospf@ietf.org" Thread-Topic: [OSPF] I-D Action: draft-ietf-ospf-encapsulation-cap-07.txt Thread-Index: AQHTKsbaDCsDLVsSukuC9nZdupQrgaKvOpxw Date: Mon, 11 Sep 2017 06:40:58 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BC10C2A@NKGEML515-MBX.china.huawei.com> References: <150511114864.9780.1980388912536335550@ietfa.amsl.com> In-Reply-To: <150511114864.9780.1980388912536335550@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0207.59B62FE5.0234, 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: e814fb2934190c38fc76880fa331a7b4 Archived-At: Subject: [OSPF] =?gb2312?b?tPC4tDogIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtb3Nw?= =?gb2312?b?Zi1lbmNhcHN1bGF0aW9uLWNhcC0wNy50eHQ=?= X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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 Sep 2017 06:40:42 -0000 SGkgYWxsLA0KDQp3ZSBqdXN0IHN1Ym1pdHRlZCBhIHJldmlzaW9uIGluIHdoaWNoIGFsbW9zdCBh bGwgb2YgdGhlIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyByZWNlaXZlZCBzbyBmYXIgaGF2ZSBi ZWVuIGluY29ycG9yYXRlZC4gDQoNClRoYW5rcyBhIGxvdCBQZXRlIFJlc25pY2ssIEpvZSBUb3Vj aCwgRGF2aWQgTWFuZGVsYmVyZywgU2FicmluYSBUYW5hbWFsLCBUaW0gV2ljaW5za2ksIEFtYW5k YSBCYWJlciBmb3IgdGhlaXIgTGFzdCBDYWxsIHJldmlld3MgYW5kIHRoYW5rIGEgbG90IFNwZW5j ZXIgRGF3a2lucywgTWlyamEgS3VlaGxld2luZCwgQmVuIENhbXBiZWxsLCBCZW5vaXQgQ2xhaXNl LCBBbHZhcm8gUmV0YW5hLCBBZGFtIFJvYWNoIGFuZCBTdXJlc2ggS3Jpc2huYW4gZm9yIHRoZWly IEFEIHJldmlld3MuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odSAob24gYmVoYWxmIG9mIGNvLWF1 dGhvcnMpDQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogT1NQRiBbbWFpbHRvOm9z cGYtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4gt6LL zcqxvOQ6IDIwMTfE6jnUwjExyNUgMTQ6MjYNCj4gytW8/sjLOiBpLWQtYW5ub3VuY2VAaWV0Zi5v cmcNCj4gs63LzTogb3NwZkBpZXRmLm9yZw0KPiDW98ziOiBbT1NQRl0gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi1vc3BmLWVuY2Fwc3VsYXRpb24tY2FwLTA3LnR4dA0KPiANCj4gDQo+IEEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cyBkaXJlY3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgT3BlbiBT aG9ydGVzdCBQYXRoIEZpcnN0IElHUCBXRyBvZiB0aGUgSUVURi4NCj4gDQo+ICAgICAgICAgVGl0 bGUgICAgICAgICAgIDogQWR2ZXJ0aXNpbmcgVHVubmVsIEVuY2Fwc3VsYXRpb24gQ2FwYWJpbGl0 aWVzIGluDQo+IE9TUEYNCj4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBYaWFvaHUgWHUNCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICBCcnVubyBEZWNyYWVuZQ0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgIFJvYmVydCBSYXN6dWsNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBM dWlzIE0uIENvbnRyZXJhcw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEx1YXkgSmFsaWwN Cj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtb3NwZi1lbmNhcHN1bGF0aW9uLWNhcC0w Ny50eHQNCj4gCVBhZ2VzICAgICAgICAgICA6IDkNCj4gCURhdGUgICAgICAgICAgICA6IDIwMTct MDktMTANCj4gDQo+IEFic3RyYWN0Og0KPiAgICBOZXR3b3JrcyB1c2UgdHVubmVscyBmb3IgYSB2 YXJpZXR5IG9mIHJlYXNvbnMuICBBIGxhcmdlIHZhcmlldHkgb2YNCj4gICAgdHVubmVsIHR5cGVz IGFyZSBkZWZpbmVkIGFuZCB0aGUgaW5ncmVzcyB0dW5uZWwgcm91dGVyIG5lZWRzIHRvDQo+ICAg IHNlbGVjdCBhIHR5cGUgb2YgdHVubmVsIHdoaWNoIGlzIHN1cHBvcnRlZCBieSB0aGUgZWdyZXNz IHR1bm5lbA0KPiAgICByb3V0ZXIgYW5kIGl0c2VsZi4gIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBo b3cgdG8gYWR2ZXJ0aXNlIHRoZSB0dW5uZWwNCj4gICAgZW5jYXBzdWxhdGlvbiBjYXBhYmlsaXRp ZXMgb2YgZWdyZXNzIHR1bm5lbCByb3V0ZXJzIGluIE9TUEYgUm91dGVyDQo+ICAgIEluZm9ybWF0 aW9uIExpbmsgU3RhdGUgQWR2ZXJ0aXNlbWVudCAoTFNBcykuDQo+IA0KPiANCj4gDQo+IFRoZSBJ RVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9zcGYtZW5jYXBzdWxhdGlvbi1j YXAvDQo+IA0KPiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6 DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9zcGYtZW5jYXBzdWxh dGlvbi1jYXAtMDcNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1pZXRmLW9zcGYtZW5jYXBzdWxhdGlvbi1jYXAtMDcNCj4gDQo+IEEgZGlmZiBmcm9tIHRoZSBw cmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtb3NwZi1lbmNhcHN1bGF0aW9uLWNhcC0wNw0KPiANCj4g DQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k IGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IEludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9TUEYgbWFpbGluZyBsaXN0DQo+IE9TUEZAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vc3BmDQo= From nobody Mon Sep 11 00:39:23 2017 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 11BE513300C; Mon, 11 Sep 2017 00:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTLwa93egjxo; Mon, 11 Sep 2017 00:39:14 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56B61124239; Mon, 11 Sep 2017 00:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6428; q=dns/txt; s=iport; t=1505115554; x=1506325154; h=subject:from:to:cc:references:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=hprWRoYgssiUVINlZSFDZE2esln5vVeXhFFA2PEjLag=; b=hBzUcz+Uk4neQUt49r9PXDL0qcCReVUdojQ8mXMxU6VLRGyzjeFhIGUE xWTy1F9eJs1BRohO19ShDLcqHDvxk3XtSXNLym5zUyw9E88tPrADNqe78 kXRU7ncKx2sFqE4NGk53xY7ivhrVVd/rvuWLbrs6uLZefC7JV/TFCH0sN E=; X-IronPort-AV: E=Sophos;i="5.42,376,1500940800"; d="scan'208";a="657370721" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2017 07:39:11 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v8B7dBI7000318; Mon, 11 Sep 2017 07:39:11 GMT From: Benoit Claise To: The IESG Cc: tjw.ietf@gmail.com, ospf@ietf.org, acee@cisco.com, ospf-chairs@ietf.org, draft-ietf-ospf-encapsulation-cap@ietf.org References: <150407984152.21582.13499330365584334713.idtracker@ietfa.amsl.com> Message-ID: <567c98a4-3105-ccdf-f8e9-4aa082bf7b28@cisco.com> Date: Mon, 11 Sep 2017 09:39:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150407984152.21582.13499330365584334713.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [OSPF] Benoit Claise's Discuss on draft-ietf-ospf-encapsulation-cap-06: (with DISCUSS and COMMENT) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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 Sep 2017 07:39:16 -0000 Dear authors, I see that a new version has been posted. Can you let me know how my DISCUSS point 2 has been addressed? Regards, Benoit > Benoit Claise has entered the following ballot position for > draft-ietf-ospf-encapsulation-cap-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > 1. I agree with Tim Wicinski's OPS DIR point about IANA. > > The content appears to be fine, but there are some outdated (the biggest > one is 5226 replaced by 8126), but its the IANA section which appears the > most confusing. > > 7.1 OSPF Router Information (RI) Registry - appears fine > > 7.2 OSPF Tunnel Encapsulation Attribute Sub-TLV Registry > > This one defines the values being defined/allocated from "This Document" > but in Section 5, each Sub-TLV is defined in other documents, so it's > totally confusing. > > 2. It's not clear which of the following sub-TLVs are > required/relevant/interconnected in the Encapsulation Capability TLV > > 0 Reserved This document > 1 Encapsulation This document > 2 Protocol Type This document > 3 Endpoint This document > 4 Color This document > 5 Load-Balancing Block This document > 6 IP QoS This document > 7 UDP Destination Port This document > > The only hint is: > > Value (variable): Zero or more Tunnel Encapsulation Attribute Sub- > TLVs as defined in Section 5. > > Zero? really, what's the point? > Now, from an operational point of view, which sub-TLVs are required/make sense? > Are some sub-TLVs irrelevant without others? Ex: Color without Encapsulation > Could we have multiple identical sub-TLVs? Ex: Color > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > - Sometimes you use "Encapsulation Capability TLV" (section 3), sometimes "The > Tunnel Encapsulation Type Sub-TLV" I guess that: OLD: > > The Tunnel Encapsulation Type Sub-TLV is structured as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Tunnel Type (2 Octets) | Length (2 Octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Sub-TLVs | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > NEW: > The Encapsulation Capability TLV is structured as follows: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Tunnel Type (2 Octets) | Length (2 Octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Sub-TLVs | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > In section 7.1, should it be? > OLD: > Value TLV Name Reference > ----- ------------------------------------ ------------- > TBD1 Tunnel Capabilities This document > > NEW: > Value TLV Name Reference > ----- ------------------------------------ ------------- > TBD1 Encapsulation Capabilities This document > > OR: > Value TLV Name Reference > ----- ------------------------------------ ------------- > TBD1 Tunnel Encapsulation Capabilities This document > > - Then there is a discrepancy between Sub-TLVs and Value in the related text > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Tunnel Type (2 Octets) | Length (2 Octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | Sub-TLVs | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Proposal: Sub-TLVs should be replaced by "Tunnel Encapsulation Attribute > Sub-TLVs", and the following text updated: > > Value (variable): Zero or more Tunnel Encapsulation Attribute Sub- > TLVs as defined in Section 5. > > - Then, reading section 5, I see yet another name: "OSPF Tunnel Encapsulation > Attribute Sub-TLVs" Section 7.2. > > You should re-read the document to be consistent with your naming convention, > in the text and in the IANA sections. > > > . > From nobody Mon Sep 11 01:20:42 2017 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 EC49A13301E; Mon, 11 Sep 2017 01:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGyPaN-Jg2EN; Mon, 11 Sep 2017 01:20:37 -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 1A009132F49; Mon, 11 Sep 2017 01:20:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOI41633; Mon, 11 Sep 2017 08:20:33 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 11 Sep 2017 09:20:32 +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; Mon, 11 Sep 2017 16:20:25 +0800 From: Xuxiaohu To: Benoit Claise , The IESG CC: "tjw.ietf@gmail.com" , "ospf@ietf.org" , "acee@cisco.com" , "ospf-chairs@ietf.org" , "draft-ietf-ospf-encapsulation-cap@ietf.org" Thread-Topic: Benoit Claise's Discuss on draft-ietf-ospf-encapsulation-cap-06: (with DISCUSS and COMMENT) Thread-Index: AQHTIWWrbL117DbmnkiRqGFBQRdS4qKu2TaAgACMXgA= Date: Mon, 11 Sep 2017 08:20:54 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BC10CC9@NKGEML515-MBX.china.huawei.com> References: <150407984152.21582.13499330365584334713.idtracker@ietfa.amsl.com> <567c98a4-3105-ccdf-f8e9-4aa082bf7b28@cisco.com> In-Reply-To: <567c98a4-3105-ccdf-f8e9-4aa082bf7b28@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] 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.0A0B0205.59B64752.00EB, 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: 9c1694d0ab152bf526dbbf3016c7aec2 Archived-At: Subject: [OSPF] =?utf-8?b?562U5aSNOiBCZW5vaXQgQ2xhaXNlJ3MgRGlzY3VzcyBvbiBk?= =?utf-8?q?raft-ietf-ospf-encapsulation-cap-06=3A_=28with_DISCUSS_and_COMM?= =?utf-8?q?ENT=29?= X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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 Sep 2017 08:20:39 -0000 SGkgQmVub2l0LA0KDQpUaGUgVHVubmVsIEVuY2Fwc3VsYXRpb24gQ2FwYWJpbGl0aWVzIFRMViBj b250YWlucyBvbmUgb3IgbW9yZSBUdW5uZWwgRW5jYXBzdWxhdGlvbiBUeXBlIFN1Yi1UTFZzIHdo aWNoIGluIHR1cm4gY29udGFpbiBaZXJvIG9yIG1vcmUgVHVubmVsIEVuY2Fwc3VsYXRpb24gQXR0 cmlidXRlIFN1Yi1UTFZzLiBNb3JlIHNwZWNpZmljYWxseSwgdGhlIGludGVudCBvZiBUdW5uZWwg RW5jYXBzdWxhdGlvbiBBdHRyaWJ1dGUgU3ViLVRMVnMgY29udGFpbmVkIGluIGEgZ2l2ZW4gVHVu bmVsIEVuY2Fwc3VsYXRpb24gVHlwZSBTdWItVExWIGlzIHRvIGRlc2NyaWJlIHRoZSBzcGVjaWZp YyBwYXJhbWV0ZXJzIHRvIGJlIHVzZWQgZm9yIHRoZSB0dW5uZWwgaW5kaWNhdGVkIGJ5IHRoZSBU eXBlIG9mIHRoYXQgVHVubmVsIEVuY2Fwc3VsYXRpb24gVHlwZSBTdWItVExWLiANCg0KSSB3b25k ZXIgd2hldGhlciBJIGhhdmUgdW5kZXJzdG9vZCB5b3VyIHBvaW50cyBjb3JyZWN0bHkuDQoNCkJl c3QgcmVnYXJkcywNClhpYW9odSANCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7 tuS6ujogQmVub2l0IENsYWlzZSBbbWFpbHRvOmJjbGFpc2VAY2lzY28uY29tXQ0KPiDlj5HpgIHm l7bpl7Q6IDIwMTflubQ55pyIMTHml6UgMTU6MzkNCj4g5pS25Lu25Lq6OiBUaGUgSUVTRw0KPiDm ioTpgIE6IHRqdy5pZXRmQGdtYWlsLmNvbTsgb3NwZkBpZXRmLm9yZzsgYWNlZUBjaXNjby5jb207 IG9zcGYtY2hhaXJzQGlldGYub3JnOw0KPiBkcmFmdC1pZXRmLW9zcGYtZW5jYXBzdWxhdGlvbi1j YXBAaWV0Zi5vcmcNCj4g5Li76aKYOiBSZTogQmVub2l0IENsYWlzZSdzIERpc2N1c3Mgb24gZHJh ZnQtaWV0Zi1vc3BmLWVuY2Fwc3VsYXRpb24tY2FwLTA2OiAod2l0aA0KPiBESVNDVVNTIGFuZCBD T01NRU5UKQ0KPiANCj4gRGVhciBhdXRob3JzLA0KPiANCj4gSSBzZWUgdGhhdCBhIG5ldyB2ZXJz aW9uIGhhcyBiZWVuIHBvc3RlZC4NCj4gQ2FuIHlvdSBsZXQgbWUga25vdyBob3cgbXkgRElTQ1VT UyBwb2ludCAyIGhhcyBiZWVuIGFkZHJlc3NlZD8NCj4gDQo+IFJlZ2FyZHMsIEJlbm9pdA0KPiA+ IEJlbm9pdCBDbGFpc2UgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24g Zm9yDQo+ID4gZHJhZnQtaWV0Zi1vc3BmLWVuY2Fwc3VsYXRpb24tY2FwLTA2OiBEaXNjdXNzDQo+ ID4NCj4gPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50 YWN0IGFuZCByZXBseSB0byBhbGwNCj4gPiBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhl IFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQNCj4gPiB0aGlzIGludHJvZHVjdG9y eSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiA+DQo+ID4NCj4gPiBQbGVhc2UgcmVmZXIgdG8NCj4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0 bWwNCj4gPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1F TlQgcG9zaXRpb25zLg0KPiA+DQo+ID4NCj4gPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3Ro ZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+ID4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vc3BmLWVuY2Fwc3VsYXRpb24tY2FwLw0K PiA+DQo+ID4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBESVNDVVNTOg0KPiA+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPg0KPiA+IDEuIEkgYWdyZWUgd2l0aCBUaW0gV2ljaW5za2kncyBPUFMgRElS IHBvaW50IGFib3V0IElBTkEuDQo+ID4NCj4gPiAgICAgIFRoZSBjb250ZW50IGFwcGVhcnMgdG8g YmUgZmluZSwgYnV0IHRoZXJlIGFyZSBzb21lIG91dGRhdGVkICh0aGUNCj4gYmlnZ2VzdA0KPiA+ ICAgICAgb25lIGlzIDUyMjYgcmVwbGFjZWQgYnkgODEyNiksIGJ1dCBpdHMgdGhlIElBTkEgc2Vj dGlvbiB3aGljaCBhcHBlYXJzDQo+IHRoZQ0KPiA+ICAgICAgbW9zdCBjb25mdXNpbmcuDQo+ID4N Cj4gPiAgICAgIDcuMSBPU1BGIFJvdXRlciBJbmZvcm1hdGlvbiAoUkkpIFJlZ2lzdHJ5IC0gIGFw cGVhcnMgZmluZQ0KPiA+DQo+ID4gICAgICA3LjIgT1NQRiBUdW5uZWwgRW5jYXBzdWxhdGlvbiBB dHRyaWJ1dGUgU3ViLVRMViBSZWdpc3RyeQ0KPiA+DQo+ID4gICAgICBUaGlzIG9uZSBkZWZpbmVz IHRoZSB2YWx1ZXMgYmVpbmcgZGVmaW5lZC9hbGxvY2F0ZWQgZnJvbSAiVGhpcw0KPiBEb2N1bWVu dCINCj4gPiAgICAgIGJ1dCBpbiBTZWN0aW9uIDUsIGVhY2ggU3ViLVRMViBpcyBkZWZpbmVkIGlu IG90aGVyIGRvY3VtZW50cywgc28gaXQncw0KPiA+ICAgICAgdG90YWxseSBjb25mdXNpbmcuDQo+ ID4NCj4gPiAyLiBJdCdzIG5vdCBjbGVhciB3aGljaCBvZiB0aGUgZm9sbG93aW5nIHN1Yi1UTFZz IGFyZQ0KPiA+IHJlcXVpcmVkL3JlbGV2YW50L2ludGVyY29ubmVjdGVkIGluIHRoZSBFbmNhcHN1 bGF0aW9uIENhcGFiaWxpdHkgVExWDQo+ID4NCj4gPiAgICAgICAgICAgICAgMCAgICBSZXNlcnZl ZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGlzDQo+IGRvY3VtZW50DQo+ID4g ICAgICAgICAgICAgIDEgICAgRW5jYXBzdWxhdGlvbiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgVGhpcw0KPiBkb2N1bWVudA0KPiA+ICAgICAgICAgICAgICAyICAgIFByb3RvY29sIFR5cGUg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoaXMNCj4gZG9jdW1lbnQNCj4gPiAgICAgICAg ICAgICAgMyAgICBFbmRwb2ludCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGlz DQo+IGRvY3VtZW50DQo+ID4gICAgICAgICAgICAgIDQgICAgQ29sb3IgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgVGhpcw0KPiBkb2N1bWVudA0KPiA+ICAgICAgICAgICAgICA1 ICAgIExvYWQtQmFsYW5jaW5nIEJsb2NrICAgICAgICAgICAgICAgICAgICAgIFRoaXMNCj4gZG9j dW1lbnQNCj4gPiAgICAgICAgICAgICAgNiAgICBJUCBRb1MgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBUaGlzDQo+IGRvY3VtZW50DQo+ID4gICAgICAgICAgICAgIDcgICAgVURQ IERlc3RpbmF0aW9uIFBvcnQgICAgICAgICAgICAgICAgICAgICAgVGhpcw0KPiBkb2N1bWVudA0K PiA+DQo+ID4gVGhlIG9ubHkgaGludCBpczoNCj4gPg0KPiA+ICAgICAgICBWYWx1ZSAodmFyaWFi bGUpOiBaZXJvIG9yIG1vcmUgVHVubmVsIEVuY2Fwc3VsYXRpb24gQXR0cmlidXRlIFN1Yi0NCj4g PiAgICAgICAgVExWcyBhcyBkZWZpbmVkIGluIFNlY3Rpb24gNS4NCj4gPg0KPiA+IFplcm8/IHJl YWxseSwgd2hhdCdzIHRoZSBwb2ludD8NCj4gPiBOb3csIGZyb20gYW4gb3BlcmF0aW9uYWwgcG9p bnQgb2Ygdmlldywgd2hpY2ggc3ViLVRMVnMgYXJlIHJlcXVpcmVkL21ha2UNCj4gc2Vuc2U/DQo+ ID4gQXJlIHNvbWUgc3ViLVRMVnMgaXJyZWxldmFudCB3aXRob3V0IG90aGVycz8gRXg6IENvbG9y IHdpdGhvdXQNCj4gPiBFbmNhcHN1bGF0aW9uIENvdWxkIHdlIGhhdmUgbXVsdGlwbGUgaWRlbnRp Y2FsIHN1Yi1UTFZzPyBFeDogQ29sb3INCj4gPg0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ IENPTU1FTlQ6DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ID4gLSBTb21ldGltZXMgeW91IHVz ZSAiRW5jYXBzdWxhdGlvbiBDYXBhYmlsaXR5IFRMViIgKHNlY3Rpb24gMyksDQo+ID4gc29tZXRp bWVzICJUaGUgVHVubmVsIEVuY2Fwc3VsYXRpb24gVHlwZSBTdWItVExWIiBJIGd1ZXNzIHRoYXQ6 IE9MRDoNCj4gPg0KPiA+ICAgVGhlIFR1bm5lbCBFbmNhcHN1bGF0aW9uIFR5cGUgU3ViLVRMViBp cyBzdHJ1Y3R1cmVkIGFzIGZvbGxvd3M6DQo+ID4NCj4gPiAgICAgICAgIDAgICAgICAgICAgICAg ICAgICAgMSAgICAgICAgICAgICAgICAgICAyDQo+IDMNCj4gPiAgICAgICAgIDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KPiA+ ICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKw0KPiA+ICAgICAgICB8ICAgIFR1bm5lbCBUeXBlICgyIE9jdGV0cykg ICAgIHwgICAgICAgIExlbmd0aCAoMiBPY3RldHMpDQo+IHwNCj4gPiAgICAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN Cj4gPiAgICAgICAgfA0KPiB8DQo+ID4gICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgU3ViLVRMVnMNCj4gfA0KPiA+ICAgICAgICB8DQo+IHwNCj4gPg0KPiA+ICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ ID4NCj4gPiBORVc6DQo+ID4gICBUaGUgRW5jYXBzdWxhdGlvbiBDYXBhYmlsaXR5IFRMViBpcyBz dHJ1Y3R1cmVkIGFzIGZvbGxvd3M6DQo+ID4NCj4gPiAgICAgICAgIDAgICAgICAgICAgICAgICAg ICAgMSAgICAgICAgICAgICAgICAgICAyDQo+IDMNCj4gPiAgICAgICAgIDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KPiA+ICAg ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KPiA+ICAgICAgICB8ICAgIFR1bm5lbCBUeXBlICgyIE9jdGV0cykgICAg IHwgICAgICAgIExlbmd0aCAoMiBPY3RldHMpDQo+IHwNCj4gPiAgICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4g PiAgICAgICAgfA0KPiB8DQo+ID4gICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg U3ViLVRMVnMNCj4gfA0KPiA+ICAgICAgICB8DQo+IHwNCj4gPg0KPiA+ICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ID4N Cj4gPiBJbiBzZWN0aW9uIDcuMSwgc2hvdWxkIGl0IGJlPw0KPiA+IE9MRDoNCj4gPiAgICAgIFZh bHVlICAgVExWIE5hbWUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUmVmZXJlbmNl DQo+ID4gICAgICAgICAtLS0tLSAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSAgIC0tLS0tLS0tLS0tLS0NCj4gPiAgICAgICAgIFRCRDEgICAgVHVubmVsIENhcGFiaWxpdGll cyAgICAgICAgICAgICAgICAgICAgVGhpcyBkb2N1bWVudA0KPiA+DQo+ID4gTkVXOg0KPiA+ICAg ICAgVmFsdWUgICBUTFYgTmFtZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZWZl cmVuY2UNCj4gPiAgICAgICAgIC0tLS0tICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tICAgLS0tLS0tLS0tLS0tLQ0KPiA+ICAgICAgICAgVEJEMSAgICBFbmNhcHN1bGF0aW9u IENhcGFiaWxpdGllcyAgICAgICAgICAgICBUaGlzIGRvY3VtZW50DQo+ID4NCj4gPiBPUjoNCj4g PiAgICAgIFZhbHVlICAgVExWIE5hbWUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg UmVmZXJlbmNlDQo+ID4gICAgICAgICAtLS0tLSAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSAgIC0tLS0tLS0tLS0tLS0NCj4gPiAgICAgICAgIFRCRDEgICAgVHVubmVsIEVu Y2Fwc3VsYXRpb24gQ2FwYWJpbGl0aWVzICAgICAgVGhpcyBkb2N1bWVudA0KPiA+DQo+ID4gLSBU aGVuIHRoZXJlIGlzIGEgZGlzY3JlcGFuY3kgYmV0d2VlbiBTdWItVExWcyBhbmQgVmFsdWUgaW4g dGhlDQo+ID4gcmVsYXRlZCB0ZXh0DQo+ID4NCj4gPiAgICAgICAgIDAgICAgICAgICAgICAgICAg ICAgMSAgICAgICAgICAgICAgICAgICAyDQo+IDMNCj4gPiAgICAgICAgIDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KPiA+ICAg ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KPiA+ICAgICAgICB8ICAgIFR1bm5lbCBUeXBlICgyIE9jdGV0cykgICAg IHwgICAgICAgIExlbmd0aCAoMiBPY3RldHMpDQo+IHwNCj4gPiAgICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4g PiAgICAgICAgfA0KPiB8DQo+ID4gICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg U3ViLVRMVnMNCj4gfA0KPiA+ICAgICAgICB8DQo+IHwNCj4gPg0KPiA+ICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ID4N Cj4gPiBQcm9wb3NhbDogU3ViLVRMVnMgc2hvdWxkIGJlIHJlcGxhY2VkIGJ5ICJUdW5uZWwgRW5j YXBzdWxhdGlvbg0KPiA+IEF0dHJpYnV0ZSBTdWItVExWcyIsIGFuZCB0aGUgZm9sbG93aW5nIHRl eHQgdXBkYXRlZDoNCj4gPg0KPiA+ICAgIFZhbHVlICh2YXJpYWJsZSk6IFplcm8gb3IgbW9yZSBU dW5uZWwgRW5jYXBzdWxhdGlvbiBBdHRyaWJ1dGUgU3ViLQ0KPiA+ICAgICAgICBUTFZzIGFzIGRl ZmluZWQgaW4gU2VjdGlvbiA1Lg0KPiA+DQo+ID4gLSBUaGVuLCByZWFkaW5nIHNlY3Rpb24gNSwg SSBzZWUgeWV0IGFub3RoZXIgbmFtZTogIk9TUEYgVHVubmVsDQo+ID4gRW5jYXBzdWxhdGlvbiBB dHRyaWJ1dGUgU3ViLVRMVnMiIFNlY3Rpb24gNy4yLg0KPiA+DQo+ID4gWW91IHNob3VsZCByZS1y ZWFkIHRoZSBkb2N1bWVudCB0byBiZSBjb25zaXN0ZW50IHdpdGggeW91ciBuYW1pbmcNCj4gPiBj b252ZW50aW9uLCBpbiB0aGUgdGV4dCBhbmQgaW4gdGhlIElBTkEgc2VjdGlvbnMuDQo+ID4NCj4g Pg0KPiA+IC4NCj4gPg0KDQo= From nobody Mon Sep 11 03:20:08 2017 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 41AC2133031; Mon, 11 Sep 2017 03:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3x5Uad9wwWOB; Mon, 11 Sep 2017 03:19:58 -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 87820128D0D; Mon, 11 Sep 2017 03:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22198; q=dns/txt; s=iport; t=1505125198; x=1506334798; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=mdlUmQvzV+YFgb/YACIasHykKP9r5RPrJoo/XWxFj0s=; b=IFQMC8bJuWcEQOfMzzpbgIsb58qKqUWSWLyXiDSivwO/7QwuVgErPMRk Qef0PQ7leUDI9uY9/HXfFEZY8sKI7hWjwg0YhE0E1iCciwY6Q+KraLnJf dPk4BFlv9yo4vHkXrCocErsbgyZUh9+qHkvE+FCDoHyuIN9kujUuNwwzg 4=; X-IronPort-AV: E=Sophos;i="5.42,377,1500940800"; d="scan'208,217";a="655553786" 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; 11 Sep 2017 10:19:55 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8BAJtUh030491; Mon, 11 Sep 2017 10:19:55 GMT To: Xuxiaohu , The IESG Cc: "tjw.ietf@gmail.com" , "ospf@ietf.org" , "acee@cisco.com" , "ospf-chairs@ietf.org" , "draft-ietf-ospf-encapsulation-cap@ietf.org" References: <150407984152.21582.13499330365584334713.idtracker@ietfa.amsl.com> <567c98a4-3105-ccdf-f8e9-4aa082bf7b28@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BC10CC9@NKGEML515-MBX.china.huawei.com> From: Benoit Claise Message-ID: Date: Mon, 11 Sep 2017 12:19:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BC10CC9@NKGEML515-MBX.china.huawei.com> Content-Type: multipart/alternative; boundary="------------9BEB58B1310FC8E8ACEEEEFC" Content-Language: en-US Archived-At: Subject: Re: [OSPF] =?utf-8?b?562U5aSNOiBCZW5vaXQgQ2xhaXNlJ3MgRGlzY3VzcyBv?= =?utf-8?q?n_draft-ietf-ospf-encapsulation-cap-06=3A_=28with_DISCUSS_and_C?= =?utf-8?q?OMMENT=29?= X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.22 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 Sep 2017 10:20:01 -0000 This is a multi-part message in MIME format. --------------9BEB58B1310FC8E8ACEEEEFC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Xiaohu, My DISCUSS is at https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/ballot/ Let me try to rephrase the second DISCUSS point. The following sentence is so generic Value (variable): Zero or more Tunnel Encapsulation Attribute Sub- TLVs as defined in Section 5. Basically, it says: you can receive 0, 1, or more instance of 0 Reserved This document 1 Encapsulation This document & [I-D.ietf-idr-tunnel-encaps] 2 Protocol Type This document & [I-D.ietf-idr-tunnel-encaps] 3 Endpoint This document 4 Color This document 5 Load-Balancing Block This document & [RFC5640] 6 IP QoS This document & [I-D.ietf-idr-tunnel-encaps] 7 UDP Destination Port This document & [I-D.ietf-idr-tunnel-encaps] 8-65499 Unassigned 65500-65534 Experimental This document 65535 Reserved This document And my question/point: really, you want to be that open/liberal in terms of Tunnel Encapsulation Attribute Sub-TLVs? You have really no rules? What if some combinations don't even make sense?     None of sub-TLVs are compulsory? Not even the Endpoint?     What does a Color mean without an Endpoint?     What do two IP QoS mean?     What do two Endpoints mean?     What do two different IP QoS with two different Endpoints mean?     etc... I wonder how you could inter-operate? Regards, Benoit > Hi Benoit, > > The Tunnel Encapsulation Capabilities TLV contains one or more Tunnel Encapsulation Type Sub-TLVs which in turn contain Zero or more Tunnel Encapsulation Attribute Sub-TLVs. More specifically, the intent of Tunnel Encapsulation Attribute Sub-TLVs contained in a given Tunnel Encapsulation Type Sub-TLV is to describe the specific parameters to be used for the tunnel indicated by the Type of that Tunnel Encapsulation Type Sub-TLV. > > I wonder whether I have understood your points correctly. > > Best regards, > Xiaohu > >> -----邮件原件----- >> 发件人: Benoit Claise [mailto:bclaise@cisco.com] >> 发送时间: 2017年9月11日 15:39 >> 收件人: The IESG >> 抄送: tjw.ietf@gmail.com; ospf@ietf.org; acee@cisco.com; ospf-chairs@ietf.org; >> draft-ietf-ospf-encapsulation-cap@ietf.org >> 主题: Re: Benoit Claise's Discuss on draft-ietf-ospf-encapsulation-cap-06: (with >> DISCUSS and COMMENT) >> >> Dear authors, >> >> I see that a new version has been posted. >> Can you let me know how my DISCUSS point 2 has been addressed? >> >> Regards, Benoit >>> Benoit Claise has entered the following ballot position for >>> draft-ietf-ospf-encapsulation-cap-06: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut >>> this introductory paragraph, however.) >>> >>> >>> Please refer to >>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> 1. I agree with Tim Wicinski's OPS DIR point about IANA. >>> >>> The content appears to be fine, but there are some outdated (the >> biggest >>> one is 5226 replaced by 8126), but its the IANA section which appears >> the >>> most confusing. >>> >>> 7.1 OSPF Router Information (RI) Registry - appears fine >>> >>> 7.2 OSPF Tunnel Encapsulation Attribute Sub-TLV Registry >>> >>> This one defines the values being defined/allocated from "This >> Document" >>> but in Section 5, each Sub-TLV is defined in other documents, so it's >>> totally confusing. >>> >>> 2. It's not clear which of the following sub-TLVs are >>> required/relevant/interconnected in the Encapsulation Capability TLV >>> >>> 0 Reserved This >> document >>> 1 Encapsulation This >> document >>> 2 Protocol Type This >> document >>> 3 Endpoint This >> document >>> 4 Color This >> document >>> 5 Load-Balancing Block This >> document >>> 6 IP QoS This >> document >>> 7 UDP Destination Port This >> document >>> The only hint is: >>> >>> Value (variable): Zero or more Tunnel Encapsulation Attribute Sub- >>> TLVs as defined in Section 5. >>> >>> Zero? really, what's the point? >>> Now, from an operational point of view, which sub-TLVs are required/make >> sense? >>> Are some sub-TLVs irrelevant without others? Ex: Color without >>> Encapsulation Could we have multiple identical sub-TLVs? Ex: Color >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> - Sometimes you use "Encapsulation Capability TLV" (section 3), >>> sometimes "The Tunnel Encapsulation Type Sub-TLV" I guess that: OLD: >>> >>> The Tunnel Encapsulation Type Sub-TLV is structured as follows: >>> >>> 0 1 2 >> 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Tunnel Type (2 Octets) | Length (2 Octets) >> | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | >> | >>> | Sub-TLVs >> | >>> | >> | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> NEW: >>> The Encapsulation Capability TLV is structured as follows: >>> >>> 0 1 2 >> 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Tunnel Type (2 Octets) | Length (2 Octets) >> | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | >> | >>> | Sub-TLVs >> | >>> | >> | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> In section 7.1, should it be? >>> OLD: >>> Value TLV Name Reference >>> ----- ------------------------------------ ------------- >>> TBD1 Tunnel Capabilities This document >>> >>> NEW: >>> Value TLV Name Reference >>> ----- ------------------------------------ ------------- >>> TBD1 Encapsulation Capabilities This document >>> >>> OR: >>> Value TLV Name Reference >>> ----- ------------------------------------ ------------- >>> TBD1 Tunnel Encapsulation Capabilities This document >>> >>> - Then there is a discrepancy between Sub-TLVs and Value in the >>> related text >>> >>> 0 1 2 >> 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Tunnel Type (2 Octets) | Length (2 Octets) >> | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | >> | >>> | Sub-TLVs >> | >>> | >> | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> Proposal: Sub-TLVs should be replaced by "Tunnel Encapsulation >>> Attribute Sub-TLVs", and the following text updated: >>> >>> Value (variable): Zero or more Tunnel Encapsulation Attribute Sub- >>> TLVs as defined in Section 5. >>> >>> - Then, reading section 5, I see yet another name: "OSPF Tunnel >>> Encapsulation Attribute Sub-TLVs" Section 7.2. >>> >>> You should re-read the document to be consistent with your naming >>> convention, in the text and in the IANA sections. >>> >>> >>> . >>> --------------9BEB58B1310FC8E8ACEEEEFC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Xiaohu,

My DISCUSS is at https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/ballot/
Let me try to rephrase the second DISCUSS point.
The following sentence is so generic
      Value (variable): Zero or more Tunnel Encapsulation Attribute Sub-
      TLVs as defined in Section 5.
Basically, it says: you can receive 0, 1, or more instance of
          0    Reserved               This document
          1    Encapsulation          This document & [I-D.ietf-idr-tunnel-encaps]
          2    Protocol Type          This document & [I-D.ietf-idr-tunnel-encaps]
          3    Endpoint               This document
          4    Color                  This document
          5    Load-Balancing Block   This document & [RFC5640]
          6    IP QoS                 This document & [I-D.ietf-idr-tunnel-encaps]
          7    UDP Destination Port   This document & [I-D.ietf-idr-tunnel-encaps]
    8-65499    Unassigned
65500-65534    Experimental           This document
      65535    Reserved               This document
And my question/point: really, you want to be that open/liberal in terms of Tunnel Encapsulation Attribute Sub-TLVs?
You have really no rules? What if some combinations don't even make sense?

    None of sub-TLVs are compulsory? Not even the Endpoint?
    What does a Color mean without an Endpoint?
    What do two IP QoS mean?
    What do two Endpoints mean?
    What do two different IP QoS with two different Endpoints mean?
    etc...

I wonder how you could inter-operate?

Regards, Benoit 
Hi Benoit,

The Tunnel Encapsulation Capabilities TLV contains one or more Tunnel Encapsulation Type Sub-TLVs which in turn contain Zero or more Tunnel Encapsulation Attribute Sub-TLVs. More specifically, the intent of Tunnel Encapsulation Attribute Sub-TLVs contained in a given Tunnel Encapsulation Type Sub-TLV is to describe the specific parameters to be used for the tunnel indicated by the Type of that Tunnel Encapsulation Type Sub-TLV. 

I wonder whether I have understood your points correctly.

Best regards,
Xiaohu 


-----邮件原件-----
发件人: Benoit Claise [mailto:bclaise@cisco.com]
发送时间: 2017年9月11日 15:39
收件人: The IESG
抄送: tjw.ietf@gmail.com; ospf@ietf.org; acee@cisco.com; ospf-chairs@ietf.org;
draft-ietf-ospf-encapsulation-cap@ietf.org
主题: Re: Benoit Claise's Discuss on draft-ietf-ospf-encapsulation-cap-06: (with
DISCUSS and COMMENT)

Dear authors,

I see that a new version has been posted.
Can you let me know how my DISCUSS point 2 has been addressed?

Regards, Benoit

Benoit Claise has entered the following ballot position for
draft-ietf-ospf-encapsulation-cap-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut
this introductory paragraph, however.)


Please refer to
https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

1. I agree with Tim Wicinski's OPS DIR point about IANA.

     The content appears to be fine, but there are some outdated (the

biggest

     one is 5226 replaced by 8126), but its the IANA section which appears

the

     most confusing.

     7.1 OSPF Router Information (RI) Registry -  appears fine

     7.2 OSPF Tunnel Encapsulation Attribute Sub-TLV Registry

     This one defines the values being defined/allocated from "This

Document"

     but in Section 5, each Sub-TLV is defined in other documents, so it's
     totally confusing.

2. It's not clear which of the following sub-TLVs are
required/relevant/interconnected in the Encapsulation Capability TLV

             0    Reserved                                  This

document

             1    Encapsulation                             This

document

             2    Protocol Type                             This

document

             3    Endpoint                                  This

document

             4    Color                                     This

document

             5    Load-Balancing Block                      This

document

             6    IP QoS                                    This

document

             7    UDP Destination Port                      This

document

The only hint is:

       Value (variable): Zero or more Tunnel Encapsulation Attribute Sub-
       TLVs as defined in Section 5.

Zero? really, what's the point?
Now, from an operational point of view, which sub-TLVs are required/make

sense?

Are some sub-TLVs irrelevant without others? Ex: Color without
Encapsulation Could we have multiple identical sub-TLVs? Ex: Color


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- Sometimes you use "Encapsulation Capability TLV" (section 3),
sometimes "The Tunnel Encapsulation Type Sub-TLV" I guess that: OLD:

  The Tunnel Encapsulation Type Sub-TLV is structured as follows:

        0                   1                   2

3

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Tunnel Type (2 Octets)     |        Length (2 Octets)

|

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |

|

       |                            Sub-TLVs

|

       |

|

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

NEW:
  The Encapsulation Capability TLV is structured as follows:

        0                   1                   2

3

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Tunnel Type (2 Octets)     |        Length (2 Octets)

|

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |

|

       |                            Sub-TLVs

|

       |

|

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

In section 7.1, should it be?
OLD:
     Value   TLV Name                                  Reference
        -----   ------------------------------------   -------------
        TBD1    Tunnel Capabilities                    This document

NEW:
     Value   TLV Name                                  Reference
        -----   ------------------------------------   -------------
        TBD1    Encapsulation Capabilities             This document

OR:
     Value   TLV Name                                  Reference
        -----   ------------------------------------   -------------
        TBD1    Tunnel Encapsulation Capabilities      This document

- Then there is a discrepancy between Sub-TLVs and Value in the
related text

        0                   1                   2

3

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Tunnel Type (2 Octets)     |        Length (2 Octets)

|

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |

|

       |                            Sub-TLVs

|

       |

|

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

Proposal: Sub-TLVs should be replaced by "Tunnel Encapsulation
Attribute Sub-TLVs", and the following text updated:

   Value (variable): Zero or more Tunnel Encapsulation Attribute Sub-
       TLVs as defined in Section 5.

- Then, reading section 5, I see yet another name: "OSPF Tunnel
Encapsulation Attribute Sub-TLVs" Section 7.2.

You should re-read the document to be consistent with your naming
convention, in the text and in the IANA sections.


.



    

    

  


--------------9BEB58B1310FC8E8ACEEEEFC--


From nobody Fri Sep 15 02:09:56 2017
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 0DC19133081; Fri, 15 Sep 2017 02:09:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level: 
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z17skFMxTZND; Fri, 15 Sep 2017 02:09:53 -0700 (PDT)
Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DE1F13307A; Fri, 15 Sep 2017 02:09:53 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id E2079C0A5C; Fri, 15 Sep 2017 11:09:51 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id BE72840058; Fri, 15 Sep 2017 11:09:51 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0361.001; Fri, 15 Sep 2017 11:09:51 +0200
From: 
To: Adam Roach 
CC: "draft-ietf-ospf-encapsulation-cap@ietf.org" , Acee Lindem , "ospf-chairs@ietf.org" , "acee@cisco.com" , "ospf@ietf.org" , The IESG 
Thread-Topic: Adam Roach's No Objection on draft-ietf-ospf-encapsulation-cap-06: (with COMMENT)
Thread-Index: AQHTIfgSj516pZXrDEWv3E2leGm/s6K0rIqw
Date: Fri, 15 Sep 2017 09:09:51 +0000
Message-ID: <16944_1505466591_59BB98DF_16944_219_1_53C29892C857584299CBF5D05346208A47874C69@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <150414274365.16920.7812788361564927226.idtracker@ietfa.amsl.com>
In-Reply-To: <150414274365.16920.7812788361564927226.idtracker@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OSPF] Adam Roach's No Objection on draft-ietf-ospf-encapsulation-cap-06: (with COMMENT)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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 Sep 2017 09:09:55 -0000

SGkgQWRhbSwNCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgY29tbWVudHMuDQpQbGVhc2Ug
c2VlIGlubGluZSBbQnJ1bm9dDQoNCj4gRnJvbTogQWRhbSBSb2FjaCBbbWFpbHRvOmFkYW1Abm9z
dHJ1bS5jb21dDQogPiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDMxLCAyMDE3IDM6MjYgQU0NCj4g
DQogPiBBZGFtIFJvYWNoIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9u
IGZvcg0KID4gZHJhZnQtaWV0Zi1vc3BmLWVuY2Fwc3VsYXRpb24tY2FwLTA2OiBObyBPYmplY3Rp
b24NCiA+IA0KID4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5l
IGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQogPiBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4g
dGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KID4gaW50cm9kdWN0
b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQogPiANCiA+IA0KID4gUGxlYXNlIHJlZmVyIHRvIGh0
dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0K
ID4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBv
c2l0aW9ucy4NCiA+IA0KID4gDQogPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFs
bG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQogPiBodHRwczovL2RhdGF0cmFja2Vy
LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9zcGYtZW5jYXBzdWxhdGlvbi1jYXAvDQogPiANCiA+
IA0KID4gDQogPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogPiBDT01NRU5UOg0KID4gLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
ID4gDQogPiBTZWN0aW9uIDUgc3BlY2lmaWVzIHRoYXQgdW5rbm93biBTdWItVExWcyBhcmUgaWdu
b3JlZCwgYnV0IHRoYXQNCiA+IGtub3duLWFuZC1pbnZhbGlkIFN1Yi1UTFZzIHJ1aW4gdGhlIHdo
b2xlIFRMVi4NCg0KW0JydW5vXSANCiJBbnkgdW5rbm93biBTdWItVExWcyBNVVNUIGJlIGlnbm9y
ZWQgYW5kIHNraXBwZWQgdXBvbiByZWNlaXB0LiINCg0KTG9va3MgZ29vZCB0byBtZSBhbmQgcHJl
c2VydmUgdGhlIFRMViBwcm9wZXJ0aWVzLg0KDQoiSWYgYSBTdWItVExWIGlzIGludmFsaWQsIGl0
cyBUdW5uZWwgRW5jYXBzdWxhdGlvbiBUTFYgTVVTVCBiZSBpZ25vcmVkDQogICBhbmQgc2tpcHBl
ZC4gIEhvd2V2ZXIsIG90aGVyIFR1bm5lbCBFbmNhcHN1bGF0aW9uIFRMVnMgTVVTVCBiZQ0KICAg
Y29uc2lkZXJlZC4iDQoNCk1lYW5zIHRoYXQgaWYgYSB0dW5uZWwgcGFyYW1ldGVyIGlzIGtub3du
IHRvIGJlIGludmFsaWQsIHRoZSBzZW5kZXIgaGFzIG1hZGUgYSBzeW50YXggb3Igc2VtYW50aWMg
ZXJyb3IgYW5kIHRoZSB3aG9sZSB0dW5uZWwgbXVzdCBub3QgYmUgdXNlZCAoYXMgc29tZSBwYXJh
bWV0ZXJzIGFyZSBrbm93biB0byBiZSB3cm9uZywgaGVuY2UgdGhlIHdob2xlIHR1bm5lbCBjYW4n
dCBiZSB0cnVzdGVkLikNCkkgZG9uJ3Qgc2VlIGhvdyB0aGlzIGJlaGF2aW9yIHJ1aW5zIHRoZSB3
aG9sZSBUTFYuIENvdWxkIHlvdSBwbGVhc2UgZWxhYm9yYXRlPw0KT1RPSCwgSSBjYW4gaW1hZ2lu
ZSB0aGF0IHRoZSB3b3JkaW5nIGlzIG5vdCBnb29kIGVub3VnaC4gSSd2ZSB0cmllZCBhIG1vcmUg
ZGV0YWlsIHRleHQ6DQpQcm9wb3NlZCBORVc6DQpBbnkgdW5rbm93biBUdW5uZWwgUGFyYW1ldGVy
IFN1Yi1UeXBlIE1VU1QgYmUgaWdub3JlZCBhbmQgc2tpcHBlZCB1cG9uIHJlY2VpcHQuIFdoZW4g
YSByZXNlcnZlZA0KICAgICAgdmFsdWUgKFNlZSA8eHJlZiB0YXJnZXQ9IlBhcmFtZXRlcnNSZWdp
c3RyeSIvPikgaXMgc2VlbiBpbiBhbiBMU0EsIGl0DQogICAgICBNVVNUIGJlIHRyZWF0ZWQgYXMg
YW4gaW52YWxpZCBUdW5uZWwgUGFyYW1ldGVyIFN1Yi1UTFYuIFdoZW4gYSBUdW5uZWwgUGFyYW1l
dGVyIFZhbHVlIGhhcyBhbiBpbmNvcnJlY3Qgc3ludGF4IG9mIHNlbWFudGljLCBpdCBNVVNUIGJl
IHRyZWF0ZWQgYXMgYW4gaW52YWxpZCBUdW5uZWwgUGFyYW1ldGVyIFN1Yi1UTFYuIElmIGEgVHVu
bmVsIFBhcmFtZXRlciBTdWItVExWIGlzIGludmFsaWQsIGl0cw0KICAgICAgVHVubmVsIFN1Yi1U
TFYgTVVTVCBiZSBpZ25vcmVkIGFuZCBza2lwcGVkLiBIb3dldmVyLA0KICAgICAgb3RoZXIgVHVu
bmVsIFN1Yi1UTFZzIE1VU1QgYmUgY29uc2lkZXJlZC4NCg0KDQogPiBJdCBzZWVtcyBhIGJpdCBv
ZGQgdGhhdCBhIGxlc3MNCiA+IGNhcGFibGUgaW1wbGVtZW50YXRpb24gd291bGQgYmUgYWJsZSB0
byBhY3Qgb24gYW4gYW5ub3VuY2VtZW50IG9mIGEgdHVubmVsLCB5ZXQNCiA+IGEgbW9yZSBjYXBh
YmxlIG9uZSB3b3VsZCBub3QgLS0gYW5kIHRoYXQncyB0aGUgZXhhY3QgY29uc2VxdWVuY2Ugb2Yg
dGhpcw0KID4gYXJyYW5nZW1lbnQuIEl0IHdvdWxkIHNlZW0gdG8gbWFrZSBtb3JlIHNlbnNlIHRv
IGFsbG93IGltcGxlbWVudGF0aW9ucyB0bw0KID4gaWdub3JlIGludmFsaWQgU3ViLVRMVnMgYXMg
aWYgdGhleSBkaWRuJ3Qga25vdyB0aGVtLg0KIA0KW0JydW5vXSBUaGF0J3MgYW5vdGhlciBwb3Nz
aWJsZSBvcHRpb24sIGJ1dCBpdCBhbHNvIGhhcyBkcmF3YmFja3MuIEZvciBleGFtcGxlIHRoZSBp
bnZhbGlkIHBhcmFtZXRlciBtYXkgYmUgYSBtYW5kYXRvcnkgb25lIChlLmcuIGFzIHRoZSBkZWNh
cHN1bGF0b3IsIEkgcmVxdWlyZSBlbmNyeXB0aW9uKSBhbmQgaWdub3JpbmcgdGhpcyBwYXJhbWV0
ZXIgYnV0IGtlZXBpbmcgdGhlIHR1bm5lbCB3aXRob3V0IHRoaXMgcGFyYW1ldGVyIG1heSBiZSBh
IHBvbGljeSB2aW9sYXRpb24sIG9yIGxlYWQgdG8gdGVjaG5pY2FsIGVycm9ycyBkcm9wcGluZyBh
bGwgcGFja2V0cyBmcm9tIHRoaXMgdHVubmVsLCBvciBzZW5kaW5nIHBhY2tldCB0byBhIHdyb25n
IGRlc3RpbmF0aW9uL3RlbmFudCBpZiB0aGUgdHVubmVsIGlzIHVzZWQgZm9yIG92ZXJsYXkuLi4u
DQpPbmUgb3B0aW9uIHdvdWxkIGJlIHRvIGFkZCBmbGFncyB0byBkZWZpbmUgdGhlIGJlaGF2aW9y
IGluIHRoaXMgY2FzZS4gQnV0IHRoYXQgaXMgYWRkaXRpb25hbCBjb21wbGV4aXR5Lg0KIA0KID4g
U2VjdGlvbiA3LjIgYWxsb2NhdGVzIHRoZSB2YWx1ZSA2NTUzNSB0d2ljZSAob25jZSBhcyAiRXhw
ZXJpbWVudGFsIiwgb25jZSBhcw0KID4gIlJlc2VydmVkIikuDQogDQpbQnJ1bm9dIENvcnJlY3Rl
ZC4gVGhhbmtzDQoNCiANCiA+IEkgYmVsaWV2ZSB0aGF0IHRoaXMgbWVjaGFuaXNtIGludHJvZHVj
ZXMgYW4gYXR0YWNrIHZlY3RvciB0aGF0IGlzIG5vdCBkaXNjdXNzZWQNCiA+IGluIHRoZSBTZWN1
cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLiBTcGVjaWZpY2FsbHk6IGJlY2F1c2UgdGhpcyBh
bGxvd3MNCiA+IHJvdXRlcnMgdG8gc2VuZCBPU1BGIGFubm91bmNlbWVudHMgY29udGFpbmluZyBh
cmJpdHJhcnkgdHVubmVsIHRlcm1pbmF0aW9uDQogPiBhZGRyZXNzZXMsIGl0IGNhbiBjYXVzZSBv
dGhlciByb3V0ZXJzIHRvIGF0dGVtcHQgdG8gY29ubmVjdCB0byBhcmJpdHJhcnkgdGhpcmQNCiA+
IHBhcnRpZXM7DQoNCltCcnVub10gSSBiZWxpZXZlIHRoaXMgcG9pbnQgaXMgYWxyZWFkeSBjb3Zl
cmVkIChpLmUuIGV4cGxpY2l0bHkgZm9yYmlkZGVuKSBieSB0aGUgc3BlY2lmaWNhdGlvbjoNCiIg
ICBBIHR1bm5lbCBNVVNUIE5PVCBiZSB1c2VkIGlmIHRoZXJlIGlzIG5vIHJvdXRlIHRvd2FyZCB0
aGUgSVAgYWRkcmVzcw0KICAgc3BlY2lmaWVkIGluIHRoZSBFbmRwb2ludCBTdWItVExWIG9yIGlm
IHRoZSByb3V0ZSBpcyBub3QgYWR2ZXJ0aXNlZA0KICAgYnkgdGhlIHJvdXRlciBhZHZlcnRpc2lu
ZyB0aGUgVHVubmVsIEVuY2Fwc3VsYXRpb24gYXR0cmlidXRlIGZvciB0aGUNCiAgIHR1bm5lbC4i
DQoNCg0KDQogPiAgYW5kLCBzaW5jZSAoYnkgbXkgYWRtaXR0ZWRseSBzaGFreSB1bmRlcnN0YW5k
aW5nIG9mIE9TUEYpLCBJIGNhbg0KID4gZGlzdHJpYnV0ZSB0aGlzIGluZm9ybWF0aW9uIHRvIGEg
bGFyZ2UgY29tbXVuaXR5IG9mIHJvdXRlcnMgd2l0aCBhIHNpbmdsZQ0KID4gbWVzc2FnZSBieSBz
ZW5kaW5nIGl0IHRvIGFuIFJSLCBJIGNhbiBlYXNpbHkgY2F1c2UgYSAqbG90KiBvZiByb3V0ZXJz
IHRvDQogPiBwb3RlbnRpYWxseSBzZW5kIHN1Y2ggdHJhZmZpYy4gRm9yIGV4YW1wbGUsIGlmIEkg
d2VyZSBhYmxlIHRvIGluamVjdCBhbg0KID4gYW5ub3VuY2VtZW50IHRoYXQgaGFzIChhKSBhIHR1
bm5lbCB0eXBlIG9mIDEzICgiTVBMUyBpbiBVRFAgRW5jYXBzdWxhdGlvbiIpLA0KID4gKGIpIGFu
ICJFbmRwb2ludCBTdWItVExWIiBvZiBhIHZpY3RpbSB3ZWIgc2VydmVyIHRoYXQgSSBrbm93IHJ1
bnMgUVVJQywgYW5kIChjKQ0KID4gYSAiVURQIERlc3RpbmF0aW9uIFBvcnQiIG9mIDQ0Mywgd291
bGRuJ3QgdGhpcyByZXN1bHQgaW4gYSBwb3RlbnRpYWwgRERvUyBvZg0KID4gdGhhdCB3ZWIgc2Vy
dmVyPw0KIA0KW0JydW5vXSB0aGUgdGV4dCBjaXRlZCBzcGVjaWZpY2FsbHkgZm9yYmlkIHRoaXMg
ZXhhbXBsZS4NCiANCiA+IEkgZG9uJ3Qga25vdyB3aGF0IHRoZSBzZWN1cml0eSBtb2RlbCBvZiBP
U1BGIGlzIG9yIGhvdyBkaWZmaWN1bHQgaXQgd291bGQgYmUgdG8NCiA+IG1vdW50IHRoaXMgYXR0
YWNrIChvciBldmVuIGhvdyBiYWQgaXQgd291bGQgYmUgY29tcGFyZWQgdG8gb3RoZXIgYXR0YWNr
cyBvbmUNCiA+IG1pZ2h0IG1vdW50IGluIE9TUEYpLCBidXQgaXQgc2VlbXMgdGhhdCBhIGJyaWVm
IHRyZWF0bWVudCBvZiB0aGlzIC0tIGFsb25nIHdpdGgNCiA+IGFueSBvcGVyYXRpb25hbCBtaXRp
Z2F0aW9uIHRlY2huaXF1ZXMgdGhhdCBtaWdodCBiZSBlbXBsb3llZCBhZ2FpbnN0IGl0IC0tDQog
PiBzaG91bGQgYmUgcGFydCBvZiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMuDQogPiANCg0K
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVu
aXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5l
IGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z
IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2
ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBx
dWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBz
dXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJp
bGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVy
Y2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRl
bnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg
bGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhv
dXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv
ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBp
dHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBs
aWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZh
bHNpZmllZC4KVGhhbmsgeW91LgoK


From nobody Fri Sep 15 04:59:55 2017
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 E31FF1331DD; Fri, 15 Sep 2017 04:59:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.617
X-Spam-Level: 
X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fw7AyeRxmojH; Fri, 15 Sep 2017 04:59:52 -0700 (PDT)
Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20C191331D2; Fri, 15 Sep 2017 04:59:52 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id BB1E5601AB; Fri, 15 Sep 2017 13:59:50 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 8C64E4004C; Fri, 15 Sep 2017 13:59:50 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0361.001; Fri, 15 Sep 2017 13:59:50 +0200
From: 
To: "Acee Lindem (acee)" , Alia Atlas , OSPF List 
CC: "draft-ietf-ospf-encapsulation-cap@ietf.org" 
Thread-Topic: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-06
Thread-Index: AQHTExSrMIAKYzPaJ0esRx1rCNILFqKA2CIAgDUw5oA=
Date: Fri, 15 Sep 2017 11:59:49 +0000
Message-ID: <13458_1505476790_59BBC0B6_13458_72_1_53C29892C857584299CBF5D05346208A47875384@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References:  
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.1]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A47875384OPEXCLILM21corp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-06
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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 Sep 2017 11:59:54 -0000

--_000_53C29892C857584299CBF5D05346208A47875384OPEXCLILM21corp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQWxpYSwgQWNlZSwgV0cNCg0KRnJvbTogQWNlZSBMaW5kZW0gKGFjZWUpIFttYWlsdG86YWNl
ZUBjaXNjby5jb21dDQpTZW50OiBTYXR1cmRheSwgQXVndXN0IDEyLCAyMDE3IDc6MjUgUE0NClRv
OiBBbGlhIEF0bGFzOyBkcmFmdC1pZXRmLW9zcGYtZW5jYXBzdWxhdGlvbi1jYXBAaWV0Zi5vcmc7
IE9TUEYgTGlzdA0KU3ViamVjdDogUmU6IFtPU1BGXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1v
c3BmLWVuY2Fwc3VsYXRpb24tY2FwLTA2DQoNCkhpIEFsaWEsDQoNCkZyb206IE9TUEYgPG9zcGYt
Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86b3NwZi1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxm
IG9mIEFsaWEgQXRsYXMgPGFrYXRsYXNAZ21haWwuY29tPG1haWx0bzpha2F0bGFzQGdtYWlsLmNv
bT4+DQpEYXRlOiBGcmlkYXksIEF1Z3VzdCAxMSwgMjAxNyBhdCAxMDo0MiBQTQ0KVG86ICJkcmFm
dC1pZXRmLW9zcGYtZW5jYXBzdWxhdGlvbi1jYXBAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYt
b3NwZi1lbmNhcHN1bGF0aW9uLWNhcEBpZXRmLm9yZz4iIDxkcmFmdC1pZXRmLW9zcGYtZW5jYXBz
dWxhdGlvbi1jYXBAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtb3NwZi1lbmNhcHN1bGF0aW9u
LWNhcEBpZXRmLm9yZz4+LCBPU1BGIFdHIExpc3QgPG9zcGZAaWV0Zi5vcmc8bWFpbHRvOm9zcGZA
aWV0Zi5vcmc+Pg0KU3ViamVjdDogW09TUEZdIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW9zcGYt
ZW5jYXBzdWxhdGlvbi1jYXAtMDYNCg0KQXMgaXMgY3VzdG9tYXJ5LCBJIGhhdmUgZG9uZSBhbm90
aGVyIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW9zcGYtZW5jYXBzdWxhdGlvbi1jYXAtMDYuICBG
aXJzdCwgSSdkIGxpa2UgdG8gdGhhbmsgdGhlIGF1dGhvcnMgZm9yIHRoZWlyIHdvcmsgYW5kIHRo
ZSBpbXByb3ZlbWVudC4NCg0KSSBoYXZlIG9uZSBtaW5vciBpc3N1ZSBvbiB0aGUgSUFOQSBzZWN0
aW9uLg0KDQpGb3IgdGhlIGN1cnJlbnQgRkNGUyBzcGFjZSwgSSB0aGluayBpdCB3b3VsZCBiZSBi
ZXR0ZXIgdG8gaGF2ZSAiU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCIgc28gdGhhdCB0aGVyZSdzIGEg
cGxhY2UgdG8gbG9vayB0byB1bmRlcnN0YW5kIHdoYXQgc3ViLVRMVnMgYXJlIGluY2x1ZGVkLg0K
SWYgdGhlIFdHIGlzIGhhcHB5IHdpdGggRkNGUywgdGhhdCBpcyBmaW5lIHRvby4NCg0KSSBkb27i
gJl0IGhhdmUgYSBzdHJvbmcgb3BpbmlvbiBoZXJlLiBUaGUgZ29hbCBpcyB0byBiZSBzdGluZ3kg
Zm9yIHRoZSBjb2RlIHBvaW50cyB0aGF0IG92ZXJsYXAgdGhlIGNvcnJlc3BvbmRpbmcgSVMtSVMg
cmVnaXN0cnkgKHdpdGggYSBzaW5nbGUgb2N0ZXQgdHlwZSkgYW5kIG1vcmUgbGliZXJhbCBoZXJl
LiBIb3dldmVyLCB3ZeKAmXZlIG5ldmVyIGdvbmUgYWxsIHRoZSB3YXkgdG8gRkNGUyBiZWZvcmUg
YW5kIOKAnFNwZWNpZmljYXRpb24gUmVxdWlyZWTigJ0gd291bGQgc2VlbSBtb3JlIGluIGxpbmUg
d2l0aCBvdGhlciBJR1AgcmVnaXN0cmllcy4NCg0KW0JydW5vXSBBbGlhLCBJIHNlZSB5b3VyIHBv
aW50IHRoYXQgd2UgbmVlZCBhIHN0YWJsZSBzcGVjaWZpY2F0aW9uIHRvIGludGVyb3AuIE9uIHRo
ZSBvdGhlciBoYW5kLCBpbiB0aGUgSURSIFdHLCB0aGVyZSBpcyBhIGRpcmVjdGlvbiB0b3dhcmQg
aGF2aW5nIGNvZGUgcG9pbnRzIGVhc2llciB0byBnZXQsIGluIG9yZGVyIHRvIGFsbG93IHF1aWNr
ZXIgaW1wbGVtZW50YXRpb25zIGFuZCBhdm9pZCBzcXVhdHRpbmcuIEkgdGhvdWdoIHRoZSBzaXR1
YXRpb24gd291bGQgYmUgc2ltaWxhciBpbiBPU1BGLCBidXQgbWF5IGJlIG5vdC4g4oCcU3BlY2lm
aWNhdGlvbiBSZXF1aXJlZOKAnSBzZWVtIHRvIG1lIHJvdWdobHkgYXMgaGFyZCB0byBnZXQgYSBj
b2RlIHBvaW50IGZyb20sIHRoYW4g4oCcU3RhbmRhcmQgQWN0aW9u4oCdIHdpdGggZWFybHkgYWxs
b2NhdGlvbi4gUGx1cyB0aGVyZSBpcyBhIG5lZWQgdG8gZmluZCBhIGRlc2lnbmF0ZWQgZXhwZXJ0
Lg0KDQpXaGF0IGFib3V0IGNoYW5naW5nIHRoZSBzaXplIG9mIHRoZSByYW5nZXM/IGUuZy4NCi0g
dGhlIGZpcnN0IGhhbGYgZm9yIFNURCBhY3Rpb24gKDEg4oCTIDMxOTk5KQ0KLSBzZWNvbmQgaGFs
ZiBmb3IgRkNGUyAgICAgICAgICgzMjAwMC02NTQ5OSkNCg0KV2l0aCAzMmsgZW50cmllcyBpbiBl
YWNoIHJhbmdlLCB0aGVyZSBzZWVtIHRvIGJlIOKAnHBsZW50eeKAnSBmb3IgZXZlcnlvbmUsIGV2
ZW4gaWYgdGhlIElFVEYgZ2V0cyBjcmVhdGl2ZSB3aXRoIG1hbnkgdHVubmVsIGVuY2Fwc3VsYXRp
b25zIGFuZCBtYW55IHBhcmFtZXRlcnMgZm9yIGVhY2guDQoNClRoYW5rcywNClJlZ2FyZHMsDQot
LUJydW5vDQoNCg0KDQpJJ20gYXNraW5nIGZvciBhbiBJRVRGIExhc3QgQ2FsbCBhbmQgd2lsbCBw
dXQgdGhpcyBvbiB0aGUgdGVsZWNoYXQgb24gQXVnIDMxLg0KDQpUaGFua3Mg4oCTIGhvcGUgdG8g
Y2xlYXIgc29tZSBtb3JlIG9mIHRoZXNlIOKAnGFsbW9zdCByZWFkeSIgZG9jdW1lbnRzIHByaW9y
IHRvIG5leHQgSUVURi4NCkFjZWUNCg0KDQpSZWdhcmRzLA0KQWxpYQ0KCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1l
c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0
aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpw
YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g
U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu
YWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq
b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh
bHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz
YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3Nh
Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls
ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3Vs
ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv
bi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm
eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu
CkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh
Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsg
eW91LgoK

--_000_53C29892C857584299CBF5D05346208A47875384OPEXCLILM21corp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0
YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl
LWxpbms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu
cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt
cmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7
DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4uVGV4dGVk
ZWJ1bGxlc0Nhcg0KCXttc28tc3R5bGUtbmFtZToiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMiOw0K
CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv
cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44
NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp
b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1
bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp
ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl
bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVy
cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBBbGlhLCBBY2VlLCBXRzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk
aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu
ZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206
PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFjZWUgTGluZGVtIChhY2Vl
KSBbbWFpbHRvOmFjZWVAY2lzY28uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBB
dWd1c3QgMTIsIDIwMTcgNzoyNSBQTTxicj4NCjxiPlRvOjwvYj4gQWxpYSBBdGxhczsgZHJhZnQt
aWV0Zi1vc3BmLWVuY2Fwc3VsYXRpb24tY2FwQGlldGYub3JnOyBPU1BGIExpc3Q8YnI+DQo8Yj5T
dWJqZWN0OjwvYj4gUmU6IFtPU1BGXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vc3BmLWVuY2Fw
c3VsYXRpb24tY2FwLTA2PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGkg
QWxpYSwmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbToN
Cjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5PU1BG
ICZsdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBo
cmVmPSJtYWlsdG86b3NwZi1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdCI+b3NwZi1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7DQogb24gYmVoYWxmIG9mIEFsaWEg
QXRsYXMgJmx0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si
PjxhIGhyZWY9Im1haWx0bzpha2F0bGFzQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQiPmFrYXRsYXNAZ21haWwuY29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk
ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRhdGU6DQo8L3NwYW4+PC9iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJpZGF5LCBBdWd1c3QgMTEsIDIw
MTcgYXQgMTA6NDIgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpkcmFm
dC1pZXRmLW9zcGYtZW5jYXBzdWxhdGlvbi1jYXBAaWV0Zi5vcmciPmRyYWZ0LWlldGYtb3NwZi1l
bmNhcHN1bGF0aW9uLWNhcEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpk
cmFmdC1pZXRmLW9zcGYtZW5jYXBzdWxhdGlvbi1jYXBAaWV0Zi5vcmciPmRyYWZ0LWlldGYtb3Nw
Zi1lbmNhcHN1bGF0aW9uLWNhcEBpZXRmLm9yZzwvYT4mZ3Q7LCBPU1BGIFdHIExpc3QgJmx0Ozxh
IGhyZWY9Im1haWx0bzpvc3BmQGlldGYub3JnIj5vc3BmQGlldGYub3JnPC9hPiZndDs8YnI+DQo8
Yj5TdWJqZWN0OiA8L2I+W09TUEZdIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW9zcGYtZW5jYXBz
dWxhdGlvbi1jYXAtMDY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowY20g
MGNtIDBjbSA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBjbSIgaWQ9Ik1B
Q19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs
YWNrIj5BcyBpcyBjdXN0b21hcnksIEkgaGF2ZSBkb25lIGFub3RoZXIgQUQgcmV2aWV3IG9mJm5i
c3A7ZHJhZnQtaWV0Zi1vc3BmLWVuY2Fwc3VsYXRpb24tY2FwLTA2LiZuYnNwOyBGaXJzdCwgSSdk
IGxpa2UgdG8gdGhhbmsgdGhlIGF1dGhvcnMgZm9yIHRoZWlyIHdvcmsgYW5kIHRoZSBpbXByb3Zl
bWVudC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SSBoYXZlIG9uZSBtaW5vciBpc3N1
ZSBvbiB0aGUgSUFOQSBzZWN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr
Ij5Gb3IgdGhlIGN1cnJlbnQgRkNGUyBzcGFjZSwgSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIg
dG8gaGF2ZSAmcXVvdDtTcGVjaWZpY2F0aW9uIFJlcXVpcmVkJnF1b3Q7IHNvIHRoYXQgdGhlcmUn
cyBhIHBsYWNlIHRvIGxvb2sgdG8gdW5kZXJzdGFuZCB3aGF0IHN1Yi1UTFZzIGFyZSBpbmNsdWRl
ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPklmIHRoZSBXRyBp
cyBoYXBweSB3aXRoIEZDRlMsIHRoYXQgaXMgZmluZSB0b28uPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs
YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkg
ZG9u4oCZdCBoYXZlIGEgc3Ryb25nIG9waW5pb24gaGVyZS4gVGhlIGdvYWwgaXMgdG8gYmUgc3Rp
bmd5IGZvciB0aGUgY29kZSBwb2ludHMgdGhhdCBvdmVybGFwIHRoZSBjb3JyZXNwb25kaW5nIElT
LUlTIHJlZ2lzdHJ5ICh3aXRoIGEgc2luZ2xlIG9jdGV0IHR5cGUpIGFuZA0KIG1vcmUgbGliZXJh
bCBoZXJlLiBIb3dldmVyLCB3ZeKAmXZlIG5ldmVyIGdvbmUgYWxsIHRoZSB3YXkgdG8gRkNGUyBi
ZWZvcmUgYW5kIOKAnFNwZWNpZmljYXRpb24gUmVxdWlyZWTigJ0gd291bGQgc2VlbSBtb3JlIGlu
IGxpbmUgd2l0aCBvdGhlciBJR1AgcmVnaXN0cmllcy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+W0Jy
dW5vXSBBbGlhLCBJIHNlZSB5b3VyIHBvaW50IHRoYXQgd2UgbmVlZCBhIHN0YWJsZSBzcGVjaWZp
Y2F0aW9uIHRvIGludGVyb3AuIE9uIHRoZSBvdGhlciBoYW5kLCBpbiB0aGUgSURSIFdHLCB0aGVy
ZSBpcyBhIGRpcmVjdGlvbiB0b3dhcmQgaGF2aW5nDQogY29kZSBwb2ludHMgZWFzaWVyIHRvIGdl
dCwgaW4gb3JkZXIgdG8gYWxsb3cgcXVpY2tlciBpbXBsZW1lbnRhdGlvbnMgYW5kIGF2b2lkIHNx
dWF0dGluZy4gSSB0aG91Z2ggdGhlIHNpdHVhdGlvbiB3b3VsZCBiZSBzaW1pbGFyIGluIE9TUEYs
IGJ1dCBtYXkgYmUgbm90LiDigJxTcGVjaWZpY2F0aW9uIFJlcXVpcmVk4oCdIHNlZW0gdG8gbWUg
cm91Z2hseSBhcyBoYXJkIHRvIGdldCBhIGNvZGUgcG9pbnQgZnJvbSwgdGhhbiDigJxTdGFuZGFy
ZCBBY3Rpb27igJ0NCiB3aXRoIGVhcmx5IGFsbG9jYXRpb24uIFBsdXMgdGhlcmUgaXMgYSBuZWVk
IHRvIGZpbmQgYSBkZXNpZ25hdGVkIGV4cGVydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si
PldoYXQgYWJvdXQgY2hhbmdpbmcgdGhlIHNpemUgb2YgdGhlIHJhbmdlcz8gZS5nLg0KPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi0gdGhlIGZpcnN0IGhhbGYgZm9yIFNU
RCBhY3Rpb24gKDEg4oCTIDMxOTk5KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs
YWNrIj4tIHNlY29uZCBoYWxmIGZvciBGQ0ZTICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOygzMjAwMC02NTQ5OSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh
Y2siPldpdGggMzJrIGVudHJpZXMgaW4gZWFjaCByYW5nZSwgdGhlcmUgc2VlbSB0byBiZSDigJxw
bGVudHnigJ0gZm9yIGV2ZXJ5b25lLCBldmVuIGlmIHRoZSBJRVRGIGdldHMgY3JlYXRpdmUgd2l0
aCBtYW55IHR1bm5lbCBlbmNhcHN1bGF0aW9ucyBhbmQgbWFueSBwYXJhbWV0ZXJzDQogZm9yIGVh
Y2guPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6YmxhY2siPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6YmxhY2siPi0tQnJ1bm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj
ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0
LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBjbSIgaWQ9Ik1BQ19PVVRMT09L
X0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw
LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjpibGFjayI+SSdtIGFza2luZyBmb3IgYW4gSUVURiBMYXN0IENhbGwgYW5kIHdpbGwgcHV0IHRo
aXMgb24gdGhlIHRlbGVjaGF0IG9uIEF1ZyAzMS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhhbmtzIOKA
kyBob3BlIHRvIGNsZWFyIHNvbWUgbW9yZSBvZiB0aGVzZSDigJxhbG1vc3QgcmVhZHkmcXVvdDsg
ZG9jdW1lbnRzIHByaW9yIHRvIG5leHQgSUVURi4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6YmxhY2siPkFjZWUmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYg
NC41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2lu
LXJpZ2h0OjBjbSIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjpibGFjayI+QWxpYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxQUkU+
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p
ciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUg
ZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMg
YXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZl
dWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1
ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1
c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmls
aXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJj
aS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu
dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs
YXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91
dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y
LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0
cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp
YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs
c2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_53C29892C857584299CBF5D05346208A47875384OPEXCLILM21corp_--


From nobody Fri Sep 15 05:41:22 2017
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 2976A13263F; Fri, 15 Sep 2017 05:41:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGvll2AuImp1; Fri, 15 Sep 2017 05:41:19 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8CE13319E; Fri, 15 Sep 2017 05:41:18 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id i189so7997040wmf.1; Fri, 15 Sep 2017 05:41:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8+PCGvtMeThVG+fbzrzVTxbMTVSrL1CmF3m+HSyUWQU=; b=OoGIsISxqXWz0PJ9eJXvd0Z4j0p7G/dnDdVxCyYHIbPiyKELoVCqENSuZnmBE5vA7F UTBpvp3gx72ugAVoy1+9j8wREshm9BKnETMm9nn2WUwEnZu8UWZU5lHztM6Ic3Wv0sDB GAJq8HP9uwn26bL1ZLEIDvrKJuIa7b/Ye5Pvs8a6r1SnDuN9WA+HWOCLc9ZpyckbsM+o oXJhLEsMrM2xIMYge5HuGTEGyQGtZ9bgFEk/q8OCt5xfZvgTl5HboVxqgt6HiddLGg0w mAGIMD7K4BLiEdwbasGSOHkaNlFIqTbOI46ynKkB+a5HLcNSZGO+oYSy2baWKjF6WLMw f6ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8+PCGvtMeThVG+fbzrzVTxbMTVSrL1CmF3m+HSyUWQU=; b=R87y2DtNUobTN/0R/AfH/ft80W9a/gvDMN/31C+YYdHue1xI9ore7MyhtipoOEWPBa FtDRtiQAKnXDYLWjb8JZTddftyr2D/fpxEq9DTxb0l270D8RlYUMrgyiglVOGv70GPtc CVZulHVQE3q1aaTLAK99UonHFFaAlp78691wdxZs1uEfHgaCMTVl0qj2pqXik232q1oa qjIcBYkvr7wHRoP8kiHuFOztYKiZk1+i0sm+LJr7Durv45qgEz/V1tXv0ssWg8k5NdqN 4PswFm2j3bA0ZczNt7lLkW1i1K1dkpG4A/soZuq+++Tp3x4VrdVQWr/NIaNwfMB+UI4U IXMQ==
X-Gm-Message-State: AHPjjUgnOOM8KDOBI1EGL+7sr0sLMJETzIBOe23oNWn45f6UKC5ktlPd 8g6lx+QiYercuRE4OjA63fzSooo7p2mmklaZzrk=
X-Google-Smtp-Source: AOwi7QA7k2T2/+0bbZ9hIC+lU1HEqb7+86uVLmBGsivNBE5PTSi3kfMeSPrfjtKWNzRxPgEpWSXsusejG07XE3ttv0g=
X-Received: by 10.28.54.101 with SMTP id d98mr2516339wma.90.1505479276880; Fri, 15 Sep 2017 05:41:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.136.153 with HTTP; Fri, 15 Sep 2017 05:41:16 -0700 (PDT)
In-Reply-To: <13458_1505476790_59BBC0B6_13458_72_1_53C29892C857584299CBF5D05346208A47875384@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References:   <13458_1505476790_59BBC0B6_13458_72_1_53C29892C857584299CBF5D05346208A47875384@OPEXCLILM21.corporate.adroot.infra.ftgroup>
From: Alia Atlas 
Date: Fri, 15 Sep 2017 08:41:16 -0400
Message-ID: 
To: Bruno Decraene 
Cc: "Acee Lindem (acee)" , OSPF List ,  "draft-ietf-ospf-encapsulation-cap@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11436bb283e7db055939b57c"
Archived-At: 
Subject: Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-06
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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 Sep 2017 12:41:21 -0000

--001a11436bb283e7db055939b57c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Bruno,

On Fri, Sep 15, 2017 at 7:59 AM,  wrote:

> Hi Alia, Acee, WG
>
>
>
> *From:* Acee Lindem (acee) [mailto:acee@cisco.com]
> *Sent:* Saturday, August 12, 2017 7:25 PM
> *To:* Alia Atlas; draft-ietf-ospf-encapsulation-cap@ietf.org; OSPF List
> *Subject:* Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-06
>
>
>
> Hi Alia,
>
>
>
> *From: *OSPF  on behalf of Alia Atlas <
> akatlas@gmail.com>
>
> *Date: *Friday, August 11, 2017 at 10:42 PM
> *To: *"draft-ietf-ospf-encapsulation-cap@ietf.org"  encapsulation-cap@ietf.org>, OSPF WG List 
> *Subject: *[OSPF] AD review of draft-ietf-ospf-encapsulation-cap-06
>
>
>
> As is customary, I have done another AD review of draft-ietf-ospf-encapsu=
lation-cap-06.
> First, I'd like to thank the authors for their work and the improvement.
>
>
>
> I have one minor issue on the IANA section.
>
>
>
> For the current FCFS space, I think it would be better to have
> "Specification Required" so that there's a place to look to understand wh=
at
> sub-TLVs are included.
>
> If the WG is happy with FCFS, that is fine too.
>
>
>
> I don=E2=80=99t have a strong opinion here. The goal is to be stingy for =
the code
> points that overlap the corresponding IS-IS registry (with a single octet
> type) and more liberal here. However, we=E2=80=99ve never gone all the wa=
y to FCFS
> before and =E2=80=9CSpecification Required=E2=80=9D would seem more in li=
ne with other IGP
> registries.
>
>
>
> [Bruno] Alia, I see your point that we need a stable specification to
> interop. On the other hand, in the IDR WG, there is a direction toward
> having code points easier to get, in order to allow quicker implementatio=
ns
> and avoid squatting. I though the situation would be similar in OSPF, but
> may be not. =E2=80=9CSpecification Required=E2=80=9D seem to me roughly a=
s hard to get a
> code point from, than =E2=80=9CStandard Action=E2=80=9D with early alloca=
tion. Plus there
> is a need to find a designated expert.
>
>
>
> What about changing the size of the ranges? e.g.
>
> - the first half for STD action (1 =E2=80=93 31999)
>
> - second half for FCFS         (32000-65499)
>
>
>
> With 32k entries in each range, there seem to be =E2=80=9Cplenty=E2=80=9D=
 for everyone,
> even if the IETF gets creative with many tunnel encapsulations and many
> parameters for each.
>

The bar for Specification Required is much lower than Standard Action.  It
just looks for something to be written down.  A web-page, an
internet-draft, etc. all qualify.

I prefer to be able to have folks know how to implement using the
code-point, but there are tons available and having a FCFS range is useful.


Acee has tracked better what the case is for OSPF - and I'm happy to have
him make the call here.

Regards,
Alia



> Thanks,
>
> Regards,
>
> --Bruno
>
>
>
>
>
>
>
> I'm asking for an IETF Last Call and will put this on the telechat on Aug
> 31.
>
>
>
> Thanks =E2=80=93 hope to clear some more of these =E2=80=9Calmost ready" =
documents prior
> to next IETF.
>
> Acee
>
>
>
>
>
> Regards,
>
> Alia
>
> _________________________________________________________________________=
________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme o=
u falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged i=
nformation that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>
>

--001a11436bb283e7db055939b57c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Bruno,

On Fri, Sep 15, 2017 at 7:59 AM,  <bruno.decraene@orange.=
com> wrote:











Hi Alia, Acee, WG


=C2=A0







From: Acee Lin=
dem (acee) [mailto:acee=
@cisco.com]


Sent: Saturday, August 12, 2017 7:25 PM

To: Alia Atlas; draft-ietf-ospf-encapsulation-cap@ietf.org=
; OSPF List

Subject: Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-=
cap-06






=C2=A0




Hi Alia,=C2=A0






=C2=A0=







From:
OSPF <ospf-bounces@ietf.org>
 on behalf of Alia Atlas <a=
katlas@gmail.com>






Date:
Friday, August 11, 2017 at 10:42 PM

To: "draft-ietf-ospf-encapsulation-cap@ietf.org&q=
uot; <draft-ietf-ospf-encapsulation-cap@ietf.org>, OSPF=
 WG List <ospf@ietf.o=
rg>

Subject: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-=
06






=C2=A0=













As is customary, I have don=
e another AD review of=C2=A0draft-ietf-ospf-encapsulation-cap-06.=C2=
=A0 First, I'd like to thank the authors for their work and the improve=
ment.





=C2=A0=







I have one minor issue on t=
he IANA section.






=C2=A0=







For the current FCFS space,=
 I think it would be better to have "Specification Required" so t=
hat there's a place to look to understand what sub-TLVs are included.






If the WG is happy with FCF=
S, that is fine too.














=C2=A0=







I don=E2=80=99t have a stro=
ng opinion here. The goal is to be stingy for the code points that overlap =
the corresponding IS-IS registry (with a single octet type) and
 more liberal here. However, we=E2=80=99ve never gone all the way to FCFS b=
efore and =E2=80=9CSpecification Required=E2=80=9D would seem more in line =
with other IGP registries.=C2=A0


=C2=A0

[Bruno]=
 Alia, I see your point that we need a stable specification to interop. On =
the other hand, in the IDR WG, there is a direction toward having
 code points easier to get, in order to allow quicker implementations and a=
void squatting. I though the situation would be similar in OSPF, but may be=
 not. =E2=80=9CSpecification Required=E2=80=9D seem to me roughly as hard t=
o get a code point from, than =E2=80=9CStandard Action=E2=80=9D
 with early allocation. Plus there is a need to find a designated expert.


=C2=A0<=
u>


What about cha=
nging the size of the ranges? e.g.



- the first ha=
lf for STD action (1 =E2=80=93 31999)


- second half =
for FCFS =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(32000-65499)


=C2=A0<=
u>


With 32k entri=
es in each range, there seem to be =E2=80=9Cplenty=E2=80=9D for everyone, e=
ven if the IETF gets creative with many tunnel encapsulations and many para=
meters
 for each.

The bar for Specification Required is much lower than Standard Action.=
=C2=A0 It just looks for something to be written down.=C2=A0 A web-page, an=
 internet-draft, etc. all qualify.

I prefer to be =
able to have folks know how to implement using the code-point, but there ar=
e tons available and having a FCFS range is useful. =C2=A0

Acee has tracked better what the case is for OSPF - and I'm ha=
ppy to have him make the call here.

Regards,
=

Alia

=C2=A0


Thanks,=



Regards,


--Bruno=



=C2=A0<=
u>


=C2=A0<=
u>














=C2=
=A0






I'm asking for an IETF =
Last Call and will put this on the telechat on Aug 31.=















=C2=A0=







Thanks =E2=80=93 hope to cl=
ear some more of these =E2=80=9Calmost ready" documents prior to next =
IETF.=C2=A0






Acee=C2=A0






=C2=A0=















=C2=A0=







Regards,






Alia















____________________________________________________________=
_____________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.







--001a11436bb283e7db055939b57c--


From nobody Fri Sep 15 08:07:56 2017
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 093A71333FE; Fri, 15 Sep 2017 08:07:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id he-hgEwHbRNz; Fri, 15 Sep 2017 08:07:53 -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 3E6FC1321A1; Fri, 15 Sep 2017 08:07:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28143; q=dns/txt; s=iport; t=1505488073; x=1506697673; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hIx2lqwuaZDPjns4bEM4wLsUTO7j5oTq41FTFWCRd7E=; b=jD1t4bjrvNzGuyO6sW7pC3jXbJ9iJRYK8KBm6+uVHwWeeg5Fmvnn4Pzn AfQgiaRJ3xBQs02/C/DF6fQ01hHKNdrFgBFyYvh+HCghJ0dKUat4BHXp7 LpV6vk1ywruwdaaDtECU6kJgv+GR5xEqzE5P8xJlNkDpKALeiOnYyeoZV A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAABj67tZ/4ENJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rgVInB4NuiiCPc4F0iDuNbA6CBAqFPAIahBA/GAECAQEBAQE?= =?us-ascii?q?BAWsohRgBAQEBAyNIDhACAQgOAwMBAQEhBwMCAgIfERQJCAIEAQ0FiU9MAxWsH?= =?us-ascii?q?YInhzcNg2oBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgyuCAoMyAYMogliBbQESATY?= =?us-ascii?q?JBgYKgl2CYAWgSDwCizWEJ4R3ghOFaop7jFmILAIRGQGBOAEfOIECC3cVSYccd?= =?us-ascii?q?oZfgSOBDwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,397,1500940800";  d="scan'208,217";a="295870637"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Sep 2017 15:07:51 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v8FF7pox025680 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Sep 2017 15:07:51 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.1263.5; Fri, 15 Sep 2017 11:07: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.1263.000; Fri, 15 Sep 2017 11:07:50 -0400
From: "Acee Lindem (acee)" 
To: Alia Atlas , Bruno Decraene 
CC: OSPF List , "draft-ietf-ospf-encapsulation-cap@ietf.org" 
Thread-Topic: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-06
Thread-Index: AQHTExSskCOZv1Go10+AOLB+JMqb8qKA+ZeAgDVXkICAAAuVAP//5d4A
Date: Fri, 15 Sep 2017 15:07:50 +0000
Message-ID: 
References:   <13458_1505476790_59BBC0B6_13458_72_1_53C29892C857584299CBF5D05346208A47875384@OPEXCLILM21.corporate.adroot.infra.ftgroup> 
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.117.47]
Content-Type: multipart/alternative; boundary="_000_D5E1645EC8117aceeciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-06
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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 Sep 2017 15:07:55 -0000

--_000_D5E1645EC8117aceeciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQWxpYSwNCg0KRnJvbTogQWxpYSBBdGxhcyA8YWthdGxhc0BnbWFpbC5jb208bWFpbHRvOmFr
YXRsYXNAZ21haWwuY29tPj4NCkRhdGU6IEZyaWRheSwgU2VwdGVtYmVyIDE1LCAyMDE3IGF0IDg6
NDEgQU0NClRvOiBCcnVubyBEZWNyYWVuZSA8YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTxtYWls
dG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT4+DQpDYzogQWNlZSBMaW5kZW0gPGFjZWVAY2lz
Y28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+LCBPU1BGIFdHIExpc3QgPG9zcGZAaWV0Zi5v
cmc8bWFpbHRvOm9zcGZAaWV0Zi5vcmc+PiwgImRyYWZ0LWlldGYtb3NwZi1lbmNhcHN1bGF0aW9u
LWNhcEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1vc3BmLWVuY2Fwc3VsYXRpb24tY2FwQGll
dGYub3JnPiIgPGRyYWZ0LWlldGYtb3NwZi1lbmNhcHN1bGF0aW9uLWNhcEBpZXRmLm9yZzxtYWls
dG86ZHJhZnQtaWV0Zi1vc3BmLWVuY2Fwc3VsYXRpb24tY2FwQGlldGYub3JnPj4NClN1YmplY3Q6
IFJlOiBbT1NQRl0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb3NwZi1lbmNhcHN1bGF0aW9uLWNh
cC0wNg0KDQpIaSBCcnVubywNCg0KT24gRnJpLCBTZXAgMTUsIDIwMTcgYXQgNzo1OSBBTSwgPGJy
dW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+
PiB3cm90ZToNCkhpIEFsaWEsIEFjZWUsIFdHDQoNCkZyb206IEFjZWUgTGluZGVtIChhY2VlKSBb
bWFpbHRvOmFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT5dDQpTZW50OiBTYXR1
cmRheSwgQXVndXN0IDEyLCAyMDE3IDc6MjUgUE0NClRvOiBBbGlhIEF0bGFzOyBkcmFmdC1pZXRm
LW9zcGYtZW5jYXBzdWxhdGlvbi1jYXBAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtb3NwZi1l
bmNhcHN1bGF0aW9uLWNhcEBpZXRmLm9yZz47IE9TUEYgTGlzdA0KU3ViamVjdDogUmU6IFtPU1BG
XSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vc3BmLWVuY2Fwc3VsYXRpb24tY2FwLTA2DQoNCkhp
IEFsaWEsDQoNCkZyb206IE9TUEYgPG9zcGYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b3NwZi1i
b3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIEFsaWEgQXRsYXMgPGFrYXRsYXNAZ21haWwu
Y29tPG1haWx0bzpha2F0bGFzQGdtYWlsLmNvbT4+DQpEYXRlOiBGcmlkYXksIEF1Z3VzdCAxMSwg
MjAxNyBhdCAxMDo0MiBQTQ0KVG86ICJkcmFmdC1pZXRmLW9zcGYtZW5jYXBzdWxhdGlvbi1jYXBA
aWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtb3NwZi1lbmNhcHN1bGF0aW9uLWNhcEBpZXRmLm9y
Zz4iIDxkcmFmdC1pZXRmLW9zcGYtZW5jYXBzdWxhdGlvbi1jYXBAaWV0Zi5vcmc8bWFpbHRvOmRy
YWZ0LWlldGYtb3NwZi1lbmNhcHN1bGF0aW9uLWNhcEBpZXRmLm9yZz4+LCBPU1BGIFdHIExpc3Qg
PG9zcGZAaWV0Zi5vcmc8bWFpbHRvOm9zcGZAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW09TUEZdIEFE
IHJldmlldyBvZiBkcmFmdC1pZXRmLW9zcGYtZW5jYXBzdWxhdGlvbi1jYXAtMDYNCg0KQXMgaXMg
Y3VzdG9tYXJ5LCBJIGhhdmUgZG9uZSBhbm90aGVyIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW9z
cGYtZW5jYXBzdWxhdGlvbi1jYXAtMDYuICBGaXJzdCwgSSdkIGxpa2UgdG8gdGhhbmsgdGhlIGF1
dGhvcnMgZm9yIHRoZWlyIHdvcmsgYW5kIHRoZSBpbXByb3ZlbWVudC4NCg0KSSBoYXZlIG9uZSBt
aW5vciBpc3N1ZSBvbiB0aGUgSUFOQSBzZWN0aW9uLg0KDQpGb3IgdGhlIGN1cnJlbnQgRkNGUyBz
cGFjZSwgSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gaGF2ZSAiU3BlY2lmaWNhdGlvbiBS
ZXF1aXJlZCIgc28gdGhhdCB0aGVyZSdzIGEgcGxhY2UgdG8gbG9vayB0byB1bmRlcnN0YW5kIHdo
YXQgc3ViLVRMVnMgYXJlIGluY2x1ZGVkLg0KSWYgdGhlIFdHIGlzIGhhcHB5IHdpdGggRkNGUywg
dGhhdCBpcyBmaW5lIHRvby4NCg0KSSBkb27igJl0IGhhdmUgYSBzdHJvbmcgb3BpbmlvbiBoZXJl
LiBUaGUgZ29hbCBpcyB0byBiZSBzdGluZ3kgZm9yIHRoZSBjb2RlIHBvaW50cyB0aGF0IG92ZXJs
YXAgdGhlIGNvcnJlc3BvbmRpbmcgSVMtSVMgcmVnaXN0cnkgKHdpdGggYSBzaW5nbGUgb2N0ZXQg
dHlwZSkgYW5kIG1vcmUgbGliZXJhbCBoZXJlLiBIb3dldmVyLCB3ZeKAmXZlIG5ldmVyIGdvbmUg
YWxsIHRoZSB3YXkgdG8gRkNGUyBiZWZvcmUgYW5kIOKAnFNwZWNpZmljYXRpb24gUmVxdWlyZWTi
gJ0gd291bGQgc2VlbSBtb3JlIGluIGxpbmUgd2l0aCBvdGhlciBJR1AgcmVnaXN0cmllcy4NCg0K
W0JydW5vXSBBbGlhLCBJIHNlZSB5b3VyIHBvaW50IHRoYXQgd2UgbmVlZCBhIHN0YWJsZSBzcGVj
aWZpY2F0aW9uIHRvIGludGVyb3AuIE9uIHRoZSBvdGhlciBoYW5kLCBpbiB0aGUgSURSIFdHLCB0
aGVyZSBpcyBhIGRpcmVjdGlvbiB0b3dhcmQgaGF2aW5nIGNvZGUgcG9pbnRzIGVhc2llciB0byBn
ZXQsIGluIG9yZGVyIHRvIGFsbG93IHF1aWNrZXIgaW1wbGVtZW50YXRpb25zIGFuZCBhdm9pZCBz
cXVhdHRpbmcuIEkgdGhvdWdoIHRoZSBzaXR1YXRpb24gd291bGQgYmUgc2ltaWxhciBpbiBPU1BG
LCBidXQgbWF5IGJlIG5vdC4g4oCcU3BlY2lmaWNhdGlvbiBSZXF1aXJlZOKAnSBzZWVtIHRvIG1l
IHJvdWdobHkgYXMgaGFyZCB0byBnZXQgYSBjb2RlIHBvaW50IGZyb20sIHRoYW4g4oCcU3RhbmRh
cmQgQWN0aW9u4oCdIHdpdGggZWFybHkgYWxsb2NhdGlvbi4gUGx1cyB0aGVyZSBpcyBhIG5lZWQg
dG8gZmluZCBhIGRlc2lnbmF0ZWQgZXhwZXJ0Lg0KDQpXaGF0IGFib3V0IGNoYW5naW5nIHRoZSBz
aXplIG9mIHRoZSByYW5nZXM/IGUuZy4NCi0gdGhlIGZpcnN0IGhhbGYgZm9yIFNURCBhY3Rpb24g
KDEg4oCTIDMxOTk5KQ0KLSBzZWNvbmQgaGFsZiBmb3IgRkNGUyAgICAgICAgICgzMjAwMC02NTQ5
OSkNCg0KV2l0aCAzMmsgZW50cmllcyBpbiBlYWNoIHJhbmdlLCB0aGVyZSBzZWVtIHRvIGJlIOKA
nHBsZW50eeKAnSBmb3IgZXZlcnlvbmUsIGV2ZW4gaWYgdGhlIElFVEYgZ2V0cyBjcmVhdGl2ZSB3
aXRoIG1hbnkgdHVubmVsIGVuY2Fwc3VsYXRpb25zIGFuZCBtYW55IHBhcmFtZXRlcnMgZm9yIGVh
Y2guDQoNClRoZSBiYXIgZm9yIFNwZWNpZmljYXRpb24gUmVxdWlyZWQgaXMgbXVjaCBsb3dlciB0
aGFuIFN0YW5kYXJkIEFjdGlvbi4gIEl0IGp1c3QgbG9va3MgZm9yIHNvbWV0aGluZyB0byBiZSB3
cml0dGVuIGRvd24uICBBIHdlYi1wYWdlLCBhbiBpbnRlcm5ldC1kcmFmdCwgZXRjLiBhbGwgcXVh
bGlmeS4NCg0KSSBwcmVmZXIgdG8gYmUgYWJsZSB0byBoYXZlIGZvbGtzIGtub3cgaG93IHRvIGlt
cGxlbWVudCB1c2luZyB0aGUgY29kZS1wb2ludCwgYnV0IHRoZXJlIGFyZSB0b25zIGF2YWlsYWJs
ZSBhbmQgaGF2aW5nIGEgRkNGUyByYW5nZSBpcyB1c2VmdWwuDQoNCkFjZWUgaGFzIHRyYWNrZWQg
YmV0dGVyIHdoYXQgdGhlIGNhc2UgaXMgZm9yIE9TUEYgLSBhbmQgSSdtIGhhcHB5IHRvIGhhdmUg
aGltIG1ha2UgdGhlIGNhbGwgaGVyZS4NCg0KSSBkb27igJl0IGhhdmUgYSBzdHJvbmcgb3Bpbmlv
biBzbyB3ZSAgY291bGQgZ28gd2l0aCB0aGUgbGFyZ2VyIFNUQU5EQVJEUyBBQ1RJT04gcmFuZ2Ug
YXMgc3VnZ2VzdGVkIGJ5IEFsaWEuIEluIGVpdGhlciByYW5nZXMsIGlmIHdlIGV2ZW4gYXBwcm9h
Y2ggZXhwaXJhdGlvbiBpbiBlaXRoZXIgcmFuZ2UgdGhlIGNhcGFiaWxpdHkgaXMgbW9zdCBsaWtl
bHkgYmVpbmcgbWlzdXNlZC4NCg0KVGhhbmtzLA0KQWNlZQ0KDQoNClJlZ2FyZHMsDQpBbGlhDQoN
Cg0KVGhhbmtzLA0KUmVnYXJkcywNCi0tQnJ1bm8NCg0KDQoNCkknbSBhc2tpbmcgZm9yIGFuIElF
VEYgTGFzdCBDYWxsIGFuZCB3aWxsIHB1dCB0aGlzIG9uIHRoZSB0ZWxlY2hhdCBvbiBBdWcgMzEu
DQoNClRoYW5rcyDigJMgaG9wZSB0byBjbGVhciBzb21lIG1vcmUgb2YgdGhlc2Ug4oCcYWxtb3N0
IHJlYWR5IiBkb2N1bWVudHMgcHJpb3IgdG8gbmV4dCBJRVRGLg0KQWNlZQ0KDQoNClJlZ2FyZHMs
DQpBbGlhDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1
dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl
Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91
IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw
YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0
cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u
aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCk9yYW5nZSBkZWNsaW5lIHRv
dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91
IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5
IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkg
YmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNl
ZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQg
dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg
dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVy
ZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2Rp
ZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCg0K

--_000_D5E1645EC8117aceeciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <070F675BEBE7154AA03AF88181F81B27@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBBbGlhLCZu
YnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD
VElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsg
dGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7
IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1M
RUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29s
aWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4g
c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5BbGlhIEF0bGFzICZsdDs8YSBo
cmVmPSJtYWlsdG86YWthdGxhc0BnbWFpbC5jb20iPmFrYXRsYXNAZ21haWwuY29tPC9hPiZndDs8
YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPkZyaWRheSwg
U2VwdGVtYmVyIDE1LCAyMDE3IGF0IDg6NDEgQU08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln
aHQ6Ym9sZCI+VG86IDwvc3Bhbj5CcnVubyBEZWNyYWVuZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJy
dW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iPmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208L2E+Jmd0
Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPkFjZWUgTGlu
ZGVtICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20iPmFjZWVAY2lzY28uY29tPC9h
PiZndDssIE9TUEYgV0cgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9zcGZAaWV0Zi5vcmciPm9z
cGZAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtb3Nw
Zi1lbmNhcHN1bGF0aW9uLWNhcEBpZXRmLm9yZyI+ZHJhZnQtaWV0Zi1vc3BmLWVuY2Fwc3VsYXRp
b24tY2FwQGlldGYub3JnPC9hPiZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0
Zi1vc3BmLWVuY2Fwc3VsYXRpb24tY2FwQGlldGYub3JnIj5kcmFmdC1pZXRmLW9zcGYtZW5jYXBz
dWxhdGlvbi1jYXBAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo
dDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtPU1BGXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0
Zi1vc3BmLWVuY2Fwc3VsYXRpb24tY2FwLTA2PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0
eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJ
TjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPkhpIEJydW5vLA0KPGRp
diBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBG
cmksIFNlcCAxNSwgMjAxNyBhdCA3OjU5IEFNLCA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9
Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+YnJ1bm8u
ZGVjcmFlbmVAb3JhbmdlLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90
ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVm
dDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgbGFuZz0iRlIiIGxpbms9
ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0ibV81MTQyODI4MDE2NTA0NzY3Mjg5
V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+
SGkgQWxpYSwgQWNlZSwgV0c8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWws
IHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwv
cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7
cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLXRvcDpzb2xpZCAjYjVjNGRmIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw
Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBw
dDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsiPkZyb206PC9zcGFuPjwvYj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlm
OyI+IEFjZWUgTGluZGVtIChhY2VlKSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzphY2VlQGNpc2Nv
LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFjZWVAY2lzY28uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6
PC9iPiBTYXR1cmRheSwgQXVndXN0IDEyLCAyMDE3IDc6MjUgUE08YnI+DQo8Yj5Ubzo8L2I+IEFs
aWEgQXRsYXM7IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW9zcGYtZW5jYXBzdWxhdGlvbi1j
YXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LWlldGYtb3NwZi1lbmNhcHN1bGF0
aW9uLTx3YnI+Y2FwQGlldGYub3JnPC9hPjsgT1NQRiBMaXN0PGJyPg0KPGI+U3ViamVjdDo8L2I+
IFJlOiBbT1NQRl0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtb3NwZi1lbmNhcHN1bGF0aW9uLTx3
YnI+Y2FwLTA2PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFu
IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAu
NXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+SGkg
QWxpYSwmbmJzcDs8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFt
aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij48dT48L3U+Jm5ic3A7PHU+
PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z
ZXJpZjsgY29sb3I6IGJsYWNrOyI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFj
azsiPk9TUEYgJmx0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh
Y2siPjxhIGhyZWY9Im1haWx0bzpvc3BmLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+b3NwZi1ib3VuY2VzQGlldGYub3JnPC9z
cGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6
IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPiZndDsNCiBvbiBiZWhhbGYgb2Yg
QWxpYSBBdGxhcyAmbHQ7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi
bGFjayI+PGEgaHJlZj0ibWFpbHRvOmFrYXRsYXNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPmFrYXRsYXNAZ21haWwuY29tPC9zcGFuPjwv
YT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli
cmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6
IGJsYWNrOyI+PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNiNWM0ZGYgMS4wcHQ7cGFkZGluZzozLjBwdCAw
Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNr
OyI+RGF0ZToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1m
YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPkZyaWRheSwgQXVndXN0
IDExLCAyMDE3IGF0IDEwOjQyIFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDs8YSBocmVmPSJtYWls
dG86ZHJhZnQtaWV0Zi1vc3BmLWVuY2Fwc3VsYXRpb24tY2FwQGlldGYub3JnIiB0YXJnZXQ9Il9i
bGFuayI+ZHJhZnQtaWV0Zi1vc3BmLTx3YnI+ZW5jYXBzdWxhdGlvbi1jYXBAaWV0Zi5vcmc8L2E+
JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1vc3BmLWVuY2Fwc3VsYXRpb24t
Y2FwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZHJhZnQtaWV0Zi1vc3BmLTx3YnI+ZW5jYXBz
dWxhdGlvbi1jYXBAaWV0Zi5vcmc8L2E+Jmd0OywNCiBPU1BGIFdHIExpc3QgJmx0OzxhIGhyZWY9
Im1haWx0bzpvc3BmQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b3NwZkBpZXRmLm9yZzwvYT4m
Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltPU1BGXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1v
c3BmLWVuY2Fwc3VsYXRpb24tPHdicj5jYXAtMDY8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7
Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjYjVjNGRmIDQuNXB0O3BhZGRpbmc6
MGNtIDBjbSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowY20iIGlk
PSJtXzUxNDI4MjgwMTY1MDQ3NjcyODlNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RF
Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNv
bG9yOiBibGFjazsiPkFzIGlzIGN1c3RvbWFyeSwgSSBoYXZlIGRvbmUgYW5vdGhlciBBRCByZXZp
ZXcgb2YmbmJzcDtkcmFmdC1pZXRmLW9zcGYtPHdicj5lbmNhcHN1bGF0aW9uLWNhcC0wNi4mbmJz
cDsgRmlyc3QsIEknZCBsaWtlIHRvIHRoYW5rIHRoZSBhdXRob3JzIGZvciB0aGVpciB3b3JrIGFu
ZCB0aGUgaW1wcm92ZW1lbnQuDQo8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZh
bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+PHU+PC91PiZuYnNwOzx1
PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z
ZXJpZjsgY29sb3I6IGJsYWNrOyI+SSBoYXZlIG9uZSBtaW5vciBpc3N1ZSBvbiB0aGUgSUFOQSBz
ZWN0aW9uLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6
IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPjx1PjwvdT4mbmJzcDs8dT48L3U+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7
IGNvbG9yOiBibGFjazsiPkZvciB0aGUgY3VycmVudCBGQ0ZTIHNwYWNlLCBJIHRoaW5rIGl0IHdv
dWxkIGJlIGJldHRlciB0byBoYXZlICZxdW90O1NwZWNpZmljYXRpb24gUmVxdWlyZWQmcXVvdDsg
c28gdGhhdCB0aGVyZSdzIGEgcGxhY2UgdG8gbG9vayB0byB1bmRlcnN0YW5kIHdoYXQgc3ViLVRM
VnMgYXJlIGluY2x1ZGVkLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9u
dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPklmIHRoZSBXRyBp
cyBoYXBweSB3aXRoIEZDRlMsIHRoYXQgaXMgZmluZSB0b28uPHU+PC91Pjx1PjwvdT48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBm
b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+PHU+PC91PiZu
YnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2PjxzcGFuIGNsYXNz
PSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0
OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+SSBkb27i
gJl0IGhhdmUgYSBzdHJvbmcgb3BpbmlvbiBoZXJlLiBUaGUgZ29hbCBpcyB0byBiZSBzdGluZ3kg
Zm9yIHRoZSBjb2RlIHBvaW50cyB0aGF0IG92ZXJsYXAgdGhlIGNvcnJlc3BvbmRpbmcgSVMtSVMg
cmVnaXN0cnkgKHdpdGggYSBzaW5nbGUgb2N0ZXQgdHlwZSkgYW5kDQogbW9yZSBsaWJlcmFsIGhl
cmUuIEhvd2V2ZXIsIHdl4oCZdmUgbmV2ZXIgZ29uZSBhbGwgdGhlIHdheSB0byBGQ0ZTIGJlZm9y
ZSBhbmQg4oCcU3BlY2lmaWNhdGlvbiBSZXF1aXJlZOKAnSB3b3VsZCBzZWVtIG1vcmUgaW4gbGlu
ZSB3aXRoIG90aGVyIElHUCByZWdpc3RyaWVzLiZuYnNwOzx1PjwvdT48dT48L3U+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZv
bnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+PHU+PC91PiZuYnNw
Ozx1PjwvdT48L3NwYW4+PC9wPg0KPC9zcGFuPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwg
c2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+W0JydW5vXSBBbGlhLCBJIHNlZSB5b3VyIHBvaW50
IHRoYXQgd2UgbmVlZCBhIHN0YWJsZSBzcGVjaWZpY2F0aW9uIHRvIGludGVyb3AuIE9uIHRoZSBv
dGhlciBoYW5kLCBpbiB0aGUgSURSIFdHLCB0aGVyZSBpcyBhIGRpcmVjdGlvbiB0b3dhcmQgaGF2
aW5nDQogY29kZSBwb2ludHMgZWFzaWVyIHRvIGdldCwgaW4gb3JkZXIgdG8gYWxsb3cgcXVpY2tl
ciBpbXBsZW1lbnRhdGlvbnMgYW5kIGF2b2lkIHNxdWF0dGluZy4gSSB0aG91Z2ggdGhlIHNpdHVh
dGlvbiB3b3VsZCBiZSBzaW1pbGFyIGluIE9TUEYsIGJ1dCBtYXkgYmUgbm90LiDigJxTcGVjaWZp
Y2F0aW9uIFJlcXVpcmVk4oCdIHNlZW0gdG8gbWUgcm91Z2hseSBhcyBoYXJkIHRvIGdldCBhIGNv
ZGUgcG9pbnQgZnJvbSwgdGhhbiDigJxTdGFuZGFyZCBBY3Rpb27igJ0NCiB3aXRoIGVhcmx5IGFs
bG9jYXRpb24uIFBsdXMgdGhlcmUgaXMgYSBuZWVkIHRvIGZpbmQgYSBkZXNpZ25hdGVkIGV4cGVy
dC48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBz
YW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5X
aGF0IGFib3V0IGNoYW5naW5nIHRoZSBzaXplIG9mIHRoZSByYW5nZXM/IGUuZy4NCjx1PjwvdT48
dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7
IGNvbG9yOiBibGFjazsiPi0gdGhlIGZpcnN0IGhhbGYgZm9yIFNURCBhY3Rpb24gKDEg4oCTIDMx
OTk5KTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWws
IHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPi0gc2Vjb25kIGhhbGYgZm9yIEZDRlMgJm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7KDMyMDAwLTY1NDk5KTx1
PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMt
c2VyaWY7IGNvbG9yOiBibGFjazsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAx
MHB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPldpdGgg
MzJrIGVudHJpZXMgaW4gZWFjaCByYW5nZSwgdGhlcmUgc2VlbSB0byBiZSDigJxwbGVudHnigJ0g
Zm9yIGV2ZXJ5b25lLCBldmVuIGlmIHRoZSBJRVRGIGdldHMgY3JlYXRpdmUgd2l0aCBtYW55IHR1
bm5lbCBlbmNhcHN1bGF0aW9ucyBhbmQgbWFueSBwYXJhbWV0ZXJzDQogZm9yIGVhY2guPC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp
dj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlIGJhciBmb3IgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCBp
cyBtdWNoIGxvd2VyIHRoYW4gU3RhbmRhcmQgQWN0aW9uLiZuYnNwOyBJdCBqdXN0IGxvb2tzIGZv
ciBzb21ldGhpbmcgdG8gYmUgd3JpdHRlbiBkb3duLiZuYnNwOyBBIHdlYi1wYWdlLCBhbiBpbnRl
cm5ldC1kcmFmdCwgZXRjLiBhbGwgcXVhbGlmeS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8
ZGl2PkkgcHJlZmVyIHRvIGJlIGFibGUgdG8gaGF2ZSBmb2xrcyBrbm93IGhvdyB0byBpbXBsZW1l
bnQgdXNpbmcgdGhlIGNvZGUtcG9pbnQsIGJ1dCB0aGVyZSBhcmUgdG9ucyBhdmFpbGFibGUgYW5k
IGhhdmluZyBhIEZDRlMgcmFuZ2UgaXMgdXNlZnVsLiAmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0K
PC9kaXY+DQo8ZGl2PkFjZWUgaGFzIHRyYWNrZWQgYmV0dGVyIHdoYXQgdGhlIGNhc2UgaXMgZm9y
IE9TUEYgLSBhbmQgSSdtIGhhcHB5IHRvIGhhdmUgaGltIG1ha2UgdGhlIGNhbGwgaGVyZS48L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGRvbuKAmXQgaGF2ZSBhIHN0cm9u
ZyBvcGluaW9uIHNvIHdlICZuYnNwO2NvdWxkIGdvIHdpdGggdGhlIGxhcmdlciBTVEFOREFSRFMg
QUNUSU9OIHJhbmdlIGFzIHN1Z2dlc3RlZCBieSBBbGlhLiBJbiBlaXRoZXIgcmFuZ2VzLCBpZiB3
ZSBldmVuIGFwcHJvYWNoIGV4cGlyYXRpb24gaW4gZWl0aGVyIHJhbmdlIHRoZSBjYXBhYmlsaXR5
IGlzIG1vc3QgbGlrZWx5IGJlaW5nIG1pc3VzZWQuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwv
ZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PkFjZWUmbmJzcDs8L2Rpdj4NCjxkaXY+PGJy
Pg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGJsb2NrcXVvdGUg
aWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVG
VDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0K
PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJk
cyw8L2Rpdj4NCjxkaXY+QWxpYTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7
PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAw
IDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxk
aXYgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0ibV81
MTQyODI4MDE2NTA0NzY3Mjg5V29yZFNlY3Rpb24xIj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IGJs
YWNrOyI+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5z
LXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5UaGFua3MsPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+UmVn
YXJkcyw8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFs
LCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij4tLUJydW5vPHU+PC91Pjx1PjwvdT48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNr
OyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBB
cmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8c3BhbiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjYjVjNGRmIDQuNXB0O3BhZGRpbmc6MGNtIDBjbSAw
Y20gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowY20iIGlkPSJtXzUxNDI4
MjgwMTY1MDQ3NjcyODlNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu
cy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTogMTAuNXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNr
OyI+SSdtIGFza2luZyBmb3IgYW4gSUVURiBMYXN0IENhbGwgYW5kIHdpbGwgcHV0IHRoaXMgb24g
dGhlIHRlbGVjaGF0IG9uIEF1ZyAzMS48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBD
YWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBj
b2xvcjogYmxhY2s7Ij5UaGFua3Mg4oCTIGhvcGUgdG8gY2xlYXIgc29tZSBtb3JlIG9mIHRoZXNl
IOKAnGFsbW9zdCByZWFkeSZxdW90OyBkb2N1bWVudHMgcHJpb3IgdG8gbmV4dCBJRVRGLiZuYnNw
Ozx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6IENhbGli
cmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPkFjZWUmbmJzcDs8dT48L3U+PHU+PC91Pjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBj
b2xvcjogYmxhY2s7Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjYjVjNGRmIDQu
NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1y
aWdodDowY20iIGlkPSJtXzUxNDI4MjgwMTY1MDQ3NjcyODlNQUNfT1VUTE9PS19BVFRSSUJVVElP
Tl9CTE9DS1FVT1RFIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxp
YnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv
cjogYmxhY2s7Ij5SZWdhcmRzLDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsg
Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPkFsaWE8dT48
L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
YmxvY2txdW90ZT4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPHByZT5fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188d2JyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzx3YnI+X19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPHdicj5fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188d2JyPl8NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBj
b250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg
ZXQgbmUgZG9pdmVudCBkb25jDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGll
cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJy
ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg
YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg
ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJl
c3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNp
ZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh
aW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJv
dGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj
b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl
bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBt
ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y
YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg
Y2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQo8L3ByZT4NCjwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
YmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_D5E1645EC8117aceeciscocom_--


From nobody Mon Sep 18 08:20:19 2017
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 8F03E1342A1; Mon, 18 Sep 2017 08:20:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.619
X-Spam-Level: 
X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1i2KgiVEAOwl; Mon, 18 Sep 2017 08:20:13 -0700 (PDT)
Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1781321A2; Mon, 18 Sep 2017 08:20:13 -0700 (PDT)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 039E81209A6; Mon, 18 Sep 2017 17:20:12 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.72]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id CFA4B80081; Mon, 18 Sep 2017 17:20:11 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0361.001; Mon, 18 Sep 2017 17:20:11 +0200
From: 
To: Suresh Krishnan 
CC: "draft-ietf-ospf-encapsulation-cap@ietf.org" , Acee Lindem , "ospf-chairs@ietf.org" , "acee@cisco.com" , "ospf@ietf.org" , The IESG 
Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-ospf-encapsulation-cap-06: (with DISCUSS and COMMENT)
Thread-Index: AQHTIgPXG5o8mWqhREuxDDpNkgkzhKK0XDJQ
Date: Mon, 18 Sep 2017 15:20:11 +0000
Message-ID: <10459_1505748011_59BFE42B_10459_96_12_53C29892C857584299CBF5D05346208A47879377@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <150414779958.16833.5322499494351720362.idtracker@ietfa.amsl.com>
In-Reply-To: <150414779958.16833.5322499494351720362.idtracker@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OSPF] Suresh Krishnan's Discuss on draft-ietf-ospf-encapsulation-cap-06: (with DISCUSS and COMMENT)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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 Sep 2017 15:20:16 -0000

U3VyZXNoLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcgYW5kIGNvbW1lbnRzLg0KUGxlYXNlIHNl
ZSBpbmxpbmUgW0JydW5vXQ0KDQo+IEZyb206IFN1cmVzaCBLcmlzaG5hbiBbbWFpbHRvOnN1cmVz
aC5rcmlzaG5hbkBnbWFpbC5jb21dDQogPiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDMxLCAyMDE3
IDQ6NTAgQU0NCj4gDQogPiBTdXJlc2ggS3Jpc2huYW4gaGFzIGVudGVyZWQgdGhlIGZvbGxvd2lu
ZyBiYWxsb3QgcG9zaXRpb24gZm9yDQogPiBkcmFmdC1pZXRmLW9zcGYtZW5jYXBzdWxhdGlvbi1j
YXAtMDY6IERpc2N1c3MNCiA+IA0KID4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUg
c3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQogPiBlbWFpbCBhZGRyZXNzZXMg
aW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0K
ID4gaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQogPiANCiA+IA0KID4gUGxlYXNl
IHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3Jp
dGVyaWEuaHRtbA0KID4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFu
ZCBDT01NRU5UIHBvc2l0aW9ucy4NCiA+IA0KID4gDQogPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdp
dGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQogPiBodHRwczov
L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9zcGYtZW5jYXBzdWxhdGlvbi1j
YXAvDQogPiANCiA+IA0KID4gDQogPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogPiBESVNDVVNTOg0KID4gLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KID4gDQogPiAqIFRoZXJlIHNlZW1zIHRvIGJlIGFuIGRpZmZlcmVuY2UgYmV0
d2VlbiB0aGlzIGRvY3VtZW50J3MgZGVmaW5pdGlvbiBvZg0KID4gc3ViLVRMVnMgKHdpdGggMiBv
Y3RldCB0eXBlcyBhbmQgbGVuZ3RocykgYW5kIHRob3NlIG9mIFJGQzU1MTIgKHdpdGggMSBvY3Rl
dA0KID4gdHlwZXMgYW5kIGxlbmd0aHMpLiBTbyBJIGFtIHN1cnByaXNlZCB0byBzZWUgdGhlIGRv
Y3VtZW50IHBvaW50IHRvIHRoZSBSRkM1NTEyDQogPiBiYXNlZCBUTFZzIGZvciBib3RoIHN5bnRh
eCBhbmQgc2VtYW50aWNzIChTZWN0aW9ucyA1LjEsIDUuMiwgNS4zIC4uLikgLiBDYW4geW91DQog
PiBwbGVhc2UgZXhwbGFpbiBob3cgdGhlc2Ugc3ViLVRMVnMgYXJlIGVuY29kZWQgb24gdGhlIHdp
cmUgdG8gYmUgY29tcGF0aWJsZSB3aXRoDQogPiB0aGlzIGRyYWZ0Pw0KIA0KW0JydW5vXSBXb3Vs
ZCB0aGUgZm9sbG93aW5nIGNoYW5nZSB3b3JrcyBmb3IgeW91Pw0KDQpPTEQ6DQogICAgICAgIFRo
aXMgU3ViLVRMViBvZiB0eXBlIDIgaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDMuNC4xICJQcm90b2Nv
bCBUeXBlDQogICAgICAgIHN1Yi1UTFYiIG9mIDx4cmVmIHRhcmdldD0iSS1ELmlldGYtaWRyLXR1
bm5lbC1lbmNhcHMiLz4gZnJvbSBhDQogICAgICAgIHN5bnRhY3RpYywgc2VtYW50aWMsIGFuZCB1
c2FnZSBzdGFuZHBvaW50Lg0KDQpORVc6DQogICAgICAgIFRoaXMgU3ViLVRMViB0eXBlIGlzIDIu
IFRoZSBzeW50YXgsIHNlbWFudGljLCBhbmQgdXNhZ2Ugb2YgaXRzIHZhbHVlIGZpZWxkIGlzIGRl
ZmluZWQgaW4gU2VjdGlvbiAzLjQuMSAiUHJvdG9jb2wgVHlwZQ0KICAgICAgICBzdWItVExWIiBv
ZiA8eHJlZiB0YXJnZXQ9IkktRC5pZXRmLWlkci10dW5uZWwtZW5jYXBzIi8+Lg0KDQoNCiANCiA+
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCiA+IENPTU1FTlQ6DQogPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogPiANCiA+ICog
SUFOQSBjb25zaWRlcmF0aW9ucw0KID4gDQogPiBMb29rcyBsaWtlIHRoZSB2YWx1ZSA2NTUzNSBp
cyBpbmNsdWRlZCBib3RoIGFzIGV4cGVyaW1lbnRhbCBhbmQgcmVzZXJ2ZWQuIFN1Z2dlc3QgY2hh
bmdpbmcNCiA+IA0KID4gT0xEOg0KID4gNjU1MDAtNjU1MzUgICAgRXhwZXJpbWVudGFsICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgVGhpcyBkb2N1bWVudA0KID4gDQogPiBORVc6DQogPiA2
NTUwMC02NTUzNCAgICBFeHBlcmltZW50YWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBU
aGlzIGRvY3VtZW50DQogPiANCg0KW0JydW5vXSBHb29kIGNhdGNoLiBUaGFua3MgZm9yIHRoZSBj
YXJlZnVsIHJldmlldy4gRml4ZWQgYXMgcGVyIHlvdSBzdWdnZXN0aW9uIGluIC0wNyBodHRwczov
L3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9zcGYtZW5jYXBzdWxhdGlv
bi1jYXAtMDcudHh0DQoNCi0tQnJ1bm8NCiANCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBw
aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50
aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVz
ZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiBy
ZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVk
aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l
c3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3Jh
bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl
cmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0
YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRp
b24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry
aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZl
IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh
bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5
IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg
YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg==


From nobody Mon Sep 18 08:20:56 2017
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 2A0601342BB; Mon, 18 Sep 2017 08:20:48 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1cDh_IP_ACC; Mon, 18 Sep 2017 08:20:46 -0700 (PDT)
Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE1681342C0; Mon, 18 Sep 2017 08:20:26 -0700 (PDT)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 38AC8120A1A; Mon, 18 Sep 2017 17:20:25 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 0E35118006E; Mon, 18 Sep 2017 17:20:25 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0361.001; Mon, 18 Sep 2017 17:20:24 +0200
From: 
To: Tim Wicinski 
CC: "ospf@ietf.org" , "draft-ietf-ospf-encapsulation-cap.all@ietf.org" , "ietf@ietf.org" , "ops-dir@ietf.org" 
Thread-Topic: Opsdir last call partial review of draft-ietf-ospf-encapsulation-cap-06
Thread-Index: AQHTIMOqXqTtdsQn8EKd6IbHTdyC2qK0rh5Q
Date: Mon, 18 Sep 2017 15:20:24 +0000
Message-ID: <20416_1505748025_59BFE439_20416_32_1_53C29892C857584299CBF5D05346208A47879394@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <150401028465.13280.5869374542696138659@ietfa.amsl.com>
In-Reply-To: <150401028465.13280.5869374542696138659@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OSPF] Opsdir last call partial review of draft-ietf-ospf-encapsulation-cap-06
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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 Sep 2017 15:20:48 -0000

SGkgVGltLA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3Lg0KQXMgeW91IGFyZSBjb3JyZWN0LCB5
b3VyIHJldmlldyBoYXMgYmVlbiByZXVzZWQgYnkgQmVub2l0IGluIGhpcyBkaXNjdXNzL2NvbW1l
bnRzLg0KSW4gb3JkZXIgdG8gYXZvaWQgZHVwbGljYXRpb24gb2YgZW1haWxzL3RocmVhZHMsIEkn
bGwgcmF0aGVyIChvbmx5KSBhbnN3ZXIgdGhlIHRocmVhZCBmcm9tIEJlbm9pdC4NCg0KVGhhbmtz
LA0KUmVnYXJkcywNCi0tQnJ1bm8NCg0KID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiA+
IEZyb206IFRpbSBXaWNpbnNraSBbbWFpbHRvOnRqdy5pZXRmQGdtYWlsLmNvbV0NCiA+IFNlbnQ6
IFR1ZXNkYXksIEF1Z3VzdCAyOSwgMjAxNyAyOjM4IFBNDQogPiBUbzogb3BzLWRpckBpZXRmLm9y
Zw0KID4gQ2M6IG9zcGZAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtb3NwZi1lbmNhcHN1bGF0aW9uLWNh
cC5hbGxAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmcNCiA+IFN1YmplY3Q6IE9wc2RpciBsYXN0IGNh
bGwgcGFydGlhbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1vc3BmLWVuY2Fwc3VsYXRpb24tY2FwLTA2
DQogPiANCiA+IA0KID4gUmV2aWV3IGlzIHBhcnRpYWxseSBkb25lLiBBbm90aGVyIHJldmlldyBy
ZXF1ZXN0IGhhcyBiZWVuIHJlZ2lzdGVyZWQgZm9yDQogPiBjb21wbGV0aW5nIGl0Lg0KID4gDQog
PiBSZXZpZXdlcjogVGltIFdpY2luc2tpDQogPiBSZXZpZXcgcmVzdWx0OiBIYXMgSXNzdWVzDQog
PiANCiA+IFN1bW1hcnk6IEFsbW9zdCBSZWFkeQ0KID4gDQogPiBUaGUgY29udGVudCBhcHBlYXJz
IHRvIGJlIGZpbmUsIGJ1dCB0aGVyZSBhcmUgc29tZSBvdXRkYXRlZCAodGhlIGJpZ2dlc3Qgb25l
IGlzDQogPiA1MjI2IHJlcGxhY2VkIGJ5IDgxMjYpLCBidXQgaXRzIHRoZSBJQU5BIHNlY3Rpb24g
d2hpY2ggYXBwZWFycyB0aGUgbW9zdA0KID4gY29uZnVzaW5nLg0KID4gDQogPiA3LjEgT1NQRiBS
b3V0ZXIgSW5mb3JtYXRpb24gKFJJKSBSZWdpc3RyeSAtICBhcHBlYXJzIGZpbmUNCiA+IA0KID4g
Ny4yIE9TUEYgVHVubmVsIEVuY2Fwc3VsYXRpb24gQXR0cmlidXRlIFN1Yi1UTFYgUmVnaXN0cnkN
CiA+IA0KID4gVGhpcyBvbmUgZGVmaW5lcyB0aGUgdmFsdWVzIGJlaW5nIGRlZmluZWQvYWxsb2Nh
dGVkIGZyb20gIlRoaXMgRG9jdW1lbnQiIGJ1dCBpbg0KID4gU2VjdGlvbiA1LCBlYWNoIFN1Yi1U
TFYgaXMgZGVmaW5lZCBpbiBvdGhlciBkb2N1bWVudHMsIHNvIGl0J3MgdG90YWxseQ0KID4gY29u
ZnVzaW5nLg0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1
dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl
Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3Ug
Y29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBh
ciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1
aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlx
dWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRl
IHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZh
bHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250
YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHBy
b3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj
b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt
YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1l
c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFu
Z2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNo
YW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo=


From nobody Mon Sep 18 08:26:10 2017
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 18A011342A7; Mon, 18 Sep 2017 08:26:01 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfPkG4djk97a; Mon, 18 Sep 2017 08:25:58 -0700 (PDT)
Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA60134299; Mon, 18 Sep 2017 08:25:58 -0700 (PDT)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 17201C07B2; Mon, 18 Sep 2017 17:25:57 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id BBDC3120077; Mon, 18 Sep 2017 17:25:56 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0361.001; Mon, 18 Sep 2017 17:25:56 +0200
From: 
To: Benoit Claise 
CC: "draft-ietf-ospf-encapsulation-cap@ietf.org" , Acee Lindem , "ospf-chairs@ietf.org" , "acee@cisco.com" , "ospf@ietf.org" , "tjw.ietf@gmail.com" , The IESG 
Thread-Topic: Benoit Claise's Discuss on draft-ietf-ospf-encapsulation-cap-06: (with DISCUSS and COMMENT)
Thread-Index: AQHTIWWdKgUkT+nECE6dYe1ZvnoXHqK0ZnJw
Date: Mon, 18 Sep 2017 15:25:55 +0000
Message-ID: <19482_1505748356_59BFE584_19482_314_1_53C29892C857584299CBF5D05346208A4787940D@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <150407984152.21582.13499330365584334713.idtracker@ietfa.amsl.com>
In-Reply-To: <150407984152.21582.13499330365584334713.idtracker@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OSPF] Benoit Claise's Discuss on draft-ietf-ospf-encapsulation-cap-06: (with DISCUSS and COMMENT)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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 Sep 2017 15:26:01 -0000

SGkgQmVub2l0LA0KDQpUaGFua3MgZm9yIHlvdSByZXZpZXcgYW5kIGNvbW1lbnRzLg0KUGxlYXNl
IHNlZSBpbmxpbmUgW0JydW5vXQ0KDQo+IEZyb206IEJlbm9pdCBDbGFpc2UgW21haWx0bzpiY2xh
aXNlQGNpc2NvLmNvbV0NCiA+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDMwLCAyMDE3IDk6NTcg
QU0NCj4gDQogPiBCZW5vaXQgQ2xhaXNlIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90
IHBvc2l0aW9uIGZvcg0KID4gZHJhZnQtaWV0Zi1vc3BmLWVuY2Fwc3VsYXRpb24tY2FwLTA2OiBE
aXNjdXNzDQogPiANCiA+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3Qg
bGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KID4gZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVk
IGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCiA+IGludHJv
ZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KID4gDQogPiANCiA+IFBsZWFzZSByZWZlciB0
byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0
bWwNCiA+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVO
VCBwb3NpdGlvbnMuDQogPiANCiA+IA0KID4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVy
IGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KID4gaHR0cHM6Ly9kYXRhdHJh
Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vc3BmLWVuY2Fwc3VsYXRpb24tY2FwLw0KID4g
DQogPiANCiA+IA0KID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KID4gRElTQ1VTUzoNCiA+IC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0NCiA+IA0KID4gMS4gSSBhZ3JlZSB3aXRoIFRpbSBXaWNpbnNraSdzIE9QUyBESVIgcG9pbnQg
YWJvdXQgSUFOQS4NCiA+IA0KID4gICAgIFRoZSBjb250ZW50IGFwcGVhcnMgdG8gYmUgZmluZSwg
YnV0IHRoZXJlIGFyZSBzb21lIG91dGRhdGVkICh0aGUgYmlnZ2VzdA0KID4gICAgIG9uZSBpcyA1
MjI2IHJlcGxhY2VkIGJ5IDgxMjYpLA0KDQpbQnJ1bm9dIFRoYW5rcy4gRml4ZWQuDQoNCiA+ICBi
dXQgaXRzIHRoZSBJQU5BIHNlY3Rpb24gd2hpY2ggYXBwZWFycyB0aGUNCiA+ICAgICBtb3N0IGNv
bmZ1c2luZy4NCiA+IA0KID4gICAgIDcuMSBPU1BGIFJvdXRlciBJbmZvcm1hdGlvbiAoUkkpIFJl
Z2lzdHJ5IC0gIGFwcGVhcnMgZmluZQ0KID4gDQogPiAgICAgNy4yIE9TUEYgVHVubmVsIEVuY2Fw
c3VsYXRpb24gQXR0cmlidXRlIFN1Yi1UTFYgUmVnaXN0cnkNCiA+IA0KID4gICAgIFRoaXMgb25l
IGRlZmluZXMgdGhlIHZhbHVlcyBiZWluZyBkZWZpbmVkL2FsbG9jYXRlZCBmcm9tICJUaGlzIERv
Y3VtZW50Ig0KID4gICAgIGJ1dCBpbiBTZWN0aW9uIDUsIGVhY2ggU3ViLVRMViBpcyBkZWZpbmVk
IGluIG90aGVyIGRvY3VtZW50cywgc28gaXQncw0KID4gICAgIHRvdGFsbHkgY29uZnVzaW5nLg0K
IA0KW0JydW5vXSBZb3VyIGNvbW1lbnQgaXMgaW4gbGluZSB3aXRoIG90aGVyIGNvbW1lbnRzLiBX
ZSBhcmUgcHJvcG9zaW5nIHRoZSB0d28gYmVsb3cgY2hhbmdlcy4gV291bGQgdGhpcyBhZGRyZXNz
IHlvdXIgcG9pbnQ/DQoNCjEpIEluIHNlY3Rpb25zIDUueCwgY2xhcmlmaWVzIHRoYXQgdGhlIFR5
cGUgdmFsdWVzIGFyZSBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuIE9ubHkgdGhlIFZhbHVlIGZp
ZWxkIGlzIGRlZmluZWQgaW4gdGhlIEJHUCBkb2N1bWVudC4NCk1vcmUgc3BlY2lmaWNhbGx5LCB0
aGUgcHJvcG9zZSBjaGFuZ2UgaXMNCk9MRDoNCiAgICAgICAgVGhpcyBTdWItVExWIG9mIHR5cGUg
MiBpcyBkZWZpbmVkIGluIFNlY3Rpb24gMy40LjEgIlByb3RvY29sIFR5cGUNCiAgICAgICAgc3Vi
LVRMViIgb2YgPHhyZWYgdGFyZ2V0PSJJLUQuaWV0Zi1pZHItdHVubmVsLWVuY2FwcyIvPiBmcm9t
IGENCiAgICAgICAgc3ludGFjdGljLCBzZW1hbnRpYywgYW5kIHVzYWdlIHN0YW5kcG9pbnQuDQoN
Ck5FVzoNCiAgICAgICAgVGhpcyBTdWItVExWIHR5cGUgaXMgMi4gVGhlIHN5bnRheCwgc2VtYW50
aWMsIGFuZCB1c2FnZSBvZiBpdHMgdmFsdWUgZmllbGQgaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDMu
NC4xICJQcm90b2NvbCBUeXBlDQogICAgICAgIHN1Yi1UTFYiIG9mIDx4cmVmIHRhcmdldD0iSS1E
LmlldGYtaWRyLXR1bm5lbC1lbmNhcHMiLz4uDQoNCg0KMikgQXMgcGVyIG90aGVyIGNvbW1lbnRz
LCBkcmFmdC0wNyBoYXMgY2hhbmdlZCB0byBJQU5BIHNlY3Rpb24NCk9MRDoNCjIgICAgICAgIFBy
b3RvY29sIFR5cGUgICAgICAgIFRoaXMgZG9jdW1lbnQgIAkNCg0KTkVXOg0KIDIgICAgUHJvdG9j
b2wgVHlwZSAgICAgICAgICBUaGlzIGRvY3VtZW50ICYgW0ktRC5pZXRmLWlkci10dW5uZWwtZW5j
YXBzXQkNCg0KDQpOb3RlIHRoYXQgSSdtIHBlcnNvbmFsbHkgbm90IHNvIGZvdW5kIG9mIHRoZSBh
Ym92ZSBjaGFuZ2UgYXMgZHJhZnQtaWV0Zi1vc3BmLWVuY2Fwc3VsYXRpb24tY2FwIGRvZXMgY3Jl
YXRlIHRoaXMgbmV3IHJlZ2lzdHJ5IGFuZCBhbGxvY2F0ZSB0aG9zZSBpbml0aWFsIHZhbHVlcy4g
QnV0IEkgY2FuIGxpdmUgd2l0aCB0aG9zZSBjaGFuZ2VzIGlmIHBlb3BsZSBzZWUgdmFsdWUuDQoN
Cg0KDQogPiAyLiBJdCdzIG5vdCBjbGVhciB3aGljaCBvZiB0aGUgZm9sbG93aW5nIHN1Yi1UTFZz
IGFyZQ0KID4gcmVxdWlyZWQvcmVsZXZhbnQvaW50ZXJjb25uZWN0ZWQgaW4gdGhlIEVuY2Fwc3Vs
YXRpb24gQ2FwYWJpbGl0eSBUTFYNCiA+IA0KID4gICAgICAgICAgICAgMCAgICBSZXNlcnZlZCAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGlzIGRvY3VtZW50DQogPiAgICAgICAg
ICAgICAxICAgIEVuY2Fwc3VsYXRpb24gICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoaXMg
ZG9jdW1lbnQNCiA+ICAgICAgICAgICAgIDIgICAgUHJvdG9jb2wgVHlwZSAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgVGhpcyBkb2N1bWVudA0KID4gICAgICAgICAgICAgMyAgICBFbmRwb2lu
dCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGlzIGRvY3VtZW50DQogPiAgICAg
ICAgICAgICA0ICAgIENvbG9yICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRo
aXMgZG9jdW1lbnQNCiA+ICAgICAgICAgICAgIDUgICAgTG9hZC1CYWxhbmNpbmcgQmxvY2sgICAg
ICAgICAgICAgICAgICAgICAgVGhpcyBkb2N1bWVudA0KID4gICAgICAgICAgICAgNiAgICBJUCBR
b1MgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGlzIGRvY3VtZW50DQogPiAg
ICAgICAgICAgICA3ICAgIFVEUCBEZXN0aW5hdGlvbiBQb3J0ICAgICAgICAgICAgICAgICAgICAg
IFRoaXMgZG9jdW1lbnQNCiA+IA0KID4gVGhlIG9ubHkgaGludCBpczoNCiA+IA0KID4gICAgICAg
VmFsdWUgKHZhcmlhYmxlKTogWmVybyBvciBtb3JlIFR1bm5lbCBFbmNhcHN1bGF0aW9uIEF0dHJp
YnV0ZSBTdWItDQogPiAgICAgICBUTFZzIGFzIGRlZmluZWQgaW4gU2VjdGlvbiA1Lg0KID4gDQog
PiBaZXJvPyByZWFsbHksIHdoYXQncyB0aGUgcG9pbnQ/DQoNCltCcnVub10gVGhlcmUgaXMgbm8g
cG9pbnQgaW4gc2VuZGluZyB6ZXJvIFN1Yi1UTFZzLCBhcyBwZXIgZHJhZnQtaWV0Zi1vc3BmLWVu
Y2Fwc3VsYXRpb24tY2FwLiBCdXQgSSdtIG5vdCBzdXJlIHRvIHNlZSBhIHJlYXNvbiB0bzoNCi0g
Zm9yYmlkIHRoaXMgdXNhZ2UgaW4gYSBmdXR1cmUgc3BlY2lmaWNhdGlvbg0KLSBjcmVhdGUgYW4g
ZXJyb3IgY2FzZSB3aXRoIHNwZWNpZmljIGVycm9yIGhhbmRsaW5nIGFzc29jaWF0ZWQuDQoNCkFs
c28gdGhpcyB0ZXh0IGlzIHRha2VuIGZyb20gUkZDIDU1MTIgc2VjdGlvbiA0LCB3aGljaCBvcmln
aW5hbGx5IGRlZmluZWQgdGhlIEJHUCBUdW5uZWwgRW5jYXBzdWxhdGlvbiBBdHRyaWJ1dGUgaHR0
cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU1MTIjc2VjdGlvbi00DQoNCg0KID4gTm93LCBm
cm9tIGFuIG9wZXJhdGlvbmFsIHBvaW50IG9mIHZpZXcsIHdoaWNoIHN1Yi1UTFZzIGFyZSByZXF1
aXJlZC9tYWtlIHNlbnNlPw0KID4gQXJlIHNvbWUgc3ViLVRMVnMgaXJyZWxldmFudCB3aXRob3V0
IG90aGVycz8gRXg6IENvbG9yIHdpdGhvdXQgRW5jYXBzdWxhdGlvbg0KDQpbQnJ1bm9dDQpSRkM1
NTEyIGRpZCBub3QgY292ZXIgdGhpcyBwb2ludCwgbm9yIGRvZXMgZHJhZnQtaWV0Zi1pZHItdHVu
bmVsLWVuY2Fwcy4NCkluIHRoZW9yeSwgYXMgb2YgdG9kYXksIFN1Yi1UTFYgdHlwZSAzIChFbmRw
b2ludCkgc2VlbXMgcmVxdWlyZWQgdG8gbWluaW1hbGx5IGRlZmluZSB0aGUgSVAgYWRkcmVzcyBv
ZiB0aGUgdHVubmVsIGRlY2Fwc3VsYXRvci4gSG93ZXZlciwgSSdtIHJlbHVjdGFudCB0byBkZWZp
bmUgc3ViLVRMViBhcyBSRVFVSVJFRCwgYXMgZnV0dXJlIFN1Yi1UTFYvdXNhZ2UgY291bGQgcG9z
c2libHkgb2Jzb2xldGUgdGhlIGluaXRpYWxseSByZXF1aXJlZCBTdWItVExWLiBTbyB3ZSB3b3Vs
ZCBjcmVhdGUgZXJyb3IgY29uZGl0aW9uIHdoaWNoIHdvdWxkIHBvc3NpYmx5IGxpbWl0IGJhY2t3
YXJkIGNvbXBhdGlibGUgaW1wcm92ZW1lbnQuIEFsc28gdGhlIEVuY2Fwc3VsYXRpb24gU3ViLVRM
ViAodHlwZSAxKSBpcyByZXF1aXJlZCBmb3Igc29tZSB0eXBlIG9mIHR1bm5lbHMuDQoNCkJlaW5n
IGEgbmV0d29yayBvcGVyYXRvciwgSSdtIGFsbCBpbiBmYXZvciBvZiBpbnRlcm9wZXJhYmlsaXR5
IGFuZCBvcGVyYXRpb25hbCBhc3BlY3RzLiBIb3dldmVyLCBJIGRvbid0IHNlZSB0aGlzIGFwcGxp
Y2FibGUgdG8gYSBnZW5lcmljIHByb3RvY29sIGV4dGVuc2lvbi4gSSdkIHJhdGhlciBzZWUgdGhp
cyBpbiBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudHMuDQoNCiA+IENvdWxkIHdlIGhhdmUgbXVsdGlw
bGUgaWRlbnRpY2FsIHN1Yi1UTFZzPyBFeDogQ29sb3INCiANCltCcnVub10gRXhjZWxsZW50IHF1
ZXN0aW9uLi4uDQpSRkM1NTEyIGRpZCBub3QgY292ZXIgdGhpcyBwb2ludCwgbm9yIGRyYWZ0LWll
dGYtaWRyLXR1bm5lbC1lbmNhcHMuLi4gTm9uZSBvZiB0aGUgU3ViLVRMViBkZWZpbmVkIGluIHRo
aXMgZG9jdW1lbnQgbmVlZCBtb3JlIHRoYW4gb25lIGluc3RhbmNlLiBMaW1pdGF0aW9uIHRvIGEg
c2luZ2xlIGluc3RhbmNlIGNvdWxkIGJlIHNwZWNpZmllZCBkdXJpbmcgdGhlIGRlZmluaXRpb24g
b2YgdGhlICJUdW5uZWwgRW5jYXBzdWxhdGlvbiBDYXBhYmlsaXRpZXMiIGluIHNlY3Rpb24gNCwg
d2hpY2ggd291bGQgaW1wb3NlIHN1Y2ggcmVzdHJpY3Rpb24gZm9yIGZ1dHVyZSBTdWItVExWLiBP
ciBmb3IgZWFjaCBTdWItVExWIGluIHNlY3Rpb25zIDUuIFRoZSBmb3JtZXIgc2VlbXMgYW4gZWFz
aWVyIHBhdGgsIHdoaWxlIHRoZSBsYXR0ZXIgbW9yZSBleHRlbnNpYmxlLiBHaXZlbiB0aGUgZXhh
bXBsZSBvZiBSRkMgNzc3MCAvIDQ5NzAsIEkgdGhpbmsgSSB3b3VsZCBwcm9wb3NlIHRoZSBsYXR0
ZXI6IGkuZS4gYWxsb3dpbmcgdGhlIGFkdmVydGlzZW1lbnQgb2YgbXVsdGlwbGUgaW5zdGFuY2Ug
b2YgYSBTdWItVExWLCBidXQgZGlzYWxsb3dpbmcgaXQgZm9yIGFsbCBTdWItVExWIGRlZmluZWQg
aW4gdGhpcyBkcmFmdC4NCkhvd2V2ZXIsIEknZCB3ZWxjb21lIGFueSBvdGhlciBvcGluaW9uLiBJ
J20gZGVmaW5pdGVseSBvcGVuIHRvIGZvbGxvdyB0aGUgZWFzaWVyIHBhdGguDQogDQogPiANCiA+
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCiA+IENPTU1FTlQ6DQogPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogPiANCiA+IC0g
U29tZXRpbWVzIHlvdSB1c2UgIkVuY2Fwc3VsYXRpb24gQ2FwYWJpbGl0eSBUTFYiIChzZWN0aW9u
IDMpLCBzb21ldGltZXMgIlRoZQ0KID4gVHVubmVsIEVuY2Fwc3VsYXRpb24gVHlwZSBTdWItVExW
IiBJIGd1ZXNzIHRoYXQ6IE9MRDoNCiA+IA0KID4gIFRoZSBUdW5uZWwgRW5jYXBzdWxhdGlvbiBU
eXBlIFN1Yi1UTFYgaXMgc3RydWN0dXJlZCBhcyBmb2xsb3dzOg0KID4gDQogPiAgICAgICAgMCAg
ICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAg
Mw0KID4gICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg
MiAzIDQgNSA2IDcgOCA5IDAgMQ0KID4gICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiA+ICAgICAgIHwgICAgVHVu
bmVsIFR5cGUgKDIgT2N0ZXRzKSAgICAgfCAgICAgICAgTGVuZ3RoICgyIE9jdGV0cykgICAgICB8
DQogPiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKw0KID4gICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiA+ICAgICAgIHwgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgU3ViLVRMVnMgICAgICAgICAgICAgICAgICAgICAgICAgICB8
DQogPiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgfA0KID4gICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiA+IA0KID4gTkVXOg0KID4g
IFRoZSBFbmNhcHN1bGF0aW9uIENhcGFiaWxpdHkgVExWIGlzIHN0cnVjdHVyZWQgYXMgZm9sbG93
czoNCiA+IA0KID4gICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAg
ICAyICAgICAgICAgICAgICAgICAgIDMNCiA+ICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg
MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiA+ICAgICAgICstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rDQogPiAgICAgICB8ICAgIFR1bm5lbCBUeXBlICgyIE9jdGV0cykgICAgIHwgICAgICAgIExl
bmd0aCAoMiBPY3RldHMpICAgICAgfA0KID4gICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiA+ICAgICAgIHwgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB8DQogPiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN1Yi1UTFZzICAgICAg
ICAgICAgICAgICAgICAgICAgICAgfA0KID4gICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiA+ICAgICAgICstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rDQogDQpbQnJ1bm9dIFlvdSBhcmUgcmlnaHQgdGhhdCBuYW1lcyBhcmUgbm90IGNvbnNpc3Rl
bnRseSB1c2VkLiBXZSBoYWQgdHJ5IHRvIGhhdmUgbmFtZXMgYmUgYWxpZ25lZCBib3RoIHdpdGgg
dGhlIEJHUCBlbmNhcHN1bGF0aW9uIGRyYWZ0IGFuZCBPU1BGIFJJL1RMViBuYW1lcywgYnV0IGZp
bmFsbHksIHRoYXQgc2VlbSBkaWZmaWN1bHQuIEdpdmVuIHRoYXQgdGhlIElEUiBkb2N1bWVudCBp
cyBzdGlsbCBhIGRyYWZ0IGFuZCBpdHMgbmFtZXMgY291bGQgY2hhbmdlLCBJIHRoaW5rIHdlIHdp
bGwgZmF2b3IgbW9yZSBpbmRlcGVuZGVudCBuYW1lcy4NClRleHQgY2hhbmdlZCB0bw0KTkVXOg0K
DQogICAgICBUaGUgVHVubmVsIFN1Yi1UTFYgaXMgc3RydWN0dXJlZCBhcyBmb2xsb3dzOg0KDQog
ICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAg
ICAgICAgMw0KICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg
MiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgVHVubmVsIFR5cGUgKDIg
T2N0ZXRzKSAgICAgfCAgICAgICAgTGVuZ3RoICgyIE9jdGV0cykgICAgICB8DQogICArLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Kw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHwNCiAgIHwgICAgICAgICAgICAgICBUdW5uZWwgUGFyYW1ldGVyIFN1Yi1U
TFZzICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQoN
Cg0KID4gSW4gc2VjdGlvbiA3LjEsIHNob3VsZCBpdCBiZT8NCiA+IE9MRDoNCiA+ICAgICBWYWx1
ZSAgIFRMViBOYW1lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJlZmVyZW5jZQ0K
ID4gICAgICAgIC0tLS0tICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICAg
LS0tLS0tLS0tLS0tLQ0KID4gICAgICAgIFRCRDEgICAgVHVubmVsIENhcGFiaWxpdGllcyAgICAg
ICAgICAgICAgICAgICAgVGhpcyBkb2N1bWVudA0KID4gDQogPiBORVc6DQogPiAgICAgVmFsdWUg
ICBUTFYgTmFtZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZWZlcmVuY2UNCiA+
ICAgICAgICAtLS0tLSAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgIC0t
LS0tLS0tLS0tLS0NCiA+ICAgICAgICBUQkQxICAgIEVuY2Fwc3VsYXRpb24gQ2FwYWJpbGl0aWVz
ICAgICAgICAgICAgIFRoaXMgZG9jdW1lbnQNCiA+IA0KID4gT1I6DQogPiAgICAgVmFsdWUgICBU
TFYgTmFtZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZWZlcmVuY2UNCiA+ICAg
ICAgICAtLS0tLSAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgIC0tLS0t
LS0tLS0tLS0NCiA+ICAgICAgICBUQkQxICAgIFR1bm5lbCBFbmNhcHN1bGF0aW9uIENhcGFiaWxp
dGllcyAgICAgIFRoaXMgZG9jdW1lbnQNCg0KDQpbQnJ1bm9dIENoYW5nZWQgdG8gDQpORVc6DQpU
QkQxICAgIFR1bm5lbCBFbmNhcHN1bGF0aW9ucyAgICAgIFRoaXMgZG9jdW1lbnQNCg0KDQo+IA0K
ID4gLSBUaGVuIHRoZXJlIGlzIGEgZGlzY3JlcGFuY3kgYmV0d2VlbiBTdWItVExWcyBhbmQgVmFs
dWUgaW4gdGhlIHJlbGF0ZWQgdGV4dA0KIA0KW0JydW5vXSBBZ3JlZWQuDQogDQogPiAgICAgICAg
MCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAg
ICAgMw0KID4gICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw
IDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KID4gICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiA+ICAgICAgIHwgICAg
VHVubmVsIFR5cGUgKDIgT2N0ZXRzKSAgICAgfCAgICAgICAgTGVuZ3RoICgyIE9jdGV0cykgICAg
ICB8DQogPiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKw0KID4gICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiA+ICAgICAgIHwgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgU3ViLVRMVnMgICAgICAgICAgICAgICAgICAgICAgICAg
ICB8DQogPiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgfA0KID4gICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiA+IA0KID4gUHJvcG9z
YWw6IFN1Yi1UTFZzIHNob3VsZCBiZSByZXBsYWNlZCBieSAiVHVubmVsIEVuY2Fwc3VsYXRpb24g
QXR0cmlidXRlDQogPiBTdWItVExWcyIsIGFuZCB0aGUgZm9sbG93aW5nIHRleHQgdXBkYXRlZDoN
CiA+IA0KID4gICBWYWx1ZSAodmFyaWFibGUpOiBaZXJvIG9yIG1vcmUgVHVubmVsIEVuY2Fwc3Vs
YXRpb24gQXR0cmlidXRlIFN1Yi0NCiA+ICAgICAgIFRMVnMgYXMgZGVmaW5lZCBpbiBTZWN0aW9u
IDUuDQogDQpbQnJ1bm9dIEFzIHRoZSBuYW1lcyBjaGFuZ2UsIGNoYW5nZWQgdG8NCg0KICAgIDAg
ICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAg
IDMNCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0
IDUgNiA3IDggOSAwIDENCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgIFR1bm5lbCBUeXBlICgyIE9jdGV0
cykgICAgIHwgICAgICAgIExlbmd0aCAoMiBPY3RldHMpICAgICAgfA0KICAgKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAg
IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB8DQogICB8ICAgICAgICAgICAgICAgVHVubmVsIFBhcmFtZXRlciBTdWItVExWcyAg
ICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgDQoNClsuLi5d
DQoNClZhbHVlICh2YXJpYWJsZSk6IFplcm8gb3IgbW9yZSBUdW5uZWwgUGFyYW1ldGVyDQogICAg
ICAgICAgU3ViLVRMVnMgYXMgZGVmaW5lZCBpbiA8eHJlZiB0YXJnZXQ9IlBhcmFtZXRlclRMVnMi
Lz4uDQoNCg0KID4gLSBUaGVuLCByZWFkaW5nIHNlY3Rpb24gNSwgSSBzZWUgeWV0IGFub3RoZXIg
bmFtZTogIk9TUEYgVHVubmVsIEVuY2Fwc3VsYXRpb24NCiA+IEF0dHJpYnV0ZSBTdWItVExWcyIg
U2VjdGlvbiA3LjIuDQogDQpbQnJ1bm9dIFRoYXQgb25lIHdhcyB0aGUgbmFtZSBvZiB0aGUgX0lB
TkEgcmVnaXN0cnlfICwgbm90IHRoZSBuYW1lIG9mIHRoZSBTdWItVExWcy4gSSBiZWxpZXZlIGFk
ZGluZyAiT1NQRiIgaXMgdXNlZnVsIGFzIElEUiBhbmQgSVMtSVMgd291bGQgaGF2ZSBhIGRpZmZl
cmVudCByZWdpc3RyeS4gSG93ZXZlciwgSSdtIG9wZW4gdG8gZGlmZmVyZW50IGluc3RydWN0aW9u
cy4NCiANCiA+IFlvdSBzaG91bGQgcmUtcmVhZCB0aGUgZG9jdW1lbnQgdG8gYmUgY29uc2lzdGVu
dCB3aXRoIHlvdXIgbmFtaW5nIGNvbnZlbnRpb24sDQogPiBpbiB0aGUgdGV4dCBhbmQgaW4gdGhl
IElBTkEgc2VjdGlvbnMuDQogIA0KW0JydW5vXSBZZXMuIFNvcnJ5IGZvciB0aGlzLiBOYW1lcyBo
YWQgY2hhbmdlZC4gSSd2ZSByZS1yZWFkIHRoZSBkb2N1bWVudC4NCg0KTWFueSB0aGFua3MgZm9y
IHRoZSByZXZpZXcuDQpSZWdhcmRzLA0KLS1CcnVubw0KDQoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBl
dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNv
bmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJl
IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz
IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEg
bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMu
IExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRp
b24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl
dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQg
aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGlu
Zm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBi
ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5
b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz
ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1h
aWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhh
dCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo=


From nobody Mon Sep 18 08:27:04 2017
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 676841321A2; Mon, 18 Sep 2017 08:27:03 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjY3blrXiLG6; Mon, 18 Sep 2017 08:27:01 -0700 (PDT)
Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D213F1342A8; Mon, 18 Sep 2017 08:26:56 -0700 (PDT)
Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 9F91D12086B; Mon, 18 Sep 2017 17:26:55 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 7A8D860069; Mon, 18 Sep 2017 17:26:55 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0361.001; Mon, 18 Sep 2017 17:26:55 +0200
From: 
To: Alvaro Retana 
CC: "draft-ietf-ospf-encapsulation-cap@ietf.org" , Acee Lindem , "ospf-chairs@ietf.org" , "ospf@ietf.org" , The IESG 
Thread-Topic: Alvaro Retana's No Objection on draft-ietf-ospf-encapsulation-cap-06: (with COMMENT)
Thread-Index: AQHTIb+YySJJiSk06EuwsX5QSggLVaK0tdqg
Date: Mon, 18 Sep 2017 15:26:54 +0000
Message-ID: <30747_1505748415_59BFE5BF_30747_374_1_53C29892C857584299CBF5D05346208A47879458@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <150411848726.21615.10966448818481552380.idtracker@ietfa.amsl.com>
In-Reply-To: <150411848726.21615.10966448818481552380.idtracker@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OSPF] Alvaro Retana's No Objection on draft-ietf-ospf-encapsulation-cap-06: (with COMMENT)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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 Sep 2017 15:27:03 -0000

SGkgQWx2YXJvLA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3IGFuZCBmZWVkYmFjay4NClBsZWFz
ZSBzZWUgaW5saW5lIFtCcnVub10NCg0KPiBGcm9tOiBBbHZhcm8gUmV0YW5hIFttYWlsdG86YXJl
dGFuYUBjaXNjby5jb21dDQogPiBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAzMCwgMjAxNyA4OjQx
IFBNDQo+IA0KID4gQWx2YXJvIFJldGFuYSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxv
dCBwb3NpdGlvbiBmb3INCiA+IGRyYWZ0LWlldGYtb3NwZi1lbmNhcHN1bGF0aW9uLWNhcC0wNjog
Tm8gT2JqZWN0aW9uDQogPiANCiA+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1
YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KID4gZW1haWwgYWRkcmVzc2VzIGlu
Y2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCiA+
IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KID4gDQogPiANCiA+IFBsZWFzZSBy
ZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRl
cmlhLmh0bWwNCiA+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQg
Q09NTUVOVCBwb3NpdGlvbnMuDQogPiANCiA+IA0KID4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRo
IG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KID4gaHR0cHM6Ly9k
YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vc3BmLWVuY2Fwc3VsYXRpb24tY2Fw
Lw0KID4gDQogPiANCiA+IA0KID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KID4gQ09NTUVOVDoNCiA+IC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0NCiA+IA0KID4gSSB0aGluayB0aGVyZSdzIGEgbm9ybWF0aXZlIGNvbmZsaWN0IGlu
IHRoZXNlIHR3byBwaWVjZXMgb2YgdGV4dDsgdGhlIGZpcnN0IG9uZQ0KID4gZnJvbSBTZWN0aW9u
IDMsIGFuZCB0aGUgc2Vjb25kIGZyb20gU2VjdGlvbiA1Og0KID4gDQogPiAgICAuLi5JZiB0aGUg
RW5jYXBzdWxhdGlvbiBDYXBhYmlsaXR5DQogPiAgICBUTFYgYXBwZWFycyBtb3JlIHRoYW4gb25j
ZSBpbiBhbiBPU1BGIFJvdXRlciBJbmZvcm1hdGlvbiBMU0EsIG9ubHkNCiA+ICAgIHRoZSBmaXJz
dCBvY2N1cnJlbmNlIE1VU1QgYmUgcHJvY2Vzc2VkIGFuZCBvdGhlcnMgTVVTVCBiZSBpZ25vcmVk
Lg0KIA0KW0JydW5vXSBBY3R1YWxseSwgSSdtIG5vdCBzdXJlIHdoeSB0aGVyZSBpcyBzdWNoIHJl
c3RyaWN0aW9uLiBPdGhlcnMgT1NQRiBSSSBhbGxvd3MgbXVsdGlwbGUgb2NjdXJlbmNlcy4gZS5n
LiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzc3Nw0KUHJvcG9zZWQgTkVXOg0KICAg
ICAgVGhlIFR1bm5lbHMgRW5jYXBzdWxhdGlvbnMgVExWIE1BWSBhcHBlYXIgbW9yZSB0aGFuIG9u
Y2UNCiAgICAgIHdpdGhpbiBhIGdpdmVuIE9TUEYgUm91dGVyIEluZm9ybWF0aW9uIChSSSkgT3Bh
cXVlIExTQS4gSWYgdGhlIFR1bm5lbHMNCiAgICAgIEVuY2Fwc3VsYXRpb25zIFRMViBhcHBlYXJz
IG1vcmUgdGhhbiBvbmNlIGluIGFuIE9TUEYgUm91dGVyDQogICAgICBJbmZvcm1hdGlvbiBMU0Es
IHRoZSBzZXQgb2YgYWxsIFR1bm5lbCBTdWItVExWcyBmcm9tIGFsbCBUdW5uZWxzIEVuY2Fwc3Vs
YXRpb25zIFRMViBTSE9VTEQgYmUgY29uc2lkZXJlZC4NCiANCk5vdGU6IE1VU1QgaXMgbm90IHJl
cXVpcmVkIGZvciBpbnRlcm9wZXJhYmlsaXR5IGFzIHdlIGFkdmVydGlzZSBpbmZvcm1hdGlvbiB0
aGF0IE1BWSBvciBNQVkgTk9UIGJlIHVzZWQNCg0KID4gLi4uDQogPiANCiA+ICAgIEFueSB1bmtu
b3duIFN1Yi1UTFZzIE1VU1QgYmUgaWdub3JlZCBhbmQgc2tpcHBlZCB1cG9uIHJlY2VpcHQuDQog
PiANCiA+ICAgIElmIGEgU3ViLVRMViBpcyBpbnZhbGlkLCBpdHMgVHVubmVsIEVuY2Fwc3VsYXRp
b24gVExWIE1VU1QgYmUgaWdub3JlZA0KID4gICAgYW5kIHNraXBwZWQuICBIb3dldmVyLCBvdGhl
ciBUdW5uZWwgRW5jYXBzdWxhdGlvbiBUTFZzIE1VU1QgYmUNCiA+ICAgIGNvbnNpZGVyZWQuDQog
PiANCiA+IFRoZSB0ZXh0IGZyb20gU2VjdGlvbiAzIHNheXMgdGhhdCBvbmx5IHRoZSBmaXJzdCBU
TFYgWypdIGlzIHRvIGJlIHByb2Nlc3NlZCAtLQ0KID4gYnV0IGR1cmluZyBzdWNoIHByb2Nlc3Np
bmcgdGhlIHJlY2VpdmVyIG1heSBmaW5kIGFuIGludmFsaWQgc3ViLVRMViwgd2hpY2ggdGhlbg0K
ID4gbWFuZGF0ZXMgKGluIFNlY3Rpb24gNSkgZm9yIG90aGVyIFRMVnMgdG8gYmUgY29uc2lkZXJl
ZC4NCiANCltCcnVub10gSSB0aGluayB0aGF0IHRoZSBiZWhhdmlvciBpcyBmaW5lLCBob3dldmVy
LCBhcyBwcmV2aW91c2x5IG5vdGVkLCB0aGUgdGVybWlub2xvZ3kgaXMgdW5jbGVhci4NCkknbSBj
aGFuZ2luZyB0aGUgdGVybWlub2xvZ3kgaW4gLTA4LiBDb3VsZCB5b3UgaGF2ZSBhIGxvb2sgYXQg
LTA4IGFuZCBzZWUgaWYgdGhpcyBwb2ludCBpcyBzdGlsbCB1bmNsZWFyPyBUaGFua3MuDQogDQog
PiBJIHRoaW5rIHRoYXQgdGhlIGVhc3kgc29sdXRpb24gaXMgdG8gY2hhbmdlIHRoZSBzZWNvbmQg
Ik1VU1QiIGZyb20gU2VjdGlvbiAzDQogPiBmb3IgYSAiU0hPVUxEIi4NCiA+IA0KID4gSXQgd291
bGQgYmUgbmljZSB0byBkZXNjcmliZSB3aGF0IGlzIGFuICJpbnZhbGlkIiBzdWItVExWLCBhbmQg
dGhhdCAiaW52YWxpZCINCiA+IGlzIG5vdCB0aGUgc2FtZSBhcyAidW5rbm93biIgKHJpZ2h0Pyku
Li5idXQgdGhhdCBhbiAidW5rbm93biBbdHVubmVsXSB0eXBlcyBhcmUNCiA+IHRvIGJlIGlnbm9y
ZWQgYW5kIHNraXBwZWQgdXBvbiByZWNlaXB0Iiwgd2hpY2ggd291bGQgcmVzdWx0IGluIHByb2Nl
c3NpbmcgdGhlDQogPiBzZWNvbmQgKGlmIGFueSkgVExWLg0KDQpbQnJ1bm9dIFByb3Bvc2VkIE5F
VzoNCkFueSB1bmtub3duIFR1bm5lbCBQYXJhbWV0ZXIgU3ViLVR5cGUgTVVTVCBiZSBpZ25vcmVk
LiBXaGVuIGEgcmVzZXJ2ZWQNCiAgICAgIHZhbHVlIChTZWUgPHhyZWYgdGFyZ2V0PSJQYXJhbWV0
ZXJzUmVnaXN0cnkiLz4pIGlzIHNlZW4gaW4gYW4gTFNBLCBpdA0KICAgICAgTVVTVCBiZSB0cmVh
dGVkIGFzIGFuIGludmFsaWQgVHVubmVsIFBhcmFtZXRlciBTdWItVExWLiBXaGVuIGEgVHVubmVs
IFBhcmFtZXRlciBWYWx1ZSBoYXMgYW4gaW5jb3JyZWN0IHN5bnRheCBvZiBzZW1hbnRpYywgaXQg
TVVTVCBiZSB0cmVhdGVkIGFzIGFuIGludmFsaWQgVHVubmVsIFBhcmFtZXRlciBTdWItVExWLiBJ
ZiBhIFR1bm5lbCBQYXJhbWV0ZXIgU3ViLVRMViBpcyBpbnZhbGlkLCBpdHMNCiAgICAgIFR1bm5l
bCBTdWItVExWIE1VU1QgYmUgaWdub3JlZCBhbmQgc2tpcHBlZC4gSG93ZXZlciwNCiAgICAgIG90
aGVyIFR1bm5lbCBTdWItVExWcyBNVVNUIGJlIGNvbnNpZGVyZWQuDQoNCiANCiA+IFsqXSBCZW5v
aXQncyBiYWxsb3QgcG9pbnRlZCBhdCB0aGUgbmVlZCBmb3IgY29uc2lzdGVuY3kgaW4gdGhlIG5h
bWVzLg0KDQpbQnJ1bm9dIEFncmVlZC4gUmVwbHlpbmcgb24gQmVub2l0J3MgdGhyZWFkLg0KIA0K
VGhhbmtzLA0KLS1CcnVubw0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2lu
dGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3Ug
cHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p
dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz
c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBs
ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxl
Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGlu
ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3Jt
ZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBt
YXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1h
eSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVz
ZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQg
dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg
dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJl
ZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlm
aWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK


From nobody Mon Sep 18 08:30:58 2017
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 520871342A6; Mon, 18 Sep 2017 08:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level: 
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBbUEehv0zD1; Mon, 18 Sep 2017 08:30:42 -0700 (PDT)
Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFF651342B7; Mon, 18 Sep 2017 08:30:41 -0700 (PDT)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 94D5F40900; Mon, 18 Sep 2017 17:30:40 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 7224D120055; Mon, 18 Sep 2017 17:30:40 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0361.001; Mon, 18 Sep 2017 17:30:40 +0200
From: 
To: Joe Touch 
CC: TSV Dir , IETF discussion list , "ospf@ietf.org" 
Thread-Topic: [OSPF] tsv-dir review of draft-ietf-ospf-encapsulation-cap-06
Thread-Index: AQHTHJMII1NCa9Cj0k2BeoROLCLB16K0ax/g
Date: Mon, 18 Sep 2017 15:30:39 +0000
Message-ID: <20376_1505748640_59BFE6A0_20376_244_13_53C29892C857584299CBF5D05346208A4787949B@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <150280426212.21081.15543071828535131713.idtracker@ietfa.amsl.com> <7ca66dbe-1437-482d-a785-d5e48a558ccb@strayalpha.com>
In-Reply-To: <7ca66dbe-1437-482d-a785-d5e48a558ccb@strayalpha.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OSPF] tsv-dir review of draft-ietf-ospf-encapsulation-cap-06
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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 Sep 2017 15:30:49 -0000

Hi Joe,

Thanks for your review and comments.
Please see inline [Bruno]

> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Joe Touch
 > Sent: Thursday, August 24, 2017 6:39 AM
>=20
 > Hi, all,
 >=20
 > I am the assigned TSV-ART reviewer for draft-ietf-ospf-encapsulation-cap
 >=20
 > For background on TSV-ART, please see the FAQ at
 > .
 >=20
 > Please resolve these comments along with any other Last Call comments
 > you may receive.
 >=20
 > Joe
 >=20
 > ------
 >=20
 > I've reviewed this document as part of the transport area directorate's
 > ongoing effort to review key IETF documents. These comments were written
 > primarily for the transport area directors, but are copied to the
 > document's authors for their information and to allow them to address
 > any issues raised. When done at the time of IETF Last Call, the authors
 > should consider this review together with any other last-call comments
 > they receive. Please always CC tsv-dir@ietf.org if you reply to or
 > forward this review.
 >=20
 > "This draft has serious issues, described in the review, and needs to be
 > rethought."
 >=20
 > Although I found no transport issues, there are many fundamental
 > problems that need to be corrected before this document should proceed.
 > These are summarized below.
 >=20
 > Sec1: The introduction jumps too quickly into a list of situations in
 > which tunnels are used, two of which are emerging (currently only
 > drafts). There are many better and more established examples (going back
 > to the M-Bone, the 6-Bone, etc., to VPNs, network virtualization, etc.).
 > Terms are used before defined (what is an ingress? are you referring to
 > the router or host at which a tunnel is attached, or the input to the
 > tunnel itself?). The last two sentences should begin the intro, which
 > should expand and explain what is meant (e.g., by "egress tunneling" and
 > the reason for wanting to encode tunnels as LSAs.

[Bruno]
- The two emerging examples have been removed in -07
- Current order to paragraph seems fine to me: first explaining that tunnel=
 are used, then explaining the problematics that this document is addressin=
g. I don't feel that swapping both would help the reader.
- "Ingress" meant "tunnel encapsulator". Would this term be better for you?=
 I found it in RFC 7510 which did not define it in its terminology, so I wo=
uld assume that this is a known term If not, would you know which RFC defin=
e it? Or would you prefer a different term?=20

=20
 > Sec2: The terminology section is incomplete. The terms tunnel, ingress,
 > egress, egress tunneling, etc. are not defined in RFC7770. Only the LSA
 > terminology is relevant from that RFC. Other terms need to be defined in
 > this doc or used from others.
=20
[Bruno] We can use the terms "tunnel encapsulator", "tunnel" and "tunnel de=
capsulator" which are used in RFC 7510. Would this be ok for you?
RFC 7510 did not redefine those terms in its terminology section Do you thi=
nk that there is a need in this document? If so, can we point to RFC 7510 o=
r would you have a better reference?

=20
 > Sec3: This section is written as if the "Encapsulation Capability TLV"
 > is already defined (in RFC7770), rather than being defined herein. The
 > section title doesn't match this name, which is confusing. The term TLV
 > is itself confusing, as this is really a single TLV of the RI Opaque LSA
 > set of types, which itself is represented as a (sub)TLV list. I
 > appreciate that this terminology was made confusing in previous,
 > established documents, but a bit of explanation would go a long way - as
 > would showing the top-level OSPF RI Opaque LSA and where the new TBD1
 > value would appear - before diving into the structure inside this new "T=
LV".
=20
[Bruno] I agree that the names are confusing. We have changed some.
Proposed NEW text:

3. Tunnels Encapsulations TLV
      Routers advertise their supported tunnel encapsulation type(s) by
      advertising a new TLV of the OSPF Router Information (RI) Opaque LSA
      , referred to as the Tunnel Encapsulations =
TLV.
      This TLV is applicable to both OSPFv2 and OSPFv3.
[...]
   The Type code of the Tunnels Encapsulations is TBD1, the
      Length value is variable, and the Value field contains one or more
      Tunnel Sub-TLVs as defined in .
=20

--
Although I see your point, I'm not in favor of showing the top-level OSPF R=
I Opaque LSA as I don't think that this would simplify this document. In ad=
dition, the encoding of this LSA is different between OSPFv2 and OSPFv3.


 > Sec 4: the discussion should clarify what happens if the length field is
 > longer than the fields indicated by the sub-TLVs (is this an error or
 > padding to be ignored; does the latter present a covert channel).
 > additionally, this section refers to RFC5512 - which is being obsoleted
 > by ietf-idr-tunnel-encaps - and this pending ID is used as the primary
 > reference in Secs 5.1 and 5.2. References to RFC5512 should be replaced
 > with that ID (which I'll assume will be published concurrently).
=20
[Bruno]
If the length field is longer than addition of sub-TLVs, I guess that the s=
ender implementation has a serious OSPF encoding issue. I'm more familiar w=
ith BGP error handling than the OSPF one, but I guess that the receiver can=
 only try to interpret the additional octets as the presence of an addition=
al sub-TLV. An unknown sub-TLVs is not an issue from a syntax standpoint, b=
ut the length of this sub-TLV may overshoot the size of the Tunnel Type TLV=
 (IOW, the length field is now shorter, which is this opposite of your case=
), which makes this TLV in error.
Sub-TLV errors are already covered  ('"If a Sub-TLV is invalid, its
      Tunnel Encapsulation Type TLV MUST be ignored and skipped. However,
      other Tunnel Encapsulation Type TLVs MUST be considered.") but Tunnel=
 Sub-TLV errors were not. I'm proposing to add a similar text in section "T=
unnel Sub-TLV"
=20
 > Sec 5: this section refers to the concept of an "invalid" sub-TLV; given
 > the previous sentence explains that unknown sub-TLVs are silently
 > ignored, then what exactly is an invalid sub-TLV? It further isn't clear
 > why 2 octets of type and 2 octets of length are needed (granted it
 > provides alignment, but is that really important for this sort of
 > application-layer protocol?)
=20
[Bruno] Proposed NEW:

When a reserved  value (See ) is seen =
in an LSA, it
      MUST be treated as an invalid Tunnel Parameter Sub-TLV. When a Tunnel=
 Parameter Value has an incorrect syntax of semantic, it MUST be treated as=
 an invalid Tunnel Parameter Sub-TLV. If a Tunnel Parameter Sub-TLV is inva=
lid, its
      Tunnel Sub-TLV MUST be ignored and skipped. However,
      other Tunnel Sub-TLVs MUST be considered.

 > Sec 5.1 and 5.2: it is unclear why the two fundamental sub-TLVs of this
 > TLV are defined elsewhere; in specific, the example of the sub-TLV
 > should appear here (actually for each of the sub-TLVs).
=20
[Bruno] Texts have been changed to have theses sections defines the sub-Typ=
e. However, the syntax of the value field is indeed defined in the BGP docu=
ment. The use of a reference ensures consistent specification encoding, whi=
le a copy/paste would allow both OSPF and BGP document be further modified =
during their process (e.g. IESG review, RFC editor) which would lead to dif=
ferences.

NEW:
This Sub-TLV of type 1. The syntax, semantic and usage of its value field i=
s defined in Section 3.2 "Encapsulation
        Sub-TLVs for Particular Tunnel Types" of  Sec 5.3 infers IP address version from length, when the version could
 > (should) easily encoded either as different types (you have 65K of
 > them!) or using an additional few bits (e.g., carved out of the excesses
 > noted in Sec 5).
=20
[Bruno] Agreed that this could have been encoded differently.
This encoding is borrowed from RFC 5512, but indeed draft-ietf-idr-tunnel-e=
ncaps now adds an "Address Family" field.
I'm personally ok to add this "Address Family" field, but this is a non bac=
kward-compatible encoding change, so I would welcome more support from the =
OSPF WG.
=20
 > Sec 5.4 - I had to thread through several different sections of the IDR
 > ID to figure out what Color meant and how it is used. Granted that is a
 > different problem in a different doc, IMO this doc should include enough
 > of a summary that this sort of 'traceback' should not be needed to
 > understand what is being described. Further, the other doc doesn't even
 > explain Color sufficiently, IMO.
=20
[Bruno] IMO, this section does define this Color Sub-TLV:
"The color value is user-defined and configured locally on the
        advertising routers. It may be used by service providers to define
        policies on the tunnel encapsulator routers, for example, to contro=
l the
        selection of the tunnel to use."

Could you please be more specific?
=09
In addition, this document refers to the Color Extended community defined i=
n "I-D.ietf-idr-tunnel-encaps" to define the relationship between both. Arg=
uably, this could alternatively be done in the IDR document, but in both ca=
ses, as we define a relationship between the OSPF Color Sub-TLV, used to co=
lor "underlay tunnels", and the BGP Extended Communities attached to "Overl=
ay service routes", any document would need to refer to the other document.=
 So IMO, it makes sense to define in the OSPF document.
=20
 > Secs 5.6 and 5.7 - There are many rules for how the outer encapsulation
 > header is composed, and many fields it may affect beyond QoS and UDP
 > destination port. This section is incomplete in describing values for
 > the outer header(s) or relationships to the inner header(s).
=20
[Bruno] I can agree with this as I've made a similar comment on the IDR doc=
ument. I got the following answer "It's impossible for a single document to=
 specify a sub-TLV for every=20
encapsulation header field that might possibly be useful.  I tried to inclu=
de in the document enough of a selection of sub-TLVs to indicate how more m=
ight be added.  If someone wants to signal a value for the IPv6 flow label =
field, it should be fairly straightforward to write a draft specifying a su=
itable sub-TLV."
I'm afraid that this is a valid answer. There is no requirement to specify =
the use of all outer header fields. Actually, it's probably better to leave=
 this specification to the ones having the need for this.
=20
 > Sec 6 - I would encourage moving this section earlier, before the
 > details of how the LSA is composed.
=20
[Bruno] Noted. This is an editorial choice. On my side, I prefer separating=
 the specification of the encoding, from the specification of the usage. I =
found this easier to read.
=20
 > Sec 7 - the document should describe where experimental values
 > can/should be safely used and how collisions are handled; it should also
 > explain what happens when a reserved value is seen in an LSA.

[Bruno] Experimental values is a well-Known Registration Status defined in =
RFC 8126 (Guidelines for Writing an IANA Considerations Section in RFCs). T=
his RFC refers to rfc 3692 to answer your valid questions. cf end of https:=
//tools.ietf.org/html/rfc3692#section-1.1 If this is not good enough, I'd s=
uggest fixing the root document by writing a rfc3692bis.

As for reserved value, we have added the following text
"When a reserved value (See Section 6.2) is seen in an LSA, it MUST be trea=
ted as an invalid Sub-TLV. "

Thanks again for your careful review.

Regards,
--Bruno
 >=20
 > ----
 >=20
 >=20
 > _______________________________________________
 > OSPF mailing list
 > OSPF@ietf.org
 > https://www.ietf.org/mailman/listinfo/ospf

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Mon Sep 18 08:33:28 2017
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 265D41342B7; Mon, 18 Sep 2017 08:33:20 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: ospf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.62.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150574880011.15651.4099883606328727652@ietfa.amsl.com>
Date: Mon, 18 Sep 2017 08:33:20 -0700
Archived-At: 
Subject: [OSPF] I-D Action: draft-ietf-ospf-encapsulation-cap-08.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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 Sep 2017 15:33:20 -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 WG of the IETF.

        Title           : The Tunnel Encapsulations OSPF Router Information
        Authors         : Xiaohu Xu
                          Bruno Decraene
                          Robert Raszuk
                          Luis M. Contreras
                          Luay Jalil
	Filename        : draft-ietf-ospf-encapsulation-cap-08.txt
	Pages           : 10
	Date            : 2017-09-18

Abstract:
   Networks use tunnels for a variety of reasons.  A large variety of
   tunnel types are defined and the tunnel encapsulator router needs to
   select a type of tunnel which is supported by the tunnel decapsulator
   router.  This document defines how to advertise, in OSPF Router
   Information Link State Advertisement (LSAs), the list of tunnel
   encapsulations supported by the tunnel decapsulator.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-encapsulation-cap-08
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-encapsulation-cap-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-encapsulation-cap-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 Mon Sep 18 08:47:36 2017
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 554631321A2; Mon, 18 Sep 2017 08:47:34 -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 akJn4_2wFZd4; Mon, 18 Sep 2017 08:47:30 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39359133063; Mon, 18 Sep 2017 08:47:30 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id v142so3919467wmv.5; Mon, 18 Sep 2017 08:47:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SjRjkC3j3dyifhMRHgBZfLtdU4ZOe0lgCSDC7lePydQ=; b=u4blMLYY7DzHkdRmbiYUx9h7v7LwsyxrrzTSc/YaHw3F9Cio28lC3kRBhWWfO/epBp JnvcRvQTYsY3byYaC1dRZ3wGckKrFhPWxep5HUR23VkEnQ9iydXMwn8/vtxbc36P1OZl oKOBbydSvJvqrdJqirwskS62L8+oiY5tIk0wa16LbnnSZrPJ91XAn8pc+R5Wtsx5l9if lCk2XnP/To1OoNCO4dbgy3YB62biUiWNLGhlK2cP1T2KZah6T4uyks0uq0uW16AsW7Dd iqnmbStJdm4MtnaYKuwc2j2P+SYm6nxkOksvucnXeCtVRQSPGryqe0jN1bO5sdxtyHKI jznA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SjRjkC3j3dyifhMRHgBZfLtdU4ZOe0lgCSDC7lePydQ=; b=db/9152mL4hotwgjf7tScjvN6U0gtlKL7trKqjDGTHa3Ol/Hg1mYWLU+a47iC6SISL mAJYfWejdfQaNetNDA4yjEJ1Gmq89Ew0+hd3TqCjP56q1Hz2s8cxN8x6mIpwj63VmUAT nytc8nNDjthfw4SKzBXcERSDqpgp+X0ko7RPpQ0JGwVLb4jFROwrI83u/XDya9bj/AA1 t3Oenev3/TU14bGbMVdcR9KDhCPqgGNDrwndChRxIu/8CqOM7AoOi4ml7g4+nma7Ypg1 loSGk7qW3arg7FF+ia/oo2Pkbm6zJP4BMME8i0p6LEJnGCn19F7cuT/+lkdD5E3L7hAd 16Dg==
X-Gm-Message-State: AHPjjUi9LrTV9DDQ3ZuHhaOJ8J0CacvlvDvtcyKrHq8qfkz1024mVpMc yMNPNfcfVkzxjhtGKQ8pN/ilgg1g3Tiwnosheexl4g==
X-Google-Smtp-Source: AOwi7QCysm8V6p+ZIeXG/3BoKc2e2xbk24jw1H6C9yhHPMF23qEYtByxUDL2+NDINWhh9F7BwnXyc957bJmYh3dCxps=
X-Received: by 10.28.18.210 with SMTP id 201mr4464852wms.135.1505749648481; Mon, 18 Sep 2017 08:47:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.136.153 with HTTP; Mon, 18 Sep 2017 08:47:28 -0700 (PDT)
In-Reply-To: <5991C1C5.9060000@cisco.com>
References:  <5991C1C5.9060000@cisco.com>
From: Alia Atlas 
Date: Mon, 18 Sep 2017 11:47:28 -0400
Message-ID: 
To: Peter Psenak 
Cc: OSPF List , draft-ietf-ospf-segment-routing-extensions@ietf.org
Content-Type: multipart/alternative; boundary="001a1145b02ceb31b2055978a803"
Archived-At: 
Subject: Re: [OSPF] AD review of draft-ietf-ospf-segment-routing-extensions-18
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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 Sep 2017 15:47:34 -0000

--001a1145b02ceb31b2055978a803
Content-Type: text/plain; charset="UTF-8"

Hi Peter,

On Mon, Aug 14, 2017 at 11:29 AM, Peter Psenak  wrote:

> Hi Alia,
>
> thanks for comments, please see inline:
>
> On 12/08/17 04:09 , Alia Atlas wrote:
>
>> As is customary, I have done another AD review
>> of draft-ietf-ospf-segment-routing-extensions-18. I do appreciate the
>> improvements in the draft.
>>
>> I do still see a few minor issues.  I would like to see a revised draft
>> before IETF Last Call. I expect to progress this at an IESG telechat
>> with the primary spring documents, when Alvaro feels they are ready.
>>
>>
>> 1) In Sec 3.1, "If the SR-Algorithm TLV appears in multiple Router
>>     Information LSAs that have different flooding scopes, the SR-
>>     Algorithm TLV in the Router Information LSA with the narrowest
>>     flooding scope SHOULD be used.  "
>>     Given that the area-scope is REQUIRED - shouldn't this also prefer
>>     the area-scope?  Is there future-proofing being done?
>>
>
> link-local scope here does not really make much sense, so the assumption
> was that it's either area or AS-scope, in which case area-scope has
> narrower flooding scope. I'll clarify that in the text.
>
>
>
>> 2) In Sec 3.4: "For the purpose of the SRMS Preference TLV
>> advertisement, AS-scoped flooding is REQUIRED.  This
>>     is because SRMS servers can be located in a different area then
>>     consumers of the SRMS advertisements.  If the SRMS advertisements
>>     from the SRMS server are only used inside the SRMS server's area,
>>     area-scoped flooding may be used."
>>
>> REQUIRED is like MUST - I think you mean "AS-scoped flooded SHOULD be
>> used.... area-scoped flooding MAY be used."
>>
>
> will change to SHOULD.
>
>
>
>> 3) In Sec 4. "The Segment Routing Mapping Server, which is described in
>>     [I-D.ietf-spring-segment-routing-ldp-interop], is an example where we
>>     need a single advertisement to advertise SIDs for multiple prefixes
>>     from a contiguous address range."
>>
>> I've read through the vastly improved section (thank you)
>> in draft-ietf-spring-segment-routing-ldp-interop-08 and I don't see any
>> explanation for why a contiguous address range is needed.
>>
>> I can speculate that a primary purpose is to advertise SIDs for the
>> loopback addresses of routers that don't support SR - and those loopback
>> addresses are likely to be allocated from a contiguous range (though why
>> some wouldn't be supporting SR and cause gaps isn't clear).
>>
>
> range is an optimization similar to summarization. Instead of advertising
> each individual prefix to SID mappings, we can advertise single range with
> the starting SID. I referenced the I-D.ietf-spring-segment-routing-ldp-interop,
> because SRMS is an example where the range advertisements is clearly
> useful, although it's not limited to to that case. One can use SRMS as a
> SID provisioning tool.
>
>
>
>> 4) Sec 5: In the end of Sec 4.2 in
>> draft-ietf-spring-segment-routing-ldp-interop-08, it says "Note: SR
>> mappings advertisements cannot set Penultimate Hop Popping.
>>     In the previous example, P6 requires the presence of the segment 103
>>     such as to map it to the LDP label 1037.  For that reason, the P flag
>>     available in the Prefix-SID is not available in the Remote-Binding
>>     SID."
>> However, in this draft Sec 5 gives the following rules:
>>
>> "As the Mapping Server does not specify the originator of a prefix
>> advertisement, it is not possible to determine PHP behavior solely based
>> on the Mapping Server advertisement. However, PHP behavior SHOULD be
>> done in following cases: The Prefix is intra-area type and the
>> downstream neighbor is the originator of the prefix. The Prefix is
>> inter-area type and downstream neighbor is an ABR, which is advertising
>> prefix reachability and is also generating the Extended Prefix TLV with
>> the A-flag set for this prefix as described in section 2.1 of [RFC7684].
>> The Prefix is external type and downstream neighbor is an ASBR, which is
>> advertising prefix reachability and is also generating the Extended
>> Prefix TLV with the A-flag set for this prefix as described in section
>> 2.1 of [RFC7684].
>>
>> These seem to be contradictory.
>>
>
> The text in draft-ietf-spring-segment-routing-ldp-interop-08 refers to
> the fact that SRMS advertisements itself can not include PHP signaling in
> the advertisement itself, like the regular SID advertisement does, because
> SRMS is not the "owner" of the prefix.
>
> The text in the draft-ietf-ospf-segment-routing-extensions-18 describes
> how the PHP can still be done for SIDs that come from the SRMS
> adverisements, using additional information available to the protocol -
> e.g. prefix owner.
>
> I don't believe these contradict each other.
>

I think this is the final issue to be resolved before I can put this into
IETF Last Call.

First, the OSPF document has to follow the architecture and behavior
defined in the SPRING documents.
This paragraph looks like a potential optimization that is not clearly
articulated and directly contradicts the
text in draft-ietf-spring-segment-routing-ldp-interop-08.

The logic in the ldp-interop draft is so that the boundary router between
segment-routing and LDP can do the mapping from segment-routing to LDP.

In the paragraph above from the ospf draft, it is handling the edge case
where the downstream neighbor originates the prefix, basically.  So - the
signaling has no indication that PHP is desired but OSPF infers that it is
based on topology and advertisements.

The explanation for why this is correct behavior does need to exist -
preferably in the ldp-interop draft - but simply having the unexplained
rules in here will not make for good interoperability or comprehensibility
of the segment-routing architecture.

To be clear, I am fine with having the rules here - if the WG believes that
they are desirable - but there must be an actual explanation as to why this
works and doesn't need the top-level label mapping that ldp-interop refers
to. I'd prefer to see that discussed in the ldp-interop, but if you think
that the issue is IGP-specific, then I could see having it in this draft.

While this may seem obvious to you as to why it is ok, this document and
associated architecture needs to make sense and ensure interoperability for
many other implementations where those developing are basing it on the
standard.  For me, that means that if it isn't obvious to me after reading
through all the related documents (as I have), then it is likely to not be
obvious to others.

Regards,
Alia



> 5) In Sec 7.1, it says "Multiple Mapping Servers can advertise
>>     Prefix-SIDs for the same prefix, in which case the same Prefix-SID
>>     MUST be advertised by all of them."
>>
>> What is forcing this constraint?  Does it work if the Prefix-SID is an
>> index into an
>> SRGB or SRLB that is not the same value globally?
>>
>
> yes, it does. The SID value for the single prefix MUST be unique though,
> otherwise we get into the conflict resolution area, that is covered by the
> draft-ietf-spring-conflict-resolution.
>
> I don't see it
>> specified in Sec 7.2 of draft-ietf-spring-segment-routing-ldp-interop-08?
>>
>
> SR architecture assumes unique mapping of a SID to a prefix. If that is
> not followed, draft-ietf-spring-conflict-resolution comes into picture.
>
> thanks,
> Peter
>
>
>
>
>> Regards,
>> Alia
>>
>
>

--001a1145b02ceb31b2055978a803
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Peter,

On Mon, Aug 14, 2017 at 11:29 AM, Peter Psenak &=
lt;ppsenak@cisco.com=
> wrote:
Hi Alia,



thanks for comments, please see inline:



On 12/08/17 04:09 , Alia Atlas wrote:



As is customary, I have done another AD review

of draft-ietf-ospf-segment-routing-extensions-18. I do appreciate the<=
br>
improvements in the draft.



I do still see a few minor issues.=C2=A0 I would like to see a revised draf=
t

before IETF Last Call. I expect to progress this at an IESG telechat

with the primary spring documents, when Alvaro feels they are ready.





1) In Sec 3.1, "If the SR-Algorithm TLV appears in multiple Router

=C2=A0 =C2=A0 Information LSAs that have different flooding scopes, the SR-=


=C2=A0 =C2=A0 Algorithm TLV in the Router Information LSA with the narrowes=
t

=C2=A0 =C2=A0 flooding scope SHOULD be used.=C2=A0 "

=C2=A0 =C2=A0 Given that the area-scope is REQUIRED - shouldn't this al=
so prefer

=C2=A0 =C2=A0 the area-scope?=C2=A0 Is there future-proofing being done?




link-local scope here does not really make much sense, so the assumption wa=
s that it's either area or AS-scope, in which case area-scope has narro=
wer flooding scope. I'll clarify that in the text.









2) In Sec 3.4: "For the purpose of the SRMS Preference TLV

advertisement, AS-scoped flooding is REQUIRED.=C2=A0 This

=C2=A0 =C2=A0 is because SRMS servers can be located in a different area th=
en

=C2=A0 =C2=A0 consumers of the SRMS advertisements.=C2=A0 If the SRMS adver=
tisements

=C2=A0 =C2=A0 from the SRMS server are only used inside the SRMS server'=
;s area,

=C2=A0 =C2=A0 area-scoped flooding may be used."



REQUIRED is like MUST - I think you mean "AS-scoped flooded SHOULD be<=
br>
used.... area-scoped flooding MAY be used."





will change to SHOULD.









3) In Sec 4. "The Segment Routing Mapping Server, which is described i=
n

=C2=A0 =C2=A0 [I-D.ietf-spring-segment-routing-ldp-interop], is an exa=
mple where we

=C2=A0 =C2=A0 need a single advertisement to advertise SIDs for multiple pr=
efixes

=C2=A0 =C2=A0 from a contiguous address range."



I've read through the vastly improved section (thank you)

in draft-ietf-spring-segment-routing-ldp-interop-08 and I don't se=
e any

explanation for why a contiguous address range is needed.



I can speculate that a primary purpose is to advertise SIDs for the

loopback addresses of routers that don't support SR - and those loopbac=
k

addresses are likely to be allocated from a contiguous range (though why
some wouldn't be supporting SR and cause gaps isn't clear).





range is an optimization similar to summarization. Instead of advertising e=
ach individual prefix to SID mappings, we can advertise single range with t=
he starting SID. I referenced the I-D.ietf-spring-segment-routing-ldp-=
interop, because SRMS is an example where the range advertisements is clear=
ly useful, although it's not limited to to that case. One can use SRMS =
as a SID provisioning tool.









4) Sec 5: In the end of Sec 4.2 in

draft-ietf-spring-segment-routing-ldp-interop-08, it says "Note: =
SR

mappings advertisements cannot set Penultimate Hop Popping.

=C2=A0 =C2=A0 In the previous example, P6 requires the presence of the segm=
ent 103

=C2=A0 =C2=A0 such as to map it to the LDP label 1037.=C2=A0 For that reaso=
n, the P flag

=C2=A0 =C2=A0 available in the Prefix-SID is not available in the Remote-Bi=
nding

=C2=A0 =C2=A0 SID."

However, in this draft Sec 5 gives the following rules:



"As the Mapping Server does not specify the originator of a prefix

advertisement, it is not possible to determine PHP behavior solely based
on the Mapping Server advertisement. However, PHP behavior SHOULD be

done in following cases: The Prefix is intra-area type and the

downstream neighbor is the originator of the prefix. The Prefix is

inter-area type and downstream neighbor is an ABR, which is advertising

prefix reachability and is also generating the Extended Prefix TLV with

the A-flag set for this prefix as described in section 2.1 of [RFC7684].
The Prefix is external type and downstream neighbor is an ASBR, which is
advertising prefix reachability and is also generating the Extended

Prefix TLV with the A-flag set for this prefix as described in section

2.1 of [RFC7684].



These seem to be contradictory.





The text in draft-ietf-spring-segment-routing-ldp-interop-08 refers to=
 the fact that SRMS advertisements itself can not include PHP signaling in =
the advertisement itself, like the regular SID advertisement does, because =
SRMS is not the "owner" of the prefix.



The text in the draft-ietf-ospf-segment-routing-extensions-18 describe=
s how the PHP can still be done for SIDs that come from the SRMS adveriseme=
nts, using additional information available to the protocol - e.g. prefix o=
wner.



I don't believe these contradict each other.

I think this is the final issue to be res=
olved before I can put this into IETF Last Call.

F=
irst, the OSPF document has to follow the architecture and behavior defined=
 in the SPRING documents.
This paragraph looks like a potential o=
ptimization that is not clearly articulated and directly contradicts the
text in draft-ietf-spring-segment-routing-ldp-interop-08.

The logic in the ldp-interop draft is so that the boundary =
router between segment-routing and LDP can do the mapping from segment-rout=
ing to LDP.

In the paragraph above from the ospf d=
raft, it is handling the edge case where the downstream neighbor originates=
 the prefix, basically.=C2=A0 So - the signaling has no indication that PHP=
 is desired but OSPF infers that it is based on topology and advertisements=
.=C2=A0

The explanation for why this is correct be=
havior does need to exist - preferably in the ldp-interop draft - but simpl=
y having the unexplained rules in here will not make for good interoperabil=
ity or comprehensibility of the segment-routing architecture.
To be clear, I am fine with having the rules here - if the WG b=
elieves that they are desirable - but there must be an actual explanation a=
s to why this works and doesn't need the top-level label mapping that l=
dp-interop refers to. I'd prefer to see that discussed in the ldp-inter=
op, but if you think that the issue is IGP-specific, then I could see havin=
g it in this draft.

While this may seem obvious to=
 you as to why it is ok, this document and associated architecture needs to=
 make sense and ensure interoperability for many other implementations wher=
e those developing are basing it on the standard.=C2=A0 For me, that means =
that if it isn't obvious to me after reading through all the related do=
cuments (as I have), then it is likely to not be obvious to others.

Regards,
Alia

=C2=A0
5) In Sec 7.1, it says "Multiple Mapping Servers can advertise=


=C2=A0 =C2=A0 Prefix-SIDs for the same prefix, in which case the same Prefi=
x-SID

=C2=A0 =C2=A0 MUST be advertised by all of them."



What is forcing this constraint?=C2=A0 Does it work if the Prefix-SID is an=


index into an

SRGB or SRLB that is not the same value globally?





yes, it does. The SID value for the single prefix MUST be unique though, ot=
herwise we get into the conflict resolution area, that is covered by the dr=
aft-ietf-spring-conflict-resolution.





I don't see it

specified in Sec 7.2 of draft-ietf-spring-segment-routing-ldp-interop-=
08?





SR architecture assumes unique mapping of a SID to a prefix. If that is not=
 followed, draft-ietf-spring-conflict-resolution comes into picture.


thanks,

Peter











Regards,

Alia









--001a1145b02ceb31b2055978a803--


From nobody Mon Sep 18 08:53:46 2017
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 C6F5D1331C1 for ; Mon, 18 Sep 2017 08:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level: 
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QikNd4B-OHUz for ; Mon, 18 Sep 2017 08:53:44 -0700 (PDT)
Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5741321A2 for ; Mon, 18 Sep 2017 08:53:44 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id D5047160156; Mon, 18 Sep 2017 17:53:42 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id A85B34006A; Mon, 18 Sep 2017 17:53:42 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0361.001; Mon, 18 Sep 2017 17:53:42 +0200
From: 
To: "ospf@ietf.org" 
CC: Joe Touch , Alia Atlas , "Acee Lindem" 
Thread-Topic: draft-ietf-ospf-encapsulation-cap
Thread-Index: AdMwlD9pAfobG2PdRZaXKUsL0mhbTA==
Date: Mon, 18 Sep 2017 15:53:41 +0000
Message-ID: <8775_1505750022_59BFEC06_8775_122_1_53C29892C857584299CBF5D05346208A47879601@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.1]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A47879601OPEXCLILM21corp_"
MIME-Version: 1.0
Archived-At: 
Subject: [OSPF] draft-ietf-ospf-encapsulation-cap
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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 Sep 2017 15:53:46 -0000

--_000_53C29892C857584299CBF5D05346208A47879601OPEXCLILM21corp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,



-07 & -08 have been uploaded following AD, directorates and IESG reviews.



Many changes are editorial.



A significant one is that Names of the TLV have changed:



>From  (-06) :
3. Advertising Encapsulation Capability . . . . . . . . . . . . 3

To  (-08) :
3. Tunnel Encapsulations TLV . . . . . . . . . . . . . . . . . . 3


4. Tunnel Encapsulation Type . . . . . . . . . . . . . . . . . . 4

4. Tunnel Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . 3


5. Tunnel Encapsulation Attribute Sub-TLVs . . . . . . . . . . . 4

5. Tunnel Parameter Sub-TLVs . . . . . . . . . . . . . . . . . . 4











There is an outstanding comment from Joe Touch, asking to change the encodi=
ng of the Endpoint sub-TLV:

- currently the distinction between IPv4 and IPv6 is performed by checking =
the length field, as done by some RFCs and RFC 5512 (defining the original =
BGP tunnel extension)

- Joe is proposing to add an explicit Address Family field. This would also=
 be aligned with the new BGP draft https://tools.ietf.org/html/draft-rosen-=
idr-tunnel-encaps-03#section-2.1





Clearly this encoding change would not be backward compatible. A priori, th=
ere should not be running code as there is no early IANA allocation of the =
code points.

- Any opinion regarding encoding preference?

- Would this change be an issue for someone?





Thanks,

Regards,

--Bruno, on behalf of all authors.



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

> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of in=
ternet-

> drafts@ietf.org

> Sent: Monday, September 18, 2017 5:33 PM

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

> Cc: ospf@ietf.org

> Subject: I-D Action: draft-ietf-ospf-encapsulation-cap-08.txt

>

 >

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

> This draft is a work item of the Open Shortest Path First IGP WG of the I=
ETF.

>

 >         Title           : The Tunnel Encapsulations OSPF Router Informat=
ion

>         Authors         : Xiaohu Xu

>                           Bruno Decraene

>                           Robert Raszuk

>                           Luis M. Contreras

>                           Luay Jalil

>         Filename        : draft-ietf-ospf-encapsulation-cap-08.txt

>         Pages           : 10

>         Date            : 2017-09-18

>

 > Abstract:

>    Networks use tunnels for a variety of reasons.  A large variety of

>    tunnel types are defined and the tunnel encapsulator router needs to

>    select a type of tunnel which is supported by the tunnel decapsulator

>    router.  This document defines how to advertise, in OSPF Router

>    Information Link State Advertisement (LSAs), the list of tunnel

>    encapsulations supported by the tunnel decapsulator.

>

 >

 >

 > The IETF datatracker status page for this draft is:

> https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/

>

 > There are also htmlized versions available at:

> https://tools.ietf.org/html/draft-ietf-ospf-encapsulation-cap-08

> https://datatracker.ietf.org/doc/html/draft-ietf-ospf-encapsulation-cap-08

>

 > A diff from the previous version is available at:

> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-encapsulation-cap-08

>

 >

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

> until the htmlized version and diff are available at tools.ietf.org.

>

 > Internet-Drafts are also available by anonymous FTP at:

> ftp://ftp.ietf.org/internet-drafts/

>

 > _______________________________________________

> I-D-Announce mailing list

> I-D-Announce@ietf.org

> https://www.ietf.org/mailman/listinfo/i-d-announce

> Internet-Draft directories: http://www.ietf.org/shadow.html

> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


--_000_53C29892C857584299CBF5D05346208A47879601OPEXCLILM21corp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all,


 


-07 & -08 have been uplo=
aded following AD, directorates and IESG reviews.


 


Many changes are editorial.<=
o:p>


 


A significant one is that Na=
mes of the TLV have changed:


 









From  (-06)&=
nbsp;:


3. Advertisi=
ng Encapsulation Capability . . . . . . . . . . . . 3





To  (-08)&nb=
sp;:


3. Tunnel En=
capsulations TLV . . . . . . . . . . . . . . . . . . 3










4. Tunnel En=
capsulation Type . . . . . . . . . . . . . . . . . . 4





4. Tunnel Su=
b-TLV . . . . . . . . . . . . . . . . . . . . . . . 3










5. Tunnel En=
capsulation Attribute Sub-TLVs . . . . . . . . . . . 4





5. Tunnel Pa=
rameter Sub-TLVs . . . . . . . . . . . . . . . . . . 4










 <=
/o:p>




 <=
/o:p>




 <=
/o:p>









 


There is an outstanding comm=
ent from Joe Touch, asking to change the encoding of the Endpoint sub-TLV:<=
o:p>


- currently the distinction =
between IPv4 and IPv6 is performed by checking the length field, as done by=
 some RFCs and RFC 5512 (defining the original BGP tunnel extension)


- Joe is proposing to add an=
 explicit Address Family field. This would also be aligned with the new BGP=
 draft

https://tools.ietf.org/htm=
l/draft-rosen-idr-tunnel-encaps-03#section-2.1=



 


 


Clearly this encoding change=
 would not be backward compatible. A priori, there should not be running co=
de as there is no early IANA allocation of the code points.


- Any opinion regarding enco=
ding preference?


- Would this change be an is=
sue for someone?


 


 


Thanks,


Regards,

--Bruno, on behalf of all au=
thors.


 


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


> From=
: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet=
-


> draf=
ts@ietf.org


> Sent=
: Monday, September 18, 2017 5:33 PM


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


> Cc: =
ospf@ietf.org


> Subj=
ect: I-D Action: draft-ietf-ospf-encapsulation-cap-08.txt


> 


 > 


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


> This draft is a work item of the Open Shorte=
st Path First IGP WG of the IETF.


> 


 >       &n=
bsp; Title          =
 : The Tunnel Encapsulations OSPF Router Information


>        &n=
bsp;Authors         : Xiaohu Xu


>        &n=
bsp;            =
;      Bruno Decraene


>        &n=
bsp;            =
;      Robert Raszuk


>        &n=
bsp;            =
;      Luis M. Contreras


>        &n=
bsp;            =
;      Luay Jalil


>         F=
ilename        : draft-ietf-ospf-encapsu=
lation-cap-08.txt


>         P=
ages           : 10


>         D=
ate            : 201=
7-09-18


> 


 > Abstract:


>    Networks use tunnels for a=
 variety of reasons.  A large variety of


>    tunnel types are defined a=
nd the tunnel encapsulator router needs to


>    select a type of tunnel wh=
ich is supported by the tunnel decapsulator


>    router.  This documen=
t defines how to advertise, in OSPF Router


>    Information Link State Adv=
ertisement (LSAs), the list of tunnel


>    encapsulations supported b=
y the tunnel decapsulator.


> 


 > 


 > 


 > The IETF datatracker status page for t=
his draft is:


> 
https://datatracker.ietf.o=
rg/doc/draft-ietf-ospf-encapsulation-cap/


> 


 > There are also htmlized versions avail=
able at:


> 
https://tools.ietf.org/htm=
l/draft-ietf-ospf-encapsulation-cap-08


> 
https://datatracker.ietf.o=
rg/doc/html/draft-ietf-ospf-encapsulation-cap-08


> 


 > A diff from the previous version is av=
ailable at:


> 
https://www.ietf.org/rfcdi=
ff?url2=3Ddraft-ietf-ospf-encapsulation-cap-08


> 


 > 


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


> until the htmlized version and diff are avai=
lable at tools.ietf.org.


> 


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


> ftp://ftp.ietf.org/int=
ernet-drafts/


> 


 > ______________________________________=
_________


> I-D-Announce mailing list


> I-D-Announce@ietf.org<=
/a>


> 
https://www.ietf.org/mailm=
an/listinfo/i-d-announce


> Internet-Draft directories: 
http://www.ietf.org/shadow=
.html


> or 
ftp://ftp.ietf.org/ietf/1s=
hadow-sites.txt




______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.




--_000_53C29892C857584299CBF5D05346208A47879601OPEXCLILM21corp_--


From nobody Mon Sep 18 13:21:52 2017
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 2CB2013308D; Mon, 18 Sep 2017 13:21:49 -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 xY-AUnu8Fa2F; Mon, 18 Sep 2017 13:21:46 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 8F63512421A; Mon, 18 Sep 2017 13:21:46 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id r85so1181330ywg.1; Mon, 18 Sep 2017 13:21:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=bestp95MJ6gma4DWsSkH5Hkb9GLFj4aGx0ZRpVQtDMs=; b=B7CyOK+jPBdZJaPYZB6WhasbjPVb/w7kH6zKlhzmaSlgJKgfMfF1D/wb8mwZPIa2M+ bPaPLKbxTstxtvDbd4woIMyMEHATgcs21tMZ74xAFlXHGjjSz6KlbAeieLvzXahF4CuX YFONDilOQiT2Ig4QwzF6qg9I3DLpXNbdWqK4vNWGH4otPqZgWH0lGlGTMsPmqOZwx2Mh sa0YAWIYTqZ+MuiYmErACpvNOa7R+zwhDgQr7bIMqv0wb91pnn9r7WVMhmCgRzeihvXO V+EAzeIAJelKBk29hTrJnwI1W47BR9FMCO4NaXzXzddyROzw2G/N/Jm77jfXknkgLaxR 7j/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=bestp95MJ6gma4DWsSkH5Hkb9GLFj4aGx0ZRpVQtDMs=; b=sqSlPEnXrUrHHNbdascA4LOfAu0ekjiWZ1MQvixe5EV6AaKe9cTch4AdF3VaZX9Pwk tekynYRN/j95noGNxPvBNyox0BRcyhE4nujaPULZy+Dxisy9nIkQ18ZtpYuEs5eF3pIg O/ev9txE5LE9IX+VVh4afgInE9Ght0O19Exbngqgz0Xzbow0xSBdFq+th4HCpCkwEcZv TuQ6C9wnUpxSEc3/JUODgjz2kkmcZriMbhgZcz0VCm6hVbQCp5kPAiBDL8rwoLIUo2ua 06XOd653ZJJmB055cna0SeeWpmI0DQBvVV+E3zyDjAItIt15fEbkQvyXNV2H12WL8qCy TXgA==
X-Gm-Message-State: AHPjjUj3sCXpDmPbZgmOrA/qRPAy+fL3GUsUfijega+MaBFdIcW4EDYw YxymO7V4LSXKGQ==
X-Google-Smtp-Source: ADKCNb4xzpETWkT7GvdZlslhj7eeKjiRXTKY38yB/8gp0qee2C219zt/ZqwdM+dulauVya9EWboRDA==
X-Received: by 10.129.91.196 with SMTP id p187mr29253436ywb.101.1505766105726;  Mon, 18 Sep 2017 13:21:45 -0700 (PDT)
Received: from [10.0.0.12] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id f184sm3321029ywc.19.2017.09.18.13.21.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Sep 2017 13:21:44 -0700 (PDT)
From: Suresh Krishnan 
Message-Id: <0548F269-E268-474F-99D7-64FFE050D0A8@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F544476A-7102-4645-89F7-E5CED41714D1"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 18 Sep 2017 16:21:44 -0400
In-Reply-To: 
Cc: The IESG , "draft-ietf-ospf-encapsulation-cap@ietf.org" ,  "ospf-chairs@ietf.org" , "ospf@ietf.org" 
To: "Acee Lindem (acee)" 
References: <150414779958.16833.5322499494351720362.idtracker@ietfa.amsl.com>   
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [OSPF] Suresh Krishnan's Discuss on draft-ietf-ospf-encapsulation-cap-06: (with DISCUSS and COMMENT)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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 Sep 2017 20:21:49 -0000

--Apple-Mail=_F544476A-7102-4645-89F7-E5CED41714D1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi all,
  Just closing the loop on this. Acee and I had a phone call to discuss =
this issue. It looks like Acee was thinking that I was talking about the =
value in the TLV while I was talking about the type and the length (as =
per my DISCUSS text). We agreed that the type and length will be encoded =
as per this document and the value as per the referred documents. The =
new text from Bruno resolves my issues.

Regards
Suresh

> On Aug 31, 2017, at 10:39 AM, Acee Lindem (acee)  =
wrote:
>=20
> Hi Suresh,=20
>=20
> From: Suresh Krishnan >
> Date: Thursday, August 31, 2017 at 10:06 AM
> To: Acee Lindem >
> Cc: The IESG >, =
"draft-ietf-ospf-encapsulation-cap@ietf.org =
" =
>, =
"ospf-chairs@ietf.org " =
>, OSPF WG List =
>
> Subject: Re: Suresh Krishnan's Discuss on =
draft-ietf-ospf-encapsulation-cap-06: (with DISCUSS and COMMENT)
>=20
> Hi Acee,
>   Thanks for the quick reply. Please find comments inline.
>=20
>> On Aug 31, 2017, at 5:50 AM, Acee Lindem (acee) > wrote:
>>=20
>> Hi Suresh,=20
>>=20
>> On 8/30/17, 10:49 PM, "Suresh Krishnan" > wrote:
>>=20
>> Suresh Krishnan has entered the following ballot position for
>> draft-ietf-ospf-encapsulation-cap-06: Discuss
>>=20
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut =
this
>> introductory paragraph, however.)
>>=20
>>=20
>> Please refer to =
https://www.ietf.org/iesg/statement/discuss-criteria.html =

>> for more information about IESG DISCUSS and COMMENT positions.
>>=20
>>=20
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/ =

>>=20
>>=20
>>=20
>> =
----------------------------------------------------------------------
>> DISCUSS:
>> =
----------------------------------------------------------------------
>>=20
>> * There seems to be an difference between this document's definition =
of
>> sub-TLVs (with 2 octet types and lengths) and those of RFC5512 (with =
1 octet
>> types and lengths). So I am surprised to see the document point to =
the RFC5512
>> based TLVs for both syntax and semantics (Sections 5.1, 5.2, 5.3 ...) =
. Can you
>> please explain how these sub-TLVs are encoded on the wire to be =
compatible with
>> this draft?
>>=20
>> I can answer this one since I specifically told the authors to use =
this format. If you look at RFC 7770, you=E2=80=99ll see that all OSPF =
Router Information (RI) LSA TLVs and Sub-TLVs have 2 octet types and =
lengths.=20
>>=20
>> 2.3. OSPF Router Information LSA TLV Format
>>=20
>> The format of the TLVs within the body of an RI LSA is the same as
>> the format used by the Traffic Engineering Extensions to OSPF [TE].
>> The LSA payload consists of one or more nested Type/Length/Value
>> (TLV) triplets. The format of each TLV is:
>>=20
>>  0 1 2 3
>>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Type | Length |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | Value... |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>=20
>> Figure 3. TLV Format
>>=20
>>=20
>> Additionally, if you look at =
https://www.ietf.org/id/draft-ietf-idr-tunnel-encaps-07.txt =
 (which =
obsoletes RFC 5512), you=E2=80=99ll see that the 1 octet length with =
insufficient.=20
>>=20
>>    Each sub-TLV consists of three fields: a 1-octet type, a 1-octet =
or
>>    2-octet length field (depending on the type), and zero or more =
octets
>>    of value.  A sub-TLV is structured as shown in Figure 2:
>>=20
>>                    +-----------------------------------+
>>                    |      Sub-TLV Type (1 Octet)       |
>>                    +-----------------------------------+
>>                    |     Sub-TLV Length (1 or 2 Octets)|
>>                    +-----------------------------------+
>>                    |     Sub-TLV Value (Variable)      |
>>                    |                                   |
>>                    +-----------------------------------+
>>=20
>>                Figure 2: Tunnel Encapsulation Sub-TLV Format
>>=20
>>    o  Sub-TLV Type (1 octet): each sub-TLV type defines a certain
>>       property about the tunnel TLV that contains this sub-TLV.
>>=20
>>=20
>>=20
>>=20
>>=20
>> Rosen, et al.           Expires January 18, 2018                [Page =
7]
>> ?
>> Internet-Draft       Tunnel Encapsulation Attribute            July =
2017
>>=20
>>=20
>>    o  Sub-TLV Length (1 or 2 octets): the total number of octets of =
the
>>       sub-TLV value field.  The Sub-TLV Length field contains 1 octet =
if
>>       the Sub-TLV Type field contains a value in the range from =
1-127.
>>       The Sub-TLV Length field contains two octets if the Sub-TLV =
Type
>>       field contains a value in the range from 128-254.
>>=20
>>    o  Sub-TLV Value (variable): encodings of the value field depend =
on
>>       the sub-TLV type as enumerated above.  The following =
sub-sections
>>       define the encoding in detail.
> I did read the draft-ietf-idr-tunnel-encaps-07 draft (following it =
from the references) and I do understand why the document made the =
switch to 2 octets for the length. The part that threw me off is that =
this document (ospf-encapsulation) mandates *2 Octet* sub-TLV types =
which are not even mentioned in draft-ietf-idr-tunnel-encaps-07. =
Similarly this document mandates 2 octet lengths without nuancing the =
length based on sub-TLV type (>127 or not). And then it states that the =
syntax is specified in the documents that use 1 octet types. This is the =
discrepancy that needs addressing.
>=20
> No it doesn=E2=80=99t=E2=80=A6  The OSPF RI TLVs and Sub-TLVs have =
uniform 2 octet types and lengths as specified in RFC 7770. If all the =
routing protocols had exactly the same encodings, we=E2=80=99d only have =
one ;^)=20
>=20
> Thanks,
> Acee=20
>=20
>=20
> Thanks
> Suresh
>=20


--Apple-Mail=_F544476A-7102-4645-89F7-E5CED41714D1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi all,
  Just closing the loop on this. =
Acee and I had a phone call to discuss this issue. It looks like Acee =
was thinking that I was talking about the value in the TLV while I was =
talking about the type and the length (as per my DISCUSS text). We =
agreed that the type and length will be encoded as per this document and =
the value as per the referred documents. The new text from Bruno =
resolves my issues.

Regards
Suresh

On =
Aug 31, 2017, at 10:39 AM, Acee Lindem (acee) <acee@cisco.com> =
wrote:








Hi Suresh, 









From: Suresh Krishnan =
<suresh.krishnan@gmail.com>

Date: Thursday, =
August 31, 2017 at 10:06 AM

To: Acee Lindem =
<acee@cisco.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-ospf-encapsulation-cap@ietf.org" <draft-ietf-ospf-encapsulation-cap@ietf.org>,
 "ospf-chairs@ietf.org" <ospf-chairs@ietf.org>, OSPF WG List <ospf@ietf.org>

Subject: Re: Suresh =
Krishnan's Discuss on draft-ietf-ospf-encapsulation-cap-06: (with =
DISCUSS and COMMENT)














Hi Acee,

  Thanks for the quick reply. Please find comments =
inline.









On Aug 31, 2017, at 5:50 AM, Acee Lindem (acee) <acee@cisco.com> =
wrote:








Hi Suresh, 







On 8/30/17, 10:49 PM, "Suresh Krishnan" <suresh.krishnan@gmail.com> wrote:









Suresh Krishnan has entered the following ballot =
position for


draft-ietf-ospf-encapsulation-cap-06: Discuss







When responding, please keep the subject line intact and =
reply to all


email addresses included in the To and CC lines. (Feel =
free to cut this


introductory paragraph, however.)












Please refer to 
https://www.ietf.org/iesg/statement/discuss-criteria.html


for more information about IESG DISCUSS and COMMENT =
positions.












The document, along with other ballot positions, can be =
found here:


https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-=
cap/

















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


DISCUSS:


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







* There seems to be an difference between this =
document's definition of


sub-TLVs (with 2 octet types and lengths) and those of =
RFC5512 (with 1 octet


types and lengths). So I am surprised to see the =
document point to the RFC5512


based TLVs for both syntax and semantics (Sections 5.1, =
5.2, 5.3 ...) . Can you


please explain how these sub-TLVs are encoded on the =
wire to be compatible with


this draft?









I can answer this one since I specifically told the authors =
to use this format. If you look at RFC 7770, you=E2=80=99ll see that all =
OSPF Router Information (RI) LSA TLVs and Sub-TLVs have 2 octet
 types and lengths. 









2.3. OSPF Router =
Information LSA TLV Format







The format of the TLVs =
within the body of an RI LSA is the same as


the format used by the =
Traffic Engineering Extensions to OSPF [TE].


The LSA payload =
consists of one or more nested Type/Length/Value


(TLV) triplets. The =
format of each TLV is:







 0 1 2 =
3


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


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+


| Type | Length =
|


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+


| Value... =
|


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+







Figure 3. TLV =
Format














Additionally, if you =
look at https://www.ietf.org/id/draft-ietf-idr-tunnel-encaps-07.txt=
 (which obsoletes RFC 5512), you=E2=80=99ll see that
 the 1 octet length with insufficient. 









   Each sub-TLV consists of three fields: a 1-octet =
type, a 1-octet or
   2-octet length field (depending on the type), and zero or more octets
   of value.  A sub-TLV is structured as shown in Figure 2:

                   +-----------------------------------+
                   |      Sub-TLV Type (1 Octet)       |
                   +-----------------------------------+
                   |     Sub-TLV Length (1 or 2 Octets)|
                   +-----------------------------------+
                   |     Sub-TLV Value (Variable)      |
                   |                                   |
                   +-----------------------------------+

               Figure 2: Tunnel Encapsulation Sub-TLV Format

   o  Sub-TLV Type (1 octet): each sub-TLV type defines a certain
      property about the tunnel TLV that contains this sub-TLV.





Rosen, et al.           Expires January 18, 2018                [Page 7]
?
Internet-Draft       Tunnel Encapsulation Attribute            July 2017


   o  Sub-TLV Length (1 or 2 octets): the total number of octets of the
      sub-TLV value field.  The Sub-TLV Length field contains 1 octet if
      the Sub-TLV Type field contains a value in the range from 1-127.
      The Sub-TLV Length field contains two octets if the Sub-TLV Type
      field contains a value in the range from 128-254.

   o  Sub-TLV Value (variable): encodings of the value field depend on
      the sub-TLV type as enumerated above.  The following sub-sections
      define the encoding in detail.









I did read the draft-ietf-idr-tunnel-encaps-07 draft (following it =
from the references) and I do understand why the document made the =
switch to 2 octets for the length. The part that threw me off is that =
this document (ospf-encapsulation) mandates *2 Octet*
 sub-TLV types which are not even mentioned in =
draft-ietf-idr-tunnel-encaps-07. Similarly this document mandates 2 =
octet lengths without nuancing the length based on sub-TLV type (>127 =
or not). And then it states that the syntax is specified in the =
documents
 that use 1 octet types. This is the discrepancy that needs =
addressing.
















No it doesn=E2=80=99t=E2=80=A6  The OSPF RI TLVs =
and Sub-TLVs have uniform 2 octet types and lengths as specified in RFC =
7770. If all the routing protocols had exactly the same encodings, =
we=E2=80=99d only have one ;^) 







Thanks,


Acee 





















Thanks


Suresh




















=

--Apple-Mail=_F544476A-7102-4645-89F7-E5CED41714D1--


From nobody Mon Sep 18 13:24:49 2017
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 DC17B13302A; Mon, 18 Sep 2017 13:24:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 cno6xqYG84E7; Mon, 18 Sep 2017 13:24:44 -0700 (PDT)
Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com [IPv6:2607:f8b0:4002:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B002A132D42; Mon, 18 Sep 2017 13:24:44 -0700 (PDT)
Received: by mail-yw0-x242.google.com with SMTP id t127so773937ywg.5; Mon, 18 Sep 2017 13:24:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7uuRPJRE6i0N4r7AvvokHbM5MMokj4MrTo6yfl15/fI=; b=APCCSmOl2Xp4u1T2dTh3Or9Euww2ud1BLerBciHO7XYQmB9C3F0QpofxLDSb5sz3K/ fXjetY+pRpUUnFDNpC/wbGKtEumItQyscXfwDuj3fYdZK9zzkYSwre+rtOU02fV7F+Pg lgHso9O2PoW7T/mU+9FG/04X0yBOop+bRiGs1SwOejeZxilsginQwHeYyzHEHfwWLEMi unPf/zunBoc/cG+FgfMErf1m/YVUPq8QvyUsFpaOkGDF0jKewWfqsxIzTVuuqDANE6g5 oYMaia3inHrGPxuu4BfzxSXgWsU0I8lLNYzfQhyhDIVCyUSAz6O7bzgY9mCEXTkvGyBE gdKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7uuRPJRE6i0N4r7AvvokHbM5MMokj4MrTo6yfl15/fI=; b=h/Lh0i2H/nWYacAhV3t4sgJXymcJBsv8OCsJBkV8ik45IHV1R+dnyw5hGSOylyX+rJ OHl/fLqjbyKDmMvxURgndyq12/fuWmtkHyC0ADN81yR4Cbs0383TCWYCdUYMhdHElZ2R 1zQAsrPKAwpPx9iF21S1IG9A/9/9rOopbU/18zh189WYKqBOAF2iO2Va/E095l0aGfFJ zRTpecPiKhpMwI2nICR3I0k+JSIhDlYeZzjc2sPPrni6lL/VDyy2TLeC1dL0LFTCoDYi f4XPSRbdiqFiWF6jiEBqX8AkoLKU0l9ILelPvnR8+y1t6xv+Xx5epdajC9lhlAX/nn2s r5dQ==
X-Gm-Message-State: AHPjjUgRDeAjsfF2W+PTpcvK2Lptd0b5SW+8u9Hwb2oNq3W6xXfeihFv Mi/cUHe7UOeqSNcx4uY=
X-Google-Smtp-Source: ADKCNb7waFVq9NaUC9Bu2Ci7kOg1xNcijKDKIHhZSIqBFOH+OD7oj6r5KXf9pNMC2ROPS5e1zm1N4w==
X-Received: by 10.37.49.213 with SMTP id x204mr27536609ybx.40.1505766283910; Mon, 18 Sep 2017 13:24:43 -0700 (PDT)
Received: from [10.0.0.12] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id w137sm3333615ywd.9.2017.09.18.13.24.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Sep 2017 13:24:43 -0700 (PDT)
From: Suresh Krishnan 
Message-Id: <1405DEF4-1AAC-459D-874B-5EB4B93AE94C@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CF74EF73-7600-4424-A55E-076A5B24BFAC"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 18 Sep 2017 16:24:42 -0400
In-Reply-To: <10459_1505748011_59BFE42B_10459_96_12_53C29892C857584299CBF5D05346208A47879377@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Cc: "draft-ietf-ospf-encapsulation-cap@ietf.org" ,  Acee Lindem , "ospf-chairs@ietf.org" , "ospf@ietf.org" , The IESG 
To: bruno.decraene@orange.com
References: <150414779958.16833.5322499494351720362.idtracker@ietfa.amsl.com> <10459_1505748011_59BFE42B_10459_96_12_53C29892C857584299CBF5D05346208A47879377@OPEXCLILM21.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [OSPF] Suresh Krishnan's Discuss on draft-ietf-ospf-encapsulation-cap-06: (with DISCUSS and COMMENT)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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 Sep 2017 20:24:47 -0000

--Apple-Mail=_CF74EF73-7600-4424-A55E-076A5B24BFAC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Bruno,
  Thanks for the changes.

> On Sep 18, 2017, at 11:20 AM,  =
 wrote:
>=20
> Suresh,
>=20
> Thanks for the review and comments.
> Please see inline [Bruno]
>=20
>> From: Suresh Krishnan [mailto:suresh.krishnan@gmail.com]
>> Sent: Thursday, August 31, 2017 4:50 AM
>>=20
>> Suresh Krishnan has entered the following ballot position for
>> draft-ietf-ospf-encapsulation-cap-06: Discuss
>>=20
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut =
this
>> introductory paragraph, however.)
>>=20
>>=20
>> Please refer to =
https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>=20
>>=20
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/
>>=20
>>=20
>>=20
>> =
----------------------------------------------------------------------
>> DISCUSS:
>> =
----------------------------------------------------------------------
>>=20
>> * There seems to be an difference between this document's definition =
of
>> sub-TLVs (with 2 octet types and lengths) and those of RFC5512 (with =
1 octet
>> types and lengths). So I am surprised to see the document point to =
the RFC5512
>> based TLVs for both syntax and semantics (Sections 5.1, 5.2, 5.3 ...) =
. Can you
>> please explain how these sub-TLVs are encoded on the wire to be =
compatible with
>> this draft?
>=20
> [Bruno] Would the following change works for you?
>=20
> OLD:
>        This Sub-TLV of type 2 is defined in Section 3.4.1 "Protocol =
Type
>        sub-TLV" of  from =
a
>        syntactic, semantic, and usage standpoint.
>=20
> NEW:
>        This Sub-TLV type is 2. The syntax, semantic, and usage of its =
value field is defined in Section 3.4.1 "Protocol Type
>        sub-TLV" of .

Excellent. That would address my concerns. I checked the new version of =
the draft and this fix addresses all of the instances of this issue. I =
will clear.

>=20
>=20
>=20
>> =
----------------------------------------------------------------------
>> COMMENT:
>> =
----------------------------------------------------------------------
>>=20
>> * IANA considerations
>>=20
>> Looks like the value 65535 is included both as experimental and =
reserved. Suggest changing
>>=20
>> OLD:
>> 65500-65535    Experimental                              This =
document
>>=20
>> NEW:
>> 65500-65534    Experimental                              This =
document
>>=20
>=20
> [Bruno] Good catch. Thanks for the careful review. Fixed as per you =
suggestion in -07 =
https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-encapsulation-cap-07=
.txt =


Great.

Regards
Suresh


--Apple-Mail=_CF74EF73-7600-4424-A55E-076A5B24BFAC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi Bruno,
  Thanks for the =
changes.

On Sep 18, 2017, at 11:20 AM, =
<bruno.decraene@orange.com> <bruno.decraene@orange.com> wrote:

Suresh,
Thanks for the review and comments.
Please see inline [Bruno]
From: Suresh Krishnan [mailto:suresh.krishnan@gmail.com]
Sent: =
Thursday, August 31, 2017 4:50 AM

Suresh =
Krishnan has entered the following ballot position for
draft-ietf-ospf-encapsulation-cap-06: Discuss
When responding, please keep the subject line intact and =
reply to all
email addresses included in the To and CC =
lines. (Feel free to cut this
introductory paragraph, =
however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT =
positions.


The document, =
along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-=
cap/



---------------------------------------------------------------=
-------
DISCUSS:
---------------------------------------------------------------=
-------

* There seems to be an difference =
between this document's definition of
sub-TLVs (with 2 =
octet types and lengths) and those of RFC5512 (with 1 octet
types and lengths). So I am surprised to see the document =
point to the RFC5512
based TLVs for both syntax and =
semantics (Sections 5.1, 5.2, 5.3 ...) . Can you
please =
explain how these sub-TLVs are encoded on the wire to be compatible =
with
this draft?

[Bruno] Would the following change works for =
you?

OLD:
       This =
Sub-TLV of type 2 is defined in Section 3.4.1 "Protocol Type
       sub-TLV"=
 of <xref target=3D"I-D.ietf-idr-tunnel-encaps"/> from a
       syntactic, =
semantic, and usage standpoint.

NEW:
       This Sub-TLV type =
is 2. The syntax, semantic, and usage of its value field is defined in =
Section 3.4.1 "Protocol Type
       sub-TLV" of =
<xref target=3D"I-D.ietf-idr-tunnel-encaps"/>.

Excellent. That =
would address my concerns. I checked the new version of the draft and =
this fix addresses all of the instances of this issue. I will =
clear.




---------------------------------------------------------------=
-------
COMMENT:
---------------------------------------------------------------=
-------

* IANA considerations

Looks like the value 65535 is included both as =
experimental and reserved. Suggest changing

OLD:
65500-65535    Experimental =
            &n=
bsp;           &nbs=
p;    This document

NEW:
65500-65534    Experimental =
            &n=
bsp;           &nbs=
p;    This document


[Bruno] Good catch. Thanks for the =
careful review. Fixed as per you suggestion in -07 https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ospf-encapsula=
tion-cap-07.txt

Great.

Regards
Suresh

=

--Apple-Mail=_CF74EF73-7600-4424-A55E-076A5B24BFAC--


From nobody Mon Sep 18 13:25:54 2017
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 F09591332CE; Mon, 18 Sep 2017 13:25:46 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Suresh Krishnan 
To: "The IESG" 
Cc: draft-ietf-ospf-encapsulation-cap@ietf.org, Acee Lindem ,  ospf-chairs@ietf.org, acee@cisco.com, ospf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.62.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150576634697.15632.10040694688090376383.idtracker@ietfa.amsl.com>
Date: Mon, 18 Sep 2017 13:25:46 -0700
Archived-At: 
Subject: [OSPF] Suresh Krishnan's No Objection on draft-ietf-ospf-encapsulation-cap-08: (with COMMENT)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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 Sep 2017 20:25:47 -0000

Suresh Krishnan has entered the following ballot position for
draft-ietf-ospf-encapsulation-cap-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing my DISCUSS and COMMENT points



From nobody Sat Sep 23 09:14:09 2017
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 6FEBD132D96; Sat, 23 Sep 2017 09:14:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 A4zfTHFCWajH; Sat, 23 Sep 2017 09:13:58 -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 151D9132351; Sat, 23 Sep 2017 09:13:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13661; q=dns/txt; s=iport; t=1506183238; x=1507392838; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=S7Jy1cV1i6SanYjfA85fJF+AUQRipUzZwa2LRMtlhyg=; b=Z0YRe1FlxRDQSnONfhFsEH9tuT2eJ3vPTE+gKo702587xcQfyBhB7tFg v9wV2Jcj91IJWSeY5vkhwXxe+VkUzem7be1BGbYKUEAHk7hbfePenhb55 hT8F8HQ5HSg45YpU2jq5oValV/mf9RujByyqPkfihuFO01+HZxwBxuYPV o=;
X-IronPort-AV: E=Sophos;i="5.42,430,1500940800"; d="scan'208";a="81153312"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Sep 2017 16:13:57 +0000
Received: from [10.24.54.208] ([10.24.54.208]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v8NGDuGE018526; Sat, 23 Sep 2017 16:13:56 GMT
To: bruno.decraene@orange.com
Cc: "draft-ietf-ospf-encapsulation-cap@ietf.org" , Acee Lindem , "ospf-chairs@ietf.org" , "ospf@ietf.org" , "tjw.ietf@gmail.com" , The IESG 
References: <150407984152.21582.13499330365584334713.idtracker@ietfa.amsl.com> <19482_1505748356_59BFE584_19482_314_1_53C29892C857584299CBF5D05346208A4787940D@OPEXCLILM21.corporate.adroot.infra.ftgroup>
From: Benoit Claise 
Message-ID: <4e42c80b-ec61-5130-35a0-a2678b7751f3@cisco.com>
Date: Sat, 23 Sep 2017 09:13:56 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <19482_1505748356_59BFE584_19482_314_1_53C29892C857584299CBF5D05346208A4787940D@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [OSPF] Benoit Claise's Discuss on draft-ietf-ospf-encapsulation-cap-06: (with DISCUSS and COMMENT)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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 Sep 2017 16:14:00 -0000

Hi Bruno,

At this point, I'll be trusting the group, the doc . shepherd, and the 
responsible AD that the right actions will be taken.
Removing my DISCUSS now.

Regards, B.
> Hi Benoit,
>
> Thanks for you review and comments.
> Please see inline [Bruno]
>
>> From: Benoit Claise [mailto:bclaise@cisco.com]
>   > Sent: Wednesday, August 30, 2017 9:57 AM
>   > Benoit Claise has entered the following ballot position for
>   > draft-ietf-ospf-encapsulation-cap-06: Discuss
>   >
>   > When responding, please keep the subject line intact and reply to all
>   > email addresses included in the To and CC lines. (Feel free to cut this
>   > introductory paragraph, however.)
>   >
>   >
>   > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>   > for more information about IESG DISCUSS and COMMENT positions.
>   >
>   >
>   > The document, along with other ballot positions, can be found here:
>   > https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/
>   >
>   >
>   >
>   > ----------------------------------------------------------------------
>   > DISCUSS:
>   > ----------------------------------------------------------------------
>   >
>   > 1. I agree with Tim Wicinski's OPS DIR point about IANA.
>   >
>   >     The content appears to be fine, but there are some outdated (the biggest
>   >     one is 5226 replaced by 8126),
>
> [Bruno] Thanks. Fixed.
>
>   >  but its the IANA section which appears the
>   >     most confusing.
>   >
>   >     7.1 OSPF Router Information (RI) Registry -  appears fine
>   >
>   >     7.2 OSPF Tunnel Encapsulation Attribute Sub-TLV Registry
>   >
>   >     This one defines the values being defined/allocated from "This Document"
>   >     but in Section 5, each Sub-TLV is defined in other documents, so it's
>   >     totally confusing.
>   
> [Bruno] Your comment is in line with other comments. We are proposing the two below changes. Would this address your point?
>
> 1) In sections 5.x, clarifies that the Type values are defined in this document. Only the Value field is defined in the BGP document.
> More specifically, the propose change is
> OLD:
>          This Sub-TLV of type 2 is defined in Section 3.4.1 "Protocol Type
>          sub-TLV" of  from a
>          syntactic, semantic, and usage standpoint.
>
> NEW:
>          This Sub-TLV type is 2. The syntax, semantic, and usage of its value field is defined in Section 3.4.1 "Protocol Type
>          sub-TLV" of .
>
>
> 2) As per other comments, draft-07 has changed to IANA section
> OLD:
> 2        Protocol Type        This document  	
>
> NEW:
>   2    Protocol Type          This document & [I-D.ietf-idr-tunnel-encaps]	
>
>
> Note that I'm personally not so found of the above change as draft-ietf-ospf-encapsulation-cap does create this new registry and allocate those initial values. But I can live with those changes if people see value.
>
>
>
>   > 2. It's not clear which of the following sub-TLVs are
>   > required/relevant/interconnected in the Encapsulation Capability TLV
>   >
>   >             0    Reserved                                  This document
>   >             1    Encapsulation                             This document
>   >             2    Protocol Type                             This document
>   >             3    Endpoint                                  This document
>   >             4    Color                                     This document
>   >             5    Load-Balancing Block                      This document
>   >             6    IP QoS                                    This document
>   >             7    UDP Destination Port                      This document
>   >
>   > The only hint is:
>   >
>   >       Value (variable): Zero or more Tunnel Encapsulation Attribute Sub-
>   >       TLVs as defined in Section 5.
>   >
>   > Zero? really, what's the point?
>
> [Bruno] There is no point in sending zero Sub-TLVs, as per draft-ietf-ospf-encapsulation-cap. But I'm not sure to see a reason to:
> - forbid this usage in a future specification
> - create an error case with specific error handling associated.
>
> Also this text is taken from RFC 5512 section 4, which originally defined the BGP Tunnel Encapsulation Attribute https://tools.ietf.org/html/rfc5512#section-4
>
>
>   > Now, from an operational point of view, which sub-TLVs are required/make sense?
>   > Are some sub-TLVs irrelevant without others? Ex: Color without Encapsulation
>
> [Bruno]
> RFC5512 did not cover this point, nor does draft-ietf-idr-tunnel-encaps.
> In theory, as of today, Sub-TLV type 3 (Endpoint) seems required to minimally define the IP address of the tunnel decapsulator. However, I'm reluctant to define sub-TLV as REQUIRED, as future Sub-TLV/usage could possibly obsolete the initially required Sub-TLV. So we would create error condition which would possibly limit backward compatible improvement. Also the Encapsulation Sub-TLV (type 1) is required for some type of tunnels.
>
> Being a network operator, I'm all in favor of interoperability and operational aspects. However, I don't see this applicable to a generic protocol extension. I'd rather see this in applicability statements.
>
>   > Could we have multiple identical sub-TLVs? Ex: Color
>   
> [Bruno] Excellent question...
> RFC5512 did not cover this point, nor draft-ietf-idr-tunnel-encaps... None of the Sub-TLV defined in this document need more than one instance. Limitation to a single instance could be specified during the definition of the "Tunnel Encapsulation Capabilities" in section 4, which would impose such restriction for future Sub-TLV. Or for each Sub-TLV in sections 5. The former seems an easier path, while the latter more extensible. Given the example of RFC 7770 / 4970, I think I would propose the latter: i.e. allowing the advertisement of multiple instance of a Sub-TLV, but disallowing it for all Sub-TLV defined in this draft.
> However, I'd welcome any other opinion. I'm definitely open to follow the easier path.
>   
>   >
>   > ----------------------------------------------------------------------
>   > COMMENT:
>   > ----------------------------------------------------------------------
>   >
>   > - Sometimes you use "Encapsulation Capability TLV" (section 3), sometimes "The
>   > Tunnel Encapsulation Type Sub-TLV" I guess that: OLD:
>   >
>   >  The Tunnel Encapsulation Type Sub-TLV is structured as follows:
>   >
>   >        0                   1                   2                   3
>   >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   >       |    Tunnel Type (2 Octets)     |        Length (2 Octets)      |
>   >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   >       |                                                               |
>   >       |                            Sub-TLVs                           |
>   >       |                                                               |
>   >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   >
>   > NEW:
>   >  The Encapsulation Capability TLV is structured as follows:
>   >
>   >        0                   1                   2                   3
>   >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   >       |    Tunnel Type (2 Octets)     |        Length (2 Octets)      |
>   >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   >       |                                                               |
>   >       |                            Sub-TLVs                           |
>   >       |                                                               |
>   >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   
> [Bruno] You are right that names are not consistently used. We had try to have names be aligned both with the BGP encapsulation draft and OSPF RI/TLV names, but finally, that seem difficult. Given that the IDR document is still a draft and its names could change, I think we will favor more independent names.
> Text changed to
> NEW:
>
>        The Tunnel Sub-TLV is structured as follows:
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |    Tunnel Type (2 Octets)     |        Length (2 Octets)      |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                                                               |
>     |               Tunnel Parameter Sub-TLVs                      |
>     |                                                               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>   > In section 7.1, should it be?
>   > OLD:
>   >     Value   TLV Name                                  Reference
>   >        -----   ------------------------------------   -------------
>   >        TBD1    Tunnel Capabilities                    This document
>   >
>   > NEW:
>   >     Value   TLV Name                                  Reference
>   >        -----   ------------------------------------   -------------
>   >        TBD1    Encapsulation Capabilities             This document
>   >
>   > OR:
>   >     Value   TLV Name                                  Reference
>   >        -----   ------------------------------------   -------------
>   >        TBD1    Tunnel Encapsulation Capabilities      This document
>
>
> [Bruno] Changed to
> NEW:
> TBD1    Tunnel Encapsulations      This document
>
>
>   > - Then there is a discrepancy between Sub-TLVs and Value in the related text
>   
> [Bruno] Agreed.
>   
>   >        0                   1                   2                   3
>   >        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   >       |    Tunnel Type (2 Octets)     |        Length (2 Octets)      |
>   >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   >       |                                                               |
>   >       |                            Sub-TLVs                           |
>   >       |                                                               |
>   >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   >
>   > Proposal: Sub-TLVs should be replaced by "Tunnel Encapsulation Attribute
>   > Sub-TLVs", and the following text updated:
>   >
>   >   Value (variable): Zero or more Tunnel Encapsulation Attribute Sub-
>   >       TLVs as defined in Section 5.
>   
> [Bruno] As the names change, changed to
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |    Tunnel Type (2 Octets)     |        Length (2 Octets)      |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                                                               |
>     |               Tunnel Parameter Sub-TLVs                      |
>     |                                                               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> [...]
>
> Value (variable): Zero or more Tunnel Parameter
>            Sub-TLVs as defined in .
>
>
>   > - Then, reading section 5, I see yet another name: "OSPF Tunnel Encapsulation
>   > Attribute Sub-TLVs" Section 7.2.
>   
> [Bruno] That one was the name of the _IANA registry_ , not the name of the Sub-TLVs. I believe adding "OSPF" is useful as IDR and IS-IS would have a different registry. However, I'm open to different instructions.
>   
>   > You should re-read the document to be consistent with your naming convention,
>   > in the text and in the IANA sections.
>    
> [Bruno] Yes. Sorry for this. Names had changed. I've re-read the document.
>
> Many thanks for the review.
> Regards,
> --Bruno
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>


From nobody Sat Sep 23 09:15:00 2017
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 C4F92132351; Sat, 23 Sep 2017 09:14:59 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benoit Claise 
To: "The IESG" 
Cc: draft-ietf-ospf-encapsulation-cap@ietf.org, Acee Lindem ,  ospf-chairs@ietf.org, acee@cisco.com, ospf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.62.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150618329975.22373.7980843209616890448.idtracker@ietfa.amsl.com>
Date: Sat, 23 Sep 2017 09:14:59 -0700
Archived-At: 
Subject: [OSPF] Benoit Claise's No Objection on draft-ietf-ospf-encapsulation-cap-08: (with COMMENT)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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 Sep 2017 16:15:00 -0000

Benoit Claise has entered the following ballot position for
draft-ietf-ospf-encapsulation-cap-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Trusting the group, doc. shepherd and responsible AD that the right things will happen.



From nobody Tue Sep 26 08:23:37 2017
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 AB2E913423A; Tue, 26 Sep 2017 08:23:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level: 
X-Spam-Status: No, score=-2.438 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCB5hUohlZdH; Tue, 26 Sep 2017 08:23:26 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFA9B134293; Tue, 26 Sep 2017 08:23:25 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id q124so9139798wmb.0; Tue, 26 Sep 2017 08:23:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=wRQmCNlchC48r/H6w9ucWpWgp/dELGQDbK+eLdqMxiE=; b=izxBsepVRnX0Z/kJfy9ODHDa18bh22GcrFJ1i0CCEC9lF6R/uTePYP6n6w8tHVNIW/ CHM8yA4jkqKcaz2d5WphYtgcMkZC5ZRkh1BG8d5z7ag3BldVrc+4P/sIeY5mHdc3sI8o gd4lxfQVlIRJR+X4eDwEVx0+t8aFN9zTILijnoHaWKdzq6X4hLSnfkoSR1SqNB98Syab 6ezUSu+2sv3OFoIbmdwQhFuyTc4q//hVkATIPKwsfEmV7OrWrhBFwyTMy+alKDoronrz S+dwan8OfA7PcgNc3pkgixmQyPRoPt1wuJJMU/1a8/iZts1mGaEnGHLdnWq6nGt10wp8 gM2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wRQmCNlchC48r/H6w9ucWpWgp/dELGQDbK+eLdqMxiE=; b=I3qlPZCB1A2H5adQKTjYTLtbbLJ5yqLhTmQanmwDxVGAtUWOYdxpLWgQ6JvwLD8X5i qIYECOUobyOA4mDDNUFziMvn/icnMufS7/OqJC8uJyK9wo+LRrQlnZFRmUDaaKkO8G2e aamZyQYsTExrRCM5CKNt53Q3EUVrjKqICD/BDytErQ5t5RFqR9yXl/sc417uLcW03Fbw dRsGwKCsz8E64XvfKMwG9KCmHjTT4HgjCzMDUGMR0lqaBL8B1/64u9qLrdFtiEZV0mc0 5lwoIiweIAKmDCu4aW9LlwySrqhyFwg3HHNy4nboetOOJc5xR+Tu2bnYouYdyzCxkzLc ScDQ==
X-Gm-Message-State: AHPjjUgfAPdH9Yb+IaC2OGLSyvP3GnRoVT05UhQVenKDySqGHqSlnFTr VraajJfPvlu9dCeDpt4jCGUVajUw3ssmnGzOucNJEA==
X-Google-Smtp-Source: AOwi7QD9tTYoYWkdMePSqStpXvXVjRkvzA0lP4cXVe2dxC6SG7ruSnQxhEaTefcH40ugI/zmgvqpHzoXZxkbKi9C1Pg=
X-Received: by 10.80.207.134 with SMTP id h6mr18196404edk.55.1506439404417; Tue, 26 Sep 2017 08:23:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.140.187 with HTTP; Tue, 26 Sep 2017 08:22:44 -0700 (PDT)
From: Tony Przygienda 
Date: Tue, 26 Sep 2017 08:22:44 -0700
Message-ID: 
To: bier-chairs@ietf.org, ospf@ietf.org
Content-Type: multipart/alternative; boundary="089e0822048c9377c1055a19416d"
Archived-At: 
Subject: [OSPF] Document Shepherd for OSPF BIER draft ...
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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, 26 Sep 2017 15:23:28 -0000

--089e0822048c9377c1055a19416d
Content-Type: text/plain; charset="UTF-8"

Ladies & Gentlemen, we still look for OSPF BIER document shepherd towards
IESG. It's important, doc is ready, you will be helped and it's a good
possibility to meet/work with the upstairs crowd a bit ...

Takers ?  please ping bier-chairs@ietf.org then ...

thanks

-- tony

--089e0822048c9377c1055a19416d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Ladies &  Gentlemen, we still look for OSPF BIER docum=
ent shepherd towards IESG. It's important, doc is ready, you will be he=
lped and it's a good possibility to meet/work with the upstairs crowd a=
 bit ...=C2=A0

Takers ? =C2=A0please ping bier-chairs@ietf.org=C2=A0then ...=C2=A0

thanks=C2=A0

-- tony=C2=A0


--089e0822048c9377c1055a19416d--


From nobody Tue Sep 26 08:30:02 2017
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 0A3EF134213; Tue, 26 Sep 2017 08:29:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3YOTGa_rNIC; Tue, 26 Sep 2017 08:29:54 -0700 (PDT)
Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::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 2B33C126BF3; Tue, 26 Sep 2017 08:29:54 -0700 (PDT)
Received: by mail-wr0-x236.google.com with SMTP id c23so13565660wrg.9; Tue, 26 Sep 2017 08:29:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UYg1zxS+ge4CNz53cAVWugyz247r61okOMAlH/T54Z0=; b=V85DBOifltp+eiF55pM+nhq7XYymVzcyk4cjamjMpeR9L6eVW/BoLDrrr66FZLII8W d7cIXPTHQ/rENndseDqRveKa1wBh0XTFvLk9lLl3cmurNIaSnozXqe5p0GSX+cirnM52 KOHBpByfnqvMyJ0Bxf8BVSJwyI58z4tzU2CSE6Co1R2jm+3qcOlCEgVdOtRc/r8OBRCd Q8sI6e08LM9AyJF53DmPngfAyNW0T/66tZx4OMCXPFkpYlQ8SYb9BN/MbAKu65Gk/2PW qrj7xgYM8NKmVA4287088JyZq/n2mBJAV8KAitPSeeGmOildcsm20cWX/6plrSGvaOrs axMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UYg1zxS+ge4CNz53cAVWugyz247r61okOMAlH/T54Z0=; b=CEE5vJN5+vCSHoXeQJTf5V38CCstUDOLJ11MMP7yqiZqFMCGW7jRQ4SDZyt5iZU93X WbsMaPDMkOU8kpV/ucz3GAvbRiBLjIL6I8qCjkkMixmpEQEAtC8RlTFuOAe8kl/VE/Mg /uXkg4z3TJC6X8WEZ1/ejQZ8aDsbaAEnslyFJ5HRk4MdVzJb3YmOxo4m4M96hIw37w0r +Mw7gKzC5L1yp3AmmEn4sJeLEc8B7ieH5SGMLZkATpvr4HAvPp7gADUymKsDTaQ9zlai jQs+0ryQp+lscZs24jSYNfgFH7pJCmDVxOOvDwai/m2fVizjYZsKIzyrdJmZd2nJfePF /NHA==
X-Gm-Message-State: AHPjjUi4LOKHm4DM1lmoD6k5yJ5lcuBIXbe6dbrRag1Yw4soO+bwWCav V1SpPYYPNXDpCxkLuyF6oE7CfiuR3+B04ljBzAA=
X-Google-Smtp-Source: AOwi7QAGu2jLg0uQvVdO4Mb2q/8EatFauyJ50uttfIup0qkHrGEjuGVYkM1puzO6R0+7nWA92jsqllc8gPCdopBAtr8=
X-Received: by 10.223.136.43 with SMTP id d40mr8695611wrd.121.1506439792386; Tue, 26 Sep 2017 08:29:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.136.153 with HTTP; Tue, 26 Sep 2017 08:29:51 -0700 (PDT)
In-Reply-To: 
References: 
From: Alia Atlas 
Date: Tue, 26 Sep 2017 11:29:51 -0400
Message-ID: 
To: Tony Przygienda 
Cc: "bier@ietf.org" , OSPF List 
Content-Type: multipart/alternative; boundary="001a11491596b369ed055a1958d1"
Archived-At: 
Subject: Re: [OSPF] Document Shepherd for OSPF BIER draft ...
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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, 26 Sep 2017 15:29:56 -0000

--001a11491596b369ed055a1958d1
Content-Type: text/plain; charset="UTF-8"

I'd like to see this draft progressed in Oct.  I need the shepherd's report
for next week to make that happen.

It's a quick read :-)

Regards,
Alia

On Tue, Sep 26, 2017 at 11:22 AM, Tony Przygienda 
wrote:

> Ladies & Gentlemen, we still look for OSPF BIER document shepherd towards
> IESG. It's important, doc is ready, you will be helped and it's a good
> possibility to meet/work with the upstairs crowd a bit ...
>
> Takers ?  please ping bier-chairs@ietf.org then ...
>
> thanks
>
> -- tony
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>
>

--001a11491596b369ed055a1958d1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I'd like to see this draft progressed in Oct.=C2=A0 I =
need the shepherd's report
for next week to make that happen.
=


It's a quick read :-)

Rega=
rds,
Alia

On Tue, Sep 26, 2017 at 11:22 AM, Tony Przygienda <tonys=
ietf@gmail.com> wrote:
Ladies &  Gentlemen, we still look for OSPF BIER document =
shepherd towards IESG. It's important, doc is ready, you will be helped=
 and it's a good possibility to meet/work with the upstairs crowd a bit=
 ...=C2=A0

Takers ? =C2=A0please ping bier-chairs@ietf.org=C2=A0then =
...=C2=A0

thanks=C2=A0

-- tony=C2=A0


_______________________________________________

OSPF mailing list

OSPF@ietf.org

https://www.ietf.org/mailman/listinfo/ospf





--001a11491596b369ed055a1958d1--


From nobody Tue Sep 26 15:12:54 2017
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 08BA9134493; Tue, 26 Sep 2017 15:12:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oeGdqmkf8Z8; Tue, 26 Sep 2017 15:12:46 -0700 (PDT)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7737413306F; Tue, 26 Sep 2017 15:12:43 -0700 (PDT)
Received: by mail-wr0-x233.google.com with SMTP id v109so14340597wrc.1; Tue, 26 Sep 2017 15:12:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=qmNBJm37wpV1KH/tV82QQ0o7fM2qACvHaXrugeNJ9uQ=; b=lX9vGpgD2sScSx5r7CtJSEZUjYgBvZxublgieQYac1qPNKdb7yF64O4VaHI6i+uFH/ CxpvOX+C6cBkDLBt9qbxcGwX3KExtWpBVufSj6qlhz6ZgSBsr9yffv/6VZqQMrr/GmUR MwKiuImTKGPMsux1GvOIrXU50rzbROYRWhbsNFE0HdOk3w8EppXt748oaZSigeRwxHzZ tP6mGN93zeGW/66YemDF3RGB6wQ4Dd5mXgVnN9yQ6cmGVfZtYJm+NvG50EpbCJKEuRS6 AIGmBj9jwuFPMJHFvdkhOWFEngVRHwmR7eAffhDb1iqJqzWkPoUVd4HAsyoVORk402fk IVkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qmNBJm37wpV1KH/tV82QQ0o7fM2qACvHaXrugeNJ9uQ=; b=NougQza+WsyUnOzc1YCDXkry+cLBy+EY2Yx6cV22RY9biY6EmOP111FqHboijphgtH r0obUFAPqJYq4NenGIG/egfpp8pDsWQj4gsfAOdOS5MjFkxX+NhXb25Ra2uCnQsGkKH7 ccM46fIHee0BZdgq/n8Czlx07E1drlTJTWodHavuXCvCTL2sfjNqhe5oCXuXEoFDdwvG VgizzS29lNbXyRic+khFFjeADgmtXidkUlRRW7YgWdn2hKTK2D80X36PgF+Y9YK2oZ3P DO0VkH+6RmGGDTL6OgGOvl2wEJ0UnQGn+xTIQw8WaRlpDRIpNvRggTHNsLeDd6vVtO9g Fu/g==
X-Gm-Message-State: AHPjjUi0RDVw7yLkX+GmMtei5LU8G0HIjiuCUUo9hOKp9B3tONRq65wk I1ou4MW3YHsdTWzg13P9L/7pFronvl6MURBoL4UjJI59
X-Google-Smtp-Source: AOwi7QCKi2oqWHl6Uy3Akjw5GmYATICMWpCXTQWWTQQcW46uPFVoEpXbELECfZ0bhRKinyJV3ErVR30Mpr+svoefYCo=
X-Received: by 10.223.136.43 with SMTP id d40mr9412913wrd.121.1506463961521; Tue, 26 Sep 2017 15:12:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.136.153 with HTTP; Tue, 26 Sep 2017 15:12:41 -0700 (PDT)
From: Alia Atlas 
Date: Tue, 26 Sep 2017 18:12:41 -0400
Message-ID: 
To: "bier@ietf.org" , OSPF List ,  draft-ietf-bier-ospf-bier-extensions@ietf.org
Content-Type: multipart/alternative; boundary="001a114915964b220b055a1ef919"
Archived-At: 
Subject: [OSPF] early AD review of draft-ietf-bier-ospf-bier-extensions-07
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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, 26 Sep 2017 22:12:48 -0000

--001a114915964b220b055a1ef919
Content-Type: text/plain; charset="UTF-8"

I have done an early AD review of draft-ietf-bier-ospf-bier-extensions-07
in preparation for the publication request.

First, I would like to thank the many authors for their work on this draft.
Given that there are currently 7 authors listed, I'd recommend appointing a
few editors or otherwise reducing down to 5 or fewer. Of course, I am also
willing to consider extraordinary circumstances where the shepherd can
explain to me privately the deep technical contribution made by each author.

I do see a number of major issues.

Major Issues:

1)  RFC7684 is just for OSPFv2.  How is the information carried for OSPFv3?
We need a mechanism that works for IPv6 also.

2) In Sec 2.1, the Length is defined as variable and the figure includes
additional sub-TLVs. Please clarify in the text what other sub-TLVs can be
carried & how the length is calculated (yes, same as always - but clarity
helps with interoperability).

3) Sec 2.2 "The size of the label range is determined by the number of Set
      Identifiers (SI) (section 1 of [I-D.ietf-bier-architecture]) that
      are used in the network.  Each SI maps to a single label in the
      label range.  The first label is for SI=0, the second label is for
      SI=1, etc.:

This implies that there is no way to indicate only a label for SI=1 or a
range for SI=1 to 3. That seems unfortunate and assumes that the BFR-ids
are always allocated from SI=0 up.   Is there a reason not to use some of
the reserved bits to indicate the starting SI value?

4) Sec 2.3: The Tree type is a 1 octet value - that doesn't appear to have
any IANA allocation or meaning clearly indicated - beyond the parenthetical
that 0=SPF.  Please fix this.

5) Sec 2.5: This section could benefit greatly from a diagram - showing the
advertising router for a prefix, the ABR, and what is then flooded for the
BIER MPLS Sub-TLV for the new areas.

Minor:

4) Sec 2.3: "Label Range Base: A 3 octet field, where the 20 rightmost
bits represent the first label in the label range."  What about the top 4
bits?  Are they Must Be Zero (MBZ)?  How about making that explicit?  Are
they potential future flags?/

Thanks,
Alia

--001a114915964b220b055a1ef919
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I have done an early AD review of draft-ietf-bier-osp=
f-bier-extensions-07 in preparation for the publication request.
=

First, I would like to thank the many authors for their work=
 on this draft. Given that there are currently 7 authors listed, I'd re=
commend appointing a few editors or otherwise reducing down to 5 or fewer. =
Of course, I am also willing to consider extraordinary circumstances where =
the shepherd can explain to me privately the deep technical contribution ma=
de by each author.

I do see a number of major issu=
es.

Major Issues:

1)=C2=A0 RFC7684 i=
s just for OSPFv2.=C2=A0 How is the information carried for OSPFv3? We need=
 a mechanism that works for IPv6 also.

2) In Sec 2=
.1, the Length is defined as variable and the figure includes additional su=
b-TLVs. Please clarify in the text what other sub-TLVs can be carried &=
 how the length is calculated (yes, same as always - but clarity helps with=
 interoperability).

3) Sec 2.2=C2=A0"The size=
 of the label range is determined by the number of Set
=C2=A0 =C2=A0 =C2=
=A0 Identifiers (SI) (section 1 of [I-D.ietf-bier-architecture]) that
=
=C2=A0 =C2=A0 =C2=A0 are used in the network.=C2=A0 Each SI maps to a singl=
e label in the
=C2=A0 =C2=A0 =C2=A0 label range.=C2=A0 The first label i=
s for SI=3D0, the second label is for
=C2=A0 =C2=A0 =C2=A0 SI=3D1, etc.:=


This implies that there is no way to indicate onl=
y a label for SI=3D1 or a range for SI=3D1 to 3. That seems unfortunate and=
 assumes that the BFR-ids are always allocated from SI=3D0 up.=C2=A0 =C2=A0=
Is there a reason not to use some of the reserved bits to indicate the star=
ting SI value?

4) Sec 2.3: The Tree type is a 1 oc=
tet value - that doesn't appear to have any IANA allocation or meaning =
clearly indicated - beyond the parenthetical that 0=3DSPF.=C2=A0 Please fix=
 this.

5) Sec 2.5: This section could benefit grea=
tly from a diagram - showing the advertising router for a prefix, the ABR, =
and what is then flooded for the BIER MPLS Sub-TLV for the new areas.=C2=A0=
=C2=A0

Minor:=C2=A0

4=
) Sec 2.3:=C2=A0"Label Range Base: A 3 octet field, where the 20 right=
most bits=C2=A0represent the first label in the label range."=C2=A0 Wh=
at about the top 4 bits?=C2=A0 Are they Must Be Zero (MBZ)?=C2=A0 How about=
 making that explicit?=C2=A0 Are they potential future flags?/
Thanks,
Alia


--001a114915964b220b055a1ef919--


From nobody Tue Sep 26 19:45:16 2017
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 5CBD513292A; Tue, 26 Sep 2017 19:45:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-p74Kxz4I5I; Tue, 26 Sep 2017 19:45:13 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0100.outbound.protection.outlook.com [104.47.0.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1381320D8; Tue, 26 Sep 2017 19:45:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=44vwI0LtyAh2U/UBnJFQsyLBx0vHAbYPHd9CGR+3H5Q=; b=JxZoxgX0R+VTNiJ8aun2NJgkgaCA32vsE1FVLXyZFRNhgTdtlrGuQ0RUGawc6djwvmFp1HpofT7ZHmzU7ICM0gvtyMaq7wbZ7a2V3VDae8lAx+ca++nFILorhr2DliUj7T++mt74ODUjYG/GWN8lInwrOyQBuZcfPVt7IvwwA+M=
Received: from HE1PR0701MB2058.eurprd07.prod.outlook.com (10.167.190.10) by HE1PR0701MB2058.eurprd07.prod.outlook.com (10.167.190.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Wed, 27 Sep 2017 02:45:09 +0000
Received: from HE1PR0701MB2058.eurprd07.prod.outlook.com ([fe80::81f3:e045:73c4:c010]) by HE1PR0701MB2058.eurprd07.prod.outlook.com ([fe80::81f3:e045:73c4:c010%13]) with mapi id 15.20.0077.016; Wed, 27 Sep 2017 02:45:09 +0000
From: "Dolganow, Andrew (Nokia - SG/Singapore)" 
To: Alia Atlas , "bier@ietf.org" , OSPF List , "draft-ietf-bier-ospf-bier-extensions@ietf.org" 
Thread-Topic: early AD review of draft-ietf-bier-ospf-bier-extensions-07
Thread-Index: AQHTNxSYkAzJ/FzSk0G2urbLqAlQYqLIjTSA
Date: Wed, 27 Sep 2017 02:45:09 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.21.0.170409
x-originating-ip: [135.245.121.30]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2058; 6:UmDIiYLD8UFFASn9gLI77UvMtXZTlnWSaEn35vjijPVx+3H/ekCqJnC6k0zYeuh8FPqR3eeZ5sImSVu2fNS6k0q113vO6o8TaI2SA6225ZwDqjXwSKLJZlsTVOIX+BDh5iF8mtyJH+UHSVGLUBQooVpbigL2XPNTcno1SIDUaspAEBW760pO4O+QOb/iCV4fTA7NRI20Lhs5temCK0hOQ0PfuzU3UMs7UH9Ut9m4b4UTy0HIsEwr6d7IgkZeLvvP6Ur+ZzLkxOWBuw8jBmh0dnf6s4I9yXH0PvL0TdO9LJA5siekV9TveIKKR/1bn0B/QUVRMqgh+XiIaotvn6Pw2w==; 5:qOwtwgj9SfR2ezZNXCZrbtTHlaJg8U+8dtpYTxX11Magw5lGpxNuPyCyuLiyRYvOS0z4a6eODDJc7MgSYWybRVUO1wJc9gOiCU8epocUvgoc1c8QeMjKAi6QcoXEBnunYNkVW8xUEqk3bfTnAxIV1Q==; 24:0dhNtMXFU+Pk1g3UjsSq5DSEJaEGEw5fkXlhGVVcsArF1a8bn2sPHqxLSxY6Z1EGMY1jAGR6BoIWaU+C0kGKtSTTyRMPGkB6/ec/H37V+CQ=; 7:Vt9Mk0SoqXYfDafx5oOAveCBg0wTvS9RzNw6UcycCbfPxZUF16zUef+/LfjAdC9jdONyvgTLozRjNdVZSq0pcT2wBGoEEMv3qUyWxQeHL9if1aGLjx+N0YZV6GNHOzWXcx+SpGyUzvcuLTWnNd0r91RXtseXNOpwbsMgwbwLocOaGwu9kbpHyoybkkqYjxmpG8QK/2r+FZTKL4oYVBoDyQUM7bZttHDPHeSHBpx8suY=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 416c3488-ba17-4088-6874-08d50551c4c9
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:HE1PR0701MB2058; 
x-ms-traffictypediagnostic: HE1PR0701MB2058:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.dolganow@nokia.com; 
x-exchange-antispam-report-test: UriScan:(138986009662008)(82608151540597)(95692535739014)(21748063052155); 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123555025)(20161123564025)(20161123558100)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB2058; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB2058; 
x-forefront-prvs: 04433051BF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(377454003)(199003)(189002)(81166006)(81156014)(6116002)(97736004)(5250100002)(83716003)(189998001)(39060400002)(68736007)(5660300001)(2950100002)(6436002)(76176999)(50986999)(6506006)(25786009)(54356999)(6486002)(2501003)(86362001)(2900100001)(101416001)(229853002)(82746002)(105586002)(106356001)(53936002)(6246003)(54896002)(6512007)(478600001)(36756003)(6306002)(53546010)(3660700001)(2906002)(8676002)(3280700002)(8936002)(99286003)(33656002)(83506001)(66066001)(14454004)(58126008)(316002)(102836003)(7736002)(3846002)(230783001)(110136005); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2058; H:HE1PR0701MB2058.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_B116980532884E91872F9C151F72DCF7nokiacom_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2017 02:45:09.4035 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2058
Archived-At: 
Subject: Re: [OSPF] early AD review of draft-ietf-bier-ospf-bier-extensions-07
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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 Sep 2017 02:45:15 -0000

--_000_B116980532884E91872F9C151F72DCF7nokiacom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QWxpYSwNCg0KVGhhbmtzLCBzbyBxdWljayBjb21tZW50czoNCg0KRnJvbTogQWxpYSBBdGxhcyA8
YWthdGxhc0BnbWFpbC5jb20+DQpEYXRlOiBXZWRuZXNkYXksIFNlcHRlbWJlciAyNywgMjAxNyBh
dCA2OjEyIEFNDQpUbzogImJpZXJAaWV0Zi5vcmciIDxiaWVyQGlldGYub3JnPiwgT1NQRiBMaXN0
IDxvc3BmQGlldGYub3JnPiwgImRyYWZ0LWlldGYtYmllci1vc3BmLWJpZXItZXh0ZW5zaW9uc0Bp
ZXRmLm9yZyIgPGRyYWZ0LWlldGYtYmllci1vc3BmLWJpZXItZXh0ZW5zaW9uc0BpZXRmLm9yZz4N
ClN1YmplY3Q6IGVhcmx5IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWJpZXItb3NwZi1iaWVyLWV4
dGVuc2lvbnMtMDcNClJlc2VudC1Gcm9tOiA8YWxpYXMtYm91bmNlc0BpZXRmLm9yZz4NClJlc2Vu
dC1UbzogUGV0ZXIgUHNlbmFrIDxwcHNlbmFrQGNpc2NvLmNvbT4sIDxuYWlrdW1hckBjaXNjby5j
b20+LCAiKEljZSkgSUpzYnJhbmQgV2lqbmFuZHMiIDxpY2VAY2lzY28uY29tPiwgQW5kcmV3IERv
bGdhbm93IDxhbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tPiwgPHByekBqdW5pcGVyLm5ldD4sIEpl
ZmZyZXkgWmhhbmcgPHp6aGFuZ0BqdW5pcGVyLm5ldD4sIDxhbGRyaW4uaWV0ZkBnbWFpbC5jb20+
DQpSZXNlbnQtRGF0ZTogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMjcsIDIwMTcgYXQgNjoxMiBBTQ0K
DQpJIGhhdmUgZG9uZSBhbiBlYXJseSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1iaWVyLW9zcGYt
Ymllci1leHRlbnNpb25zLTA3IGluIHByZXBhcmF0aW9uIGZvciB0aGUgcHVibGljYXRpb24gcmVx
dWVzdC4NCg0KRmlyc3QsIEkgd291bGQgbGlrZSB0byB0aGFuayB0aGUgbWFueSBhdXRob3JzIGZv
ciB0aGVpciB3b3JrIG9uIHRoaXMgZHJhZnQuIEdpdmVuIHRoYXQgdGhlcmUgYXJlIGN1cnJlbnRs
eSA3IGF1dGhvcnMgbGlzdGVkLCBJJ2QgcmVjb21tZW5kIGFwcG9pbnRpbmcgYSBmZXcgZWRpdG9y
cyBvciBvdGhlcndpc2UgcmVkdWNpbmcgZG93biB0byA1IG9yIGZld2VyLiBPZiBjb3Vyc2UsIEkg
YW0gYWxzbyB3aWxsaW5nIHRvIGNvbnNpZGVyIGV4dHJhb3JkaW5hcnkgY2lyY3Vtc3RhbmNlcyB3
aGVyZSB0aGUgc2hlcGhlcmQgY2FuIGV4cGxhaW4gdG8gbWUgcHJpdmF0ZWx5IHRoZSBkZWVwIHRl
Y2huaWNhbCBjb250cmlidXRpb24gbWFkZSBieSBlYWNoIGF1dGhvci4NCg0KSSBkbyBzZWUgYSBu
dW1iZXIgb2YgbWFqb3IgaXNzdWVzLg0KDQpNYWpvciBJc3N1ZXM6DQoNCg0KMSkgICAgICBSRkM3
Njg0IGlzIGp1c3QgZm9yIE9TUEZ2Mi4gIEhvdyBpcyB0aGUgaW5mb3JtYXRpb24gY2FycmllZCBm
b3IgT1NQRnYzPyBXZSBuZWVkIGEgbWVjaGFuaXNtIHRoYXQgd29ya3MgZm9yIElQdjYgYWxzby4N
CmFkPiBhZ3JlZSDigJMgdGhlIHdheSB0aGUgZHJhZnQgaXMgd3JpdHRlbiBpcyB2MiBvbmx5LiAg
bmVlZCB0byBhZGRyZXNzIHRoYXQuDQoNCjIpIEluIFNlYyAyLjEsIHRoZSBMZW5ndGggaXMgZGVm
aW5lZCBhcyB2YXJpYWJsZSBhbmQgdGhlIGZpZ3VyZSBpbmNsdWRlcyBhZGRpdGlvbmFsIHN1Yi1U
TFZzLiBQbGVhc2UgY2xhcmlmeSBpbiB0aGUgdGV4dCB3aGF0IG90aGVyIHN1Yi1UTFZzIGNhbiBi
ZSBjYXJyaWVkICYgaG93IHRoZSBsZW5ndGggaXMgY2FsY3VsYXRlZCAoeWVzLCBzYW1lIGFzIGFs
d2F5cyAtIGJ1dCBjbGFyaXR5IGhlbHBzIHdpdGggaW50ZXJvcGVyYWJpbGl0eSkuDQoNCmFkPiBS
ZXBlYXRpbmcgbWF5IG5vdCBiZSBjbGFyaWZ5aW5nLiBIb3cgYWJvdXQgd2Ugc2F5IOKAnFZhcmlh
YmxlLCBkZXBlbmRlbnQgb24gc3ViLVRMVnPigJ0gdG8gdXNlIFJGQzc2ODQtbGlrZSB0ZXh0IGZv
ciB0aGUgRXh0ZW5kZWQgcHJlZml4IFRMVi4gSSBjb3VsZCBub3QgZmluZCBhIHNpbmdsZSBleGFt
cGxlIHdoZXJlIHdlIGxpc3Qgd2hhdCBzdWItVExWcyBhcmUgY2FycmllZCBlaXRoZXIuIFRoYXQg
aXMgZG9uZSDigJMgYXMgaW4gdGhpcyBkcmFmdCDigJMgaW4gc3ViLVRMViBzZWN0aW9ucy4NCg0K
MykgU2VjIDIuMiAiVGhlIHNpemUgb2YgdGhlIGxhYmVsIHJhbmdlIGlzIGRldGVybWluZWQgYnkg
dGhlIG51bWJlciBvZiBTZXQNCiAgICAgIElkZW50aWZpZXJzIChTSSkgKHNlY3Rpb24gMSBvZiBb
SS1ELmlldGYtYmllci1hcmNoaXRlY3R1cmVdKSB0aGF0DQogICAgICBhcmUgdXNlZCBpbiB0aGUg
bmV0d29yay4gIEVhY2ggU0kgbWFwcyB0byBhIHNpbmdsZSBsYWJlbCBpbiB0aGUNCiAgICAgIGxh
YmVsIHJhbmdlLiAgVGhlIGZpcnN0IGxhYmVsIGlzIGZvciBTST0wLCB0aGUgc2Vjb25kIGxhYmVs
IGlzIGZvcg0KICAgICAgU0k9MSwgZXRjLjoNCg0KVGhpcyBpbXBsaWVzIHRoYXQgdGhlcmUgaXMg
bm8gd2F5IHRvIGluZGljYXRlIG9ubHkgYSBsYWJlbCBmb3IgU0k9MSBvciBhIHJhbmdlIGZvciBT
ST0xIHRvIDMuIFRoYXQgc2VlbXMgdW5mb3J0dW5hdGUgYW5kIGFzc3VtZXMgdGhhdCB0aGUgQkZS
LWlkcyBhcmUgYWx3YXlzIGFsbG9jYXRlZCBmcm9tIFNJPTAgdXAuICAgSXMgdGhlcmUgYSByZWFz
b24gbm90IHRvIHVzZSBzb21lIG9mIHRoZSByZXNlcnZlZCBiaXRzIHRvIGluZGljYXRlIHRoZSBz
dGFydGluZyBTSSB2YWx1ZT8NCg0KYWQ+c2V0LWlkZW50aWZpZXJzIHByb3ZpZGUgYSBzY2FsaW5n
IGZvciBCSUVSIHN1Yi1kb21haW5zIGJhc2VkIG9uIHN1cHBvcnRlZCBCaXRTdHJpbmcgbGVuZ3Ro
cy4gQ29uY2VwdHVhbGx5IHdlIGZvcndhcmQgaW4gc3ViLWRvbWFpbnMsIHRodXMgYWR2ZXJ0aXNp
bmcgbGFiZWwgcmFuZ2VzIGZvciBhIHN1Yi1kb21haW4gKGFzIGEgYmFzZSDigJx1bml04oCdIG9m
IGZvcndhcmRpbmcpIG1ha2VzIHNlbnNlLiBUaGUgZXh0cmEgbGV2ZWwgb2YgZ3JhbnVsYXJpdHkg
d291bGQgYnJlYWsgdGhhdCBzdWItZG9tYWluIGNvbnNpc3RlbmN5LiBTb21ldGltZXMganVzdCBi
ZWNhdXNlIHdlIGNvdWxkIHByb3ZpZGUgYSBoaWdoZXIgZ3JhbnVsYXJpdHkgSSBkbyBub3QgdGhp
bmsgd2Ugc2hvdWxkLiBUaGlzIHN1Yi1kb21haW4gZ3JhbnVsYXJpdHkgbWFrZXMgYWR2ZXJ0aXNp
bmcgYW5kIHByb2Nlc3Npbmcgc2ltcGxlci4NCg0KNCkgU2VjIDIuMzogVGhlIFRyZWUgdHlwZSBp
cyBhIDEgb2N0ZXQgdmFsdWUgLSB0aGF0IGRvZXNuJ3QgYXBwZWFyIHRvIGhhdmUgYW55IElBTkEg
YWxsb2NhdGlvbiBvciBtZWFuaW5nIGNsZWFybHkgaW5kaWNhdGVkIC0gYmV5b25kIHRoZSBwYXJl
bnRoZXRpY2FsIHRoYXQgMD1TUEYuICBQbGVhc2UgZml4IHRoaXMuDQoNCmFkPiBhZ3JlZSB0aGlz
IHdvdWxkIG5lZWQgdG8gYmUgZml4ZWQNCg0KNSkgU2VjIDIuNTogVGhpcyBzZWN0aW9uIGNvdWxk
IGJlbmVmaXQgZ3JlYXRseSBmcm9tIGEgZGlhZ3JhbSAtIHNob3dpbmcgdGhlIGFkdmVydGlzaW5n
IHJvdXRlciBmb3IgYSBwcmVmaXgsIHRoZSBBQlIsIGFuZCB3aGF0IGlzIHRoZW4gZmxvb2RlZCBm
b3IgdGhlIEJJRVIgTVBMUyBTdWItVExWIGZvciB0aGUgbmV3IGFyZWFzLg0KDQphZD4gYWdhaW4g
d2l0aG91dCBhcmd1aW5nIGFnYWluc3QgZGlhZ3JhbSwgSSBjYW4gb25seSBzYXkgdGhpcyB0ZXh0
IGlzIGNvbnNpc3RlbnQgd2l0aCBvdGhlciBzaW1pbGFyIHBhcmFncmFwaHMgaW4gb3RoZXIgZHJh
ZnRzL1JGQ3MgKGxpa2UgNzY4NCkuIEkgY291bGQgbm90IGZpbmQgYW4gZXhhbXBsZSB3aGVuIHdl
IGRvIHB1dCBhIGRpYWdyYW0gKGJ1dCBvbmx5IGxvb2tlZCBhdCBhYm91dCA1IE9TUEYgUkZDcy4N
Cg0KTWlub3I6DQoNCjQpIFNlYyAyLjM6ICJMYWJlbCBSYW5nZSBCYXNlOiBBIDMgb2N0ZXQgZmll
bGQsIHdoZXJlIHRoZSAyMCByaWdodG1vc3QgYml0cyByZXByZXNlbnQgdGhlIGZpcnN0IGxhYmVs
IGluIHRoZSBsYWJlbCByYW5nZS4iICBXaGF0IGFib3V0IHRoZSB0b3AgNCBiaXRzPyAgQXJlIHRo
ZXkgTXVzdCBCZSBaZXJvIChNQlopPyAgSG93IGFib3V0IG1ha2luZyB0aGF0IGV4cGxpY2l0PyAg
QXJlIHRoZXkgcG90ZW50aWFsIGZ1dHVyZSBmbGFncz8vDQoNCmFkPiBJIGFzc3VtZSB5b3UgbWVh
biAyLjIgc2VjdGlvbiwgeWVzIE1CWi4NCg0KQW5kcmV3DQoNCg0KDQpUaGFua3MsDQoNCkFsaWEN
Cg==

--_000_B116980532884E91872F9C151F72DCF7nokiacom_
Content-Type: text/html; charset="utf-8"
Content-ID: <85E39E14DCB3424B99BD3FACFCAB102B@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlz
dFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJ
bWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4w
cHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m
YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxl
LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5k
b3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1z
by1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVh
bDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250
LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw
dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlv
bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3Qg
bDANCgl7bXNvLWxpc3QtaWQ6MTcyODgwMjAwMzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt
c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4OTAxNzMyNzYgMTg4MjYxMjA2MCA2NzY5ODcxMyA2NzY5
ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcx
NTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZl
bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJn
aW4tbGVmdDo1NC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDIN
Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z
dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0
OjkwLjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjEyNi4w
cHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwt
dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2lu
LWxlZnQ6MTYyLjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6
MTk4LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjIzNC4w
cHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt
dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2lu
LWxlZnQ6MjcwLjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6
MzA2LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjM0Mi4w
cHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVs
DQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2Nv
bG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4N
CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5BbGlhLDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OkNhbGlicmkiPlRoYW5rcywgc28gcXVpY2sgY29tbWVudHM6PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh
ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29s
b3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxp
YnJpO2NvbG9yOmJsYWNrIj5BbGlhIEF0bGFzICZsdDtha2F0bGFzQGdtYWlsLmNvbSZndDs8YnI+
DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBTZXB0ZW1iZXIgMjcsIDIwMTcgYXQgNjoxMiBBTTxi
cj4NCjxiPlRvOiA8L2I+JnF1b3Q7YmllckBpZXRmLm9yZyZxdW90OyAmbHQ7YmllckBpZXRmLm9y
ZyZndDssIE9TUEYgTGlzdCAmbHQ7b3NwZkBpZXRmLm9yZyZndDssICZxdW90O2RyYWZ0LWlldGYt
Ymllci1vc3BmLWJpZXItZXh0ZW5zaW9uc0BpZXRmLm9yZyZxdW90OyAmbHQ7ZHJhZnQtaWV0Zi1i
aWVyLW9zcGYtYmllci1leHRlbnNpb25zQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwv
Yj5lYXJseSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1iaWVyLW9zcGYtYmllci1leHRlbnNpb25z
LTA3PGJyPg0KPGI+UmVzZW50LUZyb206IDwvYj4mbHQ7YWxpYXMtYm91bmNlc0BpZXRmLm9yZyZn
dDs8YnI+DQo8Yj5SZXNlbnQtVG86IDwvYj5QZXRlciBQc2VuYWsgJmx0O3Bwc2VuYWtAY2lzY28u
Y29tJmd0OywgJmx0O25haWt1bWFyQGNpc2NvLmNvbSZndDssICZxdW90OyhJY2UpIElKc2JyYW5k
IFdpam5hbmRzJnF1b3Q7ICZsdDtpY2VAY2lzY28uY29tJmd0OywgQW5kcmV3IERvbGdhbm93ICZs
dDthbmRyZXcuZG9sZ2Fub3dAbm9raWEuY29tJmd0OywgJmx0O3ByekBqdW5pcGVyLm5ldCZndDss
IEplZmZyZXkgWmhhbmcgJmx0O3p6aGFuZ0BqdW5pcGVyLm5ldCZndDssICZsdDthbGRyaW4uaWV0
ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+UmVzZW50LURhdGU6IDwvYj5XZWRuZXNkYXksIFNlcHRl
bWJlciAyNywgMjAxNyBhdCA2OjEyIEFNPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SSBoYXZlIGRvbmUgYW4gZWFybHkgQUQg
cmV2aWV3IG9mIGRyYWZ0LWlldGYtYmllci1vc3BmLWJpZXItZXh0ZW5zaW9ucy0wNyBpbiBwcmVw
YXJhdGlvbiBmb3IgdGhlIHB1YmxpY2F0aW9uIHJlcXVlc3QuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkZpcnN0LCBJIHdvdWxkIGxpa2UgdG8gdGhh
bmsgdGhlIG1hbnkgYXV0aG9ycyBmb3IgdGhlaXIgd29yayBvbiB0aGlzIGRyYWZ0LiBHaXZlbiB0
aGF0IHRoZXJlIGFyZSBjdXJyZW50bHkgNyBhdXRob3JzIGxpc3RlZCwgSSdkIHJlY29tbWVuZCBh
cHBvaW50aW5nIGEgZmV3IGVkaXRvcnMgb3Igb3RoZXJ3aXNlIHJlZHVjaW5nIGRvd24gdG8gNSBv
ciBmZXdlci4gT2YNCiBjb3Vyc2UsIEkgYW0gYWxzbyB3aWxsaW5nIHRvIGNvbnNpZGVyIGV4dHJh
b3JkaW5hcnkgY2lyY3Vtc3RhbmNlcyB3aGVyZSB0aGUgc2hlcGhlcmQgY2FuIGV4cGxhaW4gdG8g
bWUgcHJpdmF0ZWx5IHRoZSBkZWVwIHRlY2huaWNhbCBjb250cmlidXRpb24gbWFkZSBieSBlYWNo
IGF1dGhvci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw
dCI+SSBkbyBzZWUgYSBudW1iZXIgb2YgbWFqb3IgaXNzdWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw
dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5NYWpvciBJc3N1ZXM6PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w
cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy
YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp
c3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1z
by1saXN0Oklnbm9yZSI+MSk8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg
Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh
bj48IVtlbmRpZl0+UkZDNzY4NCBpcyBqdXN0IGZvciBPU1BGdjIuJm5ic3A7IEhvdyBpcyB0aGUg
aW5mb3JtYXRpb24gY2FycmllZCBmb3IgT1NQRnYzPyBXZSBuZWVkIGEgbWVjaGFuaXNtIHRoYXQg
d29ya3MgZm9yIElQdjYgYWxzby48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPmFkJmd0OyBhZ3JlZSDigJMgdGhlIHdheSB0aGUg
ZHJhZnQgaXMgd3JpdHRlbiBpcyB2MiBvbmx5LiZuYnNwOyBuZWVkIHRvIGFkZHJlc3MgdGhhdC48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+MikgSW4g
U2VjIDIuMSwgdGhlIExlbmd0aCBpcyBkZWZpbmVkIGFzIHZhcmlhYmxlIGFuZCB0aGUgZmlndXJl
IGluY2x1ZGVzIGFkZGl0aW9uYWwgc3ViLVRMVnMuIFBsZWFzZSBjbGFyaWZ5IGluIHRoZSB0ZXh0
IHdoYXQgb3RoZXIgc3ViLVRMVnMgY2FuIGJlIGNhcnJpZWQgJmFtcDsgaG93IHRoZSBsZW5ndGgg
aXMgY2FsY3VsYXRlZCAoeWVzLCBzYW1lIGFzIGFsd2F5cyAtDQogYnV0IGNsYXJpdHkgaGVscHMg
d2l0aCBpbnRlcm9wZXJhYmlsaXR5KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+YWQmZ3Q7IFJlcGVh
dGluZyBtYXkgbm90IGJlIGNsYXJpZnlpbmcuIEhvdyBhYm91dCB3ZSBzYXkg4oCcVmFyaWFibGUs
IGRlcGVuZGVudCBvbiBzdWItVExWc+KAnSB0byB1c2UgUkZDNzY4NC1saWtlIHRleHQgZm9yIHRo
ZSBFeHRlbmRlZCBwcmVmaXggVExWLiBJIGNvdWxkIG5vdCBmaW5kIGEgc2luZ2xlIGV4YW1wbGUg
d2hlcmUgd2UgbGlzdCB3aGF0IHN1Yi1UTFZzIGFyZSBjYXJyaWVkDQogZWl0aGVyLiBUaGF0IGlz
IGRvbmUg4oCTIGFzIGluIHRoaXMgZHJhZnQg4oCTIGluIHN1Yi1UTFYgc2VjdGlvbnMuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjMpIFNlYyAyLjIm
bmJzcDsmcXVvdDtUaGUgc2l6ZSBvZiB0aGUgbGFiZWwgcmFuZ2UgaXMgZGV0ZXJtaW5lZCBieSB0
aGUgbnVtYmVyIG9mIFNldDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IElkZW50aWZpZXJzIChT
SSkgKHNlY3Rpb24gMSBvZiBbSS1ELmlldGYtYmllci1hcmNoaXRlY3R1cmVdKSB0aGF0PGJyPg0K
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgYXJlIHVzZWQgaW4gdGhlIG5ldHdvcmsuJm5ic3A7IEVhY2gg
U0kgbWFwcyB0byBhIHNpbmdsZSBsYWJlbCBpbiB0aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw
OyBsYWJlbCByYW5nZS4mbmJzcDsgVGhlIGZpcnN0IGxhYmVsIGlzIGZvciBTST0wLCB0aGUgc2Vj
b25kIGxhYmVsIGlzIGZvcjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IFNJPTEsIGV0Yy46PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoaXMgaW1w
bGllcyB0aGF0IHRoZXJlIGlzIG5vIHdheSB0byBpbmRpY2F0ZSBvbmx5IGEgbGFiZWwgZm9yIFNJ
PTEgb3IgYSByYW5nZSBmb3IgU0k9MSB0byAzLiBUaGF0IHNlZW1zIHVuZm9ydHVuYXRlIGFuZCBh
c3N1bWVzIHRoYXQgdGhlIEJGUi1pZHMgYXJlIGFsd2F5cyBhbGxvY2F0ZWQgZnJvbSBTST0wIHVw
LiZuYnNwOyAmbmJzcDtJcyB0aGVyZSBhIHJlYXNvbiBub3QgdG8gdXNlDQogc29tZSBvZiB0aGUg
cmVzZXJ2ZWQgYml0cyB0byBpbmRpY2F0ZSB0aGUgc3RhcnRpbmcgU0kgdmFsdWU/PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t
bGVmdDozNi4wcHQiPmFkJmd0O3NldC1pZGVudGlmaWVycyBwcm92aWRlIGEgc2NhbGluZyBmb3Ig
QklFUiBzdWItZG9tYWlucyBiYXNlZCBvbiBzdXBwb3J0ZWQgQml0U3RyaW5nIGxlbmd0aHMuIENv
bmNlcHR1YWxseSB3ZSBmb3J3YXJkIGluIHN1Yi1kb21haW5zLCB0aHVzIGFkdmVydGlzaW5nIGxh
YmVsIHJhbmdlcyBmb3IgYSBzdWItZG9tYWluIChhcyBhIGJhc2Ug4oCcdW5pdOKAnSBvZiBmb3J3
YXJkaW5nKQ0KIG1ha2VzIHNlbnNlLiBUaGUgZXh0cmEgbGV2ZWwgb2YgZ3JhbnVsYXJpdHkgd291
bGQgYnJlYWsgdGhhdCBzdWItZG9tYWluIGNvbnNpc3RlbmN5LiBTb21ldGltZXMganVzdCBiZWNh
dXNlIHdlIGNvdWxkIHByb3ZpZGUgYSBoaWdoZXIgZ3JhbnVsYXJpdHkgSSBkbyBub3QgdGhpbmsg
d2Ugc2hvdWxkLiBUaGlzIHN1Yi1kb21haW4gZ3JhbnVsYXJpdHkgbWFrZXMgYWR2ZXJ0aXNpbmcg
YW5kIHByb2Nlc3Npbmcgc2ltcGxlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1sZWZ0OjM2LjBwdCI+NCkgU2VjIDIuMzogVGhlIFRyZWUgdHlwZSBpcyBhIDEgb2N0ZXQg
dmFsdWUgLSB0aGF0IGRvZXNuJ3QgYXBwZWFyIHRvIGhhdmUgYW55IElBTkEgYWxsb2NhdGlvbiBv
ciBtZWFuaW5nIGNsZWFybHkgaW5kaWNhdGVkIC0gYmV5b25kIHRoZSBwYXJlbnRoZXRpY2FsIHRo
YXQgMD1TUEYuJm5ic3A7IFBsZWFzZSBmaXggdGhpcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+YWQm
Z3Q7IGFncmVlIHRoaXMgd291bGQgbmVlZCB0byBiZSBmaXhlZDxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw
dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij41KSBTZWMgMi41OiBUaGlzIHNlY3Rpb24g
Y291bGQgYmVuZWZpdCBncmVhdGx5IGZyb20gYSBkaWFncmFtIC0gc2hvd2luZyB0aGUgYWR2ZXJ0
aXNpbmcgcm91dGVyIGZvciBhIHByZWZpeCwgdGhlIEFCUiwgYW5kIHdoYXQgaXMgdGhlbiBmbG9v
ZGVkIGZvciB0aGUgQklFUiBNUExTIFN1Yi1UTFYgZm9yIHRoZSBuZXcgYXJlYXMuJm5ic3A7Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPmFkJmd0OyBhZ2FpbiB3aXRo
b3V0IGFyZ3VpbmcgYWdhaW5zdCBkaWFncmFtLCBJIGNhbiBvbmx5IHNheSB0aGlzIHRleHQgaXMg
Y29uc2lzdGVudCB3aXRoIG90aGVyIHNpbWlsYXIgcGFyYWdyYXBocyBpbiBvdGhlciBkcmFmdHMv
UkZDcyAobGlrZSA3Njg0KS4gSSBjb3VsZCBub3QgZmluZCBhbiBleGFtcGxlIHdoZW4gd2UgZG8g
cHV0IGEgZGlhZ3JhbSAoYnV0IG9ubHkNCiBsb29rZWQgYXQgYWJvdXQgNSBPU1BGIFJGQ3MuPG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu
MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk1pbm9yOiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s
ZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij40KSBTZWMgMi4zOiZuYnNw
OyZxdW90O0xhYmVsIFJhbmdlIEJhc2U6IEEgMyBvY3RldCBmaWVsZCwgd2hlcmUgdGhlIDIwIHJp
Z2h0bW9zdCBiaXRzJm5ic3A7cmVwcmVzZW50IHRoZSBmaXJzdCBsYWJlbCBpbiB0aGUgbGFiZWwg
cmFuZ2UuJnF1b3Q7Jm5ic3A7IFdoYXQgYWJvdXQgdGhlIHRvcCA0IGJpdHM/Jm5ic3A7IEFyZSB0
aGV5IE11c3QgQmUgWmVybyAoTUJaKT8mbmJzcDsgSG93IGFib3V0IG1ha2luZyB0aGF0IGV4cGxp
Y2l0PyZuYnNwOw0KIEFyZSB0aGV5IHBvdGVudGlhbCBmdXR1cmUgZmxhZ3M/LzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s
ZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5hZCZndDsgSSBhc3N1bWUgeW91IG1lYW4gMi4yIHNl
Y3Rpb24sIHllcyBNQlouPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkFuZHJldzxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6
MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhhbmtz
LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0
OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5BbGlhPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_B116980532884E91872F9C151F72DCF7nokiacom_--


From nobody Wed Sep 27 17:13:55 2017
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 15AED1351D8; Wed, 27 Sep 2017 17:13:48 -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 jeAaX5PEX7pk; Wed, 27 Sep 2017 17:13:45 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0081A1351D0; Wed, 27 Sep 2017 17:13:44 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id r136so336527wmf.2; Wed, 27 Sep 2017 17:13:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z1d561IDQUFSs/re6bKt/miDrNH8WFDDOlGdo/7jHOo=; b=icPW8Szkt8dX0dvWExKO0JExPpHdKp08w4devL3Ti/oDx3bpF47C2W/J+zUhlJsiRJ 4e+YDukpCZdAQfO1cC60tj4bzQKb9bmgDrByrCDjS9780hsTYgTHEdLFZGmsc/T4Z7Ic kp8p7iOQ5tsDJHqTL9btmTHa2oGsZZh99CeUkmO6gIL4McAULr+Xfyurw6SpKj1pNoo0 MSfUBWfKIGYgqg/hN3eZj0kPAO8SflxWSWD3hRiQN2bQXAaP/KzrGH7rA6SmFAPbtHvO pSWKoG4UBC+EvryI0YzHpbUbQR478sTEFEVKs6G8u5nWklgLKvOZofM1VmB+o+qPUEfl /a2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Z1d561IDQUFSs/re6bKt/miDrNH8WFDDOlGdo/7jHOo=; b=ViD8zvpiz4fH+18a8n7+wdLoCh8Xa+r7uecnuxo9LpnInbeFqCq53vXZJTWf6JkFDV RWKs3QMdSzJ5E7pbYoLT2Nk719+cf5GmolhIDmbSF/IqzXZLqo2l/WN6JI037hV5m50S BMbHnryN3ANptxYDicNVshTgEgE+o5yP6naxIHlc1RYwgVYYjOFhQi7SvSAPA1xascUy CNYjE/D1vr7lNNf67DADO+pt5utPXLPaHAct0FTf7qeOO+GWaklyWYh8Vp1Qv4VbocRi MyytSMM0FVas8Md7sn3+EhGFW8eJLeOCfoXRPtboYLFXstGp2hvWBoszqiDHmflznR/5 CsuQ==
X-Gm-Message-State: AHPjjUgVUzymayz0wWb4bT7kL3FUCXxI9DCQ9Isr3rbKQNyAFpTy7RDx vd9P76xkUkzmLkCbo8uJIqbrgI/d6vsVTVZYh2Y=
X-Google-Smtp-Source: AOwi7QAf+B0TY+qdF0aff8mi6AyOkVDRCHrKdWbg1k0SePjlKt3rFMDZPC9vpCpEN61Qfaa3SqI5rGQ1kK0amwUbF9k=
X-Received: by 10.80.136.85 with SMTP id c21mr3663156edc.171.1506557623432; Wed, 27 Sep 2017 17:13:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.140.187 with HTTP; Wed, 27 Sep 2017 17:13:03 -0700 (PDT)
In-Reply-To: 
References:  
From: Tony Przygienda 
Date: Wed, 27 Sep 2017 17:13:03 -0700
Message-ID: 
To: "Dolganow, Andrew (Nokia - SG/Singapore)" 
Cc: Alia Atlas , "bier@ietf.org" , OSPF List , "draft-ietf-bier-ospf-bier-extensions@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045c118efa7c0a055a34c771"
Archived-At: 
Subject: Re: [OSPF] [Bier] early AD review of draft-ietf-bier-ospf-bier-extensions-07
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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 Sep 2017 00:13:48 -0000

--f403045c118efa7c0a055a34c771
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

inlined into inlines ;-)


On Tue, Sep 26, 2017 at 7:45 PM, Dolganow, Andrew (Nokia - SG/Singapore) <
andrew.dolganow@nokia.com> wrote:

> Alia,
>
>
>
> Thanks, so quick comments:
>
>
>
> *From: *Alia Atlas 
> *Date: *Wednesday, September 27, 2017 at 6:12 AM
> *To: *"bier@ietf.org" , OSPF List , "
> draft-ietf-bier-ospf-bier-extensions@ietf.org"  extensions@ietf.org>
> *Subject: *early AD review of draft-ietf-bier-ospf-bier-extensions-07
> *Resent-From: *
> *Resent-To: *Peter Psenak , ,
> "(Ice) IJsbrand Wijnands" , Andrew Dolganow <
> andrew.dolganow@nokia.com>, , Jeffrey Zhang <
> zzhang@juniper.net>, 
> *Resent-Date: *Wednesday, September 27, 2017 at 6:12 AM
>
>
>
> I have done an early AD review of draft-ietf-bier-ospf-bier-extensions-07
> in preparation for the publication request.
>
>
>
> First, I would like to thank the many authors for their work on this
> draft. Given that there are currently 7 authors listed, I'd recommend
> appointing a few editors or otherwise reducing down to 5 or fewer. Of
> course, I am also willing to consider extraordinary circumstances where t=
he
> shepherd can explain to me privately the deep technical contribution made
> by each author.
>
>
>
> I do see a number of major issues.
>
>
>
> Major Issues:
>
>
>
> 1)      RFC7684 is just for OSPFv2.  How is the information carried for
> OSPFv3? We need a mechanism that works for IPv6 also.
>
> ad> agree =E2=80=93 the way the draft is written is v2 only.  need to add=
ress that.
>
>
>

+1


> 2) In Sec 2.1, the Length is defined as variable and the figure includes
> additional sub-TLVs. Please clarify in the text what other sub-TLVs can b=
e
> carried & how the length is calculated (yes, same as always - but clarity
> helps with interoperability).
>
>
>
> ad> Repeating may not be clarifying. How about we say =E2=80=9CVariable, =
dependent
> on sub-TLVs=E2=80=9D to use RFC7684-like text for the Extended prefix TLV=
. I could
> not find a single example where we list what sub-TLVs are carried either.
> That is done =E2=80=93 as in this draft =E2=80=93 in sub-TLV sections.
>

+1 RFC7684-like text is good. Allegedly it's tad underspecified (unless you
know other drafts), i.e. it should mention whether TLV header is included
in the length or not. That's the most common implementation disagreement


>
>
> 3) Sec 2.2 "The size of the label range is determined by the number of Se=
t
>       Identifiers (SI) (section 1 of [I-D.ietf-bier-architecture]) that
>       are used in the network.  Each SI maps to a single label in the
>       label range.  The first label is for SI=3D0, the second label is fo=
r
>       SI=3D1, etc.:
>
>
>
> This implies that there is no way to indicate only a label for SI=3D1 or =
a
> range for SI=3D1 to 3. That seems unfortunate and assumes that the BFR-id=
s
> are always allocated from SI=3D0 up.   Is there a reason not to use some =
of
> the reserved bits to indicate the starting SI value?
>
>
>
> ad>set-identifiers provide a scaling for BIER sub-domains based on
> supported BitString lengths. Conceptually we forward in sub-domains, thus
> advertising label ranges for a sub-domain (as a base =E2=80=9Cunit=E2=80=
=9D of forwarding)
> makes sense. The extra level of granularity would break that sub-domain
> consistency. Sometimes just because we could provide a higher granularity=
 I
> do not think we should. This sub-domain granularity makes advertising and
> processing simpler.
>
>
>

Yes, to keep sub-TLVs compact and computation simple (missing labels would
create complex error criteria) we agreed to base @ SI=3D0 always and requir=
e
that all BFER-ids are covered by the range.


> 4) Sec 2.3: The Tree type is a 1 octet value - that doesn't appear to hav=
e
> any IANA allocation or meaning clearly indicated - beyond the parenthetic=
al
> that 0=3DSPF.  Please fix this.
>
>
>
> ad> agree this would need to be fixed
>

yes, parallel to ISIS draft. Right now missing or value =3D 0 is SPF. Needs
in IANA section a registry request


>
>
> 5) Sec 2.5: This section could benefit greatly from a diagram - showing
> the advertising router for a prefix, the ABR, and what is then flooded fo=
r
> the BIER MPLS Sub-TLV for the new areas.
>
>
>
> ad> again without arguing against diagram, I can only say this text is
> consistent with other similar paragraphs in other drafts/RFCs (like 7684)=
.
> I could not find an example when we do put a diagram (but only looked at
> about 5 OSPF RFCs.
>
>
>

I don't consider it particularly necessary given it's basically RFC7684
behavior and easily understood by anyone who implemented type-3, type-1
behavior in OSPF. We don't summarize or play any tricks (given the draft
mandates /32 and N bit).


> Minor:
>
>
>
> 4) Sec 2.3: "Label Range Base: A 3 octet field, where the 20 rightmost
> bits represent the first label in the label range."  What about the top 4
> bits?  Are they Must Be Zero (MBZ)?  How about making that explicit?  Are
> they potential future flags?/
>
>
>
> ad> I assume you mean 2.2 section, yes MBZ.
>
>
>

yepp, needs adding

Ultimate observation: We should add that if the BML translation TLV is
present, it indicates that the node CAN translate between all BMLs it
advertised itself in SD and NOT all possible downstream BMLs. Important
clarification if we end up running multi-BML computations or a BFER has to
decide which BML to inject in a mix environ (doesn't look like we go there
but it's better be safe than sorry and it's a small addition making the
spec water-tighter).

Overall, stuff doesn't look like any major items popped up and too much
work overall. Given Les made noises to rev ISIS BIER towards start next
week I'm sure Peter as editor of OSPF BIER doesn't want to be bested
(nudge, nudge ;-P

--- tony

--f403045c118efa7c0a055a34c771
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


inlined into inlines ;-)


On Tue, Sep 26, 2017 at 7:45 PM, Dolganow,=
 Andrew (Nokia - SG/Singapore) <andrew.dolganow@nokia.com><=
/span> wrote:













A=
lia,


<=
u>=C2=A0


T=
hanks, so quick comments:


<=
u>=C2=A0




From:
Alia Atlas <<=
a href=3D"mailto:akatlas@gmail.com" target=3D"_blank">akatlas@gmail.com=
>

Date: Wednesday, September 27, 2017 at 6:12 AM

To: "bier@ie=
tf.org" <bie=
r@ietf.org>, OSPF List <ospf@ietf.org>, "draft-ietf-bier-ospf-bier-=
extensions@ietf.org" <draft-ietf-bier-ospf-bier-extensions@ietf.org>

Subject: early AD review of draft-ietf-bier-ospf-bier-extension=
s-07

Resent-From: <alias-bounces@ietf.org>

Resent-To: Peter Psenak <ppsenak@cisco.com>, <naikumar@cisco.com>, "(Ice) IJsbrand=
 Wijnands" <ice@=
cisco.com>, Andrew Dolganow <andrew.dolganow@nokia.com>, <prz@juniper.net>, Jeff=
rey Zhang <zzhan=
g@juniper.net>, <aldrin.ietf@gmail.com>

Resent-Date: Wednesday, September 27, 2017 at 6:12 AM<=
/span>






=C2=A0








I have done an early AD r=
eview of draft-ietf-bier-ospf-bier-extensions-07 in preparation for th=
e publication request.






=C2=A0






First, I would like to th=
ank the many authors for their work on this draft. Given that there are cur=
rently 7 authors listed, I'd recommend appointing a few editors or othe=
rwise reducing down to 5 or fewer. Of
 course, I am also willing to consider extraordinary circumstances where th=
e shepherd can explain to me privately the deep technical contribution made=
 by each author.






=C2=A0






I do see a number of majo=
r issues.






=C2=A0






Major Issues:




=C2=A0





1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
RFC7684 is just for OSPFv2.=C2=A0 How is the informati=
on carried for OSPFv3? We need a mechanism that works for IPv6 also.=



ad> agree =E2=
=80=93 the way the draft is written is v2 only.=C2=A0 need to address that.=







=C2=A0

+1
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa=
dding-left:1ex">






2) In Sec 2.1, the Length=
 is defined as variable and the figure includes additional sub-TLVs. Please=
 clarify in the text what other sub-TLVs can be carried & how the lengt=
h is calculated (yes, same as always -
 but clarity helps with interoperability).


=C2=A0


ad> Repeating m=
ay not be clarifying. How about we say =E2=80=9CVariable, dependent on sub-=
TLVs=E2=80=9D to use RFC7684-like text for the Extended prefix TLV. I could=
 not find a single example where we list what sub-TLVs are carried
 either. That is done =E2=80=93 as in this draft =E2=80=93 in sub-TLV secti=
ons.

+1 RFC7684=
-like text is good. Allegedly it's tad underspecified (unless you know =
other drafts), i.e. it should mention whether TLV header is included in the=
 length or not. That's the most common implementation disagreement
=C2=A0






=C2=A0






3) Sec 2.2=C2=A0"The=
 size of the label range is determined by the number of Set

=C2=A0 =C2=A0 =C2=A0 Identifiers (SI) (section 1 of [I-D.ietf-bier-architec=
ture]) that

=C2=A0 =C2=A0 =C2=A0 are used in the network.=C2=A0 Each SI maps to a singl=
e label in the

=C2=A0 =C2=A0 =C2=A0 label range.=C2=A0 The first label is for SI=3D0, the =
second label is for

=C2=A0 =C2=A0 =C2=A0 SI=3D1, etc.:






=C2=A0






This implies that there i=
s no way to indicate only a label for SI=3D1 or a range for SI=3D1 to 3. Th=
at seems unfortunate and assumes that the BFR-ids are always allocated from=
 SI=3D0 up.=C2=A0 =C2=A0Is there a reason not to use
 some of the reserved bits to indicate the starting SI value?=



=C2=A0


ad>set-identifi=
ers provide a scaling for BIER sub-domains based on supported BitString len=
gths. Conceptually we forward in sub-domains, thus advertising label ranges=
 for a sub-domain (as a base =E2=80=9Cunit=E2=80=9D of forwarding)
 makes sense. The extra level of granularity would break that sub-domain co=
nsistency. Sometimes just because we could provide a higher granularity I d=
o not think we should. This sub-domain granularity makes advertising and pr=
ocessing simpler.






=C2=A0

Yes, to keep sub-TLVs comp=
act and computation simple (missing labels would create complex error crite=
ria) we agreed to base @ SI=3D0 always and require that all BFER-ids are co=
vered by the range.
=C2=A0






4) Sec 2.3: The Tree type=
 is a 1 octet value - that doesn't appear to have any IANA allocation o=
r meaning clearly indicated - beyond the parenthetical that 0=3DSPF.=C2=A0 =
Please fix this.


=C2=A0


ad> agree this =
would need to be fixed

yes, parallel to ISIS draft. Right now missing or value =3D 0 is SP=
F. Needs in IANA section a registry request=C2=A0
=C2=A0






=C2=A0






5) Sec 2.5: This section =
could benefit greatly from a diagram - showing the advertising router for a=
 prefix, the ABR, and what is then flooded for the BIER MPLS Sub-TLV for th=
e new areas.=C2=A0=C2=A0






=C2=A0


ad> again without argu=
ing against diagram, I can only say this text is consistent with other simi=
lar paragraphs in other drafts/RFCs (like 7684). I could not find an exampl=
e when we do put a diagram (but only
 looked at about 5 OSPF RFCs.


=C2=A0

I don't consider it pa=
rticularly necessary given it's basically RFC7684 behavior and easily u=
nderstood by anyone who implemented type-3, type-1 behavior in OSPF. We don=
't summarize or play any tricks (given the draft mandates /32 and N bit=
).=C2=A0
=C2=A0






Minor:=C2=A0






=C2=A0






4) Sec 2.3:=C2=A0"La=
bel Range Base: A 3 octet field, where the 20 rightmost bits=C2=A0represent=
 the first label in the label range."=C2=A0 What about the top 4 bits?=
=C2=A0 Are they Must Be Zero (MBZ)?=C2=A0 How about making that explicit?=
=C2=A0
 Are they potential future flags?/






=C2=A0


ad> I assume you mean =
2.2 section, yes MBZ.


=C2=A0

yepp, needs adding=C2=A0

Ultimate observation: We should add that if the BML=
 translation TLV is present, it indicates that the node CAN translate betwe=
en all BMLs it advertised itself in SD and NOT all possible downstream BMLs=
. Important clarification if we end up running multi-BML computations or a =
BFER has to decide which BML to inject in a mix environ (doesn't look l=
ike we go there but it's better be safe than sorry and it's a small=
 addition making the spec water-tighter).=C2=A0

Ov=
erall, stuff doesn't look like any major items popped up and too much w=
ork overall. Given Les made noises to rev ISIS BIER towards start next week=
 I'm sure Peter as editor of OSPF BIER doesn't want to be bested (n=
udge, nudge ;-P=C2=A0

--- tony=C2=A0


--f403045c118efa7c0a055a34c771--


From nobody Fri Sep 29 07:20:07 2017
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 6E9DE133044; Fri, 29 Sep 2017 07:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 GRxPS0OYzZvd; Fri, 29 Sep 2017 07:20:03 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F5A9133039; Fri, 29 Sep 2017 07:20:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8761; q=dns/txt; s=iport; t=1506694802; x=1507904402; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=XtyzqPqhG8C6Y9fiMCNuo3KpVqpOAJDTXV5mjMiUbtc=; b=J9K005ott5irrzMvhX2stwwJGVA+WjEGrevcAoLUnf8KD0XvtdDvqQ5R RRfj09y1K5+EIM6rsxQ+sBJ8MyDXeRtKtllvhatDcdCb7rLK29HW3Zd1U ePqqxeg6OdlnyjNy+tNMpZyaZfy4JoGGBOWu3Ah3rBDMVV2GsoccFDkjR I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAAD8Vc5Z/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhS4ng3iKH3SQZJYrghIKhTsChG4YAQIBAQEBAQEBayiFGQEFIxV?= =?us-ascii?q?AARALDgQGAgIFFggDAgIJAwIBAgE0Aw4GDQEFAgEBii2nIoIVEotFAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR+BDoIfg1OBaoMohF0RgymCYAEEoSyUZIIUhW6DWiSHB5V?= =?us-ascii?q?OgTkfOIEOMiEIHRWFYxyBaT42hXeCQwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,452,1500940800"; d="scan'208";a="697637763"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Sep 2017 14:19:57 +0000
Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8TEJvOq010289; Fri, 29 Sep 2017 14:19:57 GMT
Message-ID: <59CE568C.3070508@cisco.com>
Date: Fri, 29 Sep 2017 16:19:56 +0200
From: Peter Psenak 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Alia Atlas 
CC: OSPF List , draft-ietf-ospf-segment-routing-extensions@ietf.org
References:  <5991C1C5.9060000@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [OSPF] AD review of draft-ietf-ospf-segment-routing-extensions-18
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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, 29 Sep 2017 14:20:05 -0000

Hi Alia,

a new version of th draft-ietf-spring-segment-routing-ldp-interop has 
been posted, where the PHP behavior for SIDs adverised by SRMS has been 
clarified.

thanks,
Peter


On 18/09/17 17:47 , Alia Atlas wrote:
> Hi Peter,
>
> On Mon, Aug 14, 2017 at 11:29 AM, Peter Psenak  > wrote:
>
>     Hi Alia,
>
>     thanks for comments, please see inline:
>
>     On 12/08/17 04:09 , Alia Atlas wrote:
>
>         As is customary, I have done another AD review
>         of draft-ietf-ospf-segment-routing-extensions-18. I do
>         appreciate the
>         improvements in the draft.
>
>         I do still see a few minor issues.  I would like to see a
>         revised draft
>         before IETF Last Call. I expect to progress this at an IESG telechat
>         with the primary spring documents, when Alvaro feels they are ready.
>
>
>         1) In Sec 3.1, "If the SR-Algorithm TLV appears in multiple Router
>              Information LSAs that have different flooding scopes, the SR-
>              Algorithm TLV in the Router Information LSA with the narrowest
>              flooding scope SHOULD be used.  "
>              Given that the area-scope is REQUIRED - shouldn't this also
>         prefer
>              the area-scope?  Is there future-proofing being done?
>
>
>     link-local scope here does not really make much sense, so the
>     assumption was that it's either area or AS-scope, in which case
>     area-scope has narrower flooding scope. I'll clarify that in the text.
>
>
>
>         2) In Sec 3.4: "For the purpose of the SRMS Preference TLV
>         advertisement, AS-scoped flooding is REQUIRED.  This
>              is because SRMS servers can be located in a different area then
>              consumers of the SRMS advertisements.  If the SRMS
>         advertisements
>              from the SRMS server are only used inside the SRMS server's
>         area,
>              area-scoped flooding may be used."
>
>         REQUIRED is like MUST - I think you mean "AS-scoped flooded
>         SHOULD be
>         used.... area-scoped flooding MAY be used."
>
>
>     will change to SHOULD.
>
>
>
>         3) In Sec 4. "The Segment Routing Mapping Server, which is
>         described in
>              [I-D.ietf-spring-segment-routing-ldp-interop], is an
>         example where we
>              need a single advertisement to advertise SIDs for multiple
>         prefixes
>              from a contiguous address range."
>
>         I've read through the vastly improved section (thank you)
>         in draft-ietf-spring-segment-routing-ldp-interop-08 and I don't
>         see any
>         explanation for why a contiguous address range is needed.
>
>         I can speculate that a primary purpose is to advertise SIDs for the
>         loopback addresses of routers that don't support SR - and those
>         loopback
>         addresses are likely to be allocated from a contiguous range
>         (though why
>         some wouldn't be supporting SR and cause gaps isn't clear).
>
>
>     range is an optimization similar to summarization. Instead of
>     advertising each individual prefix to SID mappings, we can advertise
>     single range with the starting SID. I referenced the
>     I-D.ietf-spring-segment-routing-ldp-interop, because SRMS is an
>     example where the range advertisements is clearly useful, although
>     it's not limited to to that case. One can use SRMS as a SID
>     provisioning tool.
>
>
>
>         4) Sec 5: In the end of Sec 4.2 in
>         draft-ietf-spring-segment-routing-ldp-interop-08, it says "Note: SR
>         mappings advertisements cannot set Penultimate Hop Popping.
>              In the previous example, P6 requires the presence of the
>         segment 103
>              such as to map it to the LDP label 1037.  For that reason,
>         the P flag
>              available in the Prefix-SID is not available in the
>         Remote-Binding
>              SID."
>         However, in this draft Sec 5 gives the following rules:
>
>         "As the Mapping Server does not specify the originator of a prefix
>         advertisement, it is not possible to determine PHP behavior
>         solely based
>         on the Mapping Server advertisement. However, PHP behavior SHOULD be
>         done in following cases: The Prefix is intra-area type and the
>         downstream neighbor is the originator of the prefix. The Prefix is
>         inter-area type and downstream neighbor is an ABR, which is
>         advertising
>         prefix reachability and is also generating the Extended Prefix
>         TLV with
>         the A-flag set for this prefix as described in section 2.1 of
>         [RFC7684].
>         The Prefix is external type and downstream neighbor is an ASBR,
>         which is
>         advertising prefix reachability and is also generating the Extended
>         Prefix TLV with the A-flag set for this prefix as described in
>         section
>         2.1 of [RFC7684].
>
>         These seem to be contradictory.
>
>
>     The text in draft-ietf-spring-segment-routing-ldp-interop-08 refers
>     to the fact that SRMS advertisements itself can not include PHP
>     signaling in the advertisement itself, like the regular SID
>     advertisement does, because SRMS is not the "owner" of the prefix.
>
>     The text in the draft-ietf-ospf-segment-routing-extensions-18
>     describes how the PHP can still be done for SIDs that come from the
>     SRMS adverisements, using additional information available to the
>     protocol - e.g. prefix owner.
>
>     I don't believe these contradict each other.
>
>
> I think this is the final issue to be resolved before I can put this
> into IETF Last Call.
>
> First, the OSPF document has to follow the architecture and behavior
> defined in the SPRING documents.
> This paragraph looks like a potential optimization that is not clearly
> articulated and directly contradicts the
> text in draft-ietf-spring-segment-routing-ldp-interop-08.
>
> The logic in the ldp-interop draft is so that the boundary router
> between segment-routing and LDP can do the mapping from segment-routing
> to LDP.
>
> In the paragraph above from the ospf draft, it is handling the edge case
> where the downstream neighbor originates the prefix, basically.  So -
> the signaling has no indication that PHP is desired but OSPF infers that
> it is based on topology and advertisements.
>
> The explanation for why this is correct behavior does need to exist -
> preferably in the ldp-interop draft - but simply having the unexplained
> rules in here will not make for good interoperability or
> comprehensibility of the segment-routing architecture.
>
> To be clear, I am fine with having the rules here - if the WG believes
> that they are desirable - but there must be an actual explanation as to
> why this works and doesn't need the top-level label mapping that
> ldp-interop refers to. I'd prefer to see that discussed in the
> ldp-interop, but if you think that the issue is IGP-specific, then I
> could see having it in this draft.
>
> While this may seem obvious to you as to why it is ok, this document and
> associated architecture needs to make sense and ensure interoperability
> for many other implementations where those developing are basing it on
> the standard.  For me, that means that if it isn't obvious to me after
> reading through all the related documents (as I have), then it is likely
> to not be obvious to others.
>
> Regards,
> Alia
>
>         5) In Sec 7.1, it says "Multiple Mapping Servers can advertise
>              Prefix-SIDs for the same prefix, in which case the same
>         Prefix-SID
>              MUST be advertised by all of them."
>
>         What is forcing this constraint?  Does it work if the Prefix-SID
>         is an
>         index into an
>         SRGB or SRLB that is not the same value globally?
>
>
>     yes, it does. The SID value for the single prefix MUST be unique
>     though, otherwise we get into the conflict resolution area, that is
>     covered by the draft-ietf-spring-conflict-resolution.
>
>         I don't see it
>         specified in Sec 7.2 of
>         draft-ietf-spring-segment-routing-ldp-interop-08?
>
>
>     SR architecture assumes unique mapping of a SID to a prefix. If that
>     is not followed, draft-ietf-spring-conflict-resolution comes into
>     picture.
>
>     thanks,
>     Peter
>
>
>
>
>         Regards,
>         Alia
>
>
>


From nobody Fri Sep 29 07:38:49 2017
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 370D1133064; Fri, 29 Sep 2017 07:38:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlWy9JjjkTer; Fri, 29 Sep 2017 07:38:44 -0700 (PDT)
Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::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 158A4132944; Fri, 29 Sep 2017 07:38:44 -0700 (PDT)
Received: by mail-wr0-x236.google.com with SMTP id y95so2441675wrb.4; Fri, 29 Sep 2017 07:38:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GCFX1+1FDu+jGp4KrOnLSkq6cz9IjWYdx7RysUXp2+E=; b=OorgpAbDG5Mr88jFMWaf/LHEMB2iK10R/vabz8sE0qmM7Xp4muN6oT1w5ie8etlDth AseYGvu5WAV9OfcQXn679sNEmgg/liq69oEZBRJMEs9qWQ4c1iVSchbH5tRPOnVB3Bwm XR9m9AsgiVYhSdtqLjAlUrUZSsekKRFj3GrLzlCbFygblLsFGxAjrOHJQw/Ihu/uMMJN Q7nqkY1+AmzwA2q7EsHiCmcAk9hXhq6NOnJmKFSNxDNBkw+nOmBJJxi5/pax7UE7Vx4t St/mWDDjSw5aO7TwN2LFvy2uj4TmVEnSezCjxe+utCEpkJdwkgFGwXl39z9y6jyvP54T EROw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GCFX1+1FDu+jGp4KrOnLSkq6cz9IjWYdx7RysUXp2+E=; b=JDbK9rdgFf7a6HEHClUSdMyeENkglBlWkNfYjTckGO+nNeCj2nD1y75Bw9hyZhNpKm BacIBkjmwWISKOpHvjb2QvCBfaYE6lpRCj/Fy2S4NsIqlBDPIGuwhV05VbBJLYempTYj uA+t95IBKs4CDTxfQp4E4P/uGItrDHmgmR1I3UuvuXwErtCj3x+ZngTVxtsNE39OHyFQ mUUtI9xui4CuKCTEXbHf/LYvdRbrvCv/nvqxUmB6D8QeP3WXKGTvkEb1w6pwywgUv9OY 0/0M8dJGnsx+f3ePFpTMGx9KM+ZVq+aExClgB8B8T+oy8r8BpAWuAiQeNepBmKltaRkO wLIA==
X-Gm-Message-State: AHPjjUidBCCUB/zCr00krBqvFZZDZ5HbhXp2dL20DpnSMDxfQNHmbKGM au1h0wtxHkVVs5OfEJqXLvPXJWeow3d71fHfJq3ENQ==
X-Google-Smtp-Source: AOwi7QBIL49bhZLimfQHGnkO6jA8TGM0+nj3v/7aUeQQjMfVfmrEvbKbjAixbPTwpTTHEkzuTGPoj/Ap/+zJZPzuciE=
X-Received: by 10.223.199.69 with SMTP id b5mr3947796wrh.270.1506695922346; Fri, 29 Sep 2017 07:38:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.154.132 with HTTP; Fri, 29 Sep 2017 07:38:41 -0700 (PDT)
In-Reply-To: <59CE568C.3070508@cisco.com>
References:  <5991C1C5.9060000@cisco.com>  <59CE568C.3070508@cisco.com>
From: Alia Atlas 
Date: Fri, 29 Sep 2017 10:38:41 -0400
Message-ID: 
To: Peter Psenak 
Cc: OSPF List , draft-ietf-ospf-segment-routing-extensions@ietf.org
Content-Type: multipart/alternative; boundary="089e08244c0c3c755e055a54fb87"
Archived-At: 
Subject: Re: [OSPF] AD review of draft-ietf-ospf-segment-routing-extensions-18
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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, 29 Sep 2017 14:38:47 -0000

--089e08244c0c3c755e055a54fb87
Content-Type: text/plain; charset="UTF-8"

Hi Peter,

Excellent  - thanks.
I'll get this into IETF Last Call.

Regards,
Alia

On Fri, Sep 29, 2017 at 10:19 AM, Peter Psenak  wrote:

> Hi Alia,
>
> a new version of th draft-ietf-spring-segment-routing-ldp-interop has
> been posted, where the PHP behavior for SIDs adverised by SRMS has been
> clarified.
>
> thanks,
> Peter
>
>
> On 18/09/17 17:47 , Alia Atlas wrote:
>
>> Hi Peter,
>>
>> On Mon, Aug 14, 2017 at 11:29 AM, Peter Psenak > > wrote:
>>
>>     Hi Alia,
>>
>>     thanks for comments, please see inline:
>>
>>     On 12/08/17 04:09 , Alia Atlas wrote:
>>
>>         As is customary, I have done another AD review
>>         of draft-ietf-ospf-segment-routing-extensions-18. I do
>>         appreciate the
>>         improvements in the draft.
>>
>>         I do still see a few minor issues.  I would like to see a
>>         revised draft
>>         before IETF Last Call. I expect to progress this at an IESG
>> telechat
>>         with the primary spring documents, when Alvaro feels they are
>> ready.
>>
>>
>>         1) In Sec 3.1, "If the SR-Algorithm TLV appears in multiple Router
>>              Information LSAs that have different flooding scopes, the SR-
>>              Algorithm TLV in the Router Information LSA with the
>> narrowest
>>              flooding scope SHOULD be used.  "
>>              Given that the area-scope is REQUIRED - shouldn't this also
>>         prefer
>>              the area-scope?  Is there future-proofing being done?
>>
>>
>>     link-local scope here does not really make much sense, so the
>>     assumption was that it's either area or AS-scope, in which case
>>     area-scope has narrower flooding scope. I'll clarify that in the text.
>>
>>
>>
>>         2) In Sec 3.4: "For the purpose of the SRMS Preference TLV
>>         advertisement, AS-scoped flooding is REQUIRED.  This
>>              is because SRMS servers can be located in a different area
>> then
>>              consumers of the SRMS advertisements.  If the SRMS
>>         advertisements
>>              from the SRMS server are only used inside the SRMS server's
>>         area,
>>              area-scoped flooding may be used."
>>
>>         REQUIRED is like MUST - I think you mean "AS-scoped flooded
>>         SHOULD be
>>         used.... area-scoped flooding MAY be used."
>>
>>
>>     will change to SHOULD.
>>
>>
>>
>>         3) In Sec 4. "The Segment Routing Mapping Server, which is
>>         described in
>>              [I-D.ietf-spring-segment-routing-ldp-interop], is an
>>         example where we
>>              need a single advertisement to advertise SIDs for multiple
>>         prefixes
>>              from a contiguous address range."
>>
>>         I've read through the vastly improved section (thank you)
>>         in draft-ietf-spring-segment-routing-ldp-interop-08 and I don't
>>         see any
>>         explanation for why a contiguous address range is needed.
>>
>>         I can speculate that a primary purpose is to advertise SIDs for
>> the
>>         loopback addresses of routers that don't support SR - and those
>>         loopback
>>         addresses are likely to be allocated from a contiguous range
>>         (though why
>>         some wouldn't be supporting SR and cause gaps isn't clear).
>>
>>
>>     range is an optimization similar to summarization. Instead of
>>     advertising each individual prefix to SID mappings, we can advertise
>>     single range with the starting SID. I referenced the
>>     I-D.ietf-spring-segment-routing-ldp-interop, because SRMS is an
>>     example where the range advertisements is clearly useful, although
>>     it's not limited to to that case. One can use SRMS as a SID
>>     provisioning tool.
>>
>>
>>
>>         4) Sec 5: In the end of Sec 4.2 in
>>         draft-ietf-spring-segment-routing-ldp-interop-08, it says "Note:
>> SR
>>         mappings advertisements cannot set Penultimate Hop Popping.
>>              In the previous example, P6 requires the presence of the
>>         segment 103
>>              such as to map it to the LDP label 1037.  For that reason,
>>         the P flag
>>              available in the Prefix-SID is not available in the
>>         Remote-Binding
>>              SID."
>>         However, in this draft Sec 5 gives the following rules:
>>
>>         "As the Mapping Server does not specify the originator of a prefix
>>         advertisement, it is not possible to determine PHP behavior
>>         solely based
>>         on the Mapping Server advertisement. However, PHP behavior SHOULD
>> be
>>         done in following cases: The Prefix is intra-area type and the
>>         downstream neighbor is the originator of the prefix. The Prefix is
>>         inter-area type and downstream neighbor is an ABR, which is
>>         advertising
>>         prefix reachability and is also generating the Extended Prefix
>>         TLV with
>>         the A-flag set for this prefix as described in section 2.1 of
>>         [RFC7684].
>>         The Prefix is external type and downstream neighbor is an ASBR,
>>         which is
>>         advertising prefix reachability and is also generating the
>> Extended
>>         Prefix TLV with the A-flag set for this prefix as described in
>>         section
>>         2.1 of [RFC7684].
>>
>>         These seem to be contradictory.
>>
>>
>>     The text in draft-ietf-spring-segment-routing-ldp-interop-08 refers
>>     to the fact that SRMS advertisements itself can not include PHP
>>     signaling in the advertisement itself, like the regular SID
>>     advertisement does, because SRMS is not the "owner" of the prefix.
>>
>>     The text in the draft-ietf-ospf-segment-routing-extensions-18
>>     describes how the PHP can still be done for SIDs that come from the
>>     SRMS adverisements, using additional information available to the
>>     protocol - e.g. prefix owner.
>>
>>     I don't believe these contradict each other.
>>
>>
>> I think this is the final issue to be resolved before I can put this
>> into IETF Last Call.
>>
>> First, the OSPF document has to follow the architecture and behavior
>> defined in the SPRING documents.
>> This paragraph looks like a potential optimization that is not clearly
>> articulated and directly contradicts the
>> text in draft-ietf-spring-segment-routing-ldp-interop-08.
>>
>> The logic in the ldp-interop draft is so that the boundary router
>> between segment-routing and LDP can do the mapping from segment-routing
>> to LDP.
>>
>> In the paragraph above from the ospf draft, it is handling the edge case
>> where the downstream neighbor originates the prefix, basically.  So -
>> the signaling has no indication that PHP is desired but OSPF infers that
>> it is based on topology and advertisements.
>>
>> The explanation for why this is correct behavior does need to exist -
>> preferably in the ldp-interop draft - but simply having the unexplained
>> rules in here will not make for good interoperability or
>> comprehensibility of the segment-routing architecture.
>>
>> To be clear, I am fine with having the rules here - if the WG believes
>> that they are desirable - but there must be an actual explanation as to
>> why this works and doesn't need the top-level label mapping that
>> ldp-interop refers to. I'd prefer to see that discussed in the
>> ldp-interop, but if you think that the issue is IGP-specific, then I
>> could see having it in this draft.
>>
>> While this may seem obvious to you as to why it is ok, this document and
>> associated architecture needs to make sense and ensure interoperability
>> for many other implementations where those developing are basing it on
>> the standard.  For me, that means that if it isn't obvious to me after
>> reading through all the related documents (as I have), then it is likely
>> to not be obvious to others.
>>
>> Regards,
>> Alia
>>
>>         5) In Sec 7.1, it says "Multiple Mapping Servers can advertise
>>              Prefix-SIDs for the same prefix, in which case the same
>>         Prefix-SID
>>              MUST be advertised by all of them."
>>
>>         What is forcing this constraint?  Does it work if the Prefix-SID
>>         is an
>>         index into an
>>         SRGB or SRLB that is not the same value globally?
>>
>>
>>     yes, it does. The SID value for the single prefix MUST be unique
>>     though, otherwise we get into the conflict resolution area, that is
>>     covered by the draft-ietf-spring-conflict-resolution.
>>
>>         I don't see it
>>         specified in Sec 7.2 of
>>         draft-ietf-spring-segment-routing-ldp-interop-08?
>>
>>
>>     SR architecture assumes unique mapping of a SID to a prefix. If that
>>     is not followed, draft-ietf-spring-conflict-resolution comes into
>>     picture.
>>
>>     thanks,
>>     Peter
>>
>>
>>
>>
>>         Regards,
>>         Alia
>>
>>
>>
>>
>

--089e08244c0c3c755e055a54fb87
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Peter,

Excellent=C2=A0 - thanks.
I'll get this into IETF Last Call.

Rega=
rds,
Alia

On Fri, Sep 29, 2017 at 10:19 AM, Peter Psenak <=
ppsenak@cisco.com> wrote:
Hi Alia,



a new version of th draft-ietf-spring-segment-routing-ldp-interop has =
been posted, where the PHP behavior for SIDs adverised by SRMS has been cla=
rified.



thanks,

Peter





On 18/09/17 17:47 , Alia Atlas wrote:



Hi Peter,



On Mon, Aug 14, 2017 at 11:29 AM, Peter Psenak <ppsenak@cisco.com

<mailto:ppsenak@c=
isco.com>> wrote:



=C2=A0 =C2=A0 Hi Alia,



=C2=A0 =C2=A0 thanks for comments, please see inline:



=C2=A0 =C2=A0 On 12/08/17 04:09 , Alia Atlas wrote:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 As is customary, I have done another AD review<=
br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of draft-ietf-ospf-segment-routing-extensi=
ons-18. I do

=C2=A0 =C2=A0 =C2=A0 =C2=A0 appreciate the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 improvements in the draft.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 I do still see a few minor issues.=C2=A0 I woul=
d like to see a

=C2=A0 =C2=A0 =C2=A0 =C2=A0 revised draft

=C2=A0 =C2=A0 =C2=A0 =C2=A0 before IETF Last Call. I expect to progress thi=
s at an IESG telechat

=C2=A0 =C2=A0 =C2=A0 =C2=A0 with the primary spring documents, when Alvaro =
feels they are ready.





=C2=A0 =C2=A0 =C2=A0 =C2=A0 1) In Sec 3.1, "If the SR-Algorithm TLV ap=
pears in multiple Router

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Information LSAs that have =
different flooding scopes, the SR-

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Algorithm TLV in the Router=
 Information LSA with the narrowest

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0flooding scope SHOULD be us=
ed.=C2=A0 "

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Given that the area-scope i=
s REQUIRED - shouldn't this also

=C2=A0 =C2=A0 =C2=A0 =C2=A0 prefer

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the area-scope?=C2=A0 Is th=
ere future-proofing being done?





=C2=A0 =C2=A0 link-local scope here does not really make much sense, so the=


=C2=A0 =C2=A0 assumption was that it's either area or AS-scope, in whic=
h case

=C2=A0 =C2=A0 area-scope has narrower flooding scope. I'll clarify that=
 in the text.







=C2=A0 =C2=A0 =C2=A0 =C2=A0 2) In Sec 3.4: "For the purpose of the SRM=
S Preference TLV

=C2=A0 =C2=A0 =C2=A0 =C2=A0 advertisement, AS-scoped flooding is REQUIRED.=
=C2=A0 This

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is because SRMS servers can=
 be located in a different area then

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0consumers of the SRMS adver=
tisements.=C2=A0 If the SRMS

=C2=A0 =C2=A0 =C2=A0 =C2=A0 advertisements

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0from the SRMS server are on=
ly used inside the SRMS server's

=C2=A0 =C2=A0 =C2=A0 =C2=A0 area,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0area-scoped flooding may be=
 used."



=C2=A0 =C2=A0 =C2=A0 =C2=A0 REQUIRED is like MUST - I think you mean "=
AS-scoped flooded

=C2=A0 =C2=A0 =C2=A0 =C2=A0 SHOULD be

=C2=A0 =C2=A0 =C2=A0 =C2=A0 used.... area-scoped flooding MAY be used."=
;





=C2=A0 =C2=A0 will change to SHOULD.







=C2=A0 =C2=A0 =C2=A0 =C2=A0 3) In Sec 4. "The Segment Routing Mapping =
Server, which is

=C2=A0 =C2=A0 =C2=A0 =C2=A0 described in

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[I-D.ietf-spring-segment-ro=
uting-ldp-interop], is an

=C2=A0 =C2=A0 =C2=A0 =C2=A0 example where we

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0need a single advertisement=
 to advertise SIDs for multiple

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0from a contiguous address r=
ange."



=C2=A0 =C2=A0 =C2=A0 =C2=A0 I've read through the vastly improved secti=
on (thank you)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 in draft-ietf-spring-segment-routing-ldp-i=
nterop-08 and I don't

=C2=A0 =C2=A0 =C2=A0 =C2=A0 see any

=C2=A0 =C2=A0 =C2=A0 =C2=A0 explanation for why a contiguous address range =
is needed.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 I can speculate that a primary purpose is to ad=
vertise SIDs for the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 loopback addresses of routers that don't su=
pport SR - and those

=C2=A0 =C2=A0 =C2=A0 =C2=A0 loopback

=C2=A0 =C2=A0 =C2=A0 =C2=A0 addresses are likely to be allocated from a con=
tiguous range

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (though why

=C2=A0 =C2=A0 =C2=A0 =C2=A0 some wouldn't be supporting SR and cause ga=
ps isn't clear).





=C2=A0 =C2=A0 range is an optimization similar to summarization. Instead of=


=C2=A0 =C2=A0 advertising each individual prefix to SID mappings, we can ad=
vertise

=C2=A0 =C2=A0 single range with the starting SID. I referenced the

=C2=A0 =C2=A0 I-D.ietf-spring-segment-routing-ldp-interop, because SRM=
S is an

=C2=A0 =C2=A0 example where the range advertisements is clearly useful, alt=
hough

=C2=A0 =C2=A0 it's not limited to to that case. One can use SRMS as a S=
ID

=C2=A0 =C2=A0 provisioning tool.







=C2=A0 =C2=A0 =C2=A0 =C2=A0 4) Sec 5: In the end of Sec 4.2 in

=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-spring-segment-routing-ldp-inte=
rop-08, it says "Note: SR

=C2=A0 =C2=A0 =C2=A0 =C2=A0 mappings advertisements cannot set Penultimate =
Hop Popping.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In the previous example, P6=
 requires the presence of the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 segment 103

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0such as to map it to the LD=
P label 1037.=C2=A0 For that reason,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 the P flag

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0available in the Prefix-SID=
 is not available in the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Remote-Binding

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SID."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 However, in this draft Sec 5 gives the followin=
g rules:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 "As the Mapping Server does not specify th=
e originator of a prefix

=C2=A0 =C2=A0 =C2=A0 =C2=A0 advertisement, it is not possible to determine =
PHP behavior

=C2=A0 =C2=A0 =C2=A0 =C2=A0 solely based

=C2=A0 =C2=A0 =C2=A0 =C2=A0 on the Mapping Server advertisement. However, P=
HP behavior SHOULD be

=C2=A0 =C2=A0 =C2=A0 =C2=A0 done in following cases: The Prefix is intra-ar=
ea type and the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 downstream neighbor is the originator of the pr=
efix. The Prefix is

=C2=A0 =C2=A0 =C2=A0 =C2=A0 inter-area type and downstream neighbor is an A=
BR, which is

=C2=A0 =C2=A0 =C2=A0 =C2=A0 advertising

=C2=A0 =C2=A0 =C2=A0 =C2=A0 prefix reachability and is also generating the =
Extended Prefix

=C2=A0 =C2=A0 =C2=A0 =C2=A0 TLV with

=C2=A0 =C2=A0 =C2=A0 =C2=A0 the A-flag set for this prefix as described in =
section 2.1 of

=C2=A0 =C2=A0 =C2=A0 =C2=A0 [RFC7684].

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The Prefix is external type and downstream neig=
hbor is an ASBR,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 which is

=C2=A0 =C2=A0 =C2=A0 =C2=A0 advertising prefix reachability and is also gen=
erating the Extended

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Prefix TLV with the A-flag set for this prefix =
as described in

=C2=A0 =C2=A0 =C2=A0 =C2=A0 section

=C2=A0 =C2=A0 =C2=A0 =C2=A0 2.1 of [RFC7684].



=C2=A0 =C2=A0 =C2=A0 =C2=A0 These seem to be contradictory.





=C2=A0 =C2=A0 The text in draft-ietf-spring-segment-routing-ldp-intero=
p-08 refers

=C2=A0 =C2=A0 to the fact that SRMS advertisements itself can not include P=
HP

=C2=A0 =C2=A0 signaling in the advertisement itself, like the regular SID
=C2=A0 =C2=A0 advertisement does, because SRMS is not the "owner"=
 of the prefix.



=C2=A0 =C2=A0 The text in the draft-ietf-ospf-segment-routing-extensio=
ns-18

=C2=A0 =C2=A0 describes how the PHP can still be done for SIDs that come fr=
om the

=C2=A0 =C2=A0 SRMS adverisements, using additional information available to=
 the

=C2=A0 =C2=A0 protocol - e.g. prefix owner.



=C2=A0 =C2=A0 I don't believe these contradict each other.





I think this is the final issue to be resolved before I can put this

into IETF Last Call.



First, the OSPF document has to follow the architecture and behavior

defined in the SPRING documents.

This paragraph looks like a potential optimization that is not clearly

articulated and directly contradicts the

text in draft-ietf-spring-segment-routing-ldp-interop-08.



The logic in the ldp-interop draft is so that the boundary router

between segment-routing and LDP can do the mapping from segment-routing

to LDP.



In the paragraph above from the ospf draft, it is handling the edge case
where the downstream neighbor originates the prefix, basically.=C2=A0 So -<=
br>
the signaling has no indication that PHP is desired but OSPF infers that
it is based on topology and advertisements.



The explanation for why this is correct behavior does need to exist -

preferably in the ldp-interop draft - but simply having the unexplained

rules in here will not make for good interoperability or

comprehensibility of the segment-routing architecture.



To be clear, I am fine with having the rules here - if the WG believes

that they are desirable - but there must be an actual explanation as to

why this works and doesn't need the top-level label mapping that

ldp-interop refers to. I'd prefer to see that discussed in the

ldp-interop, but if you think that the issue is IGP-specific, then I

could see having it in this draft.



While this may seem obvious to you as to why it is ok, this document and
associated architecture needs to make sense and ensure interoperability

for many other implementations where those developing are basing it on

the standard.=C2=A0 For me, that means that if it isn't obvious to me a=
fter

reading through all the related documents (as I have), then it is likely
to not be obvious to others.



Regards,

Alia



=C2=A0 =C2=A0 =C2=A0 =C2=A0 5) In Sec 7.1, it says "Multiple Mapping S=
ervers can advertise

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Prefix-SIDs for the same pr=
efix, in which case the same

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Prefix-SID

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be advertised by all o=
f them."



=C2=A0 =C2=A0 =C2=A0 =C2=A0 What is forcing this constraint?=C2=A0 Does it =
work if the Prefix-SID

=C2=A0 =C2=A0 =C2=A0 =C2=A0 is an

=C2=A0 =C2=A0 =C2=A0 =C2=A0 index into an

=C2=A0 =C2=A0 =C2=A0 =C2=A0 SRGB or SRLB that is not the same value globall=
y?





=C2=A0 =C2=A0 yes, it does. The SID value for the single prefix MUST be uni=
que

=C2=A0 =C2=A0 though, otherwise we get into the conflict resolution area, t=
hat is

=C2=A0 =C2=A0 covered by the draft-ietf-spring-conflict-resolution.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 I don't see it

=C2=A0 =C2=A0 =C2=A0 =C2=A0 specified in Sec 7.2 of

=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-spring-segment-routing-ldp-inte=
rop-08?





=C2=A0 =C2=A0 SR architecture assumes unique mapping of a SID to a prefix. =
If that

=C2=A0 =C2=A0 is not followed, draft-ietf-spring-conflict-resolution c=
omes into

=C2=A0 =C2=A0 picture.



=C2=A0 =C2=A0 thanks,

=C2=A0 =C2=A0 Peter









=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Alia















--089e08244c0c3c755e055a54fb87--


From nobody Fri Sep 29 08:55:33 2017
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 D21CD132CE7; Fri, 29 Sep 2017 08:55:18 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.0
Auto-Submitted: auto-generated
Precedence: bulk
CC: akatlas@gmail.com, draft-ietf-ospf-segment-routing-extensions@ietf.org, ospf@ietf.org, Acee Lindem , acee@cisco.com, ospf-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender: 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <150670051885.14224.11431219480492283122.idtracker@ietfa.amsl.com>
Date: Fri, 29 Sep 2017 08:55:18 -0700
Archived-At: 
Subject: [OSPF] Last Call:  (OSPF Extensions for Segment Routing) to Proposed Standard
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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 Sep 2017 15:55:19 -0000

The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document: - 'OSPF Extensions for Segment
Routing'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-10-13. 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


   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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/ballot/

The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/2808/
   https://datatracker.ietf.org/ipr/2233/
   https://datatracker.ietf.org/ipr/2401/