From nobody Wed Jun 4 20:19:17 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFAC1A0180 for ; Wed, 4 Jun 2014 20:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InsB5B5M74Fy for ; Wed, 4 Jun 2014 20:19:14 -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 1164D1A0016 for ; Wed, 4 Jun 2014 20:19:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHV83278; Thu, 05 Jun 2014 03:19:06 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Jun 2014 04:18:12 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Jun 2014 04:19:05 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Thu, 5 Jun 2014 11:19:01 +0800 From: Xuxiaohu To: OSPF List Thread-Topic: New Version Notification for draft-xu-ospf-routable-ip-address-00.txt Thread-Index: AQHPgF8sfsiATLsLyU+fHnC20Wi9hZth2IEA Date: Thu, 5 Jun 2014 03:19:00 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827E47F@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/neY2kn37CDpzG0kV6VoquzPUTjU Subject: [OSPF] FW: New Version Notification for draft-xu-ospf-routable-ip-address-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2014 03:19:15 -0000 SGkgYWxsLA0KDQpUaGlzIGRyYWZ0IGlzIHRoZSByZXBsYWNlbWVudCBvZiBkcmFmdC14dS1vc3Bm LWlwdjYtcm91dGVyLWlkLiBUaGFua3MgYSBsb3QgZm9yIHRob3NlIHBlb3BsZSB3aG8gaGF2ZSBn aXZlbiB2YWx1YWJsZSBjb21tZW50cyBvbiB0aGUgbGF0dGVyIGRyYWZ0LiBBbnkgY29tbWVudHMg b24gdGhpcyBuZXcgZHJhZnQgYXJlIHdlbGNvbWUuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDogVGh1cnNk YXksIEp1bmUgMDUsIDIwMTQgOTo0MSBBTQ0KPiBUbzogWHV4aWFvaHU7IFh1eGlhb2h1OyBVbWEg Q2h1bmR1cmk7IE1hbmF2IEJoYXRpYTsgVW1hIENodW5kdXJpOyBNYW5hdg0KPiBCaGF0aWENCj4g U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC14dS1vc3BmLXJvdXRh YmxlLWlwLWFkZHJlc3MtMDAudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LXh1LW9zcGYtcm91dGFibGUtaXAtYWRkcmVzcy0wMC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBYaWFvaHUgWHUgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBv c2l0b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0LXh1LW9zcGYtcm91dGFibGUtaXAtYWRkcmVzcw0K PiBSZXZpc2lvbjoJMDANCj4gVGl0bGU6CQlDYXJyeWluZyBSb3V0YWJsZSBJUCBBZGRyZXNzZXMg aW4gT1NQRiBSSSBMU0ENCj4gRG9jdW1lbnQgZGF0ZToJMjAxNC0wNi0wNA0KPiBHcm91cDoJCUlu ZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBQYWdlczoJCTQNCj4gVVJMOg0KPiBodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC14dS1vc3BmLXJvdXRhYmxlLWlwLWFkZHJlc3Mt MDAudHh0DQo+IFN0YXR1czoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQteHUtb3NwZi1yb3V0YWJsZS1pcC1hZGRyZXNzLw0KPiBIdG1saXplZDoNCj4gaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtb3NwZi1yb3V0YWJsZS1pcC1hZGRyZXNzLTAwDQo+ IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgdHdvIG5ldyBU TFZzIHdpdGhpbiB0aGUgYm9keSBvZiB0aGUgT1NQRg0KPiAgICBSb3V0ZXIgSW5mb3JtYXRpb24g KFJJKSBPcGFxdWUgTFNBLCBjYWxsZWQgUm91dGFibGUgSVB2NCBBZGRyZXNzIFRMVg0KPiAgICBh bmQgUm91dGFibGUgSVB2NiBBZGRyZXNzIFRMVi4gIEhlcmUgdGhlIE9TUEYgbWVhbnMgYm90aHMg T1NQRnYyIGFuZA0KPiAgICBPU1BGdjMuDQo+IA0KPiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uDQo+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Wed Jun 4 20:26:49 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAA31A0010 for ; Wed, 4 Jun 2014 20:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYSOWaJCTsAk for ; Wed, 4 Jun 2014 20:26:45 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E3B1A000E for ; Wed, 4 Jun 2014 20:26:45 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s553QS3P005724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Jun 2014 22:26:28 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s553QPF9027500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Jun 2014 23:26:27 -0400 Received: from SG70XWXCHHUB02.zap.alcatel-lucent.com (135.253.2.47) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 4 Jun 2014 23:26:26 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.252]) by SG70XWXCHHUB02.zap.alcatel-lucent.com ([135.253.2.47]) with mapi id 14.02.0247.003; Thu, 5 Jun 2014 11:26:20 +0800 From: "Bhatia, Manav (Manav)" To: Xuxiaohu , OSPF List Thread-Topic: New Version Notification for draft-xu-ospf-routable-ip-address-00.txt Thread-Index: AQHPgF8sh9kVLldDS06jOaSxe+i7ZZth2IEAgAACM+A= Date: Thu, 5 Jun 2014 03:26:19 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E6250C3@SG70YWXCHMBA05.zap.alcatel-lucent.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827E47F@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827E47F@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/HPx34le54avFIrzahv7pQqVii14 Subject: Re: [OSPF] New Version Notification for draft-xu-ospf-routable-ip-address-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2014 03:26:47 -0000 SGksDQoNClRoZSBleHRlbnNpb25zIGRlZmluZWQgaW4gdGhpcyBkcmFmdCBhcmUgcmVxdWlyZWQg Zm9yIFMtQkZEIGNsaWVudHMgdG8gZXN0YWJsaXNoIHY0L3Y2IFMtQkZEIHNlc3Npb25zIHdpdGgg dGhlIHJlZmxlY3RvcnMgaW4gdGhlIHdpbGQuIFMtQkZEIGhhcyBiZWVuIGFwcHJvdmVkIGFzIGEg Y2hhcnRlciBpdGVtIGZvciB0aGUgQkZEIFdHLg0KDQpDaGVlcnMsIE1hbmF2DQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogWHV4aWFvaHUgW21haWx0bzp4dXhpYW9odUBo dWF3ZWkuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgSnVuZSAwNSwgMjAxNCA4OjQ5IEFNDQo+IFRv OiBPU1BGIExpc3QNCj4gQ2M6IFVtYSBDaHVuZHVyaTsgQmhhdGlhLCBNYW5hdiAoTWFuYXYpDQo+ IFN1YmplY3Q6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXh1LW9zcGYt cm91dGFibGUtaXAtDQo+IGFkZHJlc3MtMDAudHh0DQo+IA0KPiBIaSBhbGwsDQo+IA0KPiBUaGlz IGRyYWZ0IGlzIHRoZSByZXBsYWNlbWVudCBvZiBkcmFmdC14dS1vc3BmLWlwdjYtcm91dGVyLWlk LiBUaGFua3MgYQ0KPiBsb3QgZm9yIHRob3NlIHBlb3BsZSB3aG8gaGF2ZSBnaXZlbiB2YWx1YWJs ZSBjb21tZW50cyBvbiB0aGUgbGF0dGVyDQo+IGRyYWZ0LiBBbnkgY29tbWVudHMgb24gdGhpcyBu ZXcgZHJhZnQgYXJlIHdlbGNvbWUuDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IFhpYW9odQ0KPiAN Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gPiBTZW50OiBU aHVyc2RheSwgSnVuZSAwNSwgMjAxNCA5OjQxIEFNDQo+ID4gVG86IFh1eGlhb2h1OyBYdXhpYW9o dTsgVW1hIENodW5kdXJpOyBNYW5hdiBCaGF0aWE7IFVtYSBDaHVuZHVyaTsNCj4gTWFuYXYNCj4g PiBCaGF0aWENCj4gPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXh1LW9zcGYtcm91dGFibGUtaXAtDQo+IGFkZHJlc3MtMDAudHh0DQo+ID4NCj4gPg0KPiA+IEEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC14dS1vc3BmLXJvdXRhYmxlLWlwLWFkZHJlc3MtMDAu dHh0DQo+ID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBYaWFvaHUgWHUgYW5k IHBvc3RlZCB0byB0aGUgSUVURg0KPiByZXBvc2l0b3J5Lg0KPiA+DQo+ID4gTmFtZToJCWRyYWZ0 LXh1LW9zcGYtcm91dGFibGUtaXAtYWRkcmVzcw0KPiA+IFJldmlzaW9uOgkwMA0KPiA+IFRpdGxl OgkJQ2FycnlpbmcgUm91dGFibGUgSVAgQWRkcmVzc2VzIGluIE9TUEYgUkkgTFNBDQo+ID4gRG9j dW1lbnQgZGF0ZToJMjAxNC0wNi0wNA0KPiA+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQo+ID4gUGFnZXM6CQk0DQo+ID4gVVJMOg0KPiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LXh1LW9zcGYtcm91dGFibGUtaXAtDQo+IGFkZHJlc3MtMDAudHh0DQo+ ID4gU3RhdHVzOg0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXh1 LW9zcGYtcm91dGFibGUtaXAtYWRkcmVzcy8NCj4gPiBIdG1saXplZDoNCj4gPiBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1vc3BmLXJvdXRhYmxlLWlwLWFkZHJlc3MtMDANCj4g Pg0KPiA+DQo+ID4gQWJzdHJhY3Q6DQo+ID4gICAgVGhpcyBkb2N1bWVudCBwcm9wb3NlcyB0d28g bmV3IFRMVnMgd2l0aGluIHRoZSBib2R5IG9mIHRoZSBPU1BGDQo+ID4gICAgUm91dGVyIEluZm9y bWF0aW9uIChSSSkgT3BhcXVlIExTQSwgY2FsbGVkIFJvdXRhYmxlIElQdjQgQWRkcmVzcw0KPiBU TFYNCj4gPiAgICBhbmQgUm91dGFibGUgSVB2NiBBZGRyZXNzIFRMVi4gIEhlcmUgdGhlIE9TUEYg bWVhbnMgYm90aHMgT1NQRnYyDQo+IGFuZA0KPiA+ICAgIE9TUEZ2My4NCj4gPg0KPiA+DQo+ID4N Cj4gPg0KPiA+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mDQo+IHN1Ym1pc3Npb24NCj4gPiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiA+DQo+ ID4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Thu Jun 5 05:33:42 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0F41A0086 for ; Thu, 5 Jun 2014 05:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9farAxF60cHe for ; Thu, 5 Jun 2014 05:33:40 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F6E11A008B for ; Thu, 5 Jun 2014 05:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2210; q=dns/txt; s=iport; t=1401971613; x=1403181213; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=2lQdiM2g9VlDLJZKRSmdBus4VcLzmPhZL2Or9L17v+0=; b=kuGkFznB90tRZgvQagGfhq0FQCM7zVBf39S1XTMnqT+J6qyIObI8ZX0N SkS4t+AooIyPvTzbevHPNEPeawfi/VYYDhT7gazVpDpMpZ1mpubdvcPaQ g6QaIlVEYdknfSntkc/wdYU1LMnyRTvglQ6E2ke0Sw55A265NSsSaMNC8 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMEAJ5ikFOtJssW/2dsb2JhbABZg1mDRMATAYEhdIIlAQEBBCMVPwERHQYCAgUWCwICCQMCAQIBNw4GDQYCAQEFiDkNrHumExeBKo0vgnWBSwEDmhOBP4UxjEmDOjsv X-IronPort-AV: E=Sophos;i="4.98,981,1392163200"; d="scan'208";a="75472573" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 05 Jun 2014 12:33:30 +0000 Received: from [10.148.128.133] ([10.148.128.133]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s55CXUa4010871 for ; Thu, 5 Jun 2014 12:33:30 GMT Message-ID: <5390639A.7000701@cisco.com> Date: Thu, 05 Jun 2014 14:33:30 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: OSPF List References: <20140605114624.10615.19183.idtracker@ietfa.amsl.com> In-Reply-To: <20140605114624.10615.19183.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/PLppwFNfuXSkhsY0iT9x-mrdb0k Subject: [OSPF] New Version Notification for draft-psenak-ospf-segment-routing-extensions-05.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2014 12:33:42 -0000 WG, Acee, an updated version of the OSPFv2 SR extensions draft has been published. I would like to ask for the WG adoption of the draft, considering the following: - consensus between multiple vendors - see list of authors - at least two commercial implementations available at this point, others in the pipeline - SPRING WG has adopted couple of use case drafts and is progressing towards the architecture draft adoption - earlier version of the OSPF SR draft has been already presented to the OSPF WG - similar protocol extensions draft has been adopted by the ISIS WG WG adoption would allow us to take advantage of the early IANA allocation for code points to prevent potential interoperability problems in the future. thanks, Peter On 6/5/14 13:46 , internet-drafts@ietf.org wrote: > > A new version of I-D, draft-psenak-ospf-segment-routing-extensions-05.txt > has been successfully submitted by Peter Psenak and posted to the > IETF repository. > > Name: draft-psenak-ospf-segment-routing-extensions > Revision: 05 > Title: OSPF Extensions for Segment Routing > Document date: 2014-06-05 > Group: Individual Submission > Pages: 33 > URL: http://www.ietf.org/internet-drafts/draft-psenak-ospf-segment-routing-extensions-05.txt > Status: https://datatracker.ietf.org/doc/draft-psenak-ospf-segment-routing-extensions/ > Htmlized: http://tools.ietf.org/html/draft-psenak-ospf-segment-routing-extensions-05 > Diff: http://www.ietf.org/rfcdiff?url2=draft-psenak-ospf-segment-routing-extensions-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 necessary OSPF extensions that need to be > introduced for Segment Routing. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > . > From nobody Sat Jun 7 14:35:56 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438D51A021E for ; Sat, 7 Jun 2014 14:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljUNXRtPIOuY for ; Sat, 7 Jun 2014 14:35:53 -0700 (PDT) Received: from linfre.de (linfre.de [83.151.26.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE151A01F3 for ; Sat, 7 Jun 2014 14:35:52 -0700 (PDT) Received: from [127.0.0.1] by linfre.de with HTTP; Sat, 7 Jun 2014 23:35:40 +0200 From: Karsten Thomann Date: Sat, 7 Jun 2014 23:35:40 +0200 X-Mailer: Axigen WebMail To: Xuxiaohu Message-ID: <1402176940168208374@linfre.de> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827E47F@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827E47F@NKGEML512-MBS.china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="===axigen=8920629917311111935832208081894693604778=axigen===" X-AXIGEN-DK-Result: No records DomainKey-Status: no signature X-AxigenSpam-Level: 4 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/CdO2JiV5fbkbZCIFgPs7_dZHuYY Cc: OSPF List Subject: Re: [OSPF] FW: New Version Notification for draft-xu-ospf-routable-ip-address-00.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 07 Jun 2014 21:35:55 -0000 This is a MIME message. You may need a MIME compliant mail user agent. --===axigen=8920629917311111935832208081894693604778=axigen=== Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Xiaohu, one question: Why is the Routable IPv4 Address TLV limited to OSPFv2? OSPFv3 is able to route IPv4. Kind regards Karsten Xuxiaohu schrieb: > Hi all, >=20 > This draft is the replacement of draft-xu-ospf-ipv6-router-id. Thanks a l= ot for those people who have given valuable comments on the latter draft. A= ny comments on this new draft are welcome. >=20 > Best regards, > Xiaohu >=20 > > -----Original Message----- > > From: internet-drafts@ietf.org [internet-drafts@ietf.org] > > Sent: Thursday, June 05, 2014 9:41 AM > > To: Xuxiaohu; Xuxiaohu; Uma Chunduri; Manav Bhatia; Uma Chunduri; Manav > > Bhatia > > Subject: New Version Notification for draft-xu-ospf-routable-ip-address= -00.txt > >=20 > >=20 > > A new version of I-D, draft-xu-ospf-routable-ip-address-00.txt > > has been successfully submitted by Xiaohu Xu and posted to the IETF rep= ository. > >=20 > > Name: draft-xu-ospf-routable-ip-address > > Revision: 00 > > Title: Carrying Routable IP Addresses in OSPF RI LSA > > Document date: 2014-06-04 > > Group: Individual Submission > > Pages: 4 > > URL: > > http://www.ietf.org/internet-drafts/draft-xu-ospf-routable-ip-address-0= 0.txt > > Status: > > https://datatracker.ietf.org/doc/draft-xu-ospf-routable-ip-address/ > > Htmlized: > > http://tools.ietf.org/html/draft-xu-ospf-routable-ip-address-00 > >=20 > >=20 > > Abstract: > > This document proposes two new TLVs within the body of the OSPF > > Router Information (RI) Opaque LSA, called Routable IPv4 Address TLV > > and Routable IPv6 Address TLV. Here the OSPF means boths OSPFv2 and > > OSPFv3. > >=20 > >=20 > >=20 > >=20 > > Please note that it may take a couple of minutes from the time of submi= ssion > > until the htmlized version and diff are available at tools.ietf.org. > >=20 > > The IETF Secretariat >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > =20 --=20 --===axigen=8920629917311111935832208081894693604778=axigen=== Content-Type: text/html Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Xiaohu,

one question: Why is the Routable IPv4 Address TLV= limited to OSPFv2?
OSPFv3 is able to route IPv4.

Kind regardsKarsten

Xuxiaohu schrieb:
Hi all,

This draft is the replacement of draft-xu-os= pf-ipv6-router-id. Thanks a lot for those people who have given valuable co= mments on the latter draft. Any comments on this new draft are welcome.
=
Best regards,
Xiaohu

> -----Original Message-----
> = From: interne= t-drafts@ietf.org [internet-drafts@ietf.org]
> Sent: Thursday, June 05, = 2014 9:41 AM
> To: Xuxiaohu; Xuxiaohu; Uma Chunduri; Manav Bhatia; Um= a Chunduri; Manav
> Bhatia
> Subject: New Version Notification = for draft-xu-ospf-routable-ip-address-00.txt
>
>
> A ne= w version of I-D, draft-xu-ospf-routable-ip-address-00.txt
> has been= successfully submitted by Xiaohu Xu and posted to the IETF repository.
= >
> Name:        draft-xu= -ospf-routable-ip-address
> Revision:    00
&g= t; Title:        Carrying Routable = IP Addresses in OSPF RI LSA
> Document date:    2= 014-06-04
> Group:        Ind= ividual Submission
> Pages:       =  4
> URL:
> http://www.iet= f.org/internet-drafts/draft-xu-ospf-routable-ip-address-00.txt
> = Status:
> https://datatracker.ietf.org/doc/dra= ft-xu-ospf-routable-ip-address/
> Htmlized:
> http://tools.ietf.org/html/draft-xu-ospf-routable-ip-address-00>
>
> Abstract:
> This document proposes two ne= w TLVs within the body of the OSPF
> Router Information (RI) Opaqu= e LSA, called Routable IPv4 Address TLV
> and Routable IPv6 Addres= s TLV. Here the OSPF means boths OSPFv2 and
> OSPFv3.
> >
>
>
> Please note that it may take a couple of m= inutes from the time of submission
> until the htmlized version and d= iff are available at tools.ietf.org.
>
> The IETF Secretariat<= br>
_______________________________________________
OSPF mailing list=
OSPF@ietf.orgh= ttps://www.ietf.org/mailman/listinfo/ospf

--

--===axigen=8920629917311111935832208081894693604778=axigen===-- From nobody Sun Jun 8 23:49:27 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A2B1A0653 for ; Sun, 8 Jun 2014 23:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bY3nJLRESOlw for ; Sun, 8 Jun 2014 23:49:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE0A71A0303 for ; Sun, 8 Jun 2014 23:49:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIF33520; Mon, 09 Jun 2014 06:49:18 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Jun 2014 07:49:17 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 9 Jun 2014 14:49:11 +0800 From: Xuxiaohu To: Acee Lindem Thread-Topic: =?utf-8?B?562U5aSNOiBbSXNpcy13Z10gW09TUEZdIOetlOWkjTogIOetlOWkjTogIFtz?= =?utf-8?Q?unset4]___IPv6_router_IDs?= Thread-Index: AQHPbeep0KeJfDl/fkGY3udMB/Ik+ZtogCWA Date: Mon, 9 Jun 2014 06:49:10 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827F3AD@NKGEML512-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/jmKfCQAo3sLJG2f6aU2E_MYiMsw Cc: OSPF List Subject: Re: [OSPF] =?utf-8?b?562U5aSNOiBbSXNpcy13Z10gIOetlOWkjTogIOetlOWkjTog?= =?utf-8?q?_=5Bsunset4=5D___IPv6_router_IDs?= X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jun 2014 06:49:24 -0000 SGkgQWNlZSwNCg0KVGhlIG9sZCBkcmFmdCAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQteHUtb3NwZi1pcHY2LXJvdXRlci1pZC0wMCkgaGFzIGJlZW4gcmVwbGFjZWQgYnkgdGhlIG5l dyBkcmFmdCAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtb3NwZi1yb3V0YWJs ZS1pcC1hZGRyZXNzLTAwKS4gSW4gdGhlIGxhdHRlciBkcmFmdCwgdHdvIHByZWNpc2UgdXNlIGNh c2VzIGhhdmUgYmVlbiBpbmNsdWRlZCAoc2VlIHNlY3Rpb24gMSkuIEkgd29uZGVyIHdoZXRoZXIg dGhlIGxhdHRlciBkcmFmdCBoYXMgYWRkcmVzc2VkIHlvdXIgY29uY2VybnMuDQoNCkJlc3QgcmVn YXJkcywNClhpYW9odQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFj ZWUgTGluZGVtIFttYWlsdG86YWNlZS5saW5kZW1AZXJpY3Nzb24uY29tXQ0KPiBTZW50OiBNb25k YXksIE1heSAxMiwgMjAxNCA5OjQwIFBNDQo+IFRvOiBYdXhpYW9odQ0KPiBDYzogS2Fyc3RlbiBU aG9tYW5uOyBBbnRvbiBTbWlybm92OyBpc2lzLXdnQGlldGYub3JnOw0KPiBmYW5wZW5nQGNoaW5h bW9iaWxlLmNvbTsgV2VzIEdlb3JnZTsgSm9lbCBqYWVnZ2xpOyBPU1BGIExpc3Q7DQo+IHN1bnNl dDRAaWV0Zi5vcmc7IGxpemhlbnFpYW5nQGNoaW5hbW9iaWxlLmNvbQ0KPiBTdWJqZWN0OiBSZTog 562U5aSNOiBbSXNpcy13Z10gW09TUEZdIOetlOWkjTog562U5aSNOiBbc3Vuc2V0NF0gSVB2NiBy b3V0ZXIgSURzDQo+IA0KPiBIaSBYaWFvaHUsDQo+IFBsZWFzZSBpbmNsdWRlIHRoZSBwcmVjaXNl IHVzZSBjYXNlcyBhcyB0byBXSFkgdGhpcyBpcyBuZWVkZWQgT1NQRiBkcmFmdC4NCj4gQW5kIGJ5 IHByZWNpc2UsIEkgZG9uJ3QgbWVhbiBqdXN0IGxpc3RpbmcgTVBMUyBhcHBsaWNhdGlvbnMsIEkg bWVhbiBleHBsYWluaW5nDQo+IHdoeSB5b3UgbmVlZCB0aGlzIHJvdXRhYmxlIGFkZHJlc3MgYWJv dmUgYW5kIGJleW9uZCB3aGF0IGlzIGFscmVhZHkNCj4gYWR2ZXJ0aXNlZC4gQXQgbGVhc3QgaW4g dGhlIGNhc2Ugb2YgT1NQRiwgSSdtIG5vdCBjb252aW5jZWQuDQo+IFRoYW5rcywNCj4gQWNlZQ0K PiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFh1eGlhb2h1IDx4 dXhpYW9odUBodWF3ZWkuY29tPg0KPiBEYXRlOiBTdW5kYXksIE1heSAxMSwgMjAxNCA2OjQ0IFBN DQo+IFRvOiBFcmljc3NvbiA8YWNlZS5saW5kZW1AZXJpY3Nzb24uY29tPg0KPiBDYzogS2Fyc3Rl biBUaG9tYW5uIDxrYXJzdGVuX3Rob21hbm5AbGluZnJlLmRlPiwgQW50b24gU21pcm5vdg0KPiA8 YXNtaXJub3ZAY2lzY28uY29tPiwgImlzaXMtd2dAaWV0Zi5vcmciIDxpc2lzLXdnQGlldGYub3Jn PiwNCj4gImZhbnBlbmdAY2hpbmFtb2JpbGUuY29tIiA8ZmFucGVuZ0BjaGluYW1vYmlsZS5jb20+ LCBXZXMgR2VvcmdlDQo+IDx3ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tPiwgSm9lbCBqYWVnZ2xp IDxqb2VsamFAYm9ndXMuY29tPiwgT1NQRiAtIE9TUEYNCj4gV0cgTGlzdCA8b3NwZkBpZXRmLm9y Zz4sICJzdW5zZXQ0QGlldGYub3JnIiA8c3Vuc2V0NEBpZXRmLm9yZz4sDQo+ICJsaXpoZW5xaWFu Z0BjaGluYW1vYmlsZS5jb20iIDxsaXpoZW5xaWFuZ0BjaGluYW1vYmlsZS5jb20+DQo+IFN1Ympl Y3Q6IOetlOWkjTogW0lzaXMtd2ddIFtPU1BGXSDnrZTlpI06ICDnrZTlpI06ICBbc3Vuc2V0NF0g ICBJUHY2IHJvdXRlciBJRHMNCj4gDQo+ID5IaSBBY2VlLA0KPiA+DQo+ID5JTUhPLCBzZWdtZW50 IHJvdXRpbmcgY291bGQgd29yayB0b2dldGhlciB3aXRoIHRoZSBSRkMzNDY0IFZQTi4gSW4gc3Vj aA0KPiA+Y2FzZSwgdGhlIHNlZ21lbnQgcm91dGluZyBqdXN0IHJlcGxhY2UgdGhlIHJvbGUgb2Yg TERQIG9yIFJTVlAtVEUgb2YNCj4gPmVzdGFibGlzaGluZyBhIHRyYW5zcG9ydCBMU1AgYmV0d2Vl biBQRSByb3V0ZXJzLg0KPiA+DQo+ID5CZXN0IHJlZ2FyZHMsDQo+ID5YaWFvaHUNCj4gPg0KPiA+ PiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4+IOWPkeS7tuS6ujogQWNlZSBMaW5kZW0gW21h aWx0bzphY2VlLmxpbmRlbUBlcmljc3Nvbi5jb21dDQo+ID4+IOWPkemAgeaXtumXtDogMjAxNOW5 tDXmnIg55pelIDIwOjExDQo+ID4+IOaUtuS7tuS6ujogWHV4aWFvaHUNCj4gPj4g5oqE6YCBOiBL YXJzdGVuIFRob21hbm47IEFudG9uIFNtaXJub3Y7IGlzaXMtd2dAaWV0Zi5vcmc7DQo+ID4+IGZh bnBlbmdAY2hpbmFtb2JpbGUuY29tOyBXZXMgR2VvcmdlOyBKb2VsIGphZWdnbGk7IE9TUEYgTGlz dDsNCj4gPj4gc3Vuc2V0NEBpZXRmLm9yZzsgbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tDQo+ ID4+IOS4u+mimDogUmU6IFtJc2lzLXdnXSBbT1NQRl0g562U5aSNOiDnrZTlpI06IFtzdW5zZXQ0 XSBJUHY2IHJvdXRlciBJRHMNCj4gPj4NCj4gPj4gWGlhb2h1LA0KPiA+Pg0KPiA+PiBUaGUgcmVh c29uIHRoZSB1c2UgY2FzZSBpcyBjb25mdXNpbmcgaXMgdGhhdCB0aGUgdGVybSBMM1ZQTiBpcyBj b21tb25seQ0KPiA+PnVzZWQgdG8NCj4gPj4gcmVmZXIgdG8gUkZDIDQzNjQgVlBOcy4gSW4geW91 ciB1c2UgY2FzZSwgeW91IGFyZSBoeXBvdGhlc2l6aW5nDQo+ID4+c29tZXRoaW5nIGZvcg0KPiA+ PiBTZWdtZW50IFJvdXRlZCBMM1ZQTnMgdGhhdCBJ4oCZbSBub3Qgc3VyZSBpcyBuZWVkZWQgd2l0 aCBNUExTLiBDYW4geW91DQo+IGFkZA0KPiA+PiBzb21lIHJlYWwgdXNlIGNhc2VzIHRvIHlvdXIg ZHJhZnRzIHdpdGgganVzdGlmaWNhdGlvbiB0aGF0IGl0IGlzIG5lZWRlZD8NCj4gPj4NCj4gPj4g QWNlZQ0KPiA+PiBPbiBNYXkgOSwgMjAxNCwgYXQgNTozMSBBTSwgWHV4aWFvaHUgPHh1eGlhb2h1 QGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+Pg0KPiA+PiA+IEhpIEthcnN0ZW4sDQo+ID4+ID4NCj4g Pj4gPiBZb3VyIHVuZGVyc3RhbmRpbmcgaXMgY29tcGxldGVseSBjb3JyZWN0Lg0KPiA+PiA+DQo+ ID4+ID4gQmVzdCByZWdhcmRzLA0KPiA+PiA+IFhpYW9odQ0KPiA+PiA+DQo+ID4+ID4+IC0tLS0t 6YKu5Lu25Y6f5Lu2LS0tLS0NCj4gPj4gPj4g5Y+R5Lu25Lq6OiBJc2lzLXdnIFttYWlsdG86aXNp cy13Zy1ib3VuY2VzQGlldGYub3JnXSDku6PooaggS2Fyc3Rlbg0KPiBUaG9tYW5uDQo+ID4+ID4+ IOWPkemAgeaXtumXtDogMjAxNOW5tDXmnIg55pelIDE2OjU4DQo+ID4+ID4+IOaUtuS7tuS6ujog WHV4aWFvaHU7IEFudG9uIFNtaXJub3YNCj4gPj4gPj4g5oqE6YCBOiBpc2lzLXdnQGlldGYub3Jn OyBHZW9yZ2UsIFdlczsgZmFucGVuZ0BjaGluYW1vYmlsZS5jb207IGpvZWwNCj4gPj4gPj4gamFl Z2dsaTsgT1NQRiBMaXN0OyBzdW5zZXQ0QGlldGYub3JnOyBsaXpoZW5xaWFuZ0BjaGluYW1vYmls ZS5jb20NCj4gPj4gPj4g5Li76aKYOiBSZTogW0lzaXMtd2ddIFtPU1BGXSDnrZTlpI06IOetlOWk jTogW3N1bnNldDRdIElQdjYgcm91dGVyIElEcw0KPiA+PiA+Pg0KPiA+PiA+PiBIaSBYaWFvaHUs DQo+ID4+ID4+DQo+ID4+ID4+IEkgdGhpbmsgSSd2ZSB1bmRlcnN0YW5kIHlvdXIgcHJvYmxlbSBu b3csIGJ1dCBwbGVhc2UgZG9uJ3QgY2FsbCBpdCBhDQo+ID4+ID4+IFJvdXRlciBJRCwgdGhlIHJv dXRlciBJRCBtdXN0IG5vdCBiZSBhbiBJUCBhZGRyZXNzLg0KPiA+PiA+PiBUbyBhdm9pZCBhbnkg Y29uZnVzaW9uIGFib3V0IGl0IHBsZWFzZSBjYWxsIGl0IGEgcm91dGVyIGlwIG9yIHJvdXRlcg0K PiA+PiA+PiBhZGRyZXNzIHdpdGhpbiB0aGUgVExWLg0KPiA+PiA+PiBQbGVhc2UgY29ycmVjdCBt ZSBpZiBJJ20gd3JvbmcsIGJ1dCBpZiBJIHVuZGVyc3RhbmQgeW91ciBkcmFmdHMgcmlnaHQNCj4g Pj4gPj4geW91J3JlIG5vdCByZXF1ZXN0aW5nIGEgcmVhbCBJUHY2IFJvdXRlciBJRCBpbnN0ZWFk IG9mIHRoZQ0KPiA+PiA+PiAoYXJiaXRyYXJ5KSAzMmJpdCBJRCwgYnV0IGEgc2ltcGxlIFRMViB0 byBjYXJyeSB0aGUgcm91dGFibGUgSVB2Ng0KPiA+PiA+PiBhZGRyZXNzIG9mIHRoZSByb3V0ZXIg d2hpY2ggYWR2ZXJ0aXNlcyB0aGUgY2FwYWJpbGl0eS4NCj4gPj4gPj4NCj4gPj4gPj4gSWYgSSB1 bmRlcnN0YW5kIGl0IHJpZ2h0LCB3ZSBzaG91bGQgbWF5YmUgZml4IHRoZSB0ZXh0IG9mIHRoZSBv dGhlcg0KPiA+PiA+PiByZmMgdG8gcmVmZWN0IHRoYXQgaXQgaXMgYW4gcm91dGFibGUgSVAgYWRk cmVzcywgaW5zdGVhZCBvZiBhDQo+ID4+ID4+IChwb3NzaWJsZSkgYXJiaXRyYXJ5IGJ1dCB1bmlx dWUgUm91dGVyIElELg0KPiA+PiA+Pg0KPiA+PiA+PiBLaW5kIHJlZ2FyZHMNCj4gPj4gPj4gS2Fy c3Rlbg0KPiA+PiA+Pg0KPiA+PiA+PiBBbSAwOS4wNS4yMDE0IDAyOjUzLCBzY2hyaWViIFh1eGlh b2h1Og0KPiA+PiA+Pj4gSGkgQW50b24sDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gV2hlbiBJU0lTIGNh cGFiaWxpdHkgVExWcyBhcmUgZmxvb2RlZCBhY3Jvc3MgYXJlYXMsIHJvdXRlcnMgaW4gb25lDQo+ ID4+ID4+PiBhcmVhIG1heQ0KPiA+PiA+PiBuZWVkIHRvIGVzdGFibGlzaCBjb3JyZWxhdGlvbnMg YmV0d2VlbiBJUCBhZGRyZXNzZXMgYW5kIGNhcGFiaWxpdGllcw0KPiA+PiA+PiBvZiByb3V0ZXJz IGluIGFub3RoZXIgYXJlYS4gRm9yIGV4YW1wbGUsIGFzc3VtZSBJUy1JUyByb3V0ZXIgQSBpbiBv bmUNCj4gPj4gPj4gYXJlYSBoYXMgZXN0YWJsaXNoZWQgYSBMM1ZQTiBzZXNzaW9uIHdpdGggSVMt SVMgcm91dGVyIEIgaW4gYW5vdGhlcg0KPiA+PiA+PiBhcmVhLiBXaGVuIHJvdXRlciBBIG5lZWRz IHRvIHNlbmQgTDNWUE4gdHJhZmZpYyB0byByb3V0ZXIgQiB2aWEgYQ0KPiA+PiA+PiBNUExTLVNS IHR1bm5lbCwgcm91dGVyIEEgd2FudHMgdG8ga25vdyB3aGV0aGVyIHJvdXRlciBCIChpZGVudGlm aWVkDQo+ID4+ID4+IGJ5IGFuIElQIGFkZHJlc3MpIGhhcyB0aGUgRUxDDQo+ID4+ID4+IChodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1pc2lzLW1wbHMtZWxjLTAwKSBiZWZvcmUN Cj4gPj4gPj4gaW5zZXJ0aW5nIGFuIEVMIGludG8gdGhlIE1QTFMtU1IgcGFja2V0LiBJbiBzdWNo IGNhc2UsIGl0IG5lZWRzIHRvDQo+ID4+ID4+IGNvbnRhaW4gYXQgbGVhc3Qgb25lIHJvdXRhYmxl IElQIGFkZHJlc3MgaW4gdGhlIGNhcGFiaWxpdHkgVExWIHdoaWNoDQo+ID4+ID4+IGhhcyBiZWVu IGZsb29kZWQgYWNyb3NzIGFyZWEgYm91bmRhcmllcy4gSW4gdGhlIElQdjQgbmV0d29yaywgdGhl DQo+ID4+ID4+IDQtb2N0ZWN0IHJvdXRlciBJRCBmaWVsZCBjb3VsZCBjb250YWluIHN1Y2ggcm91 dGFibGUgSVB2NCBhZGRyZXNzLg0KPiA+PiA+PiBIb3dldmVyLCBpbiB0aGUgSVB2NiBuZXR3b3Jr LCB0aGVyZSBpcyBubyBjb3VudGVycGFydCBmaWVsZCB0bw0KPiA+PmNvbnRhaW4gYQ0KPiA+PiBy b3V0YWJsZSBJUHY2IGFkZHJlc3MuDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gQmVzdCByZWdhcmRzLA0K PiA+PiA+Pj4gWGlhb2h1DQo+ID4+ID4+Pg0KPiA+PiA+Pj4+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0t LS0NCj4gPj4gPj4+PiDlj5Hku7bkuro6IEFudG9uIFNtaXJub3YgW21haWx0bzphc21pcm5vdkBj aXNjby5jb21dDQo+ID4+ID4+Pj4g5Y+R6YCB5pe26Ze0OiAyMDE05bm0NeaciDjml6UgMjI6NDkN Cj4gPj4gPj4+PiDmlLbku7bkuro6IFh1eGlhb2h1DQo+ID4+ID4+Pj4g5oqE6YCBOiBpc2lzLXdn QGlldGYub3JnOyBHZW9yZ2UsIFdlczsgZmFucGVuZ0BjaGluYW1vYmlsZS5jb207IGpvZWwNCj4g Pj4gPj4+PiBqYWVnZ2xpOyBPU1BGIExpc3Q7IHN1bnNldDRAaWV0Zi5vcmc7IGxpemhlbnFpYW5n QGNoaW5hbW9iaWxlLmNvbQ0KPiA+PiA+Pj4+IOS4u+mimDogUmU6IFtPU1BGXSDnrZTlpI06IOet lOWkjTogW0lzaXMtd2ddIFtzdW5zZXQ0XSBJUHY2IHJvdXRlciBJRHMNCj4gPj4gPj4+Pg0KPiA+ PiA+Pj4+ICAgICBIZWxsbyBYaWFvaHUsDQo+ID4+ID4+Pj4gICAgIHRoaXMgd2hvbGUgdGhyZWFk IHN0YXJ0ZWQgZnJvbSBHZW9yZ2UgV2VzIHN0YXRpbmcgdGhhdCBldmVuIGluDQo+ID4+ID4+Pj4g cHVyZQ0KPiA+PiA+Pj4+IElQdjQgd29ybGQgUm91dGVyIElEIGluIG1hbnkgcHJvdG9jb2xzIGlz IE5PVCBhbiBJUHY0IGFkZHJlc3MuIEZvcg0KPiA+PiA+Pj4+IGNvbnZlbmllbmNlIGl0IGZyZXF1 ZW50bHkgaXMgYnV0IG9uIHRoZSBiaW5hcnkgc2NhbGUgIklEIGd1YXJhbnRlZWQNCj4gPj4gPj4+ PiB0byBiZSByb3V0YWJsZSBJUHY0IGFkZHJlc3MiLyJJRCBpcyBqdXN0IGEgbnVtYmVyIiAtIHRo ZSBSb3V0ZXIgSUQNCj4gPj4gPj4+PiBpcyBOT1QgYW4NCj4gPj4gPj4gSVB2NCBhZGRyZXNzLg0K PiA+PiA+Pj4+DQo+ID4+ID4+Pj4gICAgIFNvLCBiZWZvcmUgeW91IGNvbnZpbmNlIHBlb3BsZSB0 aGF0IElQdjYgUnRyIElEIGlzIG5lZWRlZCB5b3UNCj4gPj4gPj4+PiBtdXN0IHN0YXJ0IGZyb20g ZGlzY3Vzc2luZyB3aGVuIGFuZCB3aHkgUm91dGVyIElEIGlzIGJlaW5nIHVzZWQgYXMNCj4gPj4g Pj4+PiBJUHY0IGFkZHJlc3MgaW4gcHVyZQ0KPiA+PiA+Pj4+IElQdjQgd29ybGQuIEkgYmVsaWV2 ZSB0aGlzIGluIG90aGVyIHdvcmRzIGlzIHdoYXQgQWNlZSBhc2tpbmcgeW91Lg0KPiA+PiA+Pj4+ DQo+ID4+ID4+Pj4gQW50b24NCj4gPj4gPj4+Pg0KPiA+PiA+Pj4+DQo+ID4+ID4+Pj4gT24gMDUv MDcvMjAxNCAwMzoxMCBBTSwgWHV4aWFvaHUgd3JvdGU6DQo+ID4+ID4+Pj4+IEhpIEFjZWUsDQo+ ID4+ID4+Pj4+DQo+ID4+ID4+Pj4+IFRoZSBtb3RpdmF0aW9uIGZvciB0aGVzZSB0d28gZHJhZnRz DQo+ID4+ID4+Pj4gKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LWlzaXMtaXB2 Ni1yb3V0ZXItaWQtMDAgYW5kDQo+ID4+ID4+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQteHUtb3NwZi1pcHY2LXJvdXRlci1pZC0wMCkgaXMgdmVyeQ0KPiA+PiA+Pj4+IHNpbXBs ZTogdGhlDQo+ID4+ID4+Pj4gSVB2NiBJU0lTfE9TUEYgY2FwYWJpbGl0eSBUTFYvUkktTFNBIHdo aWNoIGFyZSB1c2VkIGZvciBhZHZlcnRpc2luZw0KPiA+PiA+Pj4+IHJvdXRlciBjYXBhYmlsaXRp ZXMgY2FuIGJlIGZsb29kZWQgYWNyb3NzIGFyZWFzLCBob3dldmVyLCBvbmx5IGENCj4gPj4gPj4+ PiA0LW9jdGVjdCByb3V0ZXIgSUQgaXMgY2FycmllZCBpbiB0aGVtLiBBcyBhIHJlc3VsdCwgaXTi gJlzIGhhcmQgZm9yDQo+ID4+ID4+Pj4gcm91dGVycyBpbiBvbmUgYXJlYSB0byBlc3RhYmxpc2gg Y29ycmVsYXRpb25zIGJldHdlZW4gSVB2Ng0KPiA+PiA+Pj4+IGFkZHJlc3NlcyBhbmQNCj4gPj4g Pj4gY2FwYWJpbGl0aWVzIG9mIHJvdXRlcnMgaW4gYW5vdGhlciBhcmVhLg0KPiA+PiA+Pj4+IEZv ciBleGFtcGxlLCBhc3N1bWUgSVMtSVMgcm91dGVyIEEgaW4gb25lIGFyZWEgaGFzIGVzdGFibGlz aGVkIGENCj4gPj4gPj4+PiBMM1ZQTiBzZXNzaW9uIHdpdGggSVMtSVMgcm91dGVyIEIgaW4gYW5v dGhlciBhcmVhIG92ZXIgdGhlaXIgb3duDQo+ID4+ID4+Pj4gSVB2NiBhZGRyZXNzZXMuIFdoZW4g cm91dGVyIEEgbmVlZHMgdG8gc2VuZCBMM1ZQTiB0cmFmZmljIHRvIHJvdXRlcg0KPiA+PiA+Pj4+ IEIgdmlhIGEgTVBMUy1TUiB0dW5uZWwsIHJvdXRlciBBIHdhbnRzIHRvIGtub3cgd2hldGhlciBy b3V0ZXIgQiBoYXMNCj4gPj4gPj4+PiB0aGUgRUxDDQo+ID4+ID4+Pj4gKGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXh1LWlzaXMtbXBscy1lbGMtMDApIGJlZm9yZQ0KPiA+PiA+Pj4+ IGluc2VydGluZyBhbiBFTCBpbnRvIHRoZSBNUExTLVNSIHBhY2tldCAuIEhvd2V2ZXIsIHRoZSBD YXBhYmlsaXR5DQo+ID4+ID4+Pj4gVExWIG9yaWdpbmF0ZWQgYnkgcm91dGVyIEIgZG9lc27igJl0 IGNhcnJpZWQgYW4gSVB2NiBhZGRyZXNzIG9mIGl0cw0KPiA+PiA+Pj4+IG93bi4gQXMgYSByZXN1 bHQsDQo+ID4+ID4+IGl0ICENCj4gPj4gPj4+PiAgcyBoYXJkIGZvDQo+ID4+ID4+Pj4gciByb3V0 ZXIgQSB0byBrbm93IHRoZSBFTEMgb2Ygcm91dGVyIEIuDQo+ID4+ID4+Pj4+IEJlc3QgcmVnYXJk cywNCj4gPj4gPj4+Pj4gWGlhb2h1DQo+ID4+ID4+Pj4+DQo+ID4+ID4+Pj4+PiAtLS0tLemCruS7 tuWOn+S7ti0tLS0tDQo+ID4+ID4+Pj4+PiDlj5Hku7bkuro6IEFjZWUgTGluZGVtIFttYWlsdG86 YWNlZUBsaW5kZW0uY29tXQ0KPiA+PiA+Pj4+Pj4g5Y+R6YCB5pe26Ze0OiAyMDE05bm0NeaciDbm l6UgMjE6MTQNCj4gPj4gPj4+Pj4+IOaUtuS7tuS6ujogWHV4aWFvaHUNCj4gPj4gPj4+Pj4+IOaK hOmAgTogam9lbCBqYWVnZ2xpOyBBY2VlIExpbmRlbTsgR2VvcmdlLCBXZXM7IHN1bnNldDRAaWV0 Zi5vcmc7DQo+ID4+ID4+Pj4+PiBPU1BGIExpc3Q7IGlzaXMtd2dAaWV0Zi5vcmc7IGZhbnBlbmdA Y2hpbmFtb2JpbGUuY29tOw0KPiA+PiA+Pj4+Pj4gbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29t DQo+ID4+ID4+Pj4+PiDkuLvpopg6IFJlOiBbT1NQRl0g562U5aSNOiBbSXNpcy13Z10gW3N1bnNl dDRdIElQdjYgcm91dGVyIElEcw0KPiA+PiA+Pj4+Pj4NCj4gPj4gPj4+Pj4+DQo+ID4+ID4+Pj4+ PiBPbiBNYXkgNSwgMjAxNCwgYXQgOTo0OCBQTSwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5j b20+DQo+ID4+IHdyb3RlOg0KPiA+PiA+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+ PiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4+ID4+Pj4+Pj4+IOWPkeS7tuS6ujogSXNpcy13 ZyBbbWFpbHRvOmlzaXMtd2ctYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIGpvZWwNCj4gamFlZ2ds aQ0KPiA+PiA+Pj4+Pj4+PiDlj5HpgIHml7bpl7Q6IDIwMTTlubQ15pyINeaXpSAyMzo1NQ0KPiA+ PiA+Pj4+Pj4+PiDmlLbku7bkuro6IEFjZWUgTGluZGVtOyBYdXhpYW9odTsgR2VvcmdlLCBXZXMN Cj4gPj4gPj4+Pj4+Pj4g5oqE6YCBOiBvc3BmQGlldGYub3JnOyBmYW5wZW5nQGNoaW5hbW9iaWxl LmNvbTsNCj4gaXNpcy13Z0BpZXRmLm9yZzsNCj4gPj4gPj4+Pj4+Pj4gc3Vuc2V0NEBpZXRmLm9y ZzsgbGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tDQo+ID4+ID4+Pj4+Pj4+IOS4u+mimDogUmU6 IFtJc2lzLXdnXSBbc3Vuc2V0NF0gSVB2NiByb3V0ZXIgSURzDQo+ID4+ID4+Pj4+Pj4+DQo+ID4+ ID4+Pj4+Pj4+IE9uIDUvNS8xNCwgOToyOCBBTSwgQWNlZSBMaW5kZW0gd3JvdGU6DQo+ID4+ID4+ Pj4+Pj4+PiBYaWFvaHUg4oCTIHdoYXQgYXJlIHByZWNpc2VseSB0aGUgc2l0dWF0aW9ucyB0aGF0 IHlvdSB0aGluayB5b3UNCj4gPj4gPj4+Pj4+Pj4+IG5lZWQgdGhpcw0KPiA+PiA+Pj4+Pj4+Pj4g SVB2NiBhZGRyZXNzPw0KPiA+PiA+Pj4+Pj4+Pj4gQWNlZQ0KPiA+PiA+Pj4+Pj4+PiBpZiB5b3Un cmUgdXNpbmcgcm91dGVyLWlkJ3MgYXMgZXF1aXZhbGVuY3kgYXMgYW4gaXB2NCB1bmljYXN0DQo+ ID4+YWRkcmVzc2VzLg0KPiA+PiA+Pj4+Pj4+PiB5b3UncmUgZG9pbmcgc28gYXQgeW91ciBwZXJp bCBiZWNhdXNlIHRoZXJlIGlzIHplcm8gYXNzdXJhbmNlDQo+ID4+ID4+Pj4+Pj4+IHRoYXQgdGhv c2UgYWN0dWFsbHkgbWFwLiB0aGUgZmlyc3QgdGltZSB5b3UgaGF2ZSBhIHJvdXRlciBpZCBvZg0K PiA+PiA+Pj4+Pj4+PiAxMTEwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDEwMSB3ZWxsIGJ1bW1l ci4NCj4gPj4gPj4+Pj4+PiBUaGUgSVB2NiByb3V0ZXIgSUQgc3ViLVRMViBvZiB0aGUgSVNJUyBy b3V0ZXIgY2FwYWJpbGl0eSBUTFYNCj4gPj4gPj4+Pj4+PiBtdXN0IGNhcnJ5IGENCj4gPj4gPj4+ Pj4+ICJyb3V0YWJsZSIgSVB2NiBhZGRyZXNzLiBJZiB0aGUgbmFtZSBvZiB0aGUgc3ViLVRMViBz ZWVtcw0KPiA+PiA+Pj4+Pj4gY29uZnVzaW5nLCBpdCBjYW4gYmUgY2hhbmdlZCB0byBJUHY2IGFk ZHJlc3Mgc3ViLVRMVi4NCj4gPj4gPj4+Pj4+DQo+ID4+ID4+Pj4+PiBJbmRlcGVuZGVudCBvZiB3 aGF0IHlvdSBjYWxsIGl0LCB5b3UgZGlkbuKAmXQgYW5zd2VyIG15IHF1ZXN0aW9uLg0KPiA+PiA+ Pj4+Pj4gT3RoZXIgdGhhbiBURSwgd2hhdCB0aGUgdXNlIGNhc2VzIHdoZXJlIGl0IGlzIG5lZWRl ZD8NCj4gPj4gPj4+Pj4+DQo+ID4+ID4+Pj4+PiBBY2VlDQo+ID4+ID4+Pj4+Pg0KPiA+PiA+Pj4+ Pj4NCj4gPj4gPj4+Pj4+PiBCZXN0IHJlZ2FyZHMsDQo+ID4+ID4+Pj4+Pj4gWGlhb2h1DQo+ID4+ ID4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4gSSBkb24ndCBmaW5kIHRoZSBlbWJlZGRpbmcgb2Ygc2Vt YW50aWMgbWVhbmluZyBpbiByb3V0ZXItaWRzIHRvDQo+ID4+ID4+Pj4+Pj4+IGJlIG1vcmUgY29t cGVsbGluZyB0aGVuIGl0IHdhcyBpbiBpcCBhZGRyZXNzZXMuDQo+ID4+ID4+Pj4+Pj4+DQo+ID4+ ID4+Pj4+Pj4+PiBGcm9tOiBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbQ0KPiA+PiA+Pj4+ Pj4gPG1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tPj4NCj4gPj4gPj4+Pj4+Pj4+IERhdGU6IFN1 bmRheSwgTWF5IDQsIDIwMTQgMToyOSBBTQ0KPiA+PiA+Pj4+Pj4+Pj4gVG86ICJHZW9yZ2UsIFdl cyIgPHdlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb20NCj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86d2Vz bGV5Lmdlb3JnZUB0d2NhYmxlLmNvbT4+DQo+ID4+ID4+Pj4+Pj4+PiBDYzogT1NQRiAtIE9TUEYg V0cgTGlzdCA8b3NwZkBpZXRmLm9yZw0KPiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpvc3BmQGlldGYu b3JnPj4sICJpc2lzLXdnQGlldGYub3JnDQo+ID4+ID4+Pj4+Pj4+PiA8bWFpbHRvOmlzaXMtd2dA aWV0Zi5vcmc+IiA8aXNpcy13Z0BpZXRmLm9yZw0KPiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzppc2lz LXdnQGlldGYub3JnPj4sICJmYW5wZW5nQGNoaW5hbW9iaWxlLmNvbQ0KPiA+PiA+Pj4+Pj4+Pj4g PG1haWx0bzpmYW5wZW5nQGNoaW5hbW9iaWxlLmNvbT4iDQo+IDxmYW5wZW5nQGNoaW5hbW9iaWxl LmNvbQ0KPiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpmYW5wZW5nQGNoaW5hbW9iaWxlLmNvbT4+LCAi c3Vuc2V0NEBpZXRmLm9yZw0KPiA+PiA+Pj4+Pj4+Pj4gPG1haWx0bzpzdW5zZXQ0QGlldGYub3Jn PiIgPHN1bnNldDRAaWV0Zi5vcmcNCj4gPj4gPj4+Pj4+Pj4+IDxtYWlsdG86c3Vuc2V0NEBpZXRm Lm9yZz4+LCAibGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tDQo+ID4+ID4+Pj4+Pj4+IDxtYWls dG86bGl6aGVucWlhbmdAY2hpbmFtb2JpbGUuY29tPiINCj4gPj4gPj4+Pj4+Pj4+IDxsaXpoZW5x aWFuZ0BjaGluYW1vYmlsZS5jb20NCj4gPj4gPj4+PiA8bWFpbHRvOmxpemhlbnFpYW5nQGNoaW5h bW9iaWxlLmNvbT4+DQo+ID4+ID4+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW0lzaXMtd2ddIFtzdW5z ZXQ0XSBJUHY2IHJvdXRlciBJRHMNCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+PiAgICAg SGkgV2VzLA0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+Pg0K PiA+PiA+Pj4+Pj4+Pj4gICAgIFRoYW5rcyBmb3IgcG9pbnRpbmcgb3V0IHRoZXNlIHR3byBkcmFm dHMuDQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ ID4+Pj4+Pj4+PiAgICAgVGhlIG1vdGl2YXRpb24gZm9yIHRoZXNlIHR3byBkcmFmdHMNCj4gPj4g Pj4+Pj4+Pj4+DQo+ID4+KGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LWlzaXMt aXB2Ni1yb3V0ZXItaWQtMDAgYW5kDQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+Pj4gaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtb3NwZi1pcHY2LXJvdXRlci1pZC0wMCkg aXMNCj4gPj4gPj4gdmVyeQ0KPiA+PiA+Pj4+Pj4+Pj4gICAgIHNpbXBsZTogdGhlIElQdjYgSVNJ U3xPU1BGIGNhcGFiaWxpdHkgVExWL1JJLUxTQSB3aGljaCBhcmUNCj4gPj4gPj4+Pj4+Pj4+IHVz ZWQNCj4gPj4gPj4gZm9yDQo+ID4+ID4+Pj4+Pj4+PiAgICAgYWR2ZXJ0aXNpbmcgcm91dGVyIGNh cGFiaWxpdGllcyBjYW4gYmUgZmxvb2RlZCBhY3Jvc3MNCj4gPj5hcmVhcywNCj4gPj4gPj4+Pj4+ Pj4+ICAgICBob3dldmVyLCBvbmx5IGEgNC1vY3RlY3Qgcm91dGVyIElEIGlzIGNhcnJpZWQgaW4g dGhlbS4gQXMNCj4gPj5hDQo+ID4+IHJlc3VsdCwNCj4gPj4gPj4+Pj4+Pj4+ICAgICBpdOKAmXMg aGFyZCBmb3Igcm91dGVycyBpbiBvbmUgYXJlYSB0byBlc3RhYmxpc2gNCj4gPj4gPj4+Pj4+Pj4+ IGNvcnJlbGF0aW9ucw0KPiA+PiA+PiBiZXR3ZWVuDQo+ID4+ID4+Pj4+Pj4+PiAgICAgSVB2NiBh ZGRyZXNzZXMgYW5kIGNhcGFiaWxpdGllcyBvZiByb3V0ZXJzIGluIGFub3RoZXINCj4gPj5hcmVh LiBGb3INCj4gPj4gPj4+Pj4+Pj4+ICAgICBleGFtcGxlLCBhc3N1bWUgSVMtSVMgcm91dGVyIEEg aW4gb25lIGFyZWEgaGFzIGVzdGFibGlzaGVkDQo+ID4+ID4+Pj4+Pj4+PiBhDQo+ID4+ID4+IEwz VlBODQo+ID4+ID4+Pj4+Pj4+PiAgICAgc2Vzc2lvbiB3aXRoIElTLUlTIHJvdXRlciBCIGluIGFu b3RoZXIgYXJlYSBvdmVyIHRoZWlyDQo+ID4+b3duIElQdjYNCj4gPj4gPj4+Pj4+Pj4+ICAgICBh ZGRyZXNzZXMuIFdoZW4gcm91dGVyIEEgbmVlZHMgdG8gc2VuZCBMM1ZQTiB0cmFmZmljIHRvDQo+ ID4+ID4+Pj4+Pj4+PiByb3V0ZXIgQg0KPiA+PiA+Pj4+IHZpYQ0KPiA+PiA+Pj4+Pj4+Pj4gICAg IGEgTVBMUy1TUiB0dW5uZWwsIHJvdXRlciBBIHdhbnRzIHRvIGtub3cgd2hldGhlciByb3V0ZXIN Cj4gQg0KPiA+PiA+Pj4+Pj4+Pj4gaGFzDQo+ID4+ID4+Pj4gdGhlDQo+ID4+ID4+Pj4+Pj4+PiAg ICAgRUxDIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1pc2lzLW1wbHMtZWxj LTAwKQ0KPiA+PiA+Pj4+Pj4+Pj4gYmVmb3JlDQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+PiA8aHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtaXNpcy1tcGxzLWVsYy0wMCklMjBiZWZv cmU+DQo+ID4+ID4+Pj4+Pj4+PiAgICAgaW5zZXJ0aW5nIGFuIEVMIGludG8gdGhlIE1QTFMtU1Ig cGFja2V0IC4gSG93ZXZlciwgdGhlDQo+ID4+ID4+IENhcGFiaWxpdHkNCj4gPj4gPj4+Pj4+Pj4+ ICAgICBUTFYgb3JpZ2luYXRlZCBieSByb3V0ZXIgQiBkb2VzbuKAmXQgY2FycmllZCBhbiBJUHY2 DQo+ID4+YWRkcmVzcyBvZg0KPiA+PiBpdHMNCj4gPj4gPj4+Pj4+Pj4+ICAgICBvd24uIEFzIGEg cmVzdWx0LCBpdOKAmXMgaGFyZCBmb3Igcm91dGVyIEEgdG8ga25vdyB0aGUgRUxDDQo+ID4+ID4+ Pj4+Pj4+PiBvZg0KPiA+PiA+PiByb3V0ZXIgQi4NCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+ Pj4+Pg0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4+ICAgICBCZXN0IHJlZ2FyZHMsDQo+ ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+Pj4gICAgIFhpYW9odQ0KPiA+PiA+Pj4+Pj4+Pj4N Cj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+Pj4gICAgICrlj5Hk u7bkuro6Kkdlb3JnZSwgV2VzDQo+IFttYWlsdG86d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbV0N Cj4gPj4gPj4+Pj4+Pj4+ICAgICAq5Y+R6YCB5pe26Ze0OioyMDE05bm0NeaciDLml6UxOjUxDQo+ ID4+ID4+Pj4+Pj4+PiAgICAgKuaUtuS7tuS6ujoqWHV4aWFvaHUNCj4gPj4gPj4+Pj4+Pj4+ICAg ICAq5oqE6YCBOipzdW5zZXQ0QGlldGYub3JnIDxtYWlsdG86c3Vuc2V0NEBpZXRmLm9yZz47DQo+ ID4+ID4+Pj4+Pj4+PiAgICAgZmFucGVuZ0BjaGluYW1vYmlsZS5jb20NCj4gPj4gPj4gPG1haWx0 bzpmYW5wZW5nQGNoaW5hbW9iaWxlLmNvbT47DQo+ID4+ID4+Pj4+Pj4+PiAgICAgbGl6aGVucWlh bmdAY2hpbmFtb2JpbGUuY29tDQo+ID4+ID4+Pj4gPG1haWx0bzpsaXpoZW5xaWFuZ0BjaGluYW1v YmlsZS5jb20+DQo+ID4+ID4+Pj4+Pj4+PiAgICAgKuS4u+mimDoqUmU6IFtzdW5zZXQ0XSBJUHY2 IHJvdXRlciBJRHMNCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+ Pj4NCj4gPj4gPj4+Pj4+Pj4+ICAgICBJIGdvdCBhIGJvdW5jZS1iYWNrIG9uIGFsbCAzIGRyYWZ0 IGFsaWFzZXMsIHRyeWluZyBhZ2Fpbg0KPiA+PndpdGggdGhlDQo+ID4+ID4+Pj4+Pj4+PiAgICAg YXV0aG9yc+KAmXMgZW1haWwgYWRkcmVzc2VzIGRpcmVjdGx5Lg0KPiA+PiA+Pj4+Pj4+Pj4NCj4g Pj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+Pj4gICAgICpGcm9tOiAq PEdlb3JnZT4sICJHZW9yZ2UsIFdlcyINCj4gPj4gPj4gPHdlc2xleS5nZW9yZ2VAdHdjYWJsZS5j b20NCj4gPj4gPj4+Pj4+Pj4+ICAgICA8bWFpbHRvOndlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb20+ Pg0KPiA+PiA+Pj4+Pj4+Pj4gICAgICpEYXRlOiAqVGh1cnNkYXksIE1heSAxLCAyMDE0IGF0IDE6 NDIgUE0NCj4gPj4gPj4+Pj4+Pj4+ICAgICAqVG86ICoiZHJhZnQteHUtaXNpcy1pcHY2LXJvdXRl ci1pZEB0b29scy5pZXRmLm9yZw0KPiA+PiA+Pj4+Pj4+Pj4gICAgIDxtYWlsdG86ZHJhZnQteHUt aXNpcy1pcHY2LXJvdXRlci1pZEB0b29scy5pZXRmLm9yZz4iDQo+ID4+ID4+Pj4+Pj4+PiAgICAg PGRyYWZ0LXh1LWlzaXMtaXB2Ni1yb3V0ZXItaWRAdG9vbHMuaWV0Zi5vcmcNCj4gPj4gPj4+Pj4+ Pj4+ICAgICA8bWFpbHRvOmRyYWZ0LXh1LWlzaXMtaXB2Ni1yb3V0ZXItaWRAdG9vbHMuaWV0Zi5v cmc+PiwNCj4gPj4gPj4+Pj4+Pj4+ICAgICAiZHJhZnQteHUtb3NwZi1pcHY2LXJvdXRlci1pZEB0 b29scy5pZXRmLm9yZw0KPiA+PiA+Pj4+Pj4+Pj4gICAgIDxtYWlsdG86ZHJhZnQteHUtb3NwZi1p cHY2LXJvdXRlci1pZEB0b29scy5pZXRmLm9yZz4iDQo+ID4+ID4+Pj4+Pj4+PiAgICAgPGRyYWZ0 LXh1LW9zcGYtaXB2Ni1yb3V0ZXItaWRAdG9vbHMuaWV0Zi5vcmcNCj4gPj4gPj4+Pj4+Pj4+ICAg ICA8bWFpbHRvOmRyYWZ0LXh1LW9zcGYtaXB2Ni1yb3V0ZXItaWRAdG9vbHMuaWV0Zi5vcmc+Pg0K PiA+PiA+Pj4+Pj4+Pj4gICAgICpDYzogKiJkcmFmdC1mYW4taWRyLWlwdjYtYmdwLWlkQHRvb2xz LmlldGYub3JnDQo+ID4+ID4+Pj4+Pj4+PiAgICAgPG1haWx0bzpkcmFmdC1mYW4taWRyLWlwdjYt YmdwLWlkQHRvb2xzLmlldGYub3JnPiINCj4gPj4gPj4+Pj4+Pj4+ICAgICA8ZHJhZnQtZmFuLWlk ci1pcHY2LWJncC1pZEB0b29scy5pZXRmLm9yZw0KPiA+PiA+Pj4+Pj4+Pj4gICAgIDxtYWlsdG86 ZHJhZnQtZmFuLWlkci1pcHY2LWJncC1pZEB0b29scy5pZXRmLm9yZz4+LA0KPiA+PiA+Pj4+Pj4+ Pj4gICAgICJzdW5zZXQ0QGlldGYub3JnIDxtYWlsdG86c3Vuc2V0NEBpZXRmLm9yZz4iDQo+ID4+ ID4+IDxzdW5zZXQ0QGlldGYub3JnDQo+ID4+ID4+Pj4+Pj4+PiAgICAgPG1haWx0bzpzdW5zZXQ0 QGlldGYub3JnPj4NCj4gPj4gPj4+Pj4+Pj4+ICAgICAqU3ViamVjdDogKltzdW5zZXQ0XSBJUHY2 IHJvdXRlciBJRHMNCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+ Pj4NCj4gPj4gPj4+Pj4+Pj4+ICAgICBJIHNlZSB0aGF0IHlvdSBoYXZlIHN1Ym1pdHRlZCB0d28g ZHJhZnRzIGZvciBJUHY2IHJvdXRlcg0KPiA+PiA+Pj4+Pj4+Pj4gSURzIGluDQo+ID4+ID4+IElT SVMNCj4gPj4gPj4+Pj4+Pj4+ICAgICBhbmQgT1NQRiwgbm90aW5nIHRoYXQgdGhlIGV4aXN0aW5n IHJvdXRlciBJRCBpcyBvbmx5IDQNCj4gPj5vY3RldHMuDQo+ID4+IFRoaXMNCj4gPj4gPj4+Pj4+ Pj4+ICAgICBoYXMgYWxzbyBjb21lIHVwIGluIElEUiBmb3IgQkdQLiBUaGUgYXV0aG9ycyBvZiB0 aGF0DQo+ID4+ZHJhZnQgYXJlDQo+ID4+ID4+Pj4+Pj4+PiAgICAgY29waWVkLiBJ4oCZbGwgZ2l2 ZSB5b3UgYSBzaW1pbGFyIHNldCBvZiBmZWVkYmFjayB0byB3aGF0IEkNCj4gPj4gPj4+Pj4+Pj4+ IGdhdmUgdGhlbSAtDQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+ Pj4+DQo+ID4+ID4+Pj4+Pj4+PiAgICAgSXQgaXMgaW1wb3J0YW50IHRvIGRpc3Rpbmd1aXNoIGJl dHdlZW4gcGxhY2VzIHdoZXJlIGENCj4gPj51bmlxdWUNCj4gPj4gPj4+Pj4+Pj4+ICAgICBpZGVu dGlmaWVyIGlzIG5lZWRlZCwgYW5kIGJ5ICpjb252ZW50aW9uKiBhbiBJUHY0IGFkZHJlc3MNCj4g Pj4gPj4gYXNzaWduZWQNCj4gPj4gPj4+Pj4+Pj4+ICAgICB0byB0aGUgZGV2aWNlIGhhcyBiZWVu IHVzZWQgdG8gcHJvdmlkZSB0aGF0IHVuaXF1ZSBJRCwgdnMuDQo+ID4+IHBsYWNlcw0KPiA+PiA+ Pj4+Pj4+Pj4gICAgIHdoZXJlIHRoZSBhY3R1YWwgSVAgYWRkcmVzcyBoYXMgc29tZSBzb3J0IG9m IGltcG9ydGFuY2UgdG8NCj4gPj4gdGhlDQo+ID4+ID4+Pj4+Pj4+PiAgICAgcHJvdG9jb2wgKEku ZS4gVGhhdCBpbmZvcm1hdGlvbiBtdXN0IGJlIGF2YWlsYWJsZSB0byB0YWtlDQo+ID4+ID4+Pj4+ Pj4+PiBhY3Rpb24NCj4gPj4gPj4gb24pLg0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4+ ICAgICBJbiBvdGhlciB3b3JkcywgaXMgdGhlIHByb3RvY29sIHJlcXVpcmVtZW50IHRoYXQgdGhl IElEIGJlDQo+ID4+ID4+IHVuaXF1ZQ0KPiA+PiA+Pj4+Pj4+Pj4gICAgIGFjcm9zcyBzb21lIGRv bWFpbiwgYnV0IHRoYXQgdGhlIGFjdHVhbCB2YWx1ZSBkb2VzIG5vdA0KPiA+PiA+Pj4+Pj4+Pj4g bWF0dGVyLA0KPiA+PiA+PiBvciBpcw0KPiA+PiA+Pj4+Pj4+Pj4gICAgIHRoZSBwcm90b2NvbCBy ZXF1aXJlbWVudCB0aGF0IHRoZSB2YWx1ZSBtdXN0IGNvcnJlc3BvbmQNCj4gdG8NCj4gPj4gPj4+ PiBzb21ldGhpbmcNCj4gPj4gPj4+Pj4+Pj4+ICAgICBvbiB0aGUgcm91dGVyPyBJbiBtYW55IG9m IHRoZSBmb3JtZXIgY2FzZXMsIHRoZSBmYWN0IHRoYXQNCj4gPj4gPj4+Pj4+Pj4+IHRoZQ0KPiA+ PiA+PiB2YWx1ZQ0KPiA+PiA+Pj4+Pj4+Pj4gICAgIGlzbuKAmXQgcmVsZXZhbnQgaGFzIGJlZW4g dXNlZCB0byBtYWtlIHJlY29tbWVuZGF0aW9ucw0KPiB0aGF0DQo+ID4+ID4+Pj4+Pj4+PiBhcmUN Cj4gPj4gPj4+PiBlYXNpZXINCj4gPj4gPj4+Pj4+Pj4+ICAgICBmb3IgaHVtYW5zIHRvIGRlYWwg d2l0aCAoSS5lLiBUeWluZyB0aGUgcm91dGVyIElEIHRvIGFuIElQDQo+ID4+ID4+IGFkZHJlc3Mp DQo+ID4+ID4+Pj4+Pj4+PiAgICAgYnV0IHRoYXQgdmFsdWUgYXMgYSBodW1hbi1yZWFkYWJsZSBz ZXQgb2YgaW5mbyBkb2VzIG5vdA0KPiA+PiA+PiBuZWNlc3NhcmlseQ0KPiA+PiA+Pj4+Pj4+Pj4g ICAgIGp1c3RpZnkgIGNoYW5nZXMgdG8gdGhlIHByb3RvY29sIHRvIHN1cHBvcnQgdGhhdA0KPiA+ PiA+Pj4+Pj4+Pj4gY29udmVudGlvbiBhcw0KPiA+PiA+PiB3ZQ0KPiA+PiA+Pj4+Pj4+Pj4gICAg IG1vdmUgdG8gSVB2Ni4NCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+PiAgICAgSSB3b3Vs ZCBhcmd1ZSB0aGF0IHRoZSByb3V0ZXIgSUQgdXNlZCBpbiByb3V0aW5nIHByb3RvY29scw0KPiA+ PiBtdXN0DQo+ID4+ID4+Pj4+Pj4+PiAgICAgbWVyZWx5IGJlIHVuaXF1ZSwgYnV0IGl0IGRvZXNu 4oCZdCBoYXZlIHRvIGJlIGFuIElQIGFkZHJlc3MNCj4gPj5hdA0KPiA+PiBhbGwuDQo+ID4+ID4+ Pj4+Pj4+PiAgICAgVGh1cyBpdCBpcyBub3Qgc3RyaWN0bHkgbmVjZXNzYXJ5IHRvIGNyZWF0ZSBh IG5ldyBmaWVsZA0KPiA+PnRvIGNhcnJ5DQo+ID4+ID4+Pj4+Pj4+PiAgICAgSVB2NiBhZGRyZXNz ZXMgd2hlbiBvcGVyYXRpbmcgd2l0aG91dCBJUHY0IGFkZHJlc3NlcyBvbg0KPiBhDQo+ID4+ID4+ Pj4gbmV0d29yay4NCj4gPj4gPj4+Pj4+Pj4+ICAgICBJZiB5b3UgYmVsaWV2ZSBvdGhlcndpc2Us IHRoZSBqdXN0aWZpY2F0aW9uIG5lZWRzIHRvIGJlDQo+ID4+ID4+IGRvY3VtZW50ZWQNCj4gPj4g Pj4+Pj4+Pj4+ICAgICBpbiB0aGUgZHJhZnQuDQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+ Pj4NCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+PiAgICAgVGhlcmUgYXJlIG1hbnkgcGxh Y2VzIGluIElFVEYgcHJvdG9jb2xzIHdoZXJlIGEgMzIgYml0DQo+ID4+dW5pcXVlDQo+ID4+ID4+ Pj4+Pj4+PiAgICAgaWRlbnRpZmllciBpcyBuZWVkZWQsIGFuZCBieSBjb252ZW50aW9uIGFuIElQ djQgYWRkcmVzcw0KPiA+PiA+Pj4+Pj4+Pj4gaGFzDQo+ID4+ID4+IGJlZW4NCj4gPj4gPj4+Pj4+ Pj4+ICAgICB1c2VkLiBJdCB3b3VsZCBiZSBmYXIgbW9yZSB1c2VmdWwgdG8gd3JpdGUgYSBnZW5l cmFsIGRyYWZ0DQo+ID4+ID4+Pj4+Pj4+PiAgICAgaWRlbnRpZnlpbmcgdGhpcyBwcm9ibGVtIGFu ZCBkaXNjdXNzaW5nIHNldmVyYWwgc29sdXRpb25zLA0KPiA+PiA+PiBpbmNsdWRpbmcNCj4gPj4g Pj4+Pj4+Pj4+ICAgICBzaW1wbHkgZ2VuZXJhdGluZyB1bmlxdWUgSURzIG1hbnVhbGx5LCBzeXN0 ZW1hdGljYWxseQ0KPiA+PiA+PiBnZW5lcmF0aW5nIGENCj4gPj4gPj4+Pj4+Pj4+ICAgICByYW5k b20gSUQsIGV0Yy4gIHRoZSBwbGFjZSBmb3Igc3VjaCBhIGRyYWZ0IG1heSBiZSBpbg0KPiA+PlN1 bnNldDQsDQo+ID4+ID4+Pj4+Pj4+PiAgICAgZWl0aGVyIGFzIGEgcGFydCBvZiB0aGUgZXhpc3Rp bmcgZ2FwIGFuYWx5c2lzIGRyYWZ0IG9yIGFzDQo+ID4+YW5vdGhlcg0KPiA+PiA+Pj4+Pj4+Pj4g ICAgIHN0YW5kYWxvbmUgZHJhZnQuDQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+Pj4NCj4g Pj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+PiAgICAgVGhlcmUgd2FzIHJhdGhlciBhIGxvbmcg ZGlzY3Vzc2lvbiBhYm91dCB0aGlzIG9uIElEUiwNCj4gPj50aHJlYWQNCj4gPj4gPj4+Pj4+Pj4+ ICAgICBoZXJlOg0KPiA+PiA+Pj4+Pj4+Pj4gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9h cmNoL3NlYXJjaC8/cWRyPWEmZW1haWxfbGlzdD1pZHINCj4gPj4gPj4+Pj4+Pj4+ICZxDQo+ID4+ ID4+Pj4+Pj4+PiA9JQ0KPiA+PiA+Pj4+Pj4+Pj4gMjINCj4gPj4gPj4+Pj4+Pj4+ICU1DQo+ID4+ ID4+Pj4+Pj4+PiBCaWRyJTVEKyU1QnY2b3BzJTVEK0JHUCtJZGVudGlmaWVyJTIyJmFzPTEmZ2J0 PTENCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4g Pj4+Pj4+Pj4+ICAgICBBbmQgaW4gdGhlIElEUiBtZWV0aW5nLCBtaW51dGVzOg0KPiA+PiA+Pj4+ Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4+DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv ODkvbWludXRlcy9taW51dGVzLTg5LWlkcg0KPiA+PiA+Pj4+Pj4+Pj4gKHNlZSBwYWdlIDExKQ0K PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4+ Pj4+Pj4gICAgIEnigJlkIGVuY291cmFnZSB0aGUgYXV0aG9ycyBvZiB0aGVzZSBkcmFmdHMgdG8g d29yayB0b2dldGhlcg0KPiA+PiA+Pj4+Pj4+Pj4gb24NCj4gPj4gPj4gdGhpcy4NCj4gPj4gPj4+ Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4+ICAg ICBUaGFua3MsDQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4+ DQo+ID4+ID4+Pj4+Pj4+PiAgICAgV2VzIEdlb3JnZQ0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+ Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+Pj4gICAgIEFueXRoaW5nIGJlbG93 IHRoaXMgbGluZSBoYXMgYmVlbiBhZGRlZCBieSBteSBjb21wYW554oCZcw0KPiA+PiA+Pj4+Pj4+ Pj4gbWFpbA0KPiA+PiA+Pj4+IHNlcnZlciwNCj4gPj4gPj4+Pj4+Pj4+ICAgICBJIGhhdmUgbm8g Y29udHJvbCBvdmVyIGl0Lg0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4+ICAgICAtLS0t LS0tLS0tLQ0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+Pg0K PiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+Pj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+ID4+Pj4+Pj4+PiAtLQ0K PiA+PiA+Pj4+Pj4+Pj4gLS0NCj4gPj4gPj4+Pj4+Pj4+IC0tDQo+ID4+ID4+Pj4+Pj4+PiAtLQ0K PiA+PiA+Pj4+Pj4+Pj4gLS0NCj4gPj4gPj4+Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+PiAgICAgVGhp cyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZQ0KPiA+ PiA+Pj4+Pj4+Pj4gV2FybmVyDQo+ID4+ID4+Pj4gQ2FibGUNCj4gPj4gPj4+Pj4+Pj4+ICAgICBw cm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwNCj4gPj5jb25maWRl bnRpYWwsIG9yDQo+ID4+ID4+Pj4+Pj4+PiAgICAgc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25n aW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzDQo+ID4+ID4+IEUtbWFpbCBpcw0KPiA+PiA+ Pj4+Pj4+Pj4gICAgIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVh bCBvciBlbnRpdHkNCj4gPj50byB3aGljaA0KPiA+PiBpdA0KPiA+PiA+Pj4+Pj4+Pj4gICAgIGlz IGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZg0KPiA+ PnRoaXMNCj4gPj4gRS1tYWlsLA0KPiA+PiA+Pj4+Pj4+Pj4gICAgIHlvdSBhcmUgaGVyZWJ5IG5v dGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sDQo+ID4+ZGlzdHJpYnV0aW9uLA0KPiA+PiA+ Pj4+Pj4+Pj4gICAgIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUg Y29udGVudHMgb2YNCj4gPj5hbmQNCj4gPj4gPj4+Pj4+Pj4+ICAgICBhdHRhY2htZW50cyB0byB0 aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkNCj4gPj5iZQ0KPiA+PiA+ Pj4+Pj4+Pj4gICAgIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBp biBlcnJvciwNCj4gPj5wbGVhc2Ugbm90aWZ5DQo+ID4+ID4+Pj4+Pj4+PiAgICAgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZQ0KPiBvcmlnaW5hbA0KPiA+ PiA+Pj4+Pj4+Pj4gYW5kDQo+ID4+ID4+Pj4gYW55DQo+ID4+ID4+Pj4+Pj4+PiAgICAgY29weSBv ZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0KPiA+PiA+Pj4+Pj4+Pj4NCj4gPj4gPj4+ Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4+Pg0KPiA+PiA+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gPj4+Pj4+Pj4+IHN1bnNldDQgbWFp bGluZyBsaXN0DQo+ID4+ID4+Pj4+Pj4+PiBzdW5zZXQ0QGlldGYub3JnDQo+ID4+ID4+Pj4+Pj4+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1bnNldDQNCj4gPj4gPj4+ Pj4+Pj4+DQo+ID4+ID4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPj4gPj4+Pj4+PiBPU1BGIG1haWxpbmcgbGlzdA0KPiA+PiA+Pj4+Pj4+ IE9TUEZAaWV0Zi5vcmcNCj4gPj4gPj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29zcGYNCj4gPj4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPj4gPj4+Pj4gT1NQRiBtYWlsaW5nIGxpc3QNCj4gPj4gPj4+ Pj4gT1NQRkBpZXRmLm9yZw0KPiA+PiA+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29zcGYNCj4gPj4gPj4+Pj4NCj4gPj4gPj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4+PiBPU1BGIG1haWxpbmcgbGlzdA0K PiA+PiA+Pj4gT1NQRkBpZXRmLm9yZw0KPiA+PiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vc3BmDQo+ID4+ID4+DQo+ID4+ID4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4+IElzaXMtd2cgbWFpbGluZyBsaXN0 DQo+ID4+ID4+IElzaXMtd2dAaWV0Zi5vcmcNCj4gPj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pc2lzLXdnDQo+ID4+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gPiBJc2lzLXdnIG1haWxpbmcgbGlzdA0KPiA+ PiA+IElzaXMtd2dAaWV0Zi5vcmcNCj4gPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lzaXMtd2cNCj4gPg0KDQo= From nobody Mon Jun 9 12:39:52 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447D41A035F for ; Mon, 9 Jun 2014 12:39:46 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daA1d-MmHOqd for ; Mon, 9 Jun 2014 12:39:42 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CCCA1A036B for ; Mon, 9 Jun 2014 12:39:42 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-ae-5395bcc27362 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F4.7A.27529.2CCB5935; Mon, 9 Jun 2014 15:55:15 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Mon, 9 Jun 2014 15:39:37 -0400 From: Acee Lindem To: OSPF - OSPF WG List Thread-Topic: OSPFv2 Segment Routing Draft WG Document Acceptance Poll Thread-Index: AQHPhBqMWBcp+0ROV0Wo4LkaaOkZsA== Date: Mon, 9 Jun 2014 19:39:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_CFBB5B8530F20aceelindemericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyuXSPn+7hPVODDd5eFLZouXeP3YHRY8mS n0wBjFFcNimpOZllqUX6dglcGXvndzAWnOCrWDLxKXsD42meLkZODgkBE4kPcxrYIWwxiQv3 1rN1MXJxCAkcZZTYsWUlM4SzjFFiQu8BNpAqNgEdieeP/jGD2CIC6hKrJ+9mBbGFBZwklkza DTSJAyjuLrHjkwZEiZ7Ek0frwBawCKhIbPtxjwmkhFfAVGLbEheQMCPQ3u+n1jCB2MwC4hK3 nsxngrhHQGLJnvPMELaoxMvH/8A2iQKNfHccpkZRYl//dHaI3iiJlR1HwK7kFRCUODnzCcsE RuFZSMbOQlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceQ/VaS7z8upsRWc0CRo5VjBylxall uelGBpsYgXFyTIJNdwfjnpeWhxgFOBiVeHgXtE4NFmJNLCuuzD3EKM3BoiTOq32zKlhIID2x JDU7NbUgtSi+qDQntfgQIxMHp1QDo4ZbsHx50KSNDF5ea7Mj+v6Y7j/XMbnn3pVPZ7b7My1s axAUd+zckBibdCh7l41pBdPDXc0nOj8/lDLreLXvy1Mjj6DQtR0qypxdZ4Pqv9QeXuwWZdRg vTFa8OYy2VfJzjGcWyd1BVfmXL5+gHNvZflBg/tPon6k3pvWb+rnVxw+JWl15u0HSizFGYmG WsxFxYkAIfNXN3QCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/-DRTH76xXNGL6uakEAJzB54mgaM Subject: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jun 2014 19:39:46 -0000 --_000_CFBB5B8530F20aceelindemericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Given the progress made in the SRING WG on problem statement and use caseWG= document adoption, Abhay and I now feel we can start a 1 week poll on adop= tion of the corresponding OSPF document. http://www.ietf.org/id/draft-psenak-ospf-segment-routing-extensions-05.txt Please indicate your support or opposition to WG adoption. Thanks, Abhay and Acee P.S. Assuming adoption of the OSPFv2 draft, we will poll for acceptance of = the OSPFv3 draft. --_000_CFBB5B8530F20aceelindemericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6834022DD9C00A42ACC4C68F7A8CFE0A@ericsson.com> Content-Transfer-Encoding: quoted-printable
Given the progress made in the SRING WG on problem statement and use c= aseWG document adoption, Abhay and I now feel we can start a 1 week poll on= adoption of the corresponding OSPF document. 


Please indicate your support or opposition to WG adoption.

Thanks,
Abhay and Acee
P.S. Assuming adoption of the OSPFv2 draft, we will poll for acceptanc= e of the OSPFv3 draft. 

--_000_CFBB5B8530F20aceelindemericssoncom_-- From nobody Tue Jun 10 02:03:48 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E2C1A02BA for ; Tue, 10 Jun 2014 02:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHTHmvYunOas for ; Tue, 10 Jun 2014 02:03:44 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798E71A01EB for ; Tue, 10 Jun 2014 02:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=692; q=dns/txt; s=iport; t=1402391024; x=1403600624; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=36mXxtUerEnqrWhh9Sge4HIZEG95WZZ1DNi7aymleRQ=; b=kFlsx+FQt53G/+9XxOhx43rA0h+otu10ZBWlVE9TCWYcuqgBY3/ygtT+ 8Dn4r/AZFe9Jtf+kscK/rK+KyUhnDEn5tfoZR77PXJpa+KKGaLXfzANtp GaI5FcBZ/uj2aB6lritE5iix2Y8KRVJPtcbYrVfZ06L/sh705PNU6zsHw w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQKAJfJllOtJssW/2dsb2JhbABZg1+rOgEBAQEBAQUBkVSHMgoBgSN1hAMBAQEEAQEBNTYKEQsYCRYPCQMCAQIBFTAGAQwGAgEBBYg5DcsEF4VdiRaEQQEDmiGGdoxPgz47Lw X-IronPort-AV: E=Sophos;i="4.98,1008,1392163200"; d="scan'208";a="81161994" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 10 Jun 2014 09:03:41 +0000 Received: from [10.55.51.202] (ams-ppsenak-8719.cisco.com [10.55.51.202]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5A93fZb015416; Tue, 10 Jun 2014 09:03:41 GMT Message-ID: <5396C9EF.9070103@cisco.com> Date: Tue, 10 Jun 2014 11:03:43 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Acee Lindem , OSPF - OSPF WG List References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/-j_ytf5v44DHplfST-vx8262T2o Subject: Re: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2014 09:03:46 -0000 support as author Peter On 6/9/14 21:39 , Acee Lindem wrote: > Given the progress made in the SRING WG on problem statement and use > caseWG document adoption, Abhay and I now feel we can start a 1 week > poll on adoption of the corresponding OSPF document. > > http://www.ietf.org/id/draft-psenak-ospf-segment-routing-extensions-05.txt > > Please indicate your support or opposition to WG adoption. > > Thanks, > Abhay and Acee > P.S. Assuming adoption of the OSPFv2 draft, we will poll for acceptance > of the OSPFv3 draft. > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From nobody Tue Jun 10 02:10:11 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284311A0367 for ; Tue, 10 Jun 2014 02:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SBgR53t1wFq for ; Tue, 10 Jun 2014 02:10:08 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F2A1A035B for ; Tue, 10 Jun 2014 02:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=719; q=dns/txt; s=iport; t=1402391408; x=1403601008; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+7LJWPeMn6bc32Bkj0ijqkgdqPoi8hw4biuo+NAiIYY=; b=GrTnFcTAklW9WmFdtQPArMmuSsK5JPkAhrFl9EKZSEiTvyy0lUXV+8l1 jcVZJJ2w6YEfL80Tw/DMdTzixtOD5WjgDdvubK/Y3roKbBAz8M1CxIKoM +12sw0OvASRh6NMNTiGctWFT/w2jAevzhAf3c/od82pJgh28LEpaxITQ5 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0LABbKllOtJA2N/2dsb2JhbABZgw1SWaphAQEBAQEBBQGRVIc8AYENFnWEAwEBAQMBAQEBNzQLBQsCAQg2ECcLJQIEDgUJiDEIDcsHF4VdiFwzB4MrgRYEmiGTRYM8bIFD X-IronPort-AV: E=Sophos;i="4.98,1008,1392163200"; d="scan'208";a="332019271" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP; 10 Jun 2014 09:10:08 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5A9A7fl002814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jun 2014 09:10:07 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.223]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 10 Jun 2014 04:10:07 -0500 From: "Stefano Previdi (sprevidi)" To: Acee Lindem Thread-Topic: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll Thread-Index: AQHPhIvFwDrqGw6t6UaCGDKF8bswrQ== Date: Tue, 10 Jun 2014 09:10:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.203.119] Content-Type: text/plain; charset="us-ascii" Content-ID: <8BE7B2AF0253BE49B2EE15B353DA1E8A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/D-Xswfa8KbBVwF8jAfUzUL4WWFc Cc: OSPF - OSPF WG List Subject: Re: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2014 09:10:10 -0000 support as co-author. s. On Jun 9, 2014, at 9:39 PM, Acee Lindem wrote: > Given the progress made in the SRING WG on problem statement and use case= WG document adoption, Abhay and I now feel we can start a 1 week poll on ad= option of the corresponding OSPF document.=20 >=20 > http://www.ietf.org/id/draft-psenak-ospf-segment-routing-extensions-05.tx= t >=20 > Please indicate your support or opposition to WG adoption. >=20 > Thanks, > Abhay and Acee > P.S. Assuming adoption of the OSPFv2 draft, we will poll for acceptance o= f the OSPFv3 draft.=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From nobody Tue Jun 10 02:21:04 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891E61A04CA for ; Tue, 10 Jun 2014 02:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUBWCE99c0T2 for ; Tue, 10 Jun 2014 02:21:02 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB591A04B8 for ; Tue, 10 Jun 2014 02:21:00 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s5A9Ktbi000258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Jun 2014 04:20:56 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s5A9Ks5I002625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jun 2014 11:20:54 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.52]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 10 Jun 2014 11:20:20 +0200 From: "Henderickx, Wim (Wim)" To: Acee Lindem , OSPF - OSPF WG List Thread-Topic: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll Thread-Index: AQHPhBqMWBcp+0ROV0Wo4LkaaOkZsJtqEiiA Date: Tue, 10 Jun 2014 09:20:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_CFBC9A64D5440wimhenderickxalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/YjW4RFHoeg61PQc8CwQFleOsuIE Subject: Re: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2014 09:21:03 -0000 --_000_CFBC9A64D5440wimhenderickxalcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support as co-author From: Acee Lindem > Date: Monday 9 June 2014 21:39 To: OSPF - OSPF WG List > Subject: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll Given the progress made in the SRING WG on problem statement and use caseWG= document adoption, Abhay and I now feel we can start a 1 week poll on adop= tion of the corresponding OSPF document. http://www.ietf.org/id/draft-psenak-ospf-segment-routing-extensions-05.txt Please indicate your support or opposition to WG adoption. Thanks, Abhay and Acee P.S. Assuming adoption of the OSPFv2 draft, we will poll for acceptance of = the OSPFv3 draft. --_000_CFBC9A64D5440wimhenderickxalcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6529810EDE73B342AE8383CA1EC6B339@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
Support as co-author

From: Acee Lindem <acee.lindem@ericsson.com>
Date: Monday 9 June 2014 21:39
To: OSPF - OSPF WG List <ospf@ietf.org>
Subject: [OSPF] OSPFv2 Segment Rout= ing Draft WG Document Acceptance Poll

Given the progress made in the SRING WG on problem statement and use c= aseWG document adoption, Abhay and I now feel we can start a 1 week poll on= adoption of the corresponding OSPF document. 


Please indicate your support or opposition to WG adoption.

Thanks,
Abhay and Acee
P.S. Assuming adoption of the OSPFv2 draft, we will poll for acceptanc= e of the OSPFv3 draft. 

 --_000_CFBC9A64D5440wimhenderickxalcatellucentcom_-- From nobody Tue Jun 10 02:21:59 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AF21A04F6 for ; Tue, 10 Jun 2014 02:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dudGYDeKaDBe for ; Tue, 10 Jun 2014 02:21:56 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A44A1A04CA for ; Tue, 10 Jun 2014 02:21:55 -0700 (PDT) Received: from [109.144.197.18] (helo=[10.210.205.254]) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WuIFc-0005z6-KS; Tue, 10 Jun 2014 10:21:52 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_A0EE4A93-6C63-4D53-9251-E30786264415" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Rob Shakir In-Reply-To: Date: Tue, 10 Jun 2014 10:21:53 +0100 Message-Id: <9243C02B-94FD-492D-B4CC-65FEE9FE7A11@rob.sh> References: To: Acee Lindem X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/l3bAyC8BKB-EfnCfwrb4DNBB5JY Cc: OSPF - OSPF WG List Subject: Re: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2014 09:21:57 -0000 --Apple-Mail=_A0EE4A93-6C63-4D53-9251-E30786264415 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 9 Jun 2014, at 20:39, Acee Lindem wrote: > Given the progress made in the SRING WG on problem statement and use = caseWG document adoption, Abhay and I now feel we can start a 1 week = poll on adoption of the corresponding OSPF document.=20 >=20 > = http://www.ietf.org/id/draft-psenak-ospf-segment-routing-extensions-05.txt= >=20 > Please indicate your support or opposition to WG adoption. Hi Acee, Support as a co-author. Cheers, r. --Apple-Mail=_A0EE4A93-6C63-4D53-9251-E30786264415 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 9 Jun 2014, at 20:39, Acee Lindem <acee.lindem@ericsson.com> wrote:

Given the progress made in the SRING WG on problem statement and use caseWG document adoption, Abhay and I now feel we can start a 1 week poll on adoption of the corresponding OSPF document. 


Please indicate your support or opposition to WG adoption.

Hi Acee,

Support as a co-author.

Cheers,
r.

--Apple-Mail=_A0EE4A93-6C63-4D53-9251-E30786264415-- From nobody Tue Jun 10 04:36:34 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFEC1A007F for ; Tue, 10 Jun 2014 04:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqzME9ZVtieT for ; Tue, 10 Jun 2014 04:36:14 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 078F31A0047 for ; Tue, 10 Jun 2014 04:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3287; q=dns/txt; s=iport; t=1402400174; x=1403609774; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=yVwmtROZfdlzyaRVDgBKe2e2WnXmPiuAImW9oY0F3Kk=; b=Upr9lICFKEcnlNLSpOW4HYPgydtn3fhwo2yQive//tqeSwq358onrzYx TRof736ASVAGH9Zb4QJtMdsAZrR/wgqJ0SUFobeFdsd4T4nM9vlLEOw6L pBWkG/UJ1eft7jZJLY3Xlh+7YpjSfYW2ACrVnCllaDa9jDEt9AY11t6mo U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFADPtllOtJA2L/2dsb2JhbABZgkZHUlnDfgGBCxZ1hAMBAQEEgQkCAQgEDQMBAigHMhQJCAIEARIJiDkNyzoXjlsYhEEEmiGTRYM8bIFD X-IronPort-AV: E=Sophos;i="4.98,1008,1392163200"; d="scan'208,217";a="331768102" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-1.cisco.com with ESMTP; 10 Jun 2014 11:35:48 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s5ABZmIG020891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jun 2014 11:35:48 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.31]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 10 Jun 2014 06:35:47 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: Acee Lindem , OSPF - OSPF WG List Thread-Topic: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll Thread-Index: AQHPhBqMWBcp+0ROV0Wo4LkaaOkZsJtqSMqA Date: Tue, 10 Jun 2014 11:35:46 +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/14.4.2.140509 x-originating-ip: [10.21.125.118] Content-Type: multipart/alternative; boundary="_000_CFBC5F1410BE1naikumarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/UAPAa33_WrJpZ0DUmawkBm8ayok Subject: Re: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2014 11:36:16 -0000 --_000_CFBC5F1410BE1naikumarciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support Thanks, Nagendra From: Acee Lindem > Date: Monday, June 9, 2014 at 3:39 PM To: OSPF - OSPF WG List > Subject: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll Given the progress made in the SRING WG on problem statement and use caseWG= document adoption, Abhay and I now feel we can start a 1 week poll on adop= tion of the corresponding OSPF document. http://www.ietf.org/id/draft-psenak-ospf-segment-routing-extensions-05.txt Please indicate your support or opposition to WG adoption. Thanks, Abhay and Acee P.S. Assuming adoption of the OSPFv2 draft, we will poll for acceptance of = the OSPFv3 draft. --_000_CFBC5F1410BE1naikumarciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Support

Thanks,
Nagendra

From: Acee Lindem <acee.lindem@ericsson.com>
Date: Monday, June 9, 2014 at 3:39 = PM
To: OSPF - OSPF WG List <ospf@ietf.org>
Subject: [OSPF] OSPFv2 Segment Rout= ing Draft WG Document Acceptance Poll

Given the progress made in the SRING WG on problem statement and use c= aseWG document adoption, Abhay and I now feel we can start a 1 week poll on= adoption of the corresponding OSPF document. 


Please indicate your support or opposition to WG adoption.

Thanks,
Abhay and Acee
P.S. Assuming adoption of the OSPFv2 draft, we will poll for acceptanc= e of the OSPFv3 draft. 

 --_000_CFBC5F1410BE1naikumarciscocom_-- From nobody Tue Jun 10 05:13:20 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7671A0086 for ; Tue, 10 Jun 2014 05:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBAQiZaIPoIC for ; Tue, 10 Jun 2014 05:13:16 -0700 (PDT) Received: from bgl-iport-4.cisco.com (bgl-iport-4.cisco.com [72.163.197.28]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12DFA1A007D for ; Tue, 10 Jun 2014 05:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=695; q=dns/txt; s=iport; t=1402402396; x=1403611996; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=g5xwMUL8w0f0dnq/HMgHC3Bb8edaP+y9Z29hcrdgea0=; b=S/vy6yVbt+1nYta3WRMzI4KiQ/vededgacuJLWzIViVC1/487SjoEC1V noLHsVESoOZWyiecRo1xR3/mR5GgeqsM+W/u6cv2QGbwq7WvygdZHv1Kc FScMrCkkCpySq86OJ3pB326jjLPntg61uC8elhNyR1G6rNfBkbRORv4N9 Y=; X-IronPort-AV: E=Sophos;i="4.98,1008,1392163200"; d="scan'208";a="11213739" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-4.cisco.com with ESMTP; 10 Jun 2014 12:13:13 +0000 Received: from SHTSUCHI-M-V1EK.CISCO.COM (dhcp-10-141-45-36.cisco.com [10.141.45.36]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5ACDCxU026840; Tue, 10 Jun 2014 12:13:12 GMT Message-ID: <5396F659.7060308@cisco.com> Date: Tue, 10 Jun 2014 21:13:13 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: acee.lindem@ericsson.com, ospf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/f2RwKcG0qYZRFT6IaURbXmduh90 Subject: Re: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2014 12:13:18 -0000 support! Regards, -Shishio (2014/06/10 4:39), Acee Lindem wrote: > Given the progress made in the SRING WG on problem statement and use caseWG document adoption, Abhay and I now feel we can start a 1 week poll on adoption of the corresponding OSPF document. > > http://www.ietf.org/id/draft-psenak-ospf-segment-routing-extensions-05.txt > > Please indicate your support or opposition to WG adoption. > > Thanks, > Abhay and Acee > P.S. Assuming adoption of the OSPFv2 draft, we will poll for acceptance of the OSPFv3 draft. > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > From nobody Tue Jun 10 05:15:00 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C9D1A009C for ; Tue, 10 Jun 2014 05:14:57 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQEQWF4CQWWc for ; Tue, 10 Jun 2014 05:14:56 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 577AD1A009A for ; Tue, 10 Jun 2014 05:14:56 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id wn1so495904obc.9 for ; Tue, 10 Jun 2014 05:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MFYO4wHHNGalAZ4Pvc8mRHB/AmnKwL+pCJ88a/fsY3w=; b=UTUBXBxHvgYJP2XsoGRgpkgqZYQy9zpLW0ZFVKezcHuMoryywG686KAqAs2xxjXjEC SyyT07oaYSr24NlqotrJbdCuR3eaYijdx46yIJitWVJuRomuZLYNREOTGsj/wgPZgU6Q ei8NNYwrt56xaEH69jYled0mercEraKaQRhfmb98iZhrX43MAWpfJ5ybeBfiudz/0kqe +0YbP4I5rddFcPqk6a8OJ2+ayb64jR8vjNx8kun05nHYGVSfr/O4GwGk4h74jkql24+4 IeAxCnWAs7BPSLY7xv7FL+Y3+SHq0IuTjq/ctsrt86GaHjpJ5ORk5EGrzoGm+BpS2TEi ZJeA== MIME-Version: 1.0 X-Received: by 10.60.120.98 with SMTP id lb2mr13384673oeb.52.1402402495593; Tue, 10 Jun 2014 05:14:55 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Tue, 10 Jun 2014 05:14:55 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Tue, 10 Jun 2014 05:14:55 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 Jun 2014 05:14:55 -0700 Message-ID: From: Manav Bhatia To: Acee Lindem Content-Type: multipart/alternative; boundary=047d7b339dbd95053604fb7a469e Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/6WtIQWS3iE3TjRhYSKdk3j9aJtk Cc: OSPF - OSPF WG List Subject: Re: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2014 12:14:57 -0000 --047d7b339dbd95053604fb7a469e Content-Type: text/plain; charset=UTF-8 Support! -- Thumb typed by Manav On Jun 10, 2014 1:10 AM, "Acee Lindem" wrote: > Given the progress made in the SRING WG on problem statement and use > caseWG document adoption, Abhay and I now feel we can start a 1 week poll > on adoption of the corresponding OSPF document. > > > http://www.ietf.org/id/draft-psenak-ospf-segment-routing-extensions-05.txt > > Please indicate your support or opposition to WG adoption. > > Thanks, > Abhay and Acee > P.S. Assuming adoption of the OSPFv2 draft, we will poll for acceptance of > the OSPFv3 draft. > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > --047d7b339dbd95053604fb7a469e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Support!

--
Thumb typed by Manav

On Jun 10, 2014 1:10 AM, "Acee Lindem"= <acee.lindem@ericsson.com> wrote:

_______________________________________________
OSPF mailing list
OSPF@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ospf

--047d7b339dbd95053604fb7a469e-- From nobody Tue Jun 10 06:49:27 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC871A0113 for ; Tue, 10 Jun 2014 06:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnEYkJ579vIv for ; Tue, 10 Jun 2014 06:49:22 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C031A0111 for ; Tue, 10 Jun 2014 06:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6368; q=dns/txt; s=iport; t=1402408162; x=1403617762; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=6v4YUBYjj9ZFvEM+qbjvBwL1mz3yiDf/b6Kr7RXzj0U=; b=LKxlCZ2zaU4dW1jlL23CC3+p5JUiBK7Yw/S5WhBZBceWpwracnTAxhrB O2VaQq09krWiZRwIPsApP+dCUdPma0ScUrZZ82emtkj8hDO1Xy1EsteMq HdCugWSUJsccmC2XSfu7Ia3Uw+recIMBYZb3rkqRDc2Dp2Lo1dGXHYAKy k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8LAGYMl1OtJV2U/2dsb2JhbABZgkZHUlmFTKUcAQEGlyOBbwGBCxZ1hAMBAQEELVwCAQgRBAEBCx0HMhQJCAIEARIIAYg5Dcs9F4VWiEI3AYMrgRYErWmBQoF6bIFD X-IronPort-AV: E=Sophos;i="4.98,1009,1392163200"; d="scan'208,217";a="51852431" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP; 10 Jun 2014 13:49:21 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s5ADnLrA021262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jun 2014 13:49:21 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Tue, 10 Jun 2014 08:49:21 -0500 From: "Les Ginsberg (ginsberg)" To: Acee Lindem , OSPF - OSPF WG List Thread-Topic: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll Thread-Index: AQHPhBqMWBcp+0ROV0Wo4LkaaOkZsJtqXT1g Date: Tue, 10 Jun 2014 13:49:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.69.46] Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F23DFEA04xmbalnx02ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/KEP8DUxWPBBPEpOMSgL8d6-GJMw Subject: Re: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2014 13:49:24 -0000 --_000_F3ADE4747C9E124B89F0ED2180CC814F23DFEA04xmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support Les From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem Sent: Monday, June 09, 2014 12:40 PM To: OSPF - OSPF WG List Subject: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll Given the progress made in the SRING WG on problem statement and use caseWG= document adoption, Abhay and I now feel we can start a 1 week poll on adop= tion of the corresponding OSPF document. http://www.ietf.org/id/draft-psenak-ospf-segment-routing-extensions-05.txt Please indicate your support or opposition to WG adoption. Thanks, Abhay and Acee P.S. Assuming adoption of the OSPFv2 draft, we will poll for acceptance of = the OSPFv3 draft. --_000_F3ADE4747C9E124B89F0ED2180CC814F23DFEA04xmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support=

 <= /p>

   Les

 <= /p>

From: OSPF [ma= ilto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem
Sent: Monday, June 09, 2014 12:40 PM
To: OSPF - OSPF WG List
Subject: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance = Poll

 

Given the progress made in = the SRING WG on problem statement and use caseWG document adoption, Abhay a= nd I now feel we can start a 1 week poll on adoption of the corresponding OSPF document. 

 

 

Please indicate your suppor= t or opposition to WG adoption.

 

Thanks,

Abhay and Acee

P.S. Assuming adoption of t= he OSPFv2 draft, we will poll for acceptance of the OSPFv3 draft. 

 

--_000_F3ADE4747C9E124B89F0ED2180CC814F23DFEA04xmbalnx02ciscoc_-- From nobody Tue Jun 10 07:17:27 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B75C1A049F for ; Tue, 10 Jun 2014 07:17:26 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWyTmCvho4Ig for ; Tue, 10 Jun 2014 07:17:24 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A2551A0162 for ; Tue, 10 Jun 2014 07:17:24 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-c4-5396c0435792 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 78.90.11744.340C6935; Tue, 10 Jun 2014 10:22:27 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 10:17:19 -0400 From: Jeff Tantsura To: Acee Lindem Thread-Topic: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll Thread-Index: AQHPhBqMWBcp+0ROV0Wo4LkaaOkZsJtqEiiAgABTApY= Date: Tue, 10 Jun 2014 14:17:19 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_FFF8C0CA99B644998820749106FE596Aericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXRPiK7zgWnBBhv/ilm03LvH7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOaf91kKDslUnLl6j7mBsV2yi5GTQ0LAROLCwUcsELaYxIV7 69m6GLk4hASOMkp8+jabHcJZzihx+eg0sCo2AQOJ/9+Og9kiAloSnW+/s4PYzALqEm8Pz2cF sYUFfCTmLmuHqvGVuPt9FZRtJTF59QTGLkYODhYBVYmzT61BwrwC9hKb5/1lA7GFBDIk/tye wQxicwLF9187wQRiMwId9/3UGiaIVeISt57MZ4I4WkBiyZ7zzBC2qMTLx/9YIWqSJaZeuskG MV9Q4uTMJywTGEVmIWmfhaRsFpIyiLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvoqRo7Q4 tSw33chwEyMwUo5JsDnuYFzwyfIQowAHoxIP74LWqcFCrIllxZW5hxilOViUxHn3XKsKFhJI TyxJzU5NLUgtii8qzUktPsTIxMEp1cBYsdRWKv79LEVRwXuCkV6hl1ln+B8+cH0Ds6fTwVXW V9qkf6+e8d7eruimw4RvO0V6S27eWzP3f9B7Yf+Q/s57IZF77OvnnLOQSOdqiVXr//Sga90c 3u/5/ucM0oqs1wfVu2yweKzWffHVhIWynNsXWC0rP+z15W2x5t3ME05KX9yS/k84Yq6nxFKc kWioxVxUnAgAvHagw3UCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/jHxrQS0UTR9erVL4vEf2b3QJU_w Cc: OSPF - OSPF WG List Subject: Re: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2014 14:17:26 -0000 --_000_FFF8C0CA99B644998820749106FE596Aericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support as co-author Thanks, Jeff From: Acee Lindem > Date: Monday 9 June 2014 21:39 To: OSPF - OSPF WG List > Subject: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll Given the progress made in the SRING WG on problem statement and use caseWG= document adoption, Abhay and I now feel we can start a 1 week poll on adop= tion of the corresponding OSPF document. http://www.ietf.org/id/draft-psenak-ospf-segment-routing-extensions-05.txt Please indicate your support or opposition to WG adoption. Thanks, Abhay and Acee P.S. Assuming adoption of the OSPFv2 draft, we will poll for acceptance of = the OSPFv3 draft. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --_000_FFF8C0CA99B644998820749106FE596Aericssoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Support as co-author 

Thanks,
Jeff

From: Acee Lindem <acee.lindem@ericsson.com>
Date: Monday 9 June 2014 21:39
To: OSPF - OSPF WG List <ospf@ietf.org>
Subject: [OSPF] OSPFv2 Segment Rout= ing Draft WG Document Acceptance Poll

Given the progress made in the SRING WG on problem statement and use c= aseWG document adoption, Abhay and I now feel we can start a 1 week poll on= adoption of the corresponding OSPF document. 


Please indicate your support or opposition to WG adoption.

Thanks,
Abhay and Acee
P.S. Assuming adoption of the OSPFv2 draft, we will poll for acceptanc= e of the OSPFv3 draft. 

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ie= tf.org/mailman/listinfo/ospf
--_000_FFF8C0CA99B644998820749106FE596Aericssoncom_-- From nobody Tue Jun 10 07:40:37 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779DD1B27C4; Tue, 10 Jun 2014 07:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NO4V6U6LMVOk; Tue, 10 Jun 2014 07:40:16 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E081A017F; Tue, 10 Jun 2014 07:40:16 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id j17so4136202oag.10 for ; Tue, 10 Jun 2014 07:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=p5+9mw/bfwBp5Eoio6DaiMOk98F7f9k4auYeVjF38Fc=; b=tCZoOaOhqm4MiyHBrT0KJONhTsjVA7PPz3M6+hvnzRvf/YRGAz31eH3KaoRy5GxITZ O0GSuOG3cPIOchZO/NF2zQNQRwzzk6KWOKan0lPkoy0cNqOYVoq1VYvneFAKhotXnB8W eNLEgY638vgir6WXpWlknIGD4Not0yI4vIWHYPpzUb78j5voQ+gYxcWXCjmz/biPktf+ L0YX8/z+QirDMyOzgfDCGvjlyUFoCW4g9w/j1gAuMM0Jo864o2ZlgB3PKO8Wn8u2ppdW jrGTjlRkJ5WyaUqfGHzeO+ofAeK96SPDQpebiHjb4LpSAyzxa1HFkQk5lJfcmotQ8Ss7 1c5A== MIME-Version: 1.0 X-Received: by 10.182.65.167 with SMTP id y7mr31852782obs.29.1402411215609; Tue, 10 Jun 2014 07:40:15 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Tue, 10 Jun 2014 07:40:15 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Tue, 10 Jun 2014 07:40:15 -0700 (PDT) In-Reply-To: <20140610135340.GA19601@pfrc> References: <20140610135340.GA19601@pfrc> Date: Tue, 10 Jun 2014 07:40:15 -0700 Message-ID: From: Manav Bhatia To: Jeffrey Haas , "rtg-bfd@ietf.org" , OSPF - OSPF WG List Content-Type: multipart/alternative; boundary=089e0158a91055f3ff04fb7c4e38 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/ETQw1S9R32QIZ081XpksItlUFBo Subject: Re: [OSPF] BFD re-charter complete X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2014 14:40:26 -0000 --089e0158a91055f3ff04fb7c4e38 Content-Type: text/plain; charset=UTF-8 Hi Jeff, What about the ospf/isis extn drafts for distributing the sbfd discriminators? I guess these would be owned by the respective IGP WGs. Is this correct? Cheers, Manav -- Thumb typed by Manav On Jun 10, 2014 7:23 PM, "Jeffrey Haas" wrote: > Working Group, > > Our updated charter was approved by the IESG. The S-BFD work is officially > in scope now! > > Per our prior discussion, authors please submit the following documents as > draft-ietf-bfd-*: > > draft-aldrin-bfd-seamless-use-case (Milestone: November 2014) > draft-akiya-bfd-seamless-base (Milestone: March 2015) > > The following documents are known to be work of interest, but aren't quite > ready for adoption. Please kick off additional discussions to drive that > work forward: > > draft-akiya-bfd-seamless-ip > draft-akiya-bfd-seamless-sr > draft-akiya-bfd-seamless-alert-discrim > > My recommendation is to drive the IP case first. > > -- Jeff > > > > > > ----- Forwarded message from The IESG ----- > > Date: Thu, 05 Jun 2014 10:16:58 -0700 > From: The IESG > To: IETF-Announce > Cc: bfd WG > Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd) > > The Bidirectional Forwarding Detection (bfd) working group in the Routing > Area of the IETF has been rechartered. For additional information please > contact the Area Directors or the WG Chairs. > > Bidirectional Forwarding Detection (bfd) > ------------------------------------------------ > Current Status: Active WG > > Chairs: > Nobo Akiya > Jeffrey Haas > > Technical advisors: > Dave Katz > David Ward > > Assigned Area Director: > Adrian Farrel > > Mailing list > Address: rtg-bfd@ietf.org > To Subscribe: rtg-bfd-request@ietf.org > Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/ > > Charter: > > The BFD Working Group is chartered to standardize and support the > bidirectional forwarding detection protocol (BFD) and its extensions. A > core goal of the working group is to standardize BFD in the context of > IP routing, or protocols such as MPLS that are based on IP routing, in a > way that will encourage multiple, inter-operable vendor implementations. > > The Working Group will also provide advice and guidance on BFD to other > working groups or standards bodies as requested. > > BFD is a protocol intended to detect faults in the bidirectional path > between two forwarding engines, including physical interfaces, > subinterfaces, data link(s), and to the extent possible the forwarding > engines themselves, with potentially very low latency. It operates > independently of media, data protocols, and routing protocols. An > additional goal is to provide a single mechanism that can be used for > liveness detection over any media, at any protocol layer, with > a wide range of detection times and overhead, to avoid a proliferation > of different methods. > > Important characteristics of BFD include: > > - Simple, fixed-field encoding to facilitate implementations in > hardware. > > - Independence of the data protocol being forwarded between two systems. > BFD packets are carried as the payload of whatever encapsulating > protocol is appropriate for the medium and network. > > - Path independence: BFD can provide failure detection on any kind of > path between systems, including direct physical links, virtual > circuits, tunnels, MPLS LSPs, multihop routed paths, and > unidirectional links (so long as there is some return path, of > course). > > - Ability to be bootstrapped by any other protocol that automatically > forms peer, neighbor or adjacency relationships to seed BFD endpoint > discovery. > > The working group is currently chartered to complete the following work > items: > > 1. Develop further MIB modules for BFD and submit them to the IESG for > publication as Proposed Standards. > > 2a. Provide a generic keying-based cryptographic authentication > mechanism for the BFD protocol developing the work of the KARP > working group. This mechanism will support authentication through > a key identifier for the BFD session's Security Association rather > than specifying new authentication extensions. > > 2b. Provide extensions to the BFD MIB in support of the generic keying- > based cryptographic authentication mechanism. > > 2c. Specify cryptographic authentication procedures for the BFD protocol > using HMAC-SHA-256 (possibly truncated to a smaller integrity check > value but not beyond commonly accepted lengths to ensure security) using > the generic keying-based cryptographic authentication mechanism. > > 3. Provide an extension to the BFD core protocol in support of point-to- > multipoint links and networks. > > 4. Provide an informational document to recommend standardized timers > and timer operations for BFD when used in different applications. > > 5. Define a mechanism to perform single-ended path (i.e. continuity) > verification based on the BFD specification. Allow such a mechanism to > work both proactively and on-demand, without prominent initial delay. > Allow the mechanism to maintain multiple sessions to a target entity and > between the same pair of network entities. In doing this work, the WG > will work closely with at least the following other WGs: ISIS, OSPF, > SPRING. > > The working group will maintain a relationship with the MPLS working > group. > > Milestones: > Done - Submit the base protocol specification to the IESG to be > considered as a Proposed Standard > Done - Submit BFD encapsulation and usage profile for single-hop > IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed > Standard > Done - Submit BFD encapsulation and usage profile for MPLS LSPs to > the IESG to be considered as a Proposed Standard > Done - Submit BFD encapsulation and usage profile for multi-hop > IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed > Standard > Done - Submit the BFD MIB to the IESG to be considered as a > Proposed Standard > Done - Submit the BFD over LAG mechanism to the IESG to be > considered as a Proposed Standard > Jun 2014 - Submit the the document on BFD point-to-multipoint support > to the IESG to be considered as a Proposed Standard > Nov 2014 - Submit the BFD MPLS extension MIB to the IESG to be > considered as a Proposed Standard > Jan 2015 - Submit the generic keying based cryptographic authentication > mechanism to the IESG to be considered as a Proposed Standard > Jan 2015 - Submit a BFD MIB extension in support of the generic keying > document to the IESG to be considered as a Proposed Standard > Jan 2015 - Submit the cryptographic authentication procedures for BFD > to the IESG to be considered as a Proposed Standard > Jan 2015 - Submit the BFD Common Intervals document to the IESG to be > considered as an Informational RFC > > > ----- End forwarded message ----- > > --089e0158a91055f3ff04fb7c4e38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Jeff,

What about the ospf/isis extn drafts for distributing the sbfd discrimin= ators? I guess these would be owned by the respective IGP WGs. Is this corr= ect?

Cheers, Manav

--
Thumb typed by Manav

On Jun 10, 2014 7:23 PM, "Jeffrey Haas"= ; <jhaas@pfrc.org> wrote:
Working Group,

Our updated charter was approved by the IESG. =C2=A0The S-BFD work is offic= ially
in scope now!

Per our prior discussion, authors please submit the following documents as<= br> draft-ietf-bfd-*:

draft-aldrin-bfd-seamless-use-case (Milestone: November 2014)
draft-akiya-bfd-seamless-base (Milestone: March 2015)

The following documents are known to be work of interest, but aren't qu= ite
ready for adoption. =C2=A0Please kick off additional discussions to drive t= hat
work forward:

draft-akiya-bfd-seamless-ip
draft-akiya-bfd-seamless-sr
draft-akiya-bfd-seamless-alert-discrim

My recommendation is to drive the IP case first.

-- Jeff





----- Forwarded message from The IESG <iesg-secretary@ietf.org> -----

Date: Thu, 05 Jun 2014 10:16:58 -0700
From: The IESG <iesg-secretar= y@ietf.org>
To: IETF-Announce <ietf-announ= ce@ietf.org>
Cc: bfd WG <rtg-bfd@ietf.org>=
Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd)
The Bidirectional Forwarding Detection (bfd) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs.

Bidirectional Forwarding Detection (bfd)
------------------------------------------------
Current Status: Active WG

Chairs:
=C2=A0 Nobo Akiya <nobo@cisco.com&= gt;
=C2=A0 Jeffrey Haas <jhaas@pfrc.org>

Technical advisors:
=C2=A0 Dave Katz <dkatz@juniper.net= >
=C2=A0 David Ward <dward@cisco.com>

Assigned Area Director:
=C2=A0 Adrian Farrel <adrian@oldd= og.co.uk>

Mailing list
=C2=A0 Address: rtg-bfd@ietf.org =C2=A0 To Subscribe: rtg-bfd-re= quest@ietf.org
=C2=A0 Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/

Charter:

The BFD Working Group is chartered to standardize and support the
bidirectional forwarding detection protocol (BFD) and its extensions. =C2= =A0A
core goal of the working group is to standardize BFD in the context of
IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations.
The Working Group will also provide advice and guidance on BFD to other
working groups or standards bodies as requested.

BFD is a protocol intended to detect faults in the bidirectional path
between two forwarding engines, including physical interfaces,
subinterfaces, data link(s), and to the extent possible the forwarding
engines themselves, with potentially very low latency. It operates
independently of media, data protocols, and routing protocols. An
additional goal is to provide a single mechanism that can be used for
liveness detection over any media, at any protocol layer, with
a wide range of detection times and overhead, to avoid a proliferation
of different methods.

Important characteristics of BFD include:

- Simple, fixed-field encoding to facilitate implementations in
=C2=A0 hardware.

- Independence of the data protocol being forwarded between two systems. =C2=A0 BFD packets are carried as the payload of whatever encapsulating
=C2=A0 protocol is appropriate for the medium and network.

- Path independence: BFD can provide failure detection on any kind of
=C2=A0 path between systems, including direct physical links, virtual
=C2=A0 circuits, tunnels, MPLS LSPs, multihop routed paths, and
=C2=A0 unidirectional links (so long as there is some return path, of
=C2=A0 course).

- Ability to be bootstrapped by any other protocol that automatically
=C2=A0 forms peer, neighbor or adjacency relationships to seed BFD endpoint=
=C2=A0 discovery.

The working group is currently chartered to complete the following work
items:

1. Develop further MIB modules for BFD and submit them to the IESG for
publication as Proposed Standards.

2a. Provide a generic keying-based cryptographic authentication
mechanism for the BFD protocol developing the work of the KARP
working group. =C2=A0This mechanism =C2=A0will support authentication throu= gh
a key identifier for the BFD session's Security Association rather
than specifying new authentication extensions.

2b. Provide extensions to the BFD MIB in support of the generic keying-
based cryptographic authentication mechanism.

2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check
value but not beyond commonly accepted lengths to ensure security) using the generic keying-based cryptographic authentication mechanism.

3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks.

4. Provide an informational document to recommend standardized timers
and timer operations for BFD when used in different applications.

5. Define a mechanism to perform single-ended path (i.e. continuity)
verification based on the BFD specification. =C2=A0Allow such a mechanism t= o
work both proactively and on-demand, without prominent initial delay.
Allow the mechanism to maintain multiple sessions to a target entity and between the same pair of network entities. In doing this work, the WG
will work closely with at least the following other WGs: ISIS, OSPF,
SPRING.

The working group will maintain a relationship with the MPLS working
group.

Milestones:
=C2=A0 Done =C2=A0 =C2=A0 - Submit the base protocol specification to the I= ESG to be
considered as a Proposed Standard
=C2=A0 Done =C2=A0 =C2=A0 - Submit BFD encapsulation and usage profile for = single-hop
IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed
Standard
=C2=A0 Done =C2=A0 =C2=A0 - Submit BFD encapsulation and usage profile for = MPLS LSPs to
the IESG to be considered as a Proposed Standard
=C2=A0 Done =C2=A0 =C2=A0 - Submit BFD encapsulation and usage profile for = multi-hop
IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed
Standard
=C2=A0 Done =C2=A0 =C2=A0 - Submit the BFD MIB to the IESG to be considered= as a
Proposed Standard
=C2=A0 Done =C2=A0 =C2=A0 - Submit the BFD over LAG mechanism to the IESG t= o be
considered as a Proposed Standard
=C2=A0 Jun 2014 - Submit the the document on BFD point-to-multipoint suppor= t
to the IESG to be considered as a Proposed Standard
=C2=A0 Nov 2014 - Submit the BFD MPLS extension MIB to the IESG to be
considered as a Proposed Standard
=C2=A0 Jan 2015 - Submit the generic keying based cryptographic authenticat= ion
mechanism to the IESG to be considered as a Proposed Standard
=C2=A0 Jan 2015 - Submit a BFD MIB extension in support of the generic keyi= ng
document to the IESG to be considered as a Proposed Standard
=C2=A0 Jan 2015 - Submit the cryptographic authentication procedures for BF= D
to the IESG to be considered as a Proposed Standard
=C2=A0 Jan 2015 - Submit the BFD Common Intervals document to the IESG to b= e
considered as an Informational RFC


----- End forwarded message -----

--089e0158a91055f3ff04fb7c4e38-- From nobody Tue Jun 10 07:46:03 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF5E1B27C5 for ; Tue, 10 Jun 2014 07:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.151 X-Spam-Level: X-Spam-Status: No, score=-115.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sm6rnznZN2GO for ; Tue, 10 Jun 2014 07:45:53 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA741A017A for ; Tue, 10 Jun 2014 07:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6607; q=dns/txt; s=iport; t=1402411553; x=1403621153; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=uc6ubkIjnkqtvZNR+tDNkBfTA+vDFycoT80QWrJ2GV4=; b=NV/3S0YP4sXU3OWOBaRWNN4bY6lve6VlMeVKtkKmMCC4WNElx8BpbTu3 fiA7b8zD9i3VFYCt2LF8sCtfHgWAdz6qXZ5quEXVIxvnTf2MOonAZ+a0O v/iI5n4hjpRjfGkA3LuRH92z1jtcv8NXswXdhr7yAJouVI2CktOvr3Ks8 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0FAAgZl1OtJA2G/2dsb2JhbABZgkYjJFJZhUy8R4FvAYEIFnWEAwEBAQQtXAIBCBEEAQELHQcyFAkIAgQBEggBiDkBDMtiF44YNwGDK4EWBK1pgUKBemyBQw X-IronPort-AV: E=Sophos;i="4.98,1009,1392163200"; d="scan'208,217";a="332016586" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-5.cisco.com with ESMTP; 10 Jun 2014 14:45:52 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s5AEjqLg009879 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jun 2014 14:45:52 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 10 Jun 2014 09:45:51 -0500 From: "Nobo Akiya (nobo)" To: Acee Lindem , OSPF - OSPF WG List Thread-Topic: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll Thread-Index: AQHPhBqMWBcp+0ROV0Wo4LkaaOkZsJtqbPRg Date: Tue, 10 Jun 2014 14:45:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.71] Content-Type: multipart/alternative; boundary="_000_CECE764681BE964CBE1DFF78F3CDD3941E1DE059xmbalnx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/b5mnQJwczThuE92M80n76l-B7RU Subject: Re: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2014 14:45:59 -0000 --_000_CECE764681BE964CBE1DFF78F3CDD3941E1DE059xmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. -Nobo From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem Sent: Monday, June 09, 2014 3:40 PM To: OSPF - OSPF WG List Subject: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll Given the progress made in the SRING WG on problem statement and use caseWG= document adoption, Abhay and I now feel we can start a 1 week poll on adop= tion of the corresponding OSPF document. http://www.ietf.org/id/draft-psenak-ospf-segment-routing-extensions-05.txt Please indicate your support or opposition to WG adoption. Thanks, Abhay and Acee P.S. Assuming adoption of the OSPFv2 draft, we will poll for acceptance of = the OSPFv3 draft. --_000_CECE764681BE964CBE1DFF78F3CDD3941E1DE059xmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 <= /p>

-Nobo

 <= /p>

From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem
Sent: Monday, June 09, 2014 3:40 PM
To: OSPF - OSPF WG List
Subject: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance = Poll

 

Given the progress made in = the SRING WG on problem statement and use caseWG document adoption, Abhay a= nd I now feel we can start a 1 week poll on adoption of the corresponding OSPF document. 

 

 

Please indicate your suppor= t or opposition to WG adoption.

 

Thanks,

Abhay and Acee

P.S. Assuming adoption of t= he OSPFv2 draft, we will poll for acceptance of the OSPFv3 draft. 

 

--_000_CECE764681BE964CBE1DFF78F3CDD3941E1DE059xmbalnx01ciscoc_-- From nobody Tue Jun 10 07:59:00 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125FF1B27D6 for ; Tue, 10 Jun 2014 07:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILMfn_ZQP8s5 for ; Tue, 10 Jun 2014 07:58:55 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4F71A018E for ; Tue, 10 Jun 2014 07:58:55 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s5AEwqOw025925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Jun 2014 09:58:52 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s5AEwpHm019221 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jun 2014 10:58:52 -0400 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.131]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 10 Jun 2014 10:58:51 -0400 From: "Dolganow, Andrew (Andrew)" To: Acee Lindem , OSPF - OSPF WG List Thread-Topic: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll Thread-Index: AQHPhBqMWBcp+0ROV0Wo4LkaaOkZsJtq1VkA Date: Tue, 10 Jun 2014 14:58:50 +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/14.4.2.140509 x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_CFBCE9C5533E1andrewdolganowalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/LQBxWsK77-d8-Cn7riS_YLD6uvs Subject: Re: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2014 14:58:58 -0000 --_000_CFBCE9C5533E1andrewdolganowalcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support Andrew On 2014-06-09, 9:39 PM, "Acee Lindem" wrote: Given the progress made in the SRING WG on problem statement and use caseWG= document adoption, Abhay and I now feel we can start a 1 week poll on adop= tion of the corresponding OSPF document. http://www.ietf.org/id/draft-psenak-ospf-segment-routing-extensions-05.txt Please indicate your support or opposition to WG adoption. Thanks, Abhay and Acee P.S. Assuming adoption of the OSPFv2 draft, we will poll for acceptance of = the OSPFv3 draft. --_000_CFBCE9C5533E1andrewdolganowalcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Support

Andrew

On 2014-06-09, 9:39 PM, "Acee Lindem" wrote:

Given the progress made in the SRING WG on problem statement and use c= aseWG document adoption, Abhay and I now feel we can start a 1 week poll on= adoption of the corresponding OSPF document. 


Please indicate your support or opposition to WG adoption.

Thanks,
Abhay and Acee
P.S. Assuming adoption of the OSPFv2 draft, we will poll for acceptanc= e of the OSPFv3 draft. 

 --_000_CFBCE9C5533E1andrewdolganowalcatellucentcom_-- From nobody Tue Jun 10 09:35:13 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92BC1B2820; Tue, 10 Jun 2014 09:35:08 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQsT7-9wlV-e; Tue, 10 Jun 2014 09:35:01 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 164AD1B2821; Tue, 10 Jun 2014 09:35:01 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-e7-5396e2ed1618 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 57.30.27529.DE2E6935; Tue, 10 Jun 2014 12:50:21 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 12:34:55 -0400 From: Acee Lindem To: Manav Bhatia , Jeffrey Haas , "rtg-bfd@ietf.org" , OSPF - OSPF WG List Thread-Topic: [OSPF] BFD re-charter complete Thread-Index: AQHPhLn1+tGMsKmUlUiLuM+ShUV36JtqWA6A Date: Tue, 10 Jun 2014 16:34:55 +0000 Message-ID: References: <20140610135340.GA19601@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_CFBC813F3100Aaceelindemericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyuXRPgu7bR9OCDZ6st7TYf/Atq8XlSW3s Fi337rFbfP6zjdGBxWPnrLvsHkuW/GTyuNy7lTWAOYrLJiU1J7MstUjfLoEro2f/TKaC11MZ Ky4+K29gnFLXxcjJISFgIrHs/V42CFtM4sK99UA2F4eQwFFGiedPX7FCOMsZJU6sX80OUsUm oCPx/NE/ZpCEiMBURollc/pYQBLCAtoSS37+YwSxRYCKel4+ZoWwjSQOvvwEVsMioCoxd+5/ pi5GDg5eAVOJw60uIGEhgQKJpQ+vgV3BKRAo0XJsNhOIzQh00fdTa8BsZgFxiVtP5jNBXCog sWTPeWYIW1Ti5eN/YKtEBfQkmrveMELEFSX29U9nh+iNkuh/PA/sBF4BQYmTM5+wTGAUnYVk 7CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DFUr7XEi4t3GZHVLGDkWMXIUVqcWpabbmSw iREYjcck2HR3MO55aXmIUYCDUYmHV+H6tGAh1sSy4srcQ4zSHCxK4rzaN6uChQTSE0tSs1NT C1KL4otKc1KLDzEycXBKNTAuuZ8hWKQc0sBdNcUhW2+N7xzbQ9fTloayTricFxZffbG44NXL sMtz7sgfUVt7/cnyi7+PlK/Jf+t28sNb2yuhnvXvLvusFREy/vS8Ys1v7V7+fOuT+TO+zeic JnxURVtu7zmDPc92enj7sxrNz/H/MNUkTUT79o+XU26+VTpw0NLwxk0VvpogJZbijERDLeai 4kQAhGrMRacCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/dSF98WCVj-g_kTlO_MoXZf-kpos Subject: Re: [OSPF] BFD re-charter complete X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2014 16:35:09 -0000 --_000_CFBC813F3100Aaceelindemericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Manav, From: Manav Bhatia > Date: Tuesday, June 10, 2014 7:40 AM To: Jeffrey Haas >, "rtg-bfd@ietf.org= " >, OSP= F - OSPF WG List > Subject: Re: [OSPF] BFD re-charter complete Hi Jeff, What about the ospf/isis extn drafts for distributing the sbfd discriminato= rs? I guess these would be owned by the respective IGP WGs. Is this correct= ? Since the IGP drafts contain solely the TLV encoding and IGP flooding speci= fications, there is reason for them to be homed anywhere else. Thanks, Acee Cheers, Manav -- Thumb typed by Manav On Jun 10, 2014 7:23 PM, "Jeffrey Haas" > wrote: Working Group, Our updated charter was approved by the IESG. The S-BFD work is officially in scope now! Per our prior discussion, authors please submit the following documents as draft-ietf-bfd-*: draft-aldrin-bfd-seamless-use-case (Milestone: November 2014) draft-akiya-bfd-seamless-base (Milestone: March 2015) The following documents are known to be work of interest, but aren't quite ready for adoption. Please kick off additional discussions to drive that work forward: draft-akiya-bfd-seamless-ip draft-akiya-bfd-seamless-sr draft-akiya-bfd-seamless-alert-discrim My recommendation is to drive the IP case first. -- Jeff ----- Forwarded message from The IESG > ----- Date: Thu, 05 Jun 2014 10:16:58 -0700 From: The IESG > To: IETF-Announce > Cc: bfd WG > Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd) The Bidirectional Forwarding Detection (bfd) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Bidirectional Forwarding Detection (bfd) ------------------------------------------------ Current Status: Active WG Chairs: Nobo Akiya > Jeffrey Haas > Technical advisors: Dave Katz > David Ward > Assigned Area Director: Adrian Farrel > Mailing list Address: rtg-bfd@ietf.org To Subscribe: rtg-bfd-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/ Charter: The BFD Working Group is chartered to standardize and support the bidirectional forwarding detection protocol (BFD) and its extensions. A core goal of the working group is to standardize BFD in the context of IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. The Working Group will also provide advice and guidance on BFD to other working groups or standards bodies as requested. BFD is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, subinterfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods. Important characteristics of BFD include: - Simple, fixed-field encoding to facilitate implementations in hardware. - Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. - Path independence: BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links (so long as there is some return path, of course). - Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. The working group is currently chartered to complete the following work items: 1. Develop further MIB modules for BFD and submit them to the IESG for publication as Proposed Standards. 2a. Provide a generic keying-based cryptographic authentication mechanism for the BFD protocol developing the work of the KARP working group. This mechanism will support authentication through a key identifier for the BFD session's Security Association rather than specifying new authentication extensions. 2b. Provide extensions to the BFD MIB in support of the generic keying- based cryptographic authentication mechanism. 2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check value but not beyond commonly accepted lengths to ensure security) using the generic keying-based cryptographic authentication mechanism. 3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks. 4. Provide an informational document to recommend standardized timers and timer operations for BFD when used in different applications. 5. Define a mechanism to perform single-ended path (i.e. continuity) verification based on the BFD specification. Allow such a mechanism to work both proactively and on-demand, without prominent initial delay. Allow the mechanism to maintain multiple sessions to a target entity and between the same pair of network entities. In doing this work, the WG will work closely with at least the following other WGs: ISIS, OSPF, SPRING. The working group will maintain a relationship with the MPLS working group. Milestones: Done - Submit the base protocol specification to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for MPLS LSPs to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit the BFD MIB to the IESG to be considered as a Proposed Standard Done - Submit the BFD over LAG mechanism to the IESG to be considered as a Proposed Standard Jun 2014 - Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard Nov 2014 - Submit the BFD MPLS extension MIB to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the generic keying based cryptographic authentication mechanism to the IESG to be considered as a Proposed Standard Jan 2015 - Submit a BFD MIB extension in support of the generic keying document to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the cryptographic authentication procedures for BFD to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the BFD Common Intervals document to the IESG to be considered as an Informational RFC ----- End forwarded message ----- --_000_CFBC813F3100Aaceelindemericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Manav, 

From: Manav Bhatia <manavbhatia@gmail.com>
Date: Tuesday, June 10, 2014 7:40 A= M
To: Jeffrey Haas <jhaas@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, OSPF - OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] BFD re-charter = complete

Hi Jeff,

What about the ospf/isis extn drafts for distributing the sbfd discrimin= ators? I guess these would be owned by the respective IGP WGs. Is this corr= ect?
Since the IGP drafts contain solely the TLV encoding and IGP flooding = specifications, there is reason for them to be homed anywhere else. 

Thanks,
Acee 



Cheers, Manav

--
Thumb typed by Manav

On Jun 10, 2014 7:23 PM, "Jeffrey Haas"= ; <jhaas@pfrc.org> wrote:
Working Group,

Our updated charter was approved by the IESG.  The S-BFD work is offic= ially
in scope now!

Per our prior discussion, authors please submit the following documents as<= br> draft-ietf-bfd-*:

draft-aldrin-bfd-seamless-use-case (Milestone: November 2014)
draft-akiya-bfd-seamless-base (Milestone: March 2015)

The following documents are known to be work of interest, but aren't quite<= br> ready for adoption.  Please kick off additional discussions to drive t= hat
work forward:

draft-akiya-bfd-seamless-ip
draft-akiya-bfd-seamless-sr
draft-akiya-bfd-seamless-alert-discrim

My recommendation is to drive the IP case first.

-- Jeff





----- Forwarded message from The IESG <iesg-secretary@ietf.org> -----

Date: Thu, 05 Jun 2014 10:16:58 -0700
From: The IESG <iesg-secretar= y@ietf.org>
To: IETF-Announce <ietf-announ= ce@ietf.org>
Cc: bfd WG <rtg-bfd@ietf.org>=
Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd)
The Bidirectional Forwarding Detection (bfd) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs.

Bidirectional Forwarding Detection (bfd)
------------------------------------------------
Current Status: Active WG

Chairs:
  Nobo Akiya <nobo@cisco.com&= gt;
  Jeffrey Haas <jhaas@pfrc.org>

Technical advisors:
  Dave Katz <dkatz@juniper.net= >
  David Ward <dward@cisco.com>

Assigned Area Director:
  Adrian Farrel <adrian@oldd= og.co.uk>

Mailing list
  Address: rtg-bfd@ietf.org   To Subscribe: rtg-bfd-re= quest@ietf.org
  Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/

Charter:

The BFD Working Group is chartered to standardize and support the
bidirectional forwarding detection protocol (BFD) and its extensions.  = ;A
core goal of the working group is to standardize BFD in the context of
IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations.
The Working Group will also provide advice and guidance on BFD to other
working groups or standards bodies as requested.

BFD is a protocol intended to detect faults in the bidirectional path
between two forwarding engines, including physical interfaces,
subinterfaces, data link(s), and to the extent possible the forwarding
engines themselves, with potentially very low latency. It operates
independently of media, data protocols, and routing protocols. An
additional goal is to provide a single mechanism that can be used for
liveness detection over any media, at any protocol layer, with
a wide range of detection times and overhead, to avoid a proliferation
of different methods.

Important characteristics of BFD include:

- Simple, fixed-field encoding to facilitate implementations in
  hardware.

- Independence of the data protocol being forwarded between two systems.   BFD packets are carried as the payload of whatever encapsulating
  protocol is appropriate for the medium and network.

- Path independence: BFD can provide failure detection on any kind of
  path between systems, including direct physical links, virtual
  circuits, tunnels, MPLS LSPs, multihop routed paths, and
  unidirectional links (so long as there is some return path, of
  course).

- Ability to be bootstrapped by any other protocol that automatically
  forms peer, neighbor or adjacency relationships to seed BFD endpoint=
  discovery.

The working group is currently chartered to complete the following work
items:

1. Develop further MIB modules for BFD and submit them to the IESG for
publication as Proposed Standards.

2a. Provide a generic keying-based cryptographic authentication
mechanism for the BFD protocol developing the work of the KARP
working group.  This mechanism  will support authentication throu= gh
a key identifier for the BFD session's Security Association rather
than specifying new authentication extensions.

2b. Provide extensions to the BFD MIB in support of the generic keying-
based cryptographic authentication mechanism.

2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check
value but not beyond commonly accepted lengths to ensure security) using the generic keying-based cryptographic authentication mechanism.

3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks.

4. Provide an informational document to recommend standardized timers
and timer operations for BFD when used in different applications.

5. Define a mechanism to perform single-ended path (i.e. continuity)
verification based on the BFD specification.  Allow such a mechanism t= o
work both proactively and on-demand, without prominent initial delay.
Allow the mechanism to maintain multiple sessions to a target entity and between the same pair of network entities. In doing this work, the WG
will work closely with at least the following other WGs: ISIS, OSPF,
SPRING.

The working group will maintain a relationship with the MPLS working
group.

Milestones:
  Done     - Submit the base protocol specification to the I= ESG to be
considered as a Proposed Standard
  Done     - Submit BFD encapsulation and usage profile for = single-hop
IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed
Standard
  Done     - Submit BFD encapsulation and usage profile for = MPLS LSPs to
the IESG to be considered as a Proposed Standard
  Done     - Submit BFD encapsulation and usage profile for = multi-hop
IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed
Standard
  Done     - Submit the BFD MIB to the IESG to be considered= as a
Proposed Standard
  Done     - Submit the BFD over LAG mechanism to the IESG t= o be
considered as a Proposed Standard
  Jun 2014 - Submit the the document on BFD point-to-multipoint suppor= t
to the IESG to be considered as a Proposed Standard
  Nov 2014 - Submit the BFD MPLS extension MIB to the IESG to be
considered as a Proposed Standard
  Jan 2015 - Submit the generic keying based cryptographic authenticat= ion
mechanism to the IESG to be considered as a Proposed Standard
  Jan 2015 - Submit a BFD MIB extension in support of the generic keyi= ng
document to the IESG to be considered as a Proposed Standard
  Jan 2015 - Submit the cryptographic authentication procedures for BF= D
to the IESG to be considered as a Proposed Standard
  Jan 2015 - Submit the BFD Common Intervals document to the IESG to b= e
considered as an Informational RFC


----- End forwarded message -----

 --_000_CFBC813F3100Aaceelindemericssoncom_-- From nobody Tue Jun 10 09:50:51 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB83D1A019B; Tue, 10 Jun 2014 09:50:49 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WH-g-_gj-1t; Tue, 10 Jun 2014 09:50:47 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8EC1A021E; Tue, 10 Jun 2014 09:50:46 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-c5-5396e434b30d Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 36.DA.11744.434E6935; Tue, 10 Jun 2014 12:55:48 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 12:50:44 -0400 From: Acee Lindem To: Acee Lindem , Manav Bhatia , Jeffrey Haas , "rtg-bfd@ietf.org" , OSPF - OSPF WG List Thread-Topic: [OSPF] BFD re-charter complete Thread-Index: AQHPhLn1+tGMsKmUlUiLuM+ShUV36JtqWA6AgAAEbAA= Date: Tue, 10 Jun 2014 16:50:45 +0000 Message-ID: References: <20140610135340.GA19601@pfrc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_CFBC84C131017aceelindemericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyuXRPgq7Jk2nBBs+WKFrsP/iW1eLypDZ2 i5Z799gtPv/ZxujA4rFz1l12jyVLfjJ5XO7dyhrAHMVlk5Kak1mWWqRvl8CV8eDDd6aCmWsZ K94/OMvawHh9EmMXIyeHhICJxMWLm5khbDGJC/fWs3UxcnEICRxllLjUc4QZwlnOKHHq4gqw DjYBHYnnj/6BJUQE9jNK/N75GaxdWEBbYsnPf2BFIkBFPS8fs0LYVhJrPt8Bs1kEVCXWH7gF VM/BwStgKjHjhwfEgjmMEm1XzrGCxDkFzCTap/iClDMCXfT91BomEJtZQFzi1pP5TBCXCkgs 2XMe6mpRiZeP/4GNFxXQk2juegP1maLEvv7p7BC9URIX1rxmA7F5BQQlTs58wjKBUXQWkrGz kJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHUL3WEhM2v0RRs4CRYxUjR2lxalluupHhJkZg RB6TYHPcwbjgk+UhRgEORiUeXoXr04KFWBPLiitzDzFKc7AoifPuuVYVLCSQnliSmp2aWpBa FF9UmpNafIiRiYNTqoHRwfClZcErwS1dJ9awvflrZRxz/dWXHSLme0V9wzqvyQmlHzATEjJ7 IJ/XmLBpYZgCT8fxPu+LMd8bfr4LqdnT+zIxWkfsZrn8zxgtpQutUYdafHprfh158Pv6nPvz 92s4Rh+y+x5ZV1p/kNX1sMLx+kaLU9Ia7Kd1BN75Wdel87+/eTf+0SMlluKMREMt5qLiRACE ZPoMqQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/8fQOqSHYq1csBTPLzxEUNwrlk5U Subject: Re: [OSPF] BFD re-charter complete X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2014 16:50:50 -0000 --_000_CFBC84C131017aceelindemericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Ericsson > Date: Tuesday, June 10, 2014 9:34 AM To: Manav Bhatia >, Jef= frey Haas >, "rtg-bfd@ietf.org" >, OSPF - OSP= F WG List > Subject: Re: [OSPF] BFD re-charter complete Hi Manav, From: Manav Bhatia > Date: Tuesday, June 10, 2014 7:40 AM To: Jeffrey Haas >, "rtg-bfd@ietf.org= " >, OSP= F - OSPF WG List > Subject: Re: [OSPF] BFD re-charter complete Hi Jeff, What about the ospf/isis extn drafts for distributing the sbfd discriminato= rs? I guess these would be owned by the respective IGP WGs. Is this correct= ? Since the IGP drafts contain solely the TLV encoding and IGP flooding speci= fications, there is reason for them to be homed anywhere else. All, I meant "no reason for them to be homed anywhere else". Thanks, Acee Thanks, Acee Cheers, Manav -- Thumb typed by Manav On Jun 10, 2014 7:23 PM, "Jeffrey Haas" > wrote: Working Group, Our updated charter was approved by the IESG. The S-BFD work is officially in scope now! Per our prior discussion, authors please submit the following documents as draft-ietf-bfd-*: draft-aldrin-bfd-seamless-use-case (Milestone: November 2014) draft-akiya-bfd-seamless-base (Milestone: March 2015) The following documents are known to be work of interest, but aren't quite ready for adoption. Please kick off additional discussions to drive that work forward: draft-akiya-bfd-seamless-ip draft-akiya-bfd-seamless-sr draft-akiya-bfd-seamless-alert-discrim My recommendation is to drive the IP case first. -- Jeff ----- Forwarded message from The IESG > ----- Date: Thu, 05 Jun 2014 10:16:58 -0700 From: The IESG > To: IETF-Announce > Cc: bfd WG > Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd) The Bidirectional Forwarding Detection (bfd) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Bidirectional Forwarding Detection (bfd) ------------------------------------------------ Current Status: Active WG Chairs: Nobo Akiya > Jeffrey Haas > Technical advisors: Dave Katz > David Ward > Assigned Area Director: Adrian Farrel > Mailing list Address: rtg-bfd@ietf.org To Subscribe: rtg-bfd-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/ Charter: The BFD Working Group is chartered to standardize and support the bidirectional forwarding detection protocol (BFD) and its extensions. A core goal of the working group is to standardize BFD in the context of IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. The Working Group will also provide advice and guidance on BFD to other working groups or standards bodies as requested. BFD is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, subinterfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods. Important characteristics of BFD include: - Simple, fixed-field encoding to facilitate implementations in hardware. - Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. - Path independence: BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links (so long as there is some return path, of course). - Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. The working group is currently chartered to complete the following work items: 1. Develop further MIB modules for BFD and submit them to the IESG for publication as Proposed Standards. 2a. Provide a generic keying-based cryptographic authentication mechanism for the BFD protocol developing the work of the KARP working group. This mechanism will support authentication through a key identifier for the BFD session's Security Association rather than specifying new authentication extensions. 2b. Provide extensions to the BFD MIB in support of the generic keying- based cryptographic authentication mechanism. 2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check value but not beyond commonly accepted lengths to ensure security) using the generic keying-based cryptographic authentication mechanism. 3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks. 4. Provide an informational document to recommend standardized timers and timer operations for BFD when used in different applications. 5. Define a mechanism to perform single-ended path (i.e. continuity) verification based on the BFD specification. Allow such a mechanism to work both proactively and on-demand, without prominent initial delay. Allow the mechanism to maintain multiple sessions to a target entity and between the same pair of network entities. In doing this work, the WG will work closely with at least the following other WGs: ISIS, OSPF, SPRING. The working group will maintain a relationship with the MPLS working group. Milestones: Done - Submit the base protocol specification to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for MPLS LSPs to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit the BFD MIB to the IESG to be considered as a Proposed Standard Done - Submit the BFD over LAG mechanism to the IESG to be considered as a Proposed Standard Jun 2014 - Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard Nov 2014 - Submit the BFD MPLS extension MIB to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the generic keying based cryptographic authentication mechanism to the IESG to be considered as a Proposed Standard Jan 2015 - Submit a BFD MIB extension in support of the generic keying document to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the cryptographic authentication procedures for BFD to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the BFD Common Intervals document to the IESG to be considered as an Informational RFC ----- End forwarded message ----- --_000_CFBC84C131017aceelindemericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5F8456B945CB024CAAFE3BB80C6193FF@ericsson.com> Content-Transfer-Encoding: quoted-printable
Date: Tuesday, June 10, 2014 9:34 A= M
To: Manav Bhatia <manavbhatia@gmail.com>, Jeffrey Haas <= jhaas@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, OSPF - OSPF WG List <ospf@ietf.org= >
Subject: Re: [OSPF] BFD re-charter = complete

Hi Manav, 

From: Manav Bhatia <manavbhatia@gmail.com>
Date: Tuesday, June 10, 2014 7:40 A= M
To: Jeffrey Haas <jhaas@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, OSPF - OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] BFD re-charter = complete

Hi Jeff,

What about the ospf/isis extn drafts for distributing the sbfd discrimin= ators? I guess these would be owned by the respective IGP WGs. Is this corr= ect?
Since the IGP drafts contain solely the TLV encoding and IGP flooding = specifications, there is reason for them to be homed anywhere else. 

All,
I meant "no reason for them to be homed anywhere else". = ;
Thanks,
Acee 






Thanks,
Acee 



Cheers, Manav

--
Thumb typed by Manav

On Jun 10, 2014 7:23 PM, "Jeffrey Haas"= ; <jhaas@pfrc.org> wrote:
Working Group,

Our updated charter was approved by the IESG.  The S-BFD work is offic= ially
in scope now!

Per our prior discussion, authors please submit the following documents as<= br> draft-ietf-bfd-*:

draft-aldrin-bfd-seamless-use-case (Milestone: November 2014)
draft-akiya-bfd-seamless-base (Milestone: March 2015)

The following documents are known to be work of interest, but aren't quite<= br> ready for adoption.  Please kick off additional discussions to drive t= hat
work forward:

draft-akiya-bfd-seamless-ip
draft-akiya-bfd-seamless-sr
draft-akiya-bfd-seamless-alert-discrim

My recommendation is to drive the IP case first.

-- Jeff





----- Forwarded message from The IESG <iesg-secretary@ietf.org> -----

Date: Thu, 05 Jun 2014 10:16:58 -0700
From: The IESG <iesg-secretar= y@ietf.org>
To: IETF-Announce <ietf-announ= ce@ietf.org>
Cc: bfd WG <rtg-bfd@ietf.org>=
Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd)
The Bidirectional Forwarding Detection (bfd) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs.

Bidirectional Forwarding Detection (bfd)
------------------------------------------------
Current Status: Active WG

Chairs:
  Nobo Akiya <nobo@cisco.com&= gt;
  Jeffrey Haas <jhaas@pfrc.org>

Technical advisors:
  Dave Katz <dkatz@juniper.net= >
  David Ward <dward@cisco.com>

Assigned Area Director:
  Adrian Farrel <adrian@oldd= og.co.uk>

Mailing list
  Address: rtg-bfd@ietf.org   To Subscribe: rtg-bfd-re= quest@ietf.org
  Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/

Charter:

The BFD Working Group is chartered to standardize and support the
bidirectional forwarding detection protocol (BFD) and its extensions.  = ;A
core goal of the working group is to standardize BFD in the context of
IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations.
The Working Group will also provide advice and guidance on BFD to other
working groups or standards bodies as requested.

BFD is a protocol intended to detect faults in the bidirectional path
between two forwarding engines, including physical interfaces,
subinterfaces, data link(s), and to the extent possible the forwarding
engines themselves, with potentially very low latency. It operates
independently of media, data protocols, and routing protocols. An
additional goal is to provide a single mechanism that can be used for
liveness detection over any media, at any protocol layer, with
a wide range of detection times and overhead, to avoid a proliferation
of different methods.

Important characteristics of BFD include:

- Simple, fixed-field encoding to facilitate implementations in
  hardware.

- Independence of the data protocol being forwarded between two systems.   BFD packets are carried as the payload of whatever encapsulating
  protocol is appropriate for the medium and network.

- Path independence: BFD can provide failure detection on any kind of
  path between systems, including direct physical links, virtual
  circuits, tunnels, MPLS LSPs, multihop routed paths, and
  unidirectional links (so long as there is some return path, of
  course).

- Ability to be bootstrapped by any other protocol that automatically
  forms peer, neighbor or adjacency relationships to seed BFD endpoint=
  discovery.

The working group is currently chartered to complete the following work
items:

1. Develop further MIB modules for BFD and submit them to the IESG for
publication as Proposed Standards.

2a. Provide a generic keying-based cryptographic authentication
mechanism for the BFD protocol developing the work of the KARP
working group.  This mechanism  will support authentication throu= gh
a key identifier for the BFD session's Security Association rather
than specifying new authentication extensions.

2b. Provide extensions to the BFD MIB in support of the generic keying-
based cryptographic authentication mechanism.

2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check
value but not beyond commonly accepted lengths to ensure security) using the generic keying-based cryptographic authentication mechanism.

3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks.

4. Provide an informational document to recommend standardized timers
and timer operations for BFD when used in different applications.

5. Define a mechanism to perform single-ended path (i.e. continuity)
verification based on the BFD specification.  Allow such a mechanism t= o
work both proactively and on-demand, without prominent initial delay.
Allow the mechanism to maintain multiple sessions to a target entity and between the same pair of network entities. In doing this work, the WG
will work closely with at least the following other WGs: ISIS, OSPF,
SPRING.

The working group will maintain a relationship with the MPLS working
group.

Milestones:
  Done     - Submit the base protocol specification to the I= ESG to be
considered as a Proposed Standard
  Done     - Submit BFD encapsulation and usage profile for = single-hop
IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed
Standard
  Done     - Submit BFD encapsulation and usage profile for = MPLS LSPs to
the IESG to be considered as a Proposed Standard
  Done     - Submit BFD encapsulation and usage profile for = multi-hop
IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed
Standard
  Done     - Submit the BFD MIB to the IESG to be considered= as a
Proposed Standard
  Done     - Submit the BFD over LAG mechanism to the IESG t= o be
considered as a Proposed Standard
  Jun 2014 - Submit the the document on BFD point-to-multipoint suppor= t
to the IESG to be considered as a Proposed Standard
  Nov 2014 - Submit the BFD MPLS extension MIB to the IESG to be
considered as a Proposed Standard
  Jan 2015 - Submit the generic keying based cryptographic authenticat= ion
mechanism to the IESG to be considered as a Proposed Standard
  Jan 2015 - Submit a BFD MIB extension in support of the generic keyi= ng
document to the IESG to be considered as a Proposed Standard
  Jan 2015 - Submit the cryptographic authentication procedures for BF= D
to the IESG to be considered as a Proposed Standard
  Jan 2015 - Submit the BFD Common Intervals document to the IESG to b= e
considered as an Informational RFC


----- End forwarded message -----

 --_000_CFBC84C131017aceelindemericssoncom_-- From nobody Tue Jun 10 10:50:16 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725C41A0259; Tue, 10 Jun 2014 10:49: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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Was33e0pkRfo; Tue, 10 Jun 2014 10:49:43 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36AC21A0240; Tue, 10 Jun 2014 10:49:43 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id uy5so6005572obc.3 for ; Tue, 10 Jun 2014 10:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7C6UJpry1Gn/wbF8ZZlsdnwxBrYGMkOZbcwKxy2LcsU=; b=WF8huHlBmEyqsh1oIfYSY/RCokz5pqebcCeDxlkux0q+C22CHkQuykOiiuIAmUspb0 5eWSznC4ynu4gWMFr+amfCcveFNAfFje1YYIMnY5Pki1Dpocia80pbM/G923+0m9tnyj 3+8IFc1soyVpgeE8m5//fcpRjWsAqSOgyVjoJQ5lTcotJFweKyyt4p6N5IvgevazNjrG MiVjuJJaafFLGwcZnT2TC8QqPClkCx47/w4OYWRjXmkiTRFmHFLoMo5J4XHpuBXSWAAr BzO+4w9iceENSWT9/GCZqarfz26V+u6SAcKUsngA4P/dwh0o3b7GFaZb+5wkFnzdqZLI KmjA== MIME-Version: 1.0 X-Received: by 10.182.138.99 with SMTP id qp3mr11009804obb.69.1402422582559; Tue, 10 Jun 2014 10:49:42 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Tue, 10 Jun 2014 10:49:42 -0700 (PDT) Received: by 10.76.77.97 with HTTP; Tue, 10 Jun 2014 10:49:42 -0700 (PDT) In-Reply-To: References: <20140610135340.GA19601@pfrc> Date: Tue, 10 Jun 2014 10:49:42 -0700 Message-ID: From: Manav Bhatia To: Acee Lindem Content-Type: multipart/alternative; boundary=e89a8ff25450dbc7c204fb7ef333 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/kM5y6vHEivtyUIrdLwsbkIioIT8 Cc: Jeffrey Haas , OSPF - OSPF WG List , "rtg-bfd@ietf.org" Subject: Re: [OSPF] BFD re-charter complete X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2014 17:49:46 -0000 --e89a8ff25450dbc7c204fb7ef333 Content-Type: text/plain; charset=UTF-8 Hi Acee, You might also want to consider another draft submitted by Xu, Uma and yours truly which advertises a reachable ipv4/6 address in ospf te tlvs. That draft will be reqd by the sbfd to work. Thx, Manav -- Thumb typed by Manav On Jun 10, 2014 10:20 PM, "Acee Lindem" wrote: > From: Ericsson > Date: Tuesday, June 10, 2014 9:34 AM > To: Manav Bhatia , Jeffrey Haas , " > rtg-bfd@ietf.org" , OSPF - OSPF WG List > Subject: Re: [OSPF] BFD re-charter complete > > Hi Manav, > > From: Manav Bhatia > Date: Tuesday, June 10, 2014 7:40 AM > To: Jeffrey Haas , "rtg-bfd@ietf.org" , > OSPF - OSPF WG List > Subject: Re: [OSPF] BFD re-charter complete > > Hi Jeff, > > What about the ospf/isis extn drafts for distributing the sbfd > discriminators? I guess these would be owned by the respective IGP WGs. Is > this correct? > > Since the IGP drafts contain solely the TLV encoding and IGP flooding > specifications, there is reason for them to be homed anywhere else. > > > All, > I meant "no reason for them to be homed anywhere else". > Thanks, > Acee > > > > > > > Thanks, > Acee > > > > Cheers, Manav > > -- > Thumb typed by Manav > On Jun 10, 2014 7:23 PM, "Jeffrey Haas" wrote: > >> Working Group, >> >> Our updated charter was approved by the IESG. The S-BFD work is >> officially >> in scope now! >> >> Per our prior discussion, authors please submit the following documents as >> draft-ietf-bfd-*: >> >> draft-aldrin-bfd-seamless-use-case (Milestone: November 2014) >> draft-akiya-bfd-seamless-base (Milestone: March 2015) >> >> The following documents are known to be work of interest, but aren't quite >> ready for adoption. Please kick off additional discussions to drive that >> work forward: >> >> draft-akiya-bfd-seamless-ip >> draft-akiya-bfd-seamless-sr >> draft-akiya-bfd-seamless-alert-discrim >> >> My recommendation is to drive the IP case first. >> >> -- Jeff >> >> >> >> >> >> ----- Forwarded message from The IESG ----- >> >> Date: Thu, 05 Jun 2014 10:16:58 -0700 >> From: The IESG >> To: IETF-Announce >> Cc: bfd WG >> Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd) >> >> The Bidirectional Forwarding Detection (bfd) working group in the Routing >> Area of the IETF has been rechartered. For additional information please >> contact the Area Directors or the WG Chairs. >> >> Bidirectional Forwarding Detection (bfd) >> ------------------------------------------------ >> Current Status: Active WG >> >> Chairs: >> Nobo Akiya >> Jeffrey Haas >> >> Technical advisors: >> Dave Katz >> David Ward >> >> Assigned Area Director: >> Adrian Farrel >> >> Mailing list >> Address: rtg-bfd@ietf.org >> To Subscribe: rtg-bfd-request@ietf.org >> Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/ >> >> Charter: >> >> The BFD Working Group is chartered to standardize and support the >> bidirectional forwarding detection protocol (BFD) and its extensions. A >> core goal of the working group is to standardize BFD in the context of >> IP routing, or protocols such as MPLS that are based on IP routing, in a >> way that will encourage multiple, inter-operable vendor implementations. >> >> The Working Group will also provide advice and guidance on BFD to other >> working groups or standards bodies as requested. >> >> BFD is a protocol intended to detect faults in the bidirectional path >> between two forwarding engines, including physical interfaces, >> subinterfaces, data link(s), and to the extent possible the forwarding >> engines themselves, with potentially very low latency. It operates >> independently of media, data protocols, and routing protocols. An >> additional goal is to provide a single mechanism that can be used for >> liveness detection over any media, at any protocol layer, with >> a wide range of detection times and overhead, to avoid a proliferation >> of different methods. >> >> Important characteristics of BFD include: >> >> - Simple, fixed-field encoding to facilitate implementations in >> hardware. >> >> - Independence of the data protocol being forwarded between two systems. >> BFD packets are carried as the payload of whatever encapsulating >> protocol is appropriate for the medium and network. >> >> - Path independence: BFD can provide failure detection on any kind of >> path between systems, including direct physical links, virtual >> circuits, tunnels, MPLS LSPs, multihop routed paths, and >> unidirectional links (so long as there is some return path, of >> course). >> >> - Ability to be bootstrapped by any other protocol that automatically >> forms peer, neighbor or adjacency relationships to seed BFD endpoint >> discovery. >> >> The working group is currently chartered to complete the following work >> items: >> >> 1. Develop further MIB modules for BFD and submit them to the IESG for >> publication as Proposed Standards. >> >> 2a. Provide a generic keying-based cryptographic authentication >> mechanism for the BFD protocol developing the work of the KARP >> working group. This mechanism will support authentication through >> a key identifier for the BFD session's Security Association rather >> than specifying new authentication extensions. >> >> 2b. Provide extensions to the BFD MIB in support of the generic keying- >> based cryptographic authentication mechanism. >> >> 2c. Specify cryptographic authentication procedures for the BFD protocol >> using HMAC-SHA-256 (possibly truncated to a smaller integrity check >> value but not beyond commonly accepted lengths to ensure security) using >> the generic keying-based cryptographic authentication mechanism. >> >> 3. Provide an extension to the BFD core protocol in support of point-to- >> multipoint links and networks. >> >> 4. Provide an informational document to recommend standardized timers >> and timer operations for BFD when used in different applications. >> >> 5. Define a mechanism to perform single-ended path (i.e. continuity) >> verification based on the BFD specification. Allow such a mechanism to >> work both proactively and on-demand, without prominent initial delay. >> Allow the mechanism to maintain multiple sessions to a target entity and >> between the same pair of network entities. In doing this work, the WG >> will work closely with at least the following other WGs: ISIS, OSPF, >> SPRING. >> >> The working group will maintain a relationship with the MPLS working >> group. >> >> Milestones: >> Done - Submit the base protocol specification to the IESG to be >> considered as a Proposed Standard >> Done - Submit BFD encapsulation and usage profile for single-hop >> IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed >> Standard >> Done - Submit BFD encapsulation and usage profile for MPLS LSPs to >> the IESG to be considered as a Proposed Standard >> Done - Submit BFD encapsulation and usage profile for multi-hop >> IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed >> Standard >> Done - Submit the BFD MIB to the IESG to be considered as a >> Proposed Standard >> Done - Submit the BFD over LAG mechanism to the IESG to be >> considered as a Proposed Standard >> Jun 2014 - Submit the the document on BFD point-to-multipoint support >> to the IESG to be considered as a Proposed Standard >> Nov 2014 - Submit the BFD MPLS extension MIB to the IESG to be >> considered as a Proposed Standard >> Jan 2015 - Submit the generic keying based cryptographic authentication >> mechanism to the IESG to be considered as a Proposed Standard >> Jan 2015 - Submit a BFD MIB extension in support of the generic keying >> document to the IESG to be considered as a Proposed Standard >> Jan 2015 - Submit the cryptographic authentication procedures for BFD >> to the IESG to be considered as a Proposed Standard >> Jan 2015 - Submit the BFD Common Intervals document to the IESG to be >> considered as an Informational RFC >> >> >> ----- End forwarded message ----- >> >> --e89a8ff25450dbc7c204fb7ef333 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Acee,

You might also want to consider another draft submitted by Xu, Uma and y= ours truly which advertises a reachable ipv4/6 address in ospf te tlvs. Tha= t draft will be reqd by the sbfd to work.

Thx, Manav

--
Thumb typed by Manav

On Jun 10, 2014 10:20 PM, "Acee Lindem"= ; <acee.lindem@ericsson.com<= /a>> wrote:
Date: Tuesday, June 10, 2014 9:34 A= M
To: Manav Bhatia <manavbhatia@gmail.com>,= Jeffrey Haas <jhaas= @pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, OSPF - OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] BFD re-charter = complete

Hi Manav,=C2=A0

From: Manav Bhatia <manavbhatia@gmail.com>= ;
Date: Tuesday, June 10, 2014 7:40 A= M
To: Jeffrey Haas <jhaas@pfrc.org>, "rtg-bfd@ietf.org" &= lt;rtg-bfd@ietf.org>, OSPF - OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] BFD re-charter = complete

Hi Jeff,

What about the ospf/isis extn drafts for distributing the sbfd discrimin= ators? I guess these would be owned by the respective IGP WGs. Is this corr= ect?
Since the IGP drafts contain solely the TLV encoding and IGP flooding = specifications, there is reason for them to be homed anywhere else.=C2=A0

All,
I meant "no reason for them to be homed anywhere else".=C2= =A0
Thanks,
Acee=C2=A0






Thanks,
Acee=C2=A0



Cheers, Manav

--
Thumb typed by Manav

On Jun 10, 2014 7:23 PM, "Jeffrey Haas"= ; <jhaas@pfrc.org> wrote:
Working Group,

Our updated charter was approved by the IESG. =C2=A0The S-BFD work is offic= ially
in scope now!

Per our prior discussion, authors please submit the following documents as<= br> draft-ietf-bfd-*:

draft-aldrin-bfd-seamless-use-case (Milestone: November 2014)
draft-akiya-bfd-seamless-base (Milestone: March 2015)

The following documents are known to be work of interest, but aren't qu= ite
ready for adoption. =C2=A0Please kick off additional discussions to drive t= hat
work forward:

draft-akiya-bfd-seamless-ip
draft-akiya-bfd-seamless-sr
draft-akiya-bfd-seamless-alert-discrim

My recommendation is to drive the IP case first.

-- Jeff





----- Forwarded message from The IESG <iesg-secretary@ietf.org> -----

Date: Thu, 05 Jun 2014 10:16:58 -0700
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: bfd WG <rtg-bf= d@ietf.org>
Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd)
The Bidirectional Forwarding Detection (bfd) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs.

Bidirectional Forwarding Detection (bfd)
------------------------------------------------
Current Status: Active WG

Chairs:
=C2=A0 Nobo Akiya <n= obo@cisco.com>
=C2=A0 Jeffrey Haas <jhaas@pfrc.org>

Technical advisors:
=C2=A0 Dave Katz <dkatz@juniper.net>
=C2=A0 David Ward <= dward@cisco.com>

Assigned Area Director:
=C2=A0 Adrian Farrel <adrian@olddog.co.uk>

Mailing list
=C2=A0 Address: rtg-b= fd@ietf.org
=C2=A0 To Subscribe: rtg-bfd-request@ietf.org
=C2=A0 Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/

Charter:

The BFD Working Group is chartered to standardize and support the
bidirectional forwarding detection protocol (BFD) and its extensions. =C2= =A0A
core goal of the working group is to standardize BFD in the context of
IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations.
The Working Group will also provide advice and guidance on BFD to other
working groups or standards bodies as requested.

BFD is a protocol intended to detect faults in the bidirectional path
between two forwarding engines, including physical interfaces,
subinterfaces, data link(s), and to the extent possible the forwarding
engines themselves, with potentially very low latency. It operates
independently of media, data protocols, and routing protocols. An
additional goal is to provide a single mechanism that can be used for
liveness detection over any media, at any protocol layer, with
a wide range of detection times and overhead, to avoid a proliferation
of different methods.

Important characteristics of BFD include:

- Simple, fixed-field encoding to facilitate implementations in
=C2=A0 hardware.

- Independence of the data protocol being forwarded between two systems. =C2=A0 BFD packets are carried as the payload of whatever encapsulating
=C2=A0 protocol is appropriate for the medium and network.

- Path independence: BFD can provide failure detection on any kind of
=C2=A0 path between systems, including direct physical links, virtual
=C2=A0 circuits, tunnels, MPLS LSPs, multihop routed paths, and
=C2=A0 unidirectional links (so long as there is some return path, of
=C2=A0 course).

- Ability to be bootstrapped by any other protocol that automatically
=C2=A0 forms peer, neighbor or adjacency relationships to seed BFD endpoint=
=C2=A0 discovery.

The working group is currently chartered to complete the following work
items:

1. Develop further MIB modules for BFD and submit them to the IESG for
publication as Proposed Standards.

2a. Provide a generic keying-based cryptographic authentication
mechanism for the BFD protocol developing the work of the KARP
working group. =C2=A0This mechanism =C2=A0will support authentication throu= gh
a key identifier for the BFD session's Security Association rather
than specifying new authentication extensions.

2b. Provide extensions to the BFD MIB in support of the generic keying-
based cryptographic authentication mechanism.

2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check
value but not beyond commonly accepted lengths to ensure security) using the generic keying-based cryptographic authentication mechanism.

3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks.

4. Provide an informational document to recommend standardized timers
and timer operations for BFD when used in different applications.

5. Define a mechanism to perform single-ended path (i.e. continuity)
verification based on the BFD specification. =C2=A0Allow such a mechanism t= o
work both proactively and on-demand, without prominent initial delay.
Allow the mechanism to maintain multiple sessions to a target entity and between the same pair of network entities. In doing this work, the WG
will work closely with at least the following other WGs: ISIS, OSPF,
SPRING.

The working group will maintain a relationship with the MPLS working
group.

Milestones:
=C2=A0 Done =C2=A0 =C2=A0 - Submit the base protocol specification to the I= ESG to be
considered as a Proposed Standard
=C2=A0 Done =C2=A0 =C2=A0 - Submit BFD encapsulation and usage profile for = single-hop
IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed
Standard
=C2=A0 Done =C2=A0 =C2=A0 - Submit BFD encapsulation and usage profile for = MPLS LSPs to
the IESG to be considered as a Proposed Standard
=C2=A0 Done =C2=A0 =C2=A0 - Submit BFD encapsulation and usage profile for = multi-hop
IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed
Standard
=C2=A0 Done =C2=A0 =C2=A0 - Submit the BFD MIB to the IESG to be considered= as a
Proposed Standard
=C2=A0 Done =C2=A0 =C2=A0 - Submit the BFD over LAG mechanism to the IESG t= o be
considered as a Proposed Standard
=C2=A0 Jun 2014 - Submit the the document on BFD point-to-multipoint suppor= t
to the IESG to be considered as a Proposed Standard
=C2=A0 Nov 2014 - Submit the BFD MPLS extension MIB to the IESG to be
considered as a Proposed Standard
=C2=A0 Jan 2015 - Submit the generic keying based cryptographic authenticat= ion
mechanism to the IESG to be considered as a Proposed Standard
=C2=A0 Jan 2015 - Submit a BFD MIB extension in support of the generic keyi= ng
document to the IESG to be considered as a Proposed Standard
=C2=A0 Jan 2015 - Submit the cryptographic authentication procedures for BF= D
to the IESG to be considered as a Proposed Standard
=C2=A0 Jan 2015 - Submit the BFD Common Intervals document to the IESG to b= e
considered as an Informational RFC


----- End forwarded message -----
--e89a8ff25450dbc7c204fb7ef333-- From nobody Tue Jun 10 14:23:57 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFBE1A0318 for ; Tue, 10 Jun 2014 14:23:55 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dbi2DHCVwRiu for ; Tue, 10 Jun 2014 14:23:53 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974031A0317 for ; Tue, 10 Jun 2014 14:23:52 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-e5-539726a1c2df Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id CC.F2.27529.1A627935; Tue, 10 Jun 2014 17:39:14 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Tue, 10 Jun 2014 17:23:50 -0400 From: Acee Lindem To: OSPF - OSPF WG List Thread-Topic: Improving and Restructuring the Routing Area Thread-Index: AQHPhOjSyCOhQjAmy0a/BDJtUJUvN5tqqGiA Date: Tue, 10 Jun 2014 21:23:50 +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/14.4.2.140509 x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_CFBCC54E310FAaceelindemericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXRPuO4itenBBm9XM1u03LvH7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujI63LxgLli5lrPi8fhVjA+OufsYuRk4OCQETiZa218wQtpjE hXvr2boYuTiEBI4yShy7s5YdwlnOKPF9wQJWkCo2AR2J54/+gXWICKhLrJ68GywuLGApcf7K DBaIuJXE/5vtUDVGEmf3/QKrYRFQlbixYSbYZl4BU4ndU2exgdhCAtMZJVY1SYHYnAKBEp9/ NYD1MgJd9P3UGiYQm1lAXOLWk/lMEJcKSCzZcx7qalGJl4//gc0XFdCTaO56A/WZosS+/uns EL1REi+vzWOH2CsocXLmE5YJjKKzkIydhaRsFpIyiLiOxILdn9ggbG2JZQtfM8PYZw48huq1 lrg8E1XNAkaOVYwcpcWpZbnpRgabGIHxdUyCTXcH456XlocYBTgYlXh4Fa5PCxZiTSwrrsw9 xCjNwaIkzqt9sypYSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2OC7YPV72cEabnz8t378Hzv tPMG38xVeH/rxPtFSeQvCdo4N+Gjf7bIKqN/B5Nt2X1Vzkd9Sj3KvSPo3uu58ZeuXXJ2OrR2 Tbvw9ZvK0o/FLt0KemkzaUPiu9OXjN7vFdrwVejT9f0JW/8ty9MteP2lQX3y/wdBL/4enjM7 3+qfc5JJ3eSW0y3nlFiKMxINtZiLihMBeiL6EZACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/TDFsypfPxCOarVBg2lCBgCVbJjw Subject: [OSPF] FW: Improving and Restructuring the Routing Area X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jun 2014 21:23:55 -0000 --_000_CFBCC54E310FAaceelindemericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please be aware of the ongoing effort to improve the productivity of the IE= TF Routing Area. Also note that discussion will happen on routing-discussi= on@ietf.org and those wishing to partic= ipate should assure that they are subscribed. Thanks, Acee From: Alia Atlas > Date: Tuesday, June 10, 2014 1:14 PM To: "rtg-chairs@ietf.org" > Subject: Fwd: Improving and Restructuring the Routing Area Resent-To: >, "Nobo Akiya (nobo)" >, Deborah Brungard >, Lou Berger >, >, >, >, >, >, John Scudder >, Chris Hopps >, Hannes Gredler >, >, >, >, >, >, Stan Ratliff >, >, >, >, >, >, Abhay Roy >, Ericsson >, <= jpv@cisco.com>, >, >, = >, >, "Andrew G. Malis" >, >, = >, >, >, >, >, >, >, >, John Scudder = >, Alia Atlas >, Adrian Farrel > Could you please forward to your working groups for those not on routing-di= scussion? Thanks, Alia ---------- Forwarded message ---------- From: Alia Atlas > Date: Tue, Jun 10, 2014 at 3:57 PM Subject: Improving and Restructuring the Routing Area To: routing-discussion@ietf.org To all participants in the Routing Area, Adrian and I are working on improving the quality, speed, and experience of getting work done in the IETF Routing Area. There are three initiatives that we are working: WG Draft QA, Routing Area specific WG chair training, and reorganizing the working groups in the area. First, we intend to use our Routing Directorate more proactively by introducing a Working Group Draft Quality Assurance (WG Draft QA) process where the same selected routing directorate member will review a draft during WG draft adoption and during WG last call. The process will be documented on the Routing Area wiki (http://trac.tools.ietf.org/area/rtg/trac/wiki). This should allow directorate reviews to report technical issues that can actually get fixed early in the process (equivalent of bug reports) as opposed to just noting the concerns in the drafts (equivalent of release notes). Second, as was discussed during the recent IESG retreat, in addition to the IETF-wide WG chair training, we intend to have a series of training sessions for WG Chairs in the Routing Area addressing topics such as judging consensus, project management, motivating volunteers, using the datatracker (via a sandbox version that can be played with safely), and sharing experiences between WG chairs. Third, we intend to reorganize the working groups in the Routing area. We feel that it is important to focus on areas where there is active interest in standardization and to be open and able to accept new work into the area. As you know, we have had several new working groups (nvo3, i2rs, sfc, spring) created in the last few years and we need to be open and able to handle more new work as it comes in. We would also like to improve the signal-to-noise ratio experienced by participants in the different working groups and improve the quantity and quality of discussion and reviews. It is likely that not all WGs in the Routing Area will be directly affected. Here is the time-line for reorganizing the WGs. NOW: public discussion on routing-discussion@ietf.org about how to reorganize the working groups to best meet our motivations. Additional focused discussions are expected on the rtg-chairs@ietf.org and rtg-dir@ietf.org mailing lists. In Toronto: There will be meetings with the WG chairs and the Routing Directorate to get the ideas described and agreed upon. At the Routing Area Meeting in Toronto: Discuss the set of reorganized WGs and general charter content in the Routing Area meeting. September 2014: Based upon the feedback, suggestions, and discussion, Adrian and I finalize the reorganized WG charters. We start the internal IESG discussion and public reviews. October 2014: Formal rechartering process completes. In Honolulu: The new set of WGs meet. After Honolulu: Adrian and I deal with any issues and charter updates based upon a few months of experience. Here are the motivations that Adrian and I would like to be considered when coming up with ideas for how the WGs should be reorganized. 1) Move towards organizing working groups on functional responsibilities rather than scoping them to specific protocols. 2) Split giant working groups so relevant work is done in one place and there is an improved signal-to-noise ratio for participants who are only interested in a slice of the current working group's work. 3) Create synergies for scattered functionality (example ideas: OAM, FRR, traffic-engineering) 4) Create a DISPATCH working group for clear new idea discussion; rtgwg serves some of this purpose but doesn't have a clear process and isn't drawing in the new ideas. 5) Focus Routing Area time on design centers rather than on far corner cases. 6) Each working group should have clear, well defined, and achievable go= als. Noting that the Routing Area has inherited some of its WG structure from the sub-IP area, it is not a goal to force IP routing and MPLS routing to remain separated. The goal of this reorganization is not closing working groups. Adrian and Alia are perfectly capable of closing working groups without going through restructuring. For those of you that have read this far, thank you. Getting this 80% right is going to take some serious discussion and thought. We all work in the Routing Area together with different perspectives. Please think carefully and help us have a highly focused discussion. Thanks, Alia and Adrian --_000_CFBCC54E310FAaceelindemericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <2C59A06BEB521E449B2F9D28195246CD@ericsson.com> Content-Transfer-Encoding: quoted-printable
Please be aware of the ongoing effort to improve the productivity of t= he IETF Routing Area.  Also note that discussion will happen on <= a href=3D"mailto:routing-discussion@ietf.org">routing-discussion@ietf.org and those wishing to participate should assure that they are subscribed. 
 
Thanks,
Acee


From: Alia Atlas <akatlas@gmail.com>
Date: Tuesday, June 10, 2014 1:14 P= M
To: "rtg-chairs@ietf.org" <rtg-chairs@ietf.org>
Subject: Fwd: Improving and Restruc= turing the Routing Area
Resent-To: <jhaas@pfrc.org>, "Nobo Akiya (nobo)" <nobo@cisco.com>, Deborah Brungard <= ;dbrungard@att.com>, Lou Berger <lberger@labn.net>, &= lt;hadi@mojatatu.com>, <damascene.joachimpillai@= verizon.com>, <jhaas@pfrc.org>, <edc@google.com>, <shares@ndzh.com>, John Scudder <jgs@juniper.net>, Chris Hopps <chopps@rawdofmt.org>, Hannes Gredler <hannes@juniper.net&g= t;, <nabil.n.bitar@verizon.= com>, <giheron@cisco.com= >, <thomas.morin@orange.co= m>, <martin.vigoureu= x@alcatel-lucent.com>, <macker@itd.nrl.navy.mil>, Stan Ratliff <sratliff@cisco.com>, <swallow@cisco.com>, <loa@pi.nu>, <rcallon@juniper.net>, <bensons@queuefull.net>, <matthew.bocci@alcatel-lucent.com>, Abhay Roy <akr@cisco.com>, Eric= sson <acee.lindem@ericsson.c= om>, <jpv@cisco.com>, <= ;julien.meuric@orange.com&g= t;, <mmcbride7@gmail.com>, &l= t;stig@venaas.com>, <matthew.bocci@alcatel-lucent.c= om>, "Andrew G. Malis" <agmalis@gmail.com>, <mcr+ietf@sandelman.ca= >, <mariainesrobles@= gmail.com>, <aretana@cisco.c= om>, <jeff.tantsura= @ericsson.com>, <narten@us.ibm.com>, <jguichar@cisco.com>, <sandy@tislabs.com>, <morrowc@ops-netman.net>, <aretana@cisco.com>, John Scudder <jgs@juniper.net>= ;, Alia Atlas <akatlas@gmail.com>, Adrian Farrel <adrian@oldd= og.co.uk>

Could you please forward to your working groups for those = not on routing-discussion?

Thanks,
Alia

---------- Forwarded message ----------
From: Alia Atlas <akatlas@gmail.com>
Date: Tue, Jun 10, 2014 at 3:57 PM
Subject: Improving and Restructuring the Routing Area
To: routing-discussion@ietf.= org


To all participants in the Routing Area,

Adrian and I are working on improving the quality, speed, and
experience of getting work done in the IETF Routing Area.  There = are
three initiatives that we are working: WG Draft QA, Routing Area
specific WG chair training, and reorganizing the working groups in the=
area.

First, we intend to use our Routing Directorate more proactively by
introducing a Working Group Draft Quality Assurance (WG Draft QA)
process where the same selected routing directorate member will review=
a draft during WG draft adoption and during WG last call.  The pr= ocess
will be documented on the Routing Area wiki
directorate reviews to report technical issues that can actually get
fixed early in the process (equivalent of bug reports) as opposed to
just noting the concerns in the drafts (equivalent of release notes).<= /div>

Second, as was discussed during the recent IESG retreat, in addition
to the IETF-wide WG chair training, we intend to have a series of
training sessions for WG Chairs in the Routing Area addressing topics<= /div>
such as judging consensus, project management, motivating volunteers,<= /div>
using the datatracker (via a sandbox version that can be played
with safely), and sharing experiences between WG chairs.

Third, we intend to reorganize the working groups in the Routing area.=
We feel that it is important to focus on areas where there is active
interest in standardization and to be open and able to accept new work=
into the area.  As you know, we have had several new working grou= ps
(nvo3, i2rs, sfc, spring) created in the last few years and we need to=
be open and able to handle more new work as it comes in.  We woul= d
also like to improve the signal-to-noise ratio experienced by
participants in the different working groups and improve the quantity<= /div>
and quality of discussion and reviews.  It is likely that not all= WGs
in the Routing Area will be directly affected.

Here is the time-line for reorganizing the WGs.

   NOW: public discussion on routing-discussion@ietf.org about how to
   reorganize the working groups to best meet our motivation= s.
   Additional focused discussions are expected on the
   = rtg-chairs@ietf.org and rtg-dir@ietf.org = mailing lists.

   In Toronto: There will be meetings with the WG chairs and= the
   Routing Directorate to get the ideas described and agreed= upon.

   At the Routing Area Meeting in Toronto: Discuss the set o= f
   reorganized WGs and general charter content in the Routin= g Area
   meeting.

   September 2014: Based upon the feedback, suggestions, and=
   discussion, Adrian and I finalize the reorganized WG char= ters.  We
   start the internal IESG discussion and public reviews.

   October 2014: Formal rechartering process completes.

   In Honolulu: The new set of WGs meet.

   After Honolulu: Adrian and I deal with any issues and cha= rter
   updates based upon a few months of experience.

Here are the motivations that Adrian and I would like to be considered=
when coming up with ideas for how the WGs should be reorganized.

   1) Move towards organizing working groups on functional
   responsibilities rather than scoping them to specific pro= tocols.

   2) Split giant working groups so relevant work is done in= one place
   and there is an improved signal-to-noise ratio for partic= ipants who
   are only interested in a slice of the current working gro= up's work.

   3) Create synergies for scattered functionality (example = ideas:
   OAM, FRR, traffic-engineering)

   4) Create a DISPATCH working group for clear new idea dis= cussion;
   rtgwg serves some of this purpose but doesn't have a clea= r process
   and isn't drawing in the new ideas.

   5) Focus Routing Area time on design centers rather than = on far
   corner cases.

   6) Each working group should have clear, well defined, an= d achievable goals.

Noting that the Routing Area has inherited some of its WG structure
from the sub-IP area, it is not a goal to force IP routing and MPLS
routing to remain separated.

The goal of this reorganization is not closing working groups.  A= drian
and Alia are perfectly capable of closing working groups without going=
through restructuring.

For those of you that have read this far, thank you.  Getting thi= s 80%
right is going to take some serious discussion and thought.  We a= ll
work in the Routing Area together with different perspectives.  P= lease
think carefully and help us have a highly focused discussion.

Thanks,
Alia and Adrian


 --_000_CFBCC54E310FAaceelindemericssoncom_-- From nobody Wed Jun 11 19:59:06 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38EA1A0354 for ; Wed, 11 Jun 2014 19:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0WHuiEiMR4J for ; Wed, 11 Jun 2014 19:59:01 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31331A0310 for ; Wed, 11 Jun 2014 19:58:57 -0700 (PDT) Received: from CH1PRD0510HT001.namprd05.prod.outlook.com (10.255.150.36) by DM2PR05MB383.namprd05.prod.outlook.com (10.141.101.147) with Microsoft SMTP Server (TLS) id 15.0.954.9; Thu, 12 Jun 2014 02:58:55 +0000 Received: from juniper.net (193.110.55.19) by pod51010.outlook.com (10.255.150.36) with Microsoft SMTP Server (TLS) id 14.16.459.0; Thu, 12 Jun 2014 02:58:50 +0000 Date: Thu, 12 Jun 2014 04:58:42 +0200 From: Hannes Gredler To: Acee Lindem Message-ID: <20140612025842.GB15759@juniper.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [193.110.55.19] X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 02408926C4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(24454002)(164054003)(189002)(199002)(47776003)(23726002)(50466002)(4396001)(79102001)(50986999)(81542001)(101416001)(20776003)(33656002)(87936001)(54356999)(76176999)(81342001)(97756001)(21056001)(64706001)(74662001)(36756003)(83506001)(102836001)(31966008)(71816001)(15202345003)(83072002)(77982001)(19580405001)(83322001)(92726001)(19580395003)(80022001)(66066001)(92566001)(86362001)(99396002)(15975445006)(76482001)(85852003)(74502001)(46406003)(46102001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB383; H:CH1PRD0510HT001.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=hannes@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/bHYeKCSzTx5H9DeXBUNLnyfxgUs Cc: OSPF - OSPF WG List Subject: Re: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jun 2014 02:59:03 -0000 support as an co-author; On Mon, Jun 09, 2014 at 07:39:37PM +0000, Acee Lindem wrote: | Given the progress made in the SRING WG on problem statement and use | caseWG document adoption, Abhay and I now feel we can start a 1 week poll | on adoption of the corresponding OSPF document. | http://www.ietf.org/id/draft-psenak-ospf-segment-routing-extensions-05.txt | Please indicate your support or opposition to WG adoption. | Thanks, | Abhay and Acee | P.S. Assuming adoption of the OSPFv2 draft, we will poll for acceptance of | the OSPFv3 draft. | _______________________________________________ | OSPF mailing list | OSPF@ietf.org | https://www.ietf.org/mailman/listinfo/ospf From nobody Thu Jun 12 03:10:15 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2A61B2833; Thu, 12 Jun 2014 03:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_SIDE=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQ3CWKyIRfoJ; Thu, 12 Jun 2014 03:10:12 -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 7FC3E1A0325; Thu, 12 Jun 2014 03:10:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BII60348; Thu, 12 Jun 2014 10:10:09 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Jun 2014 11:10:08 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Thu, 12 Jun 2014 18:10:02 +0800 From: Xuxiaohu To: "isis-wg@ietf.org" Thread-Topic: Comments on draft-ietf-isis-segment-routing-extensions-01 Thread-Index: Ac+GJni8pnqnrJn8Sty9J1EyPVqh3g== Date: Thu, 12 Jun 2014 10:10:01 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08280249@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/0oEUgmwP2v-asLTpGUB5buo2uYw Cc: OSPF List Subject: [OSPF] Comments on draft-ietf-isis-segment-routing-extensions-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jun 2014 10:10:13 -0000 Hi all,=20 The following are some comments on draft-ietf-isis-segment-routing-extensio= ns-01 (Note that the former four comments are applicable to draft-psenak-os= pf-segment-routing-extensions-05 as well.): 1. Terminology inconsistency issues The first example is about the semantics of the SID. According to the follo= wing description in section 2.1 "...SID/Index/Label: according to the V and= L flags, it contains...", the SID would be something other than label and = index. However, in the same section, it said "... Multiple Prefix-SIDs Sub= -TLVs MAY appear on the same prefix in which case each SID is encoded as a = separate Sub-TLV....", here the SID seems to be a generic terminology, whic= h could be index, label or SID.=20 The second example is about the length of the SID (here the SID is somethin= g other than index and label). In section 2.1, it said "...A variable lengt= h SID (e.g.: an IPv6 address SID)...." However, in section 2.3, it said "..= . SID/Label: if length is set to 3 then the 20 rightmost bits represent a M= PLS label. If length is 4 then the value represents a 32 bits SID..."=20 2. The uncertain usage of the 32-bit SID It said in draft-previdi-6man-segment-routing-header-01 that "In Segment Ro= uting IPv6 the SID is an IPv6 address". Therefore, what's the usage of the = 32-bit SID (see section 2.3, it said "... SID/Label: if length is set to 3 = then the 20 rightmost bits represent a MPLS label. If length is 4 then the= value represents a 32 bits SID)? 3. The uncertain usage of the 16-octect SID in the Prefix-SID sub-TLV In IPv6-SR case, since the SID is an IPv6 address, what's the usage of the = prefix-SID sub-TLV? It has been said in draft-previdi-6man-segment-routing-= header-00 that " When Segment Routing is applied to IPv6, segments are enco= ded as 128-bit IPv6 addresses. This implies that, in the IPv6 instantiatio= n of SR, the SID values are in fact the prefixes advertised in the IPv6 con= trol-plane. Hence there's no need to advertise any additional specific ide= ntifier (other than IPv6 prefix) for the purpose of SR. This simplifies the= introduction of IPv6 Segment Routing in existing protocols (i.e.: IS-IS, O= SPF and BGP). " I noticed that the above statement has been disappeared in the -01 version.= Did that mean that the co-authors of that draft have changed their minds s= ignificantly? 4. Suggestion on the algorithm field in the prefix-SID sub-TLV It seems that using various algorithms in the best path computation could a= lso be applicable to some cases other than SR. For instance, use different = algorithms for different topologies [rfc5120]. Therefore, it seems better t= o decouple the best path computation algorithm advertisement from the SR-sp= ecific advertisement. In this way, the algorithm is just coupled with the t= opology while the labels advertised through the prefix-sid sub-TLVs could b= e used to determine to which topology the received SR-MPLS packet belongs t= o. This behavior is much similar to the LDP and the LDP-MT. In other words,= the SR-specific IGP extension just plays the role of label distribution pr= otocol which shouldn't have any impact on the path computation behavior.=20 5. The lack of MT-ID field in the SID/Label Binding TLV I had suggested to add an MT-ID field in the SID/Label Binding TLV and Stef= ano had agreed to that suggestion. But it seems that the MT-ID field has no= t been added yet. 6. Suggestion on SR-Capabilities Sub-TLV The SR-Capabilities Sub-TLV is used to advertise: 1) data-plane capability;= 2) range of SID/Label values. It seems better to advertise these two capab= ilities via two separate sub-TLVs, e.g., DP-Capability sub-TLV and SID/Labe= l Range sub-TLV. In the way, the role of SID/Label Range sub-tlv is consist= ent with the counterpart in OSPF extensions (i.e., SID/Label Range TLV). An= yway, it seems better to keep the ISIS and OSPF extensions for the same fun= ction as consistent as possible.=20 Best regards, Xiaohu From nobody Thu Jun 12 03:42:08 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3491A0390; Thu, 12 Jun 2014 03:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.852 X-Spam-Level: X-Spam-Status: No, score=-12.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_SIDE=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCPeGUbsgZAM; Thu, 12 Jun 2014 03:42:04 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6F311B283F; Thu, 12 Jun 2014 03:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5701; q=dns/txt; s=iport; t=1402569722; x=1403779322; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jNZ7ZarqQB8cIkATbkKKlCD4UoW0AvOL4gAYi6dAyRE=; b=lYOOtEOd+dyxIV+phEbjSnbqJyuVlokLtyQwaSkdXidjCyntDfw5qu+9 VdGtKR51JGSv2M1ohqdI6hDngJtTC4ELVBfC6eJMWvid2+Q6gXnEeFA+U rVZy9mtWSt5aCkgB/84lIkDUh/U5+KKAFkW2xtUhrO5K5HxDGg8VKQKeK Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigGAMWDmVOtJA2E/2dsb2JhbABagw1SWalMAQEBAQEBBQGRYoc8AYEKFnWEAwEBAQMBAQEBNzQLBQsCAQgYHhAnCyUCBA4FiDoIDdF2EwSFXINRhHszB4MrgRYBA5oyk1KDPIIv X-IronPort-AV: E=Sophos;i="5.01,464,1400025600"; d="scan'208";a="52411180" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP; 12 Jun 2014 10:41:44 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s5CAfigA008456 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jun 2014 10:41:44 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.223]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Thu, 12 Jun 2014 05:41:44 -0500 From: "Stefano Previdi (sprevidi)" To: Xuxiaohu Thread-Topic: [OSPF] Comments on draft-ietf-isis-segment-routing-extensions-01 Thread-Index: AQHPhirmyIu3kHg8d0CjVJRpZBJZGA== Date: Thu, 12 Jun 2014 10:41:43 +0000 Message-ID: <442F4557-73F8-46B3-8ED7-E3E4BECF3523@cisco.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08280249@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08280249@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.220.243] Content-Type: text/plain; charset="us-ascii" Content-ID: <3C20A75C77D9A64BB2D5D2C7E9971916@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/jWscI_iq8mg4Z6J-3G1idfJed-A Cc: OSPF List , "isis-wg@ietf.org" Subject: Re: [OSPF] Comments on draft-ietf-isis-segment-routing-extensions-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jun 2014 10:42:06 -0000 Hi Xiaohu, On Jun 12, 2014, at 12:10 PM, Xuxiaohu wrote: > Hi all,=20 >=20 > The following are some comments on draft-ietf-isis-segment-routing-extens= ions-01 (Note that the former four comments are applicable to draft-psenak-= ospf-segment-routing-extensions-05 as well.): >=20 > 1. Terminology inconsistency issues >=20 > The first example is about the semantics of the SID. According to the fol= lowing description in section 2.1 "...SID/Index/Label: according to the V a= nd L flags, it contains...", the SID would be something other than label an= d index. However, in the same section, it said "... Multiple Prefix-SIDs S= ub-TLVs MAY appear on the same prefix in which case each SID is encoded as = a separate Sub-TLV....", here the SID seems to be a generic terminology, wh= ich could be index, label or SID.=20 >=20 > The second example is about the length of the SID (here the SID is someth= ing other than index and label). In section 2.1, it said "...A variable len= gth SID (e.g.: an IPv6 address SID)...." However, in section 2.3, it said "= ... SID/Label: if length is set to 3 then the 20 rightmost bits represent a= MPLS label. If length is 4 then the value represents a 32 bits SID..."=20 I'm not sure I understand where the inconsistency is. Prefix-SID goes with prefixes. Adj-SID goes with adjacencies. Both SubTLVs may be value or index and may have local or global scope. This is the flexibility we want to have. > 2. The uncertain usage of the 32-bit SID >=20 > It said in draft-previdi-6man-segment-routing-header-01 that "In Segment = Routing IPv6 the SID is an IPv6 address". Therefore, what's the usage of th= e 32-bit SID (see section 2.3, it said "... SID/Label: if length is set to = 3 then the 20 rightmost bits represent a MPLS label. If length is 4 then t= he value represents a 32 bits SID)? you're right. I'll fix the text. > 3. The uncertain usage of the 16-octect SID in the Prefix-SID sub-TLV >=20 > In IPv6-SR case, since the SID is an IPv6 address, what's the usage of th= e prefix-SID sub-TLV? It has been said in draft-previdi-6man-segment-routin= g-header-00 that " When Segment Routing is applied to IPv6, segments are en= coded as 128-bit IPv6 addresses. This implies that, in the IPv6 instantiat= ion of SR, the SID values are in fact the prefixes advertised in the IPv6 c= ontrol-plane. Hence there's no need to advertise any additional specific i= dentifier (other than IPv6 prefix) for the purpose of SR. This simplifies t= he introduction of IPv6 Segment Routing in existing protocols (i.e.: IS-IS,= OSPF and BGP). " > I noticed that the above statement has been disappeared in the -01 versio= n. Did that mean that the co-authors of that draft have changed their minds= significantly? nope. The text you mentioned has been replaced by the following one: "The Node-SID identifies a node. With SR-IPv6 the Node-SID is an IPv6=20 prefix that the operator configured on the node and that is used as=20 the node identifier. Typically, in case of a router, this is the IPv6=20 address of the node loopback interface. Therefore, SR-IPv6 does not=20 require any additional SID advertisement for the Node Segment. The=20 Node-SID is in fact the IPv6 address of the node." > 4. Suggestion on the algorithm field in the prefix-SID sub-TLV >=20 > It seems that using various algorithms in the best path computation could= also be applicable to some cases other than SR. For instance, use differen= t algorithms for different topologies [rfc5120]. Therefore, it seems better= to decouple the best path computation algorithm advertisement from the SR-= specific advertisement. In this way, the algorithm is just coupled with the= topology while the labels advertised through the prefix-sid sub-TLVs could= be used to determine to which topology the received SR-MPLS packet belongs= to. This behavior is much similar to the LDP and the LDP-MT. In other word= s, the SR-specific IGP extension just plays the role of label distribution = protocol which shouldn't have any impact on the path computation behavior.= =20 initially, we thought about making the algorithm a generic TLV but=20 later preferred to confine it to the SR context. If there's consensus, I don't mind to enlarge the scope but I'd prefer=20 not to re-invent MT. > 5. The lack of MT-ID field in the SID/Label Binding TLV >=20 > I had suggested to add an MT-ID field in the SID/Label Binding TLV and St= efano had agreed to that suggestion. But it seems that the MT-ID field has = not been added yet. I agree with you but since the binding TLV was not originally part of=20 the SR proposal (i.e.: it's the merge with Hannes draft) I'd let Hannes=20 to comment. > 6. Suggestion on SR-Capabilities Sub-TLV > The SR-Capabilities Sub-TLV is used to advertise: 1) data-plane capabilit= y; 2) range of SID/Label values. It seems better to advertise these two cap= abilities via two separate sub-TLVs, e.g., DP-Capability sub-TLV and SID/La= bel Range sub-TLV. In the way, the role of SID/Label Range sub-tlv is consi= stent with the counterpart in OSPF extensions (i.e., SID/Label Range TLV). = Anyway, it seems better to keep the ISIS and OSPF extensions for the same f= unction as consistent as possible.=20 I disagree. Keeping encoding aligned between isis and ospf is NOT a goal.=20 What is necessary is to keep consistency between functionalities. s. >=20 > Best regards, > Xiaohu >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From nobody Thu Jun 12 05:14:52 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0415B1B2876; Thu, 12 Jun 2014 05:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4fHsOXuO8Wz; Thu, 12 Jun 2014 05:14:44 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8941B2863; Thu, 12 Jun 2014 05:14:44 -0700 (PDT) Received: from CH1PRD0510HT002.namprd05.prod.outlook.com (10.255.150.37) by DM2PR05MB479.namprd05.prod.outlook.com (10.141.99.140) with Microsoft SMTP Server (TLS) id 15.0.949.11; Thu, 12 Jun 2014 12:14:42 +0000 Received: from [172.29.66.152] (193.110.55.19) by pod51010.outlook.com (10.255.150.37) with Microsoft SMTP Server (TLS) id 14.16.459.0; Thu, 12 Jun 2014 12:14:41 +0000 MIME-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset="us-ascii" From: Hannes Gredler In-Reply-To: <442F4557-73F8-46B3-8ED7-E3E4BECF3523@cisco.com> Date: Thu, 12 Jun 2014 14:14:34 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <349E5A21-A323-4D05-9ABB-CC6642E51E0D@juniper.net> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08280249@NKGEML512-MBS.china.huawei.com> <442F4557-73F8-46B3-8ED7-E3E4BECF3523@cisco.com> To: Xuxiaohu X-Mailer: Apple Mail (2.1283) X-Originating-IP: [193.110.55.19] X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 02408926C4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(24454002)(189002)(199002)(51704005)(377454003)(101416001)(74662001)(80022001)(74502001)(77096999)(89996001)(4396001)(66066001)(46102001)(31966008)(64706001)(83322001)(77156001)(97756001)(23726002)(76176999)(102836001)(50466002)(93916002)(99396002)(86362001)(561944003)(104166001)(50986999)(62966002)(92726001)(92566001)(88136002)(81542001)(82746002)(81342001)(87936001)(46406003)(57306001)(50226001)(83716003)(87286001)(36756003)(83072002)(21056001)(85852003)(79102001)(20776003)(33656002)(76482001)(77982001)(47776003)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB479; H:CH1PRD0510HT002.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=hannes@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/1Fg9nRN_9HnfP7heejrshKK3RQ4 Cc: OSPF List , "isis-wg@ietf.org list" Subject: Re: [OSPF] Comments on draft-ietf-isis-segment-routing-extensions-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 12 Jun 2014 12:14:46 -0000 On Jun 12, 2014, at 12:41 PM, Stefano Previdi (sprevidi) wrote: >> 5. The lack of MT-ID field in the SID/Label Binding TLV >>=20 >> I had suggested to add an MT-ID field in the SID/Label Binding TLV = and Stefano had agreed to that suggestion. But it seems that the MT-ID = field has not been added yet. >=20 >=20 > I agree with you but since the binding TLV was not originally part of=20= > the SR proposal (i.e.: it's the merge with Hannes draft) I'd let = Hannes=20 > to comment. no concerns from my side, we can add a MTID subTLV to specify what topology an advertised path does belong to. do you want to send text for the suggested change or shall i give a stab = at it ? /hannes= From nobody Thu Jun 12 19:05:49 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B581B2893; Thu, 12 Jun 2014 19:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_SIDE=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khrSJY0UpNEq; Thu, 12 Jun 2014 19:05:43 -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 6E9FE1B288D; Thu, 12 Jun 2014 19:05:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFJ09359; Fri, 13 Jun 2014 02:05:40 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Jun 2014 03:05:39 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 13 Jun 2014 10:05:33 +0800 From: Xuxiaohu To: "Stefano Previdi (sprevidi)" Thread-Topic: [OSPF] Comments on draft-ietf-isis-segment-routing-extensions-01 Thread-Index: Ac+GJni8pnqnrJn8Sty9J1EyPVqh3v//gr+A//6GH9A= Date: Fri, 13 Jun 2014 02:05:32 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828066E@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08280249@NKGEML512-MBS.china.huawei.com> <442F4557-73F8-46B3-8ED7-E3E4BECF3523@cisco.com> In-Reply-To: <442F4557-73F8-46B3-8ED7-E3E4BECF3523@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.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/UUWgtpwmcqR2ihPG2kHIyeM89ns Cc: OSPF List , "isis-wg@ietf.org" Subject: Re: [OSPF] Comments on draft-ietf-isis-segment-routing-extensions-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jun 2014 02:05:46 -0000 Hi Stefano, > -----Original Message----- > From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > Sent: Thursday, June 12, 2014 6:42 PM > To: Xuxiaohu > Cc: isis-wg@ietf.org; OSPF List > Subject: Re: [OSPF] Comments on draft-ietf-isis-segment-routing-extension= s-01 >=20 > Hi Xiaohu, >=20 >=20 > On Jun 12, 2014, at 12:10 PM, Xuxiaohu wrote: > > Hi all, > > > > The following are some comments on > draft-ietf-isis-segment-routing-extensions-01 (Note that the former four > comments are applicable to draft-psenak-ospf-segment-routing-extensions-0= 5 > as well.): > > > > 1. Terminology inconsistency issues > > > > The first example is about the semantics of the SID. According to the f= ollowing > description in section 2.1 "...SID/Index/Label: according to the V and L = flags, it > contains...", the SID would be something other than label and index. Howe= ver, > in the same section, it said "... Multiple Prefix-SIDs Sub-TLVs MAY appea= r on the > same prefix in which case each SID is encoded as a separate Sub-TLV....",= here > the SID seems to be a generic terminology, which could be index, label or= SID. > > > > The second example is about the length of the SID (here the SID is some= thing > other than index and label). In section 2.1, it said "...A variable lengt= h SID (e.g.: > an IPv6 address SID)...." However, in section 2.3, it said "... SID/Label= : if length is > set to 3 then the 20 rightmost bits represent a MPLS label. If length is= 4 then > the value represents a 32 bits SID..." >=20 >=20 > I'm not sure I understand where the inconsistency is. >=20 > Prefix-SID goes with prefixes. Adj-SID goes with adjacencies. >=20 > Both SubTLVs may be value or index and may have local or global scope. >=20 > This is the flexibility we want to have. If you want to take the "SID" as a generic term which would be interpreted = as an MPLS label in the MPLS-SR case and an IPv6 address in the IPv6-SR cas= e, you'd better not list it with index/label in parallel (e.g., a descripti= on in section 2.1 "...SID/Index/Label: according to the V and L flags, it c= ontains..." ) . Otherwise, it would be deemed as a particular format of the= segment identifier (e.g., a 32-bit SID which was specifically designed for= IPv6-SR previously, or a 128-bit SID which is currently designed for IPv6-= SR). That's my point. =20 > > 2. The uncertain usage of the 32-bit SID > > > > It said in draft-previdi-6man-segment-routing-header-01 that "In Segmen= t > Routing IPv6 the SID is an IPv6 address". Therefore, what's the usage of = the > 32-bit SID (see section 2.3, it said "... SID/Label: if length is set to = 3 then the 20 > rightmost bits represent a MPLS label. If length is 4 then the value rep= resents a > 32 bits SID)? >=20 >=20 > you're right. I'll fix the text. >=20 >=20 > > 3. The uncertain usage of the 16-octect SID in the Prefix-SID sub-TLV > > > > In IPv6-SR case, since the SID is an IPv6 address, what's the usage of = the > prefix-SID sub-TLV? It has been said in > draft-previdi-6man-segment-routing-header-00 that " When Segment Routing = is > applied to IPv6, segments are encoded as 128-bit IPv6 addresses. This im= plies > that, in the IPv6 instantiation of SR, the SID values are in fact the pre= fixes > advertised in the IPv6 control-plane. Hence there's no need to advertise= any > additional specific identifier (other than IPv6 prefix) for the purpose o= f SR. This > simplifies the introduction of IPv6 Segment Routing in existing protocols= (i.e.: > IS-IS, OSPF and BGP). " > > I noticed that the above statement has been disappeared in the -01 vers= ion. > Did that mean that the co-authors of that draft have changed their minds > significantly? >=20 >=20 > nope. The text you mentioned has been replaced by the following one: >=20 > "The Node-SID identifies a node. With SR-IPv6 the Node-SID is an IPv6 pr= efix If the node-sid is an IPv6 address for sure, you'd better not say " the Nod= e-SID is an IPv6 prefix ". Otherwise, it would cause an unnecessary confus= ion. > that the operator configured on the node and that is used as the node > identifier. Typically, in case of a router, this is the IPv6 address of = the node > loopback interface. Therefore, SR-IPv6 does not require any additional S= ID > advertisement for the Node Segment. The Node-SID is in fact the IPv6 add= ress > of the node." If so, does it mean that the prefix-sid sub-TLV would not be used in the IP= v6-SR case? Or do you still want to use it for some IPv6 prefixes with pref= ix-len being shorter than 128? > > 4. Suggestion on the algorithm field in the prefix-SID sub-TLV > > > > It seems that using various algorithms in the best path computation cou= ld also > be applicable to some cases other than SR. For instance, use different al= gorithms > for different topologies [rfc5120]. Therefore, it seems better to decoupl= e the > best path computation algorithm advertisement from the SR-specific > advertisement. In this way, the algorithm is just coupled with the topolo= gy while > the labels advertised through the prefix-sid sub-TLVs could be used to de= termine > to which topology the received SR-MPLS packet belongs to. This behavior i= s > much similar to the LDP and the LDP-MT. In other words, the SR-specific I= GP > extension just plays the role of label distribution protocol which should= n't have > any impact on the path computation behavior. >=20 >=20 > initially, we thought about making the algorithm a generic TLV but later > preferred to confine it to the SR context. >=20 > If there's consensus, I don't mind to enlarge the scope but I'd prefer no= t to > re-invent MT. A generic algorithm sub-TLV could be useful in some cases other than SR in = the future. Take the TE router-id sub-TLV of the CAPABILITY TLV as an examp= le, the routable address contained in such sub-TLV should have not been cou= pled with the TE purpose since it is now useful in some cases other than TE= (note that this was discussed a few weeks ago in the ISIS mailing-list). > > 5. The lack of MT-ID field in the SID/Label Binding TLV > > > > I had suggested to add an MT-ID field in the SID/Label Binding TLV and = Stefano > had agreed to that suggestion. But it seems that the MT-ID field has not = been > added yet. >=20 >=20 > I agree with you but since the binding TLV was not originally part of > the SR proposal (i.e.: it's the merge with Hannes draft) I'd let Hannes > to comment. >=20 >=20 > > 6. Suggestion on SR-Capabilities Sub-TLV > > The SR-Capabilities Sub-TLV is used to advertise: 1) data-plane capabil= ity; 2) > range of SID/Label values. It seems better to advertise these two capabil= ities via > two separate sub-TLVs, e.g., DP-Capability sub-TLV and SID/Label Range su= b-TLV. > In the way, the role of SID/Label Range sub-tlv is consistent with the co= unterpart > in OSPF extensions (i.e., SID/Label Range TLV). Anyway, it seems better t= o keep > the ISIS and OSPF extensions for the same function as consistent as possi= ble. >=20 >=20 > I disagree. Keeping encoding aligned between isis and ospf is NOT a goal. > What is necessary is to keep consistency between functionalities. I agree that the most important goal is to keep consistency between functio= nalities. However, wouldn't it be better if the consistency of encodings be= tween ISIS and OSPF can be kept as well without any additional cost? At lea= st, it becomes more easy for implementers and operators to read these two d= rafts if the consistency of encodings can be kept. Best regards, Xiaohu > s. >=20 >=20 > > > > Best regards, > > Xiaohu > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf From nobody Thu Jun 12 22:45:51 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012F51B28E2; Thu, 12 Jun 2014 22:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kT2KbE0XjZHH; Thu, 12 Jun 2014 22:45:48 -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 3BAEF1A036C; Thu, 12 Jun 2014 22:45:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIJ32323; Fri, 13 Jun 2014 05:45:45 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Jun 2014 06:45:44 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 13 Jun 2014 13:45:38 +0800 From: Xuxiaohu To: Hannes Gredler Thread-Topic: [OSPF] Comments on draft-ietf-isis-segment-routing-extensions-01 Thread-Index: Ac+GJni8pnqnrJn8Sty9J1EyPVqh3v//gr+AgAAZ8QD//lSTsA== Date: Fri, 13 Jun 2014 05:45:37 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082806E3@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08280249@NKGEML512-MBS.china.huawei.com> <442F4557-73F8-46B3-8ED7-E3E4BECF3523@cisco.com> <349E5A21-A323-4D05-9ABB-CC6642E51E0D@juniper.net> In-Reply-To: <349E5A21-A323-4D05-9ABB-CC6642E51E0D@juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/iQMS-xxoLVnq5dolMOGCDzZ_How Cc: OSPF List , "isis-wg@ietf.org list" Subject: Re: [OSPF] Comments on draft-ietf-isis-segment-routing-extensions-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jun 2014 05:45:50 -0000 Hi Hannes, > -----Original Message----- > From: Hannes Gredler [mailto:hannes@juniper.net] > Sent: Thursday, June 12, 2014 8:15 PM > To: Xuxiaohu > Cc: OSPF List; isis-wg@ietf.org list; Stefano Previdi (sprevidi) > Subject: Re: [OSPF] Comments on draft-ietf-isis-segment-routing-extension= s-01 >=20 >=20 > On Jun 12, 2014, at 12:41 PM, Stefano Previdi (sprevidi) wrote: > >> 5. The lack of MT-ID field in the SID/Label Binding TLV > >> > >> I had suggested to add an MT-ID field in the SID/Label Binding TLV and > Stefano had agreed to that suggestion. But it seems that the MT-ID field = has not > been added yet. > > > > > > I agree with you but since the binding TLV was not originally part of > > the SR proposal (i.e.: it's the merge with Hannes draft) I'd let > > Hannes to comment. >=20 >=20 > no concerns from my side, we can add a MTID subTLV to specify what topolo= gy > an advertised path does belong to. That would be great. Best regards, Xiaohu > do you want to send text for the suggested change or shall i give a stab = at it ? >=20 > /hannes From nobody Thu Jun 12 23:55:45 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6358D1B28DA; Thu, 12 Jun 2014 23:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.852 X-Spam-Level: X-Spam-Status: No, score=-12.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_SIDE=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmh_G7SJW-mJ; Thu, 12 Jun 2014 23:55:42 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176EF1B28D8; Thu, 12 Jun 2014 23:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8814; q=dns/txt; s=iport; t=1402642542; x=1403852142; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3+jdkfifidrsnPtJGkakQRd8sydvxKE1eeSKZo8uGyI=; b=ZTQotbkEXYLPYv7dL1wm7rUxL/z6nXXuwuWi6mwRxhKp3mi3b4/9sCeP fN62aaql7BZP56EprVsYtrMwSfeuYi4mbVHQNwB+l/Jh920FtjUeGMeY6 q+TH2IelmOq1lZNXfZceW5CIL7KF+Q6Zd2MqYZryjKs74FXbr+W0rGWza k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQGABCgmlOtJV2P/2dsb2JhbABagw1SWalWAQQBBQGRY4c8AYEFFnWEAwEBAQMBAQEBNzQGBQUHBAIBCBEEAQEBHgkHJwsUCQgBAQQOBYg6CA3RfhMEhVyDUoR7MwcGgyWBFgEDmjaTVIM8gi8 X-IronPort-AV: E=Sophos;i="5.01,470,1400025600"; d="scan'208";a="332629141" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-1.cisco.com with ESMTP; 13 Jun 2014 06:55:41 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s5D6teQq018241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Jun 2014 06:55:40 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.223]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Fri, 13 Jun 2014 01:55:40 -0500 From: "Stefano Previdi (sprevidi)" To: Xuxiaohu Thread-Topic: [Isis-wg] [OSPF] Comments on draft-ietf-isis-segment-routing-extensions-01 Thread-Index: Ac+GJni8pnqnrJn8Sty9J1EyPVqh3v//gr+A//6GH9CAA6b6gA== Date: Fri, 13 Jun 2014 06:55:39 +0000 Message-ID: <88398D6A-180C-417A-B719-295CDAA35850@cisco.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08280249@NKGEML512-MBS.china.huawei.com> <442F4557-73F8-46B3-8ED7-E3E4BECF3523@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828066E@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828066E@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.82.84] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/kJfJd-PlOIQDzY4AebAkC4ccfFI Cc: OSPF List , "isis-wg@ietf.org" Subject: Re: [OSPF] [Isis-wg] Comments on draft-ietf-isis-segment-routing-extensions-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jun 2014 06:55:44 -0000 On Jun 13, 2014, at 4:05 AM, Xuxiaohu wrote: > Hi Stefano, >> -----Original Message----- >> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >> Sent: Thursday, June 12, 2014 6:42 PM >> To: Xuxiaohu >> Cc: isis-wg@ietf.org; OSPF List >> Subject: Re: [OSPF] Comments on draft-ietf-isis-segment-routing-extensio= ns-01 >>=20 >> Hi Xiaohu, >>=20 >>=20 >> On Jun 12, 2014, at 12:10 PM, Xuxiaohu wrote: >>> Hi all, >>>=20 >>> The following are some comments on >> draft-ietf-isis-segment-routing-extensions-01 (Note that the former four >> comments are applicable to draft-psenak-ospf-segment-routing-extensions-= 05 >> as well.): >>>=20 >>> 1. Terminology inconsistency issues >>>=20 >>> The first example is about the semantics of the SID. According to the f= ollowing >> description in section 2.1 "...SID/Index/Label: according to the V and L= flags, it >> contains...", the SID would be something other than label and index. How= ever, >> in the same section, it said "... Multiple Prefix-SIDs Sub-TLVs MAY appe= ar on the >> same prefix in which case each SID is encoded as a separate Sub-TLV...."= , here >> the SID seems to be a generic terminology, which could be index, label o= r SID. >>>=20 >>> The second example is about the length of the SID (here the SID is some= thing >> other than index and label). In section 2.1, it said "...A variable leng= th SID (e.g.: >> an IPv6 address SID)...." However, in section 2.3, it said "... SID/Labe= l: if length is >> set to 3 then the 20 rightmost bits represent a MPLS label. If length i= s 4 then >> the value represents a 32 bits SID..." >>=20 >>=20 >> I'm not sure I understand where the inconsistency is. >>=20 >> Prefix-SID goes with prefixes. Adj-SID goes with adjacencies. >>=20 >> Both SubTLVs may be value or index and may have local or global scope. >>=20 >> This is the flexibility we want to have. >=20 > If you want to take the "SID" as a generic term which would be interprete= d as an MPLS label in the MPLS-SR case and an IPv6 address in the IPv6-SR c= ase, you'd better not list it with index/label in parallel (e.g., a descrip= tion in section 2.1 "...SID/Index/Label: according to the V and L flags, it= contains..." ) . Otherwise, it would be deemed as a particular format of t= he segment identifier (e.g., a 32-bit SID which was specifically designed f= or IPv6-SR previously, or a 128-bit SID which is currently designed for IPv= 6-SR). That's my point. >=20 >=20 >>> 2. The uncertain usage of the 32-bit SID >>>=20 >>> It said in draft-previdi-6man-segment-routing-header-01 that "In Segmen= t >> Routing IPv6 the SID is an IPv6 address". Therefore, what's the usage of= the >> 32-bit SID (see section 2.3, it said "... SID/Label: if length is set to= 3 then the 20 >> rightmost bits represent a MPLS label. If length is 4 then the value re= presents a >> 32 bits SID)? >>=20 >>=20 >> you're right. I'll fix the text. >>=20 >>=20 >>> 3. The uncertain usage of the 16-octect SID in the Prefix-SID sub-TLV >>>=20 >>> In IPv6-SR case, since the SID is an IPv6 address, what's the usage of = the >> prefix-SID sub-TLV? It has been said in >> draft-previdi-6man-segment-routing-header-00 that " When Segment Routing= is >> applied to IPv6, segments are encoded as 128-bit IPv6 addresses. This i= mplies >> that, in the IPv6 instantiation of SR, the SID values are in fact the pr= efixes >> advertised in the IPv6 control-plane. Hence there's no need to advertis= e any >> additional specific identifier (other than IPv6 prefix) for the purpose = of SR. This >> simplifies the introduction of IPv6 Segment Routing in existing protocol= s (i.e.: >> IS-IS, OSPF and BGP). " >>> I noticed that the above statement has been disappeared in the -01 vers= ion. >> Did that mean that the co-authors of that draft have changed their minds >> significantly? >>=20 >>=20 >> nope. The text you mentioned has been replaced by the following one: >>=20 >> "The Node-SID identifies a node. With SR-IPv6 the Node-SID is an IPv6 p= refix >=20 > If the node-sid is an IPv6 address for sure, you'd better not say " the N= ode-SID is an IPv6 prefix ". Otherwise, it would cause an unnecessary conf= usion. ok, sorry. I intended a /128 prefix but you're right and I'll fix that. >> that the operator configured on the node and that is used as the node >> identifier. Typically, in case of a router, this is the IPv6 address of= the node >> loopback interface. Therefore, SR-IPv6 does not require any additional = SID >> advertisement for the Node Segment. The Node-SID is in fact the IPv6 ad= dress >> of the node." >=20 > If so, does it mean that the prefix-sid sub-TLV would not be used in the = IPv6-SR case? not at this stage. In the future we may come back and revisit the idea of using 32bit=20 SIDs for ipv6 as well. > Or do you still want to use it for some IPv6 prefixes with prefix-len bei= ng shorter than 128? >=20 >>> 4. Suggestion on the algorithm field in the prefix-SID sub-TLV >>>=20 >>> It seems that using various algorithms in the best path computation cou= ld also >> be applicable to some cases other than SR. For instance, use different a= lgorithms >> for different topologies [rfc5120]. Therefore, it seems better to decoup= le the >> best path computation algorithm advertisement from the SR-specific >> advertisement. In this way, the algorithm is just coupled with the topol= ogy while >> the labels advertised through the prefix-sid sub-TLVs could be used to d= etermine >> to which topology the received SR-MPLS packet belongs to. This behavior = is >> much similar to the LDP and the LDP-MT. In other words, the SR-specific = IGP >> extension just plays the role of label distribution protocol which shoul= dn't have >> any impact on the path computation behavior. >>=20 >>=20 >> initially, we thought about making the algorithm a generic TLV but later >> preferred to confine it to the SR context. >>=20 >> If there's consensus, I don't mind to enlarge the scope but I'd prefer n= ot to >> re-invent MT. >=20 > A generic algorithm sub-TLV could be useful in some cases other than SR i= n the future. Take the TE router-id sub-TLV of the CAPABILITY TLV as an exa= mple, the routable address contained in such sub-TLV should have not been c= oupled with the TE purpose since it is now useful in some cases other than = TE (note that this was discussed a few weeks ago in the ISIS mailing-list). >=20 >>> 5. The lack of MT-ID field in the SID/Label Binding TLV >>>=20 >>> I had suggested to add an MT-ID field in the SID/Label Binding TLV and = Stefano >> had agreed to that suggestion. But it seems that the MT-ID field has not= been >> added yet. >>=20 >>=20 >> I agree with you but since the binding TLV was not originally part of >> the SR proposal (i.e.: it's the merge with Hannes draft) I'd let Hannes >> to comment. >>=20 >>=20 >>> 6. Suggestion on SR-Capabilities Sub-TLV >>> The SR-Capabilities Sub-TLV is used to advertise: 1) data-plane capabil= ity; 2) >> range of SID/Label values. It seems better to advertise these two capabi= lities via >> two separate sub-TLVs, e.g., DP-Capability sub-TLV and SID/Label Range s= ub-TLV. >> In the way, the role of SID/Label Range sub-tlv is consistent with the c= ounterpart >> in OSPF extensions (i.e., SID/Label Range TLV). Anyway, it seems better = to keep >> the ISIS and OSPF extensions for the same function as consistent as poss= ible. >>=20 >>=20 >> I disagree. Keeping encoding aligned between isis and ospf is NOT a goal= . >> What is necessary is to keep consistency between functionalities. >=20 > I agree that the most important goal is to keep consistency between funct= ionalities. However, wouldn't it be better if the consistency of encodings = between ISIS and OSPF can be kept as well without any additional cost? I disagree. Protocols are not the same and in the encodings one protocol may=20 require additional info while the other already has it so let's=20 not try to do something that: 1. is not needed 2. will require substantial effort Thanks. s. > At least, it becomes more easy for implementers and operators to read the= se two drafts if the consistency of encodings can be kept. > =1D > Best regards, > Xiaohu >=20 >> s. >>=20 >>=20 >>>=20 >>> Best regards, >>> Xiaohu >>>=20 >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Fri Jun 13 00:51:59 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F26B1A01CE; Fri, 13 Jun 2014 00:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAWPmaKRpWam; Fri, 13 Jun 2014 00:51:53 -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 F40A01A016C; Fri, 13 Jun 2014 00:51:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFJ30623; Fri, 13 Jun 2014 07:51:51 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Jun 2014 08:51:50 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 13 Jun 2014 15:51:44 +0800 From: Xuxiaohu To: "isis-wg@ietf.org list" , OSPF List Thread-Topic: Encoding inconsistency between ISIS and OSPFv2 extensions for SR Thread-Index: Ac+G3FEp8zYfOWcFTgiN+WbMbdhxlA== Date: Fri, 13 Jun 2014 07:51:44 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828073D@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/tbHAkhmHMBcxSGaqOOQDpoes_m8 Subject: [OSPF] Encoding inconsistency between ISIS and OSPFv2 extensions for SR X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jun 2014 07:51:56 -0000 Hi all, There are some encoding inconsistencies between OSPFv2 extensions and ISIS = extensions for SR as follows: 1. In ISIS-SR, the prefix-sid advertisement is piggybacked on the IP reacha= bility advertisement. In OSPF-SR, the prefix-sid advertisement is piggyback= ed on OSPF Extended Prefix LSA which is used to advertise other attributes = associated with the prefix, rather than the reachability. IMHO, the OSPF en= coding is more flexible since the label distribution and the reachability a= dvertisement are independent. As a result, the route summary on area bounda= ries at least can be enabled as before. Besides, the prefix-SID sub-TLV can= be used to advertise a range of prefix/SID pairs (see item2). In fact, ISI= S allows us to do the same way as OSPF with a much lower cost (see section = 3 of http://tools.ietf.org/html/draft-xu-isis-global-label-sid-adv-00). Of = course, it seems that you co-authors prefer to the piggyback way.=20 2. In ISIS-SR, the Prefix-SID Sub-TLV can only be used to advertise an SID = for a single prefix. And it relays on the SID/Label Binding TLV to advertis= e a range of prefix/SID pairs. In contrast, In OSPF-SR, the prefix-sid sub-= TLV can be used to specify a range of addresses and their associated Prefix= SIDs. By the way, in the 4.3. SID/Label Binding sub-TLV. it has the follo= wing text: "Range Size: usage is the same as described in Section 4.2." Did= you co-authors want to propose two ways (i.e., prefix-sid sub-TLV and SID-= Label Binding sub-TLV) to achieve the same goal (i..e, advertise a range of= prefix/SID pairs)? 3. In ISIS-SR, the range of SID/Label values is advertised by the SR Capabi= lity sub-TLV. Meanwhile, the data-plane capability is advertised by such su= b-TLV as well. In OSPF-SR, the range of SID/Label values is advertised by t= he label/sid range sub-TLV. I wonder what the special purpose of the data-p= lane capability advertisement is in the ISIS-SR case.=20 4. In ISIS-SR, the Prefix-SID Sub-TLV can be sub-TLV of the SID/Label Bindi= ng-TLV and its' the the prefix-sid sub-TLV which is used to associate prefi= x-sids with the range of prefixes advertised by the SID/Label Binding TLV. = In OSPF-SR, the prefix-sid sub-TLV and the SID/label binding sub-TLV are no= w at the same level of the sub-TLV hierarchy(i.e., both of them are sub-TLV= s of the OSPF Extended Prefix TLV ). As a result. it's the SID/Label sub-TL= V, rather than the prefix-sid sub-TLV which is used to associate prefix-sid= s with the range of prefixes. 5. In ISIS-SR, "The SID/Label Sub-TLV (Type: TBD, suggested value 1) contai= ns the SID/Label value as defined in Section 2.3. It MAY be present in the= SID/Label Binding TLV" . However, in OSPF-SR, "SID/Label sub-TLV as descri= bed in Section 2.1. This sub-TLV MUST appear in the SID/Label Binding Sub-= TLV". In other words, the sid/label sub-TLV is optional to the SID/Label bi= nding sub-TLV in the ISIS-SR case while the sid/label sub-TLV is mandatory = to the SID/label binding TLV in the OSPF-SR case. 6. In ISIS-SR, the prefix-SID sub-TLV doesn't contain the MT-ID field since= the MT-ID field is already contained in the parent TLV of the prefix-SID s= ub-TLV. In OSPF, the MT-ID field is contained in the Prefix SID Sub-TLV sin= ce the parent TLV of the prefix-sid sub-TLV doesn't contain that MT-ID fiel= d. IMHO, it's better to contain the MT-ID in the parent prefix-specific TLV= of the prefix-SID sub-TLV. In other words, why not contain the MT-ID in th= e OSPF Extended Prefix TLV, instead of the prefix-sid sub-TLV (see section = 3 of http://tools.ietf.org/html/draft-xu-ospf-global-label-sid-adv-00)? Anyway, although it is unavoidable for us to define extensions to both ISIS= and OSPF for the same thing due to the fact that both protocols have been = widely used, could we try our best to keep the encodings of ISIS and OSPF a= s consistent as possible for the same functionality? In this way, once some= one has read the ISIS extension draft, he or she can easily think of what h= as been done in the OSPF extension draft accordingly, and vice verse. Best regards, Xiaohu From nobody Fri Jun 13 01:11:01 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8731A01F9; Fri, 13 Jun 2014 01:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tMQkrn3h5nn; Fri, 13 Jun 2014 01:10:56 -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 0CEC71A01CE; Fri, 13 Jun 2014 01:10:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFJ32535; Fri, 13 Jun 2014 08:10:54 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Jun 2014 09:10:53 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Fri, 13 Jun 2014 16:10:45 +0800 From: Xuxiaohu To: Xuxiaohu , "isis-wg@ietf.org list" , OSPF List Thread-Topic: Encoding inconsistency between ISIS and OSPFv2 extensions for SR Thread-Index: Ac+G3FEp8zYfOWcFTgiN+WbMbdhxlAAAbf0Q Date: Fri, 13 Jun 2014 08:10:45 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08280765@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/vMo4SdQmRfTmOBxYtJqp1rwmYeY Subject: Re: [OSPF] Encoding inconsistency between ISIS and OSPFv2 extensions for SR X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jun 2014 08:10:59 -0000 > -----Original Message----- > From: Xuxiaohu > Sent: Friday, June 13, 2014 3:52 PM > To: isis-wg@ietf.org list; OSPF List > Subject: Encoding inconsistency between ISIS and OSPFv2 extensions for SR >=20 > Hi all, >=20 > There are some encoding inconsistencies between OSPFv2 extensions and ISI= S > extensions for SR as follows: >=20 > 1. In ISIS-SR, the prefix-sid advertisement is piggybacked on the IP reac= hability > advertisement. In OSPF-SR, the prefix-sid advertisement is piggybacked on= OSPF s/ piggybacked on OSPF/ carried in OSPF > Extended Prefix LSA which is used to advertise other attributes associate= d with > the prefix, rather than the reachability. IMHO, the OSPF encoding is more > flexible since the label distribution and the reachability advertisement = are > independent. As a result, the route summary on area boundaries at least c= an be > enabled as before. Besides, the prefix-SID sub-TLV can be used to adverti= se a > range of prefix/SID pairs (see item2). In fact, ISIS allows us to do the = same way > as OSPF with a much lower cost (see section 3 of > http://tools.ietf.org/html/draft-xu-isis-global-label-sid-adv-00). Of cou= rse, it > seems that you co-authors prefer to the piggyback way. The piggyback way here just means the current way used by the ISIS-SR. Best regards, Xiaohu > 2. In ISIS-SR, the Prefix-SID Sub-TLV can only be used to advertise an SI= D for a > single prefix. And it relays on the SID/Label Binding TLV to advertise a = range of > prefix/SID pairs. In contrast, In OSPF-SR, the prefix-sid sub-TLV can be = used to > specify a range of addresses and their associated Prefix SIDs. By the way= , in the > 4.3. SID/Label Binding sub-TLV. it has the following text: "Range Size: = usage is > the same as described in Section 4.2." Did you co-authors want to propose= two > ways (i.e., prefix-sid sub-TLV and SID-Label Binding sub-TLV) to achieve = the same > goal (i..e, advertise a range of prefix/SID pairs)? > 3. In ISIS-SR, the range of SID/Label values is advertised by the SR Capa= bility > sub-TLV. Meanwhile, the data-plane capability is advertised by such sub-T= LV as > well. In OSPF-SR, the range of SID/Label values is advertised by the labe= l/sid > range sub-TLV. I wonder what the special purpose of the data-plane capabi= lity > advertisement is in the ISIS-SR case. >=20 > 4. In ISIS-SR, the Prefix-SID Sub-TLV can be sub-TLV of the SID/Label Bin= ding-TLV > and its' the the prefix-sid sub-TLV which is used to associate prefix-sid= s with the > range of prefixes advertised by the SID/Label Binding TLV. In OSPF-SR, th= e > prefix-sid sub-TLV and the SID/label binding sub-TLV are now at the same = level of > the sub-TLV hierarchy(i.e., both of them are sub-TLVs of the OSPF Extende= d > Prefix TLV ). As a result. it's the SID/Label sub-TLV, rather than the pr= efix-sid > sub-TLV which is used to associate prefix-sids with the range of prefixes= . > 5. In ISIS-SR, "The SID/Label Sub-TLV (Type: TBD, suggested value 1) cont= ains the > SID/Label value as defined in Section 2.3. It MAY be present in the SID/= Label > Binding TLV" . However, in OSPF-SR, "SID/Label sub-TLV as described in Se= ction > 2.1. This sub-TLV MUST appear in the SID/Label Binding Sub-TLV". In othe= r > words, the sid/label sub-TLV is optional to the SID/Label binding sub-TLV= in the > ISIS-SR case while the sid/label sub-TLV is mandatory to the SID/label bi= nding > TLV in the OSPF-SR case. >=20 > 6. In ISIS-SR, the prefix-SID sub-TLV doesn't contain the MT-ID field sin= ce the > MT-ID field is already contained in the parent TLV of the prefix-SID sub-= TLV. In > OSPF, the MT-ID field is contained in the Prefix SID Sub-TLV since the pa= rent TLV > of the prefix-sid sub-TLV doesn't contain that MT-ID field. IMHO, it's be= tter to > contain the MT-ID in the parent prefix-specific TLV of the prefix-SID sub= -TLV. In > other words, why not contain the MT-ID in the OSPF Extended Prefix TLV, > instead of the prefix-sid sub-TLV (see section 3 of > http://tools.ietf.org/html/draft-xu-ospf-global-label-sid-adv-00)? >=20 > Anyway, although it is unavoidable for us to define extensions to both IS= IS and > OSPF for the same thing due to the fact that both protocols have been wid= ely > used, could we try our best to keep the encodings of ISIS and OSPF as con= sistent > as possible for the same functionality? In this way, once someone has rea= d the > ISIS extension draft, he or she can easily think of what has been done in= the > OSPF extension draft accordingly, and vice verse. >=20 > Best regards, > Xiaohu From nobody Fri Jun 13 01:31:44 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A32A1A0312; Fri, 13 Jun 2014 01:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91PfOaVfmNvL; Fri, 13 Jun 2014 01:31:40 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28871A021E; Fri, 13 Jun 2014 01:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3804; q=dns/txt; s=iport; t=1402648300; x=1403857900; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=1g4YqG6oqmuQc4K3tjw/8q0WrQZ4dyN52YJYE3B/oaw=; b=m1KutfkD33yG6fp7yvgudpsLWe7yCyRwdKkiczgS5OUbBHpGj5qYgzGs GaJN0v6J0DLDDvRJ1/LjpWxDaR0nWyZSEK/DnvMOzIVfYzSwfpo/58sof uK1On4UM4wqbF0h8sfbjArSJJ5XrME+fSLnDQEf6pqMGrk3SOXIXdi6SU M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0FAB22mlOtJssW/2dsb2JhbABag1+qMQEEAQUBkWOHPAGBG3WEAwEBAQMBAQEBNTYKBgsLGAkWDwkDAgECARUwBgEMBgIBAYg2CA3RfheFXINShTWEQQEDmjaBQ4U3jFqDPjs X-IronPort-AV: E=Sophos;i="5.01,470,1400025600"; d="scan'208";a="79960486" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 13 Jun 2014 08:31:38 +0000 Received: from [10.55.51.202] (ams-ppsenak-8719.cisco.com [10.55.51.202]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s5D8Vb3w015408; Fri, 13 Jun 2014 08:31:37 GMT Message-ID: <539AB6E9.3070108@cisco.com> Date: Fri, 13 Jun 2014 10:31:37 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Xuxiaohu , "isis-wg@ietf.org list" , OSPF List References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828073D@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828073D@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/LpXXgV3InonYQjywsv7OOzrsZxM Subject: Re: [OSPF] [Isis-wg] Encoding inconsistency between ISIS and OSPFv2 extensions for SR X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jun 2014 08:31:42 -0000 Xiaohu, please see inline: On 6/13/14 09:51 , Xuxiaohu wrote: > Hi all, > > There are some encoding inconsistencies between OSPFv2 extensions and ISIS extensions for SR as follows: > > 1. In ISIS-SR, the prefix-sid advertisement is piggybacked on the IP reachability advertisement. In OSPF-SR, the prefix-sid advertisement is piggybacked on OSPF Extended Prefix LSA which is used to advertise other attributes associated with the prefix, rather than the reachability. IMHO, the OSPF encoding is more flexible since the label distribution and the reachability advertisement are independent. As a result, the route summary on area boundaries at least can be enabled as before. Besides, the prefix-SID sub-TLV can be used to advertise a range of prefix/SID pairs (see item2). In fact, ISIS allows us to do the same way as OSPF with a much lower cost (see section 3 of http://tools.ietf.org/html/draft-xu-isis-global-label-sid-adv-00). Of course, it seems that you co-authors prefer to the piggyback way. OSPF LSAs that are used to advertise the prefixex are not extensible, so we had to define a new LSA for the purpose of advertising a prefix related attributes. ISIS is different, as they can add sub-TLVs to existing TLVs. > > 2. In ISIS-SR, the Prefix-SID Sub-TLV can only be used to advertise an SID for a single prefix. And it relays on the SID/Label Binding TLV to advertise a range of prefix/SID pairs. In contrast, In OSPF-SR, the prefix-sid sub-TLV can be used to specify a range of addresses and their associated Prefix SIDs. By the way, in the 4.3. SID/Label Binding sub-TLV. it has the following text: "Range Size: usage is the same as described in Section 4.2." Did you co-authors want to propose two ways (i.e., prefix-sid sub-TLV and SID-Label Binding sub-TLV) to achieve the same goal (i..e, advertise a range of prefix/SID pairs)? because in OSPF advertisement of the prefix SID is decoupled from the advertisement of prefix reachability, we can afford to advertise the range of SIDs in the prefix-SID sub-TLV as such. No, we do not define two ways to achieve the same thing. Binding TLV is used for a different purpose and the same usage is only applicable to the Range semantics, not to the whole Binding TLV. > 6. In ISIS-SR, the prefix-SID sub-TLV doesn't contain the MT-ID field since the MT-ID field is already contained in the parent TLV of the prefix-SID sub-TLV. In OSPF, the MT-ID field is contained in the Prefix SID Sub-TLV since the parent TLV of the prefix-sid sub-TLV doesn't contain that MT-ID field. IMHO, it's better to contain the MT-ID in the parent prefix-specific TLV of the prefix-SID sub-TLV. In other words, why not contain the MT-ID in the OSPF Extended Prefix TLV, instead of the prefix-sid sub-TLV (see section 3 of http://tools.ietf.org/html/draft-xu-ospf-global-label-sid-adv-00)? no, we do not want to put the MT-ID in the OSPF Extended Prefix TLV. The reason is that attributes are MT specific, not the prefix itself - e.g. you may want to advertise different metrics for the same prefix in different topologies, not the same prefix twice. regards, Peter > > Anyway, although it is unavoidable for us to define extensions to both ISIS and OSPF for the same thing due to the fact that both protocols have been widely used, could we try our best to keep the encodings of ISIS and OSPF as consistent as possible for the same functionality? In this way, once someone has read the ISIS extension draft, he or she can easily think of what has been done in the OSPF extension draft accordingly, and vice verse. > > Best regards, > Xiaohu > > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg > . > From nobody Fri Jun 13 03:12:17 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520BE1A0460; Fri, 13 Jun 2014 03:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YXC6dy3k_k7; Fri, 13 Jun 2014 03:12:13 -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 416661B28DA; Fri, 13 Jun 2014 03:12:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFJ44441; Fri, 13 Jun 2014 10:12:10 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Jun 2014 11:10:00 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Fri, 13 Jun 2014 18:09:53 +0800 From: Xuxiaohu To: Peter Psenak , "isis-wg@ietf.org list" , OSPF List Thread-Topic: [Isis-wg] Encoding inconsistency between ISIS and OSPFv2 extensions for SR Thread-Index: Ac+G3FEp8zYfOWcFTgiN+WbMbdhxlP//hQmA//91kcA= Date: Fri, 13 Jun 2014 10:09:53 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082807D1@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828073D@NKGEML512-MBS.china.huawei.com> <539AB6E9.3070108@cisco.com> In-Reply-To: <539AB6E9.3070108@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.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/u6EPy6e2PdQsoeeDpaIeU5I8PXs Subject: Re: [OSPF] [Isis-wg] Encoding inconsistency between ISIS and OSPFv2 extensions for SR X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jun 2014 10:12:15 -0000 Hi peter, > -----Original Message----- > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Peter Psenak > Sent: Friday, June 13, 2014 4:32 PM > To: Xuxiaohu; isis-wg@ietf.org list; OSPF List > Subject: Re: [Isis-wg] Encoding inconsistency between ISIS and OSPFv2 > extensions for SR >=20 > Xiaohu, >=20 > please see inline: >=20 > On 6/13/14 09:51 , Xuxiaohu wrote: > > Hi all, > > > > There are some encoding inconsistencies between OSPFv2 extensions and I= SIS > extensions for SR as follows: > > > > 1. In ISIS-SR, the prefix-sid advertisement is piggybacked on the IP re= achability > advertisement. In OSPF-SR, the prefix-sid advertisement is piggybacked on= OSPF > Extended Prefix LSA which is used to advertise other attributes associate= d with > the prefix, rather than the reachability. IMHO, the OSPF encoding is more > flexible since the label distribution and the reachability advertisement = are > independent. As a result, the route summary on area boundaries at least c= an be > enabled as before. Besides, the prefix-SID sub-TLV can be used to adverti= se a > range of prefix/SID pairs (see item2). In fact, ISIS allows us to do the = same way > as OSPF with a much lower cost (see section 3 of > http://tools.ietf.org/html/draft-xu-isis-global-label-sid-adv-00). Of cou= rse, it > seems that you co-authors prefer to the piggyback way. >=20 > OSPF LSAs that are used to advertise the prefixex are not extensible, so = we had > to define a new LSA for the purpose of advertising a prefix related attri= butes. > ISIS is different, as they can add sub-TLVs to existing TLVs. I see. For ISIS, you use the piggyback way (piggyback the label/sid adverti= sement on the reachability advertisement messages). For OSPFv2, you have no= way to use the piggyback way anymore, so you defined a new LSA... That's w= hy I said you prefer to the piggyback way. However, I don't think the piggy= back way is much worthwhile from the perspective of flexibility and extensi= bility.=20 > > > > 2. In ISIS-SR, the Prefix-SID Sub-TLV can only be used to advertise an = SID for a > single prefix. And it relays on the SID/Label Binding TLV to advertise a = range of > prefix/SID pairs. In contrast, In OSPF-SR, the prefix-sid sub-TLV can be = used to > specify a range of addresses and their associated Prefix SIDs. By the way= , in the > 4.3. SID/Label Binding sub-TLV. it has the following text: "Range Size: = usage is > the same as described in Section 4.2." Did you co-authors want to propose= two > ways (i.e., prefix-sid sub-TLV and SID-Label Binding sub-TLV) to achieve = the same > goal (i..e, advertise a range of prefix/SID pairs)? >=20 > because in OSPF advertisement of the prefix SID is decoupled from the > advertisement of prefix reachability, we can afford to advertise the rang= e of SIDs > in the prefix-SID sub-TLV as such. IMHO, the ISIS and OSPFv3 advertisement of the prefix SIDs should be decoup= led from the prefix reachability advertisement as well:) =20 > No, we do not define two ways to achieve the same thing. Binding TLV is u= sed > for a different purpose and the same usage is only applicable to the Rang= e > semantics, not to the whole Binding TLV. Does that mean the Binding sub-TLV in the OSPF-SR could not be used to adve= rtise a range of prefix/sid pairs while the binding sub-TLV in the ISIS-SR = could? > > 6. In ISIS-SR, the prefix-SID sub-TLV doesn't contain the MT-ID field s= ince the > MT-ID field is already contained in the parent TLV of the prefix-SID sub-= TLV. In > OSPF, the MT-ID field is contained in the Prefix SID Sub-TLV since the pa= rent TLV > of the prefix-sid sub-TLV doesn't contain that MT-ID field. IMHO, it's be= tter to > contain the MT-ID in the parent prefix-specific TLV of the prefix-SID sub= -TLV. In > other words, why not contain the MT-ID in the OSPF Extended Prefix TLV, > instead of the prefix-sid sub-TLV (see section 3 of > http://tools.ietf.org/html/draft-xu-ospf-global-label-sid-adv-00)? >=20 > no, we do not want to put the MT-ID in the OSPF Extended Prefix TLV. The > reason is that attributes are MT specific, not the prefix itself - e.g. > you may want to advertise different metrics for the same prefix in differ= ent > topologies, not the same prefix twice. Make the prefix-sid as a sub-TLV of the Multi-Topology sub-TLV? Best regards, Xiaohu > regards, > Peter >=20 >=20 >=20 >=20 >=20 > > > > Anyway, although it is unavoidable for us to define extensions to both = ISIS and > OSPF for the same thing due to the fact that both protocols have been wid= ely > used, could we try our best to keep the encodings of ISIS and OSPF as con= sistent > as possible for the same functionality? In this way, once someone has rea= d the > ISIS extension draft, he or she can easily think of what has been done in= the > OSPF extension draft accordingly, and vice verse. > > > > Best regards, > > Xiaohu > > > > _______________________________________________ > > Isis-wg mailing list > > Isis-wg@ietf.org > > https://www.ietf.org/mailman/listinfo/isis-wg > > . > > >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Fri Jun 13 05:30:36 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B9E1B2842; Fri, 13 Jun 2014 05:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r74ZI5WGV7Ct; Fri, 13 Jun 2014 05:30:33 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92D471A04CA; Fri, 13 Jun 2014 05:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6134; q=dns/txt; s=iport; t=1402662632; x=1403872232; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=1xfvXh0ZtFyUkYkoWL47BYzjDZRxxezDDUi8cemZQBY=; b=Ftnb8Yz17vn5U6d6CwwB7lagwKVISiZ8LP9w5HQNg2nMKWWS7EC5UQY9 yDEU4QlDFX2bvB0gkEu/9UNyv2BtrYnYsN8PdJvTbEkNCxlehHZCNJ0uo ZFohMfxoE3pfgX7PFMiVBf5DIbPtNm4v7nRABSLL+R4NHMHx0GujnnjO/ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4FAJ7tmlOtJssW/2dsb2JhbABag1+qMwEEAQUBkWOHPAGBGXWEAwEBAQMBAQEBNTYKDQQLEQQBAQEJFggHCQMCAQIBFR8JCAYBDAYCAQGINggN0g0XhVyDUoU1BoQ7AQOaNoFDhTeMWoM+Ow X-IronPort-AV: E=Sophos;i="5.01,471,1400025600"; d="scan'208";a="84893014" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 13 Jun 2014 12:30:30 +0000 Received: from [10.148.128.133] ([10.148.128.133]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s5DCUUqw019944; Fri, 13 Jun 2014 12:30:30 GMT Message-ID: <539AEEE6.3080605@cisco.com> Date: Fri, 13 Jun 2014 14:30:30 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Xuxiaohu , "isis-wg@ietf.org list" , OSPF List References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828073D@NKGEML512-MBS.china.huawei.com> <539AB6E9.3070108@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082807D1@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082807D1@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/tQ87JB2NueF0sLM8PdpslGSRF1Q Subject: Re: [OSPF] [Isis-wg] Encoding inconsistency between ISIS and OSPFv2 extensions for SR X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jun 2014 12:30:35 -0000 Hi Xiaohu, please see inline: On 6/13/14 12:09 , Xuxiaohu wrote: > Hi peter, > >> -----Original Message----- >> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Peter Psenak >> Sent: Friday, June 13, 2014 4:32 PM >> To: Xuxiaohu; isis-wg@ietf.org list; OSPF List >> Subject: Re: [Isis-wg] Encoding inconsistency between ISIS and OSPFv2 >> extensions for SR >> >> Xiaohu, >> >> please see inline: >> >> On 6/13/14 09:51 , Xuxiaohu wrote: >>> Hi all, >>> >>> There are some encoding inconsistencies between OSPFv2 extensions and ISIS >> extensions for SR as follows: >>> >>> 1. In ISIS-SR, the prefix-sid advertisement is piggybacked on the IP reachability >> advertisement. In OSPF-SR, the prefix-sid advertisement is piggybacked on OSPF >> Extended Prefix LSA which is used to advertise other attributes associated with >> the prefix, rather than the reachability. IMHO, the OSPF encoding is more >> flexible since the label distribution and the reachability advertisement are >> independent. As a result, the route summary on area boundaries at least can be >> enabled as before. Besides, the prefix-SID sub-TLV can be used to advertise a >> range of prefix/SID pairs (see item2). In fact, ISIS allows us to do the same way >> as OSPF with a much lower cost (see section 3 of >> http://tools.ietf.org/html/draft-xu-isis-global-label-sid-adv-00). Of course, it >> seems that you co-authors prefer to the piggyback way. >> >> OSPF LSAs that are used to advertise the prefixex are not extensible, so we had >> to define a new LSA for the purpose of advertising a prefix related attributes. >> ISIS is different, as they can add sub-TLVs to existing TLVs. > > I see. For ISIS, you use the piggyback way (piggyback the label/sid advertisement on the reachability advertisement messages). For OSPFv2, you have no way to use the piggyback way anymore, so you defined a new LSA... That's why I said you prefer to the piggyback way. However, I don't think the piggyback way is much worthwhile from the perspective of flexibility and extensibility. > >>> >>> 2. In ISIS-SR, the Prefix-SID Sub-TLV can only be used to advertise an SID for a >> single prefix. And it relays on the SID/Label Binding TLV to advertise a range of >> prefix/SID pairs. In contrast, In OSPF-SR, the prefix-sid sub-TLV can be used to >> specify a range of addresses and their associated Prefix SIDs. By the way, in the >> 4.3. SID/Label Binding sub-TLV. it has the following text: "Range Size: usage is >> the same as described in Section 4.2." Did you co-authors want to propose two >> ways (i.e., prefix-sid sub-TLV and SID-Label Binding sub-TLV) to achieve the same >> goal (i..e, advertise a range of prefix/SID pairs)? >> >> because in OSPF advertisement of the prefix SID is decoupled from the >> advertisement of prefix reachability, we can afford to advertise the range of SIDs >> in the prefix-SID sub-TLV as such. > > IMHO, the ISIS and OSPFv3 advertisement of the prefix SIDs should be decoupled from the prefix reachability advertisement as well:) in OSPFv3 case, we have a way to advertise the prefix using the proposed encoding in draft-acee-ospfv3-lsa-extend, but do not advertise the reachability of the prefix - it's call NU-bit (rfc5340, A.4.1.1.) > >> No, we do not define two ways to achieve the same thing. Binding TLV is used >> for a different purpose and the same usage is only applicable to the Range >> semantics, not to the whole Binding TLV. > > Does that mean the Binding sub-TLV in the OSPF-SR could not be used to advertise a range of prefix/sid pairs while the binding sub-TLV in the ISIS-SR could? Binding TLV in OSPF is only used to advertise a "LSP path" local to the advertising router, it's not used for anything else. YOu can still advertise a single "LSP path" for range of prefixes. In ISIS, due to the need to decouple prefix reachability from SID advertisement, Binding TLV is used for SR Mapping Server (SRMS) adevrtisement on top of what it is used in OSPF (in OSPF SRMS advertisements are using the Prefix/SID sub-TLV). > >>> 6. In ISIS-SR, the prefix-SID sub-TLV doesn't contain the MT-ID field since the >> MT-ID field is already contained in the parent TLV of the prefix-SID sub-TLV. In >> OSPF, the MT-ID field is contained in the Prefix SID Sub-TLV since the parent TLV >> of the prefix-sid sub-TLV doesn't contain that MT-ID field. IMHO, it's better to >> contain the MT-ID in the parent prefix-specific TLV of the prefix-SID sub-TLV. In >> other words, why not contain the MT-ID in the OSPF Extended Prefix TLV, >> instead of the prefix-sid sub-TLV (see section 3 of >> http://tools.ietf.org/html/draft-xu-ospf-global-label-sid-adv-00)? >> >> no, we do not want to put the MT-ID in the OSPF Extended Prefix TLV. The >> reason is that attributes are MT specific, not the prefix itself - e.g. >> you may want to advertise different metrics for the same prefix in different >> topologies, not the same prefix twice. > > Make the prefix-sid as a sub-TLV of the Multi-Topology sub-TLV? no, we don't want to end up with sub-sub-TLVs right from the beginning. regards, Peter > > Best regards, > Xiaohu > >> regards, >> Peter >> >> >> >> >> >>> >>> Anyway, although it is unavoidable for us to define extensions to both ISIS and >> OSPF for the same thing due to the fact that both protocols have been widely >> used, could we try our best to keep the encodings of ISIS and OSPF as consistent >> as possible for the same functionality? In this way, once someone has read the >> ISIS extension draft, he or she can easily think of what has been done in the >> OSPF extension draft accordingly, and vice verse. >>> >>> Best regards, >>> Xiaohu >>> >>> _______________________________________________ >>> Isis-wg mailing list >>> Isis-wg@ietf.org >>> https://www.ietf.org/mailman/listinfo/isis-wg >>> . >>> >> >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg@ietf.org >> https://www.ietf.org/mailman/listinfo/isis-wg > . > From nobody Sun Jun 15 19:58:47 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79451B29F4; Sun, 15 Jun 2014 19:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGJ7_g50echX; Sun, 15 Jun 2014 19:58:43 -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 DACA71B29ED; Sun, 15 Jun 2014 19:58:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFL15551; Mon, 16 Jun 2014 02:58:41 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 16 Jun 2014 03:58:40 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Mon, 16 Jun 2014 10:58:34 +0800 From: Xuxiaohu To: Peter Psenak , "isis-wg@ietf.org list" , OSPF List Thread-Topic: [Isis-wg] Encoding inconsistency between ISIS and OSPFv2 extensions for SR Thread-Index: Ac+G3FEp8zYfOWcFTgiN+WbMbdhxlP//hQmA//91kcCAAM0tAP/7brkA Date: Mon, 16 Jun 2014 02:58:33 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08280DB0@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828073D@NKGEML512-MBS.china.huawei.com> <539AB6E9.3070108@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082807D1@NKGEML512-MBS.china.huawei.com> <539AEEE6.3080605@cisco.com> In-Reply-To: <539AEEE6.3080605@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.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/TYkj99FO7aGObNUtxgTsMji5EPQ Subject: Re: [OSPF] [Isis-wg] Encoding inconsistency between ISIS and OSPFv2 extensions for SR X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jun 2014 02:58:46 -0000 Hi Peter, Please see my response inline > -----Original Message----- > From: Peter Psenak [mailto:ppsenak@cisco.com] > Sent: Friday, June 13, 2014 8:31 PM > To: Xuxiaohu; isis-wg@ietf.org list; OSPF List > Subject: Re: [Isis-wg] Encoding inconsistency between ISIS and OSPFv2 > extensions for SR >=20 > Hi Xiaohu, >=20 > please see inline: >=20 > On 6/13/14 12:09 , Xuxiaohu wrote: > > Hi peter, > > > >> -----Original Message----- > >> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Peter > >> Psenak > >> Sent: Friday, June 13, 2014 4:32 PM > >> To: Xuxiaohu; isis-wg@ietf.org list; OSPF List > >> Subject: Re: [Isis-wg] Encoding inconsistency between ISIS and OSPFv2 > >> extensions for SR > >> > >> Xiaohu, > >> > >> please see inline: > >> > >> On 6/13/14 09:51 , Xuxiaohu wrote: > >>> Hi all, > >>> > >>> There are some encoding inconsistencies between OSPFv2 extensions > >>> and ISIS > >> extensions for SR as follows: > >>> > >>> 1. In ISIS-SR, the prefix-sid advertisement is piggybacked on the IP > >>> reachability > >> advertisement. In OSPF-SR, the prefix-sid advertisement is > >> piggybacked on OSPF Extended Prefix LSA which is used to advertise > >> other attributes associated with the prefix, rather than the > >> reachability. IMHO, the OSPF encoding is more flexible since the > >> label distribution and the reachability advertisement are > >> independent. As a result, the route summary on area boundaries at > >> least can be enabled as before. Besides, the prefix-SID sub-TLV can > >> be used to advertise a range of prefix/SID pairs (see item2). In > >> fact, ISIS allows us to do the same way as OSPF with a much lower > >> cost (see section 3 of > http://tools.ietf.org/html/draft-xu-isis-global-label-sid-adv-00). Of cou= rse, it > seems that you co-authors prefer to the piggyback way. > >> > >> OSPF LSAs that are used to advertise the prefixex are not extensible, > >> so we had to define a new LSA for the purpose of advertising a prefix = related > attributes. > >> ISIS is different, as they can add sub-TLVs to existing TLVs. > > > > I see. For ISIS, you use the piggyback way (piggyback the label/sid > advertisement on the reachability advertisement messages). For OSPFv2, yo= u > have no way to use the piggyback way anymore, so you defined a new LSA... > That's why I said you prefer to the piggyback way. However, I don't think= the > piggyback way is much worthwhile from the perspective of flexibility and > extensibility. > > > >>> > >>> 2. In ISIS-SR, the Prefix-SID Sub-TLV can only be used to advertise > >>> an SID for a > >> single prefix. And it relays on the SID/Label Binding TLV to > >> advertise a range of prefix/SID pairs. In contrast, In OSPF-SR, the > >> prefix-sid sub-TLV can be used to specify a range of addresses and > >> their associated Prefix SIDs. By the way, in the 4.3. SID/Label > >> Binding sub-TLV. it has the following text: "Range Size: usage is the > >> same as described in Section 4.2." Did you co-authors want to propose > >> two ways (i.e., prefix-sid sub-TLV and SID-Label Binding sub-TLV) to a= chieve > the same goal (i..e, advertise a range of prefix/SID pairs)? > >> > >> because in OSPF advertisement of the prefix SID is decoupled from the > >> advertisement of prefix reachability, we can afford to advertise the > >> range of SIDs in the prefix-SID sub-TLV as such. > > > > IMHO, the ISIS and OSPFv3 advertisement of the prefix SIDs should be > > decoupled from the prefix reachability advertisement as well:) >=20 > in OSPFv3 case, we have a way to advertise the prefix using the proposed > encoding in draft-acee-ospfv3-lsa-extend, but do not advertise the reacha= bility > of the prefix - it's call NU-bit (rfc5340, A.4.1.1.) That's great. BTW, don't you believe the ISIS protocol has provided almost = the same capability as the NU-bit (see the following text quoted from RFC53= 05)? "...If a prefix is advertised with a metric larger then MAX_PATH_METRIC (0xFE000000, see paragraph 3.0), this prefix MUST NOT be considered during the normal SPF computation. This allows advertisement of a prefix for purposes other than building the normal IP routing table...". =20 > > > >> No, we do not define two ways to achieve the same thing. Binding TLV > >> is used for a different purpose and the same usage is only applicable > >> to the Range semantics, not to the whole Binding TLV. > > > > Does that mean the Binding sub-TLV in the OSPF-SR could not be used to > advertise a range of prefix/sid pairs while the binding sub-TLV in the IS= IS-SR > could? >=20 > Binding TLV in OSPF is only used to advertise a "LSP path" local to the a= dvertising > router, it's not used for anything else. YOu can still advertise a single= "LSP path" > for range of prefixes. Don't you believe it's better for the Binding TLV in ISIS to be used to adv= ertise a LSP as well?=20 > In ISIS, due to the need to decouple prefix reachability from SID adverti= sement, > Binding TLV is used for SR Mapping Server (SRMS) adevrtisement on top of = what > it is used in OSPF (in OSPF SRMS advertisements are using the Prefix/SID > sub-TLV). To decouple prefix reachability from SID advertisement, why not consider th= e approach of using the MAX_PATH_METRIC trick (see section 3 of http://tool= s.ietf.org/html/draft-xu-isis-global-label-sid-adv-00)? Best regards, Xiaohu > >>> 6. In ISIS-SR, the prefix-SID sub-TLV doesn't contain the MT-ID > >>> field since the > >> MT-ID field is already contained in the parent TLV of the prefix-SID > >> sub-TLV. In OSPF, the MT-ID field is contained in the Prefix SID > >> Sub-TLV since the parent TLV of the prefix-sid sub-TLV doesn't > >> contain that MT-ID field. IMHO, it's better to contain the MT-ID in > >> the parent prefix-specific TLV of the prefix-SID sub-TLV. In other > >> words, why not contain the MT-ID in the OSPF Extended Prefix TLV, > >> instead of the prefix-sid sub-TLV (see section 3 of > http://tools.ietf.org/html/draft-xu-ospf-global-label-sid-adv-00)? > >> > >> no, we do not want to put the MT-ID in the OSPF Extended Prefix TLV. > >> The reason is that attributes are MT specific, not the prefix itself -= e.g. > >> you may want to advertise different metrics for the same prefix in > >> different topologies, not the same prefix twice. > > > > Make the prefix-sid as a sub-TLV of the Multi-Topology sub-TLV? >=20 > no, we don't want to end up with sub-sub-TLVs right from the beginning. >=20 > regards, > Peter >=20 > > > > Best regards, > > Xiaohu > > > >> regards, > >> Peter > >> > >> > >> > >> > >> > >>> > >>> Anyway, although it is unavoidable for us to define extensions to > >>> both ISIS and > >> OSPF for the same thing due to the fact that both protocols have been > >> widely used, could we try our best to keep the encodings of ISIS and > >> OSPF as consistent as possible for the same functionality? In this > >> way, once someone has read the ISIS extension draft, he or she can > >> easily think of what has been done in the OSPF extension draft accordi= ngly, > and vice verse. > >>> > >>> Best regards, > >>> Xiaohu > >>> > >>> _______________________________________________ > >>> Isis-wg mailing list > >>> Isis-wg@ietf.org > >>> https://www.ietf.org/mailman/listinfo/isis-wg > >>> . > >>> > >> > >> _______________________________________________ > >> Isis-wg mailing list > >> Isis-wg@ietf.org > >> https://www.ietf.org/mailman/listinfo/isis-wg > > . > > From nobody Mon Jun 16 00:17:02 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E3A1A03B0; Mon, 16 Jun 2014 00:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fv_-2REMnXE; Mon, 16 Jun 2014 00:16:54 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FFF01A0365; Mon, 16 Jun 2014 00:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7966; q=dns/txt; s=iport; t=1402903014; x=1404112614; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=PtZiLx6wqO8p4j7mqZUX3ffgzLscFGcMmvWL+nmcb0U=; b=WNjasWPikiKgyW8Y/1i7TzRotEf0JHehGpbB8XoHxn9qgPe0W9o3rZDc Xek7mpWUe+JGfVhrt+ckpPvyj5j7aBtsjATnDrNjjNw39w0a3MSmv1aEU T55rWIF7zJerifcKhJ4vtHNInMlBdYBrrAUY8V1Hu7dV9sjpU+glngnCp g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFABSZnlOtJssW/2dsb2JhbABag1+qQQEBAQMFAZFnhz0BgSV1hAMBAQEDAQEBATU2Cg0ECxEEAQEBCRYIBwkDAgECARUfCQgGAQwGAgEBiDYIDc5rF4Vjg2CFOgaEPQEDmkOBQ4U3jF6DQjs X-IronPort-AV: E=Sophos;i="5.01,484,1400025600"; d="scan'208";a="83196453" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 16 Jun 2014 07:16:52 +0000 Received: from [10.55.51.202] (ams-ppsenak-8719.cisco.com [10.55.51.202]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5G7Gpdd008339; Mon, 16 Jun 2014 07:16:51 GMT Message-ID: <539E99E3.5030305@cisco.com> Date: Mon, 16 Jun 2014 09:16:51 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Xuxiaohu , "isis-wg@ietf.org list" , OSPF List References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828073D@NKGEML512-MBS.china.huawei.com> <539AB6E9.3070108@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082807D1@NKGEML512-MBS.china.huawei.com> <539AEEE6.3080605@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08280DB0@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08280DB0@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/HKnzPU-dxDZG5tL9_GgJ5jjbPVY Subject: Re: [OSPF] [Isis-wg] Encoding inconsistency between ISIS and OSPFv2 extensions for SR X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jun 2014 07:16:58 -0000 Xiaohu, please see inline: On 6/16/14 04:58 , Xuxiaohu wrote: > Hi Peter, > > Please see my response inline > >> -----Original Message----- >> From: Peter Psenak [mailto:ppsenak@cisco.com] >> Sent: Friday, June 13, 2014 8:31 PM >> To: Xuxiaohu; isis-wg@ietf.org list; OSPF List >> Subject: Re: [Isis-wg] Encoding inconsistency between ISIS and OSPFv2 >> extensions for SR >> >> Hi Xiaohu, >> >> please see inline: >> >> On 6/13/14 12:09 , Xuxiaohu wrote: >>> Hi peter, >>> >>>> -----Original Message----- >>>> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Peter >>>> Psenak >>>> Sent: Friday, June 13, 2014 4:32 PM >>>> To: Xuxiaohu; isis-wg@ietf.org list; OSPF List >>>> Subject: Re: [Isis-wg] Encoding inconsistency between ISIS and OSPFv2 >>>> extensions for SR >>>> >>>> Xiaohu, >>>> >>>> please see inline: >>>> >>>> On 6/13/14 09:51 , Xuxiaohu wrote: >>>>> Hi all, >>>>> >>>>> There are some encoding inconsistencies between OSPFv2 extensions >>>>> and ISIS >>>> extensions for SR as follows: >>>>> >>>>> 1. In ISIS-SR, the prefix-sid advertisement is piggybacked on the IP >>>>> reachability >>>> advertisement. In OSPF-SR, the prefix-sid advertisement is >>>> piggybacked on OSPF Extended Prefix LSA which is used to advertise >>>> other attributes associated with the prefix, rather than the >>>> reachability. IMHO, the OSPF encoding is more flexible since the >>>> label distribution and the reachability advertisement are >>>> independent. As a result, the route summary on area boundaries at >>>> least can be enabled as before. Besides, the prefix-SID sub-TLV can >>>> be used to advertise a range of prefix/SID pairs (see item2). In >>>> fact, ISIS allows us to do the same way as OSPF with a much lower >>>> cost (see section 3 of >> http://tools.ietf.org/html/draft-xu-isis-global-label-sid-adv-00). Of course, it >> seems that you co-authors prefer to the piggyback way. >>>> >>>> OSPF LSAs that are used to advertise the prefixex are not extensible, >>>> so we had to define a new LSA for the purpose of advertising a prefix related >> attributes. >>>> ISIS is different, as they can add sub-TLVs to existing TLVs. >>> >>> I see. For ISIS, you use the piggyback way (piggyback the label/sid >> advertisement on the reachability advertisement messages). For OSPFv2, you >> have no way to use the piggyback way anymore, so you defined a new LSA... >> That's why I said you prefer to the piggyback way. However, I don't think the >> piggyback way is much worthwhile from the perspective of flexibility and >> extensibility. >>> >>>>> >>>>> 2. In ISIS-SR, the Prefix-SID Sub-TLV can only be used to advertise >>>>> an SID for a >>>> single prefix. And it relays on the SID/Label Binding TLV to >>>> advertise a range of prefix/SID pairs. In contrast, In OSPF-SR, the >>>> prefix-sid sub-TLV can be used to specify a range of addresses and >>>> their associated Prefix SIDs. By the way, in the 4.3. SID/Label >>>> Binding sub-TLV. it has the following text: "Range Size: usage is the >>>> same as described in Section 4.2." Did you co-authors want to propose >>>> two ways (i.e., prefix-sid sub-TLV and SID-Label Binding sub-TLV) to achieve >> the same goal (i..e, advertise a range of prefix/SID pairs)? >>>> >>>> because in OSPF advertisement of the prefix SID is decoupled from the >>>> advertisement of prefix reachability, we can afford to advertise the >>>> range of SIDs in the prefix-SID sub-TLV as such. >>> >>> IMHO, the ISIS and OSPFv3 advertisement of the prefix SIDs should be >>> decoupled from the prefix reachability advertisement as well:) >> >> in OSPFv3 case, we have a way to advertise the prefix using the proposed >> encoding in draft-acee-ospfv3-lsa-extend, but do not advertise the reachability >> of the prefix - it's call NU-bit (rfc5340, A.4.1.1.) > > That's great. BTW, don't you believe the ISIS protocol has provided almost the same capability as the NU-bit (see the following text quoted from RFC5305)? correct, max-metric means unreachable in ISIS. > > "...If a prefix is advertised > with a metric larger then MAX_PATH_METRIC (0xFE000000, see paragraph > 3.0), this prefix MUST NOT be considered during the normal SPF > computation. This allows advertisement of a prefix for purposes > other than building the normal IP routing table...". > >>> >>>> No, we do not define two ways to achieve the same thing. Binding TLV >>>> is used for a different purpose and the same usage is only applicable >>>> to the Range semantics, not to the whole Binding TLV. >>> >>> Does that mean the Binding sub-TLV in the OSPF-SR could not be used to >> advertise a range of prefix/sid pairs while the binding sub-TLV in the ISIS-SR >> could? >> >> Binding TLV in OSPF is only used to advertise a "LSP path" local to the advertising >> router, it's not used for anything else. YOu can still advertise a single "LSP path" >> for range of prefixes. > > Don't you believe it's better for the Binding TLV in ISIS to be used to advertise a LSP as well? Binding TLV in ISIS can be used to advertise "LSP path" as well as SRMS mappings. > >> In ISIS, due to the need to decouple prefix reachability from SID advertisement, >> Binding TLV is used for SR Mapping Server (SRMS) adevrtisement on top of what >> it is used in OSPF (in OSPF SRMS advertisements are using the Prefix/SID >> sub-TLV). > > To decouple prefix reachability from SID advertisement, why not consider the approach of using the MAX_PATH_METRIC trick (see section 3 of http://tools.ietf.org/html/draft-xu-isis-global-label-sid-adv-00)? it's a matter of choice. Authors of ISIS draft choose the cleaner way IMHO. regards, Peter > > Best regards, > Xiaohu > >>>>> 6. In ISIS-SR, the prefix-SID sub-TLV doesn't contain the MT-ID >>>>> field since the >>>> MT-ID field is already contained in the parent TLV of the prefix-SID >>>> sub-TLV. In OSPF, the MT-ID field is contained in the Prefix SID >>>> Sub-TLV since the parent TLV of the prefix-sid sub-TLV doesn't >>>> contain that MT-ID field. IMHO, it's better to contain the MT-ID in >>>> the parent prefix-specific TLV of the prefix-SID sub-TLV. In other >>>> words, why not contain the MT-ID in the OSPF Extended Prefix TLV, >>>> instead of the prefix-sid sub-TLV (see section 3 of >> http://tools.ietf.org/html/draft-xu-ospf-global-label-sid-adv-00)? >>>> >>>> no, we do not want to put the MT-ID in the OSPF Extended Prefix TLV. >>>> The reason is that attributes are MT specific, not the prefix itself - e.g. >>>> you may want to advertise different metrics for the same prefix in >>>> different topologies, not the same prefix twice. >>> >>> Make the prefix-sid as a sub-TLV of the Multi-Topology sub-TLV? >> >> no, we don't want to end up with sub-sub-TLVs right from the beginning. >> >> regards, >> Peter >> >>> >>> Best regards, >>> Xiaohu >>> >>>> regards, >>>> Peter >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> Anyway, although it is unavoidable for us to define extensions to >>>>> both ISIS and >>>> OSPF for the same thing due to the fact that both protocols have been >>>> widely used, could we try our best to keep the encodings of ISIS and >>>> OSPF as consistent as possible for the same functionality? In this >>>> way, once someone has read the ISIS extension draft, he or she can >>>> easily think of what has been done in the OSPF extension draft accordingly, >> and vice verse. >>>>> >>>>> Best regards, >>>>> Xiaohu >>>>> >>>>> _______________________________________________ >>>>> Isis-wg mailing list >>>>> Isis-wg@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>>> . >>>>> >>>> >>>> _______________________________________________ >>>> Isis-wg mailing list >>>> Isis-wg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/isis-wg >>> . >>> > > . > From nobody Mon Jun 16 02:11:53 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275CA1A0644; Mon, 16 Jun 2014 02:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUF-1aU6F2XA; Mon, 16 Jun 2014 02:11:43 -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 7EFCB1A0225; Mon, 16 Jun 2014 02:11:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFM05224; Mon, 16 Jun 2014 09:11:40 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 16 Jun 2014 10:11:01 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Mon, 16 Jun 2014 17:10:57 +0800 From: Xuxiaohu To: Peter Psenak , "isis-wg@ietf.org list" , OSPF List Thread-Topic: [Isis-wg] Encoding inconsistency between ISIS and OSPFv2 extensions for SR Thread-Index: Ac+G3FEp8zYfOWcFTgiN+WbMbdhxlP//hQmA//91kcCAAM0tAP/7brkAgAjwpID//10bYA== Date: Mon, 16 Jun 2014 09:10:56 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08280EAC@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828073D@NKGEML512-MBS.china.huawei.com> <539AB6E9.3070108@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082807D1@NKGEML512-MBS.china.huawei.com> <539AEEE6.3080605@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08280DB0@NKGEML512-MBS.china.huawei.com> <539E99E3.5030305@cisco.com> In-Reply-To: <539E99E3.5030305@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.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/LgmbPt8IQWrHhXPx8-llUt9BAsY Subject: Re: [OSPF] [Isis-wg] Encoding inconsistency between ISIS and OSPFv2 extensions for SR X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jun 2014 09:11:51 -0000 > -----Original Message----- > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Peter Psenak > Sent: Monday, June 16, 2014 3:17 PM > To: Xuxiaohu; isis-wg@ietf.org list; OSPF List > Subject: Re: [Isis-wg] Encoding inconsistency between ISIS and OSPFv2 > extensions for SR >=20 > Xiaohu, >=20 > please see inline: >=20 > On 6/16/14 04:58 , Xuxiaohu wrote: > > Hi Peter, > > > > Please see my response inline > > > >> -----Original Message----- > >> From: Peter Psenak [mailto:ppsenak@cisco.com] > >> Sent: Friday, June 13, 2014 8:31 PM > >> To: Xuxiaohu; isis-wg@ietf.org list; OSPF List > >> Subject: Re: [Isis-wg] Encoding inconsistency between ISIS and OSPFv2 > >> extensions for SR > >> > >> Hi Xiaohu, > >> > >> please see inline: > >> > >> On 6/13/14 12:09 , Xuxiaohu wrote: > >>> Hi peter, > >>> > >>>> -----Original Message----- > >>>> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Peter > >>>> Psenak > >>>> Sent: Friday, June 13, 2014 4:32 PM > >>>> To: Xuxiaohu; isis-wg@ietf.org list; OSPF List > >>>> Subject: Re: [Isis-wg] Encoding inconsistency between ISIS and > >>>> OSPFv2 extensions for SR > >>>> > >>>> Xiaohu, > >>>> > >>>> please see inline: > >>>> > >>>> On 6/13/14 09:51 , Xuxiaohu wrote: > >>>>> Hi all, > >>>>> > >>>>> There are some encoding inconsistencies between OSPFv2 extensions > >>>>> and ISIS > >>>> extensions for SR as follows: > >>>>> > >>>>> 1. In ISIS-SR, the prefix-sid advertisement is piggybacked on the > >>>>> IP reachability > >>>> advertisement. In OSPF-SR, the prefix-sid advertisement is > >>>> piggybacked on OSPF Extended Prefix LSA which is used to advertise > >>>> other attributes associated with the prefix, rather than the > >>>> reachability. IMHO, the OSPF encoding is more flexible since the > >>>> label distribution and the reachability advertisement are > >>>> independent. As a result, the route summary on area boundaries at > >>>> least can be enabled as before. Besides, the prefix-SID sub-TLV can > >>>> be used to advertise a range of prefix/SID pairs (see item2). In > >>>> fact, ISIS allows us to do the same way as OSPF with a much lower > >>>> cost (see section 3 of > >> http://tools.ietf.org/html/draft-xu-isis-global-label-sid-adv-00). Of > >> course, it seems that you co-authors prefer to the piggyback way. > >>>> > >>>> OSPF LSAs that are used to advertise the prefixex are not > >>>> extensible, so we had to define a new LSA for the purpose of > >>>> advertising a prefix related > >> attributes. > >>>> ISIS is different, as they can add sub-TLVs to existing TLVs. > >>> > >>> I see. For ISIS, you use the piggyback way (piggyback the label/sid > >> advertisement on the reachability advertisement messages). For > >> OSPFv2, you have no way to use the piggyback way anymore, so you defin= ed > a new LSA... > >> That's why I said you prefer to the piggyback way. However, I don't > >> think the piggyback way is much worthwhile from the perspective of > >> flexibility and extensibility. > >>> > >>>>> > >>>>> 2. In ISIS-SR, the Prefix-SID Sub-TLV can only be used to > >>>>> advertise an SID for a > >>>> single prefix. And it relays on the SID/Label Binding TLV to > >>>> advertise a range of prefix/SID pairs. In contrast, In OSPF-SR, the > >>>> prefix-sid sub-TLV can be used to specify a range of addresses and > >>>> their associated Prefix SIDs. By the way, in the 4.3. SID/Label > >>>> Binding sub-TLV. it has the following text: "Range Size: usage is > >>>> the same as described in Section 4.2." Did you co-authors want to > >>>> propose two ways (i.e., prefix-sid sub-TLV and SID-Label Binding > >>>> sub-TLV) to achieve > >> the same goal (i..e, advertise a range of prefix/SID pairs)? > >>>> > >>>> because in OSPF advertisement of the prefix SID is decoupled from > >>>> the advertisement of prefix reachability, we can afford to > >>>> advertise the range of SIDs in the prefix-SID sub-TLV as such. > >>> > >>> IMHO, the ISIS and OSPFv3 advertisement of the prefix SIDs should be > >>> decoupled from the prefix reachability advertisement as well:) > >> > >> in OSPFv3 case, we have a way to advertise the prefix using the > >> proposed encoding in draft-acee-ospfv3-lsa-extend, but do not > >> advertise the reachability of the prefix - it's call NU-bit (rfc5340, > >> A.4.1.1.) > > > > That's great. BTW, don't you believe the ISIS protocol has provided alm= ost the > same capability as the NU-bit (see the following text quoted from RFC5305= )? >=20 > correct, max-metric means unreachable in ISIS. > > > > "...If a prefix is advertised > > with a metric larger then MAX_PATH_METRIC (0xFE000000, see > paragraph > > 3.0), this prefix MUST NOT be considered during the normal SPF > > computation. This allows advertisement of a prefix for purposes > > other than building the normal IP routing table...". > > > >>> > >>>> No, we do not define two ways to achieve the same thing. Binding > >>>> TLV is used for a different purpose and the same usage is only > >>>> applicable to the Range semantics, not to the whole Binding TLV. > >>> > >>> Does that mean the Binding sub-TLV in the OSPF-SR could not be used > >>> to > >> advertise a range of prefix/sid pairs while the binding sub-TLV in > >> the ISIS-SR could? > >> > >> Binding TLV in OSPF is only used to advertise a "LSP path" local to > >> the advertising router, it's not used for anything else. YOu can still= advertise a > single "LSP path" > >> for range of prefixes. > > > > Don't you believe it's better for the Binding TLV in ISIS to be used to= advertise a > LSP as well? >=20 > Binding TLV in ISIS can be used to advertise "LSP path" as well as SRMS > mappings. I had wanted to say: "Don't you believe it's better for the Binding TLV in = ISIS to be used ONLY to advertise a LSP as well?" In this way, the functionality of the Binding TLV keeps fully= consistent in OSPF and ISIS. Best regards, Xiaohu > >> In ISIS, due to the need to decouple prefix reachability from SID > >> advertisement, Binding TLV is used for SR Mapping Server (SRMS) > >> adevrtisement on top of what it is used in OSPF (in OSPF SRMS > >> advertisements are using the Prefix/SID sub-TLV). > > > > To decouple prefix reachability from SID advertisement, why not conside= r the > approach of using the MAX_PATH_METRIC trick (see section 3 of > http://tools.ietf.org/html/draft-xu-isis-global-label-sid-adv-00)? >=20 > it's a matter of choice. Authors of ISIS draft choose the cleaner way IMH= O. > regards, > Peter >=20 > > > > Best regards, > > Xiaohu > > > >>>>> 6. In ISIS-SR, the prefix-SID sub-TLV doesn't contain the MT-ID > >>>>> field since the > >>>> MT-ID field is already contained in the parent TLV of the > >>>> prefix-SID sub-TLV. In OSPF, the MT-ID field is contained in the > >>>> Prefix SID Sub-TLV since the parent TLV of the prefix-sid sub-TLV > >>>> doesn't contain that MT-ID field. IMHO, it's better to contain the > >>>> MT-ID in the parent prefix-specific TLV of the prefix-SID sub-TLV. > >>>> In other words, why not contain the MT-ID in the OSPF Extended > >>>> Prefix TLV, instead of the prefix-sid sub-TLV (see section 3 of > >> http://tools.ietf.org/html/draft-xu-ospf-global-label-sid-adv-00)? > >>>> > >>>> no, we do not want to put the MT-ID in the OSPF Extended Prefix TLV. > >>>> The reason is that attributes are MT specific, not the prefix itself= - e.g. > >>>> you may want to advertise different metrics for the same prefix in > >>>> different topologies, not the same prefix twice. > >>> > >>> Make the prefix-sid as a sub-TLV of the Multi-Topology sub-TLV? > >> > >> no, we don't want to end up with sub-sub-TLVs right from the beginning= . > >> > >> regards, > >> Peter > >> > >>> > >>> Best regards, > >>> Xiaohu > >>> > >>>> regards, > >>>> Peter > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> > >>>>> Anyway, although it is unavoidable for us to define extensions to > >>>>> both ISIS and > >>>> OSPF for the same thing due to the fact that both protocols have > >>>> been widely used, could we try our best to keep the encodings of > >>>> ISIS and OSPF as consistent as possible for the same functionality? > >>>> In this way, once someone has read the ISIS extension draft, he or > >>>> she can easily think of what has been done in the OSPF extension > >>>> draft accordingly, > >> and vice verse. > >>>>> > >>>>> Best regards, > >>>>> Xiaohu > >>>>> > >>>>> _______________________________________________ > >>>>> Isis-wg mailing list > >>>>> Isis-wg@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/isis-wg > >>>>> . > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Isis-wg mailing list > >>>> Isis-wg@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/isis-wg > >>> . > >>> > > > > . > > >=20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Tue Jun 17 00:08:52 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425631A02D9; Tue, 17 Jun 2014 00:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uyz5uEJlGnz7; Tue, 17 Jun 2014 00:08:35 -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 AF1751A02BE; Tue, 17 Jun 2014 00:08:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIM95022; Tue, 17 Jun 2014 07:08:27 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 17 Jun 2014 08:08:25 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 17 Jun 2014 15:08:12 +0800 From: Xuxiaohu To: "Stefano Previdi (sprevidi)" Thread-Topic: [Isis-wg] [OSPF] Comments on draft-ietf-isis-segment-routing-extensions-01 Thread-Index: AQHPhtSCyFjbUlXIUU+3C74w5rfXOZt05QLw Date: Tue, 17 Jun 2014 07:08:12 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08281246@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08280249@NKGEML512-MBS.china.huawei.com> <442F4557-73F8-46B3-8ED7-E3E4BECF3523@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0828066E@NKGEML512-MBS.china.huawei.com> <88398D6A-180C-417A-B719-295CDAA35850@cisco.com> In-Reply-To: <88398D6A-180C-417A-B719-295CDAA35850@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.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/ArAEWm2NEc9sCFNzigS6yuoQGkk Cc: OSPF List , "isis-wg@ietf.org" Subject: Re: [OSPF] [Isis-wg] Comments on draft-ietf-isis-segment-routing-extensions-01 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jun 2014 07:08:42 -0000 > > If so, does it mean that the prefix-sid sub-TLV would not be used in th= e IPv6-SR > case? >=20 >=20 > not at this stage. >=20 > In the future we may come back and revisit the idea of using 32bit SIDs f= or ipv6 > as well. Hi Stefano, What's the motivation for using 32-bit SIDs, rather than 20-bit MPLS labels= for IPv6, especially when the GLOBAL MPLS label concept has been explicitl= y supported by the draft and encapsulating an MPLS label stack into an IPv6= -based tunnel (e.g., MPLS-over-GRE) is a very mature technology? Best regards, Xiaohu =20 From nobody Wed Jun 18 13:49:51 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C0A1A030E for ; Wed, 18 Jun 2014 13:49:49 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQN34e0eQ-q9 for ; Wed, 18 Jun 2014 13:49:48 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60DF1A0313 for ; Wed, 18 Jun 2014 13:49:47 -0700 (PDT) X-AuditID: c618062d-f79be6d000006b89-18-53a1aa3beac3 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 2A.64.27529.C3AA1A35; Wed, 18 Jun 2014 17:03:24 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Wed, 18 Jun 2014 16:49:46 -0400 From: Acee Lindem To: OSPF - OSPF WG List Thread-Topic: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll Thread-Index: AQHPizbW3Qi+Qx0iJUeNFuMftMALsA== Date: Wed, 18 Jun 2014 20:49:45 +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/14.4.2.140509 x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_CFC748A531998aceelindemericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXRPiK7NqoXBBvdPKFu03LvH7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEVbVrMWnJKt2DTrD3sD423JLkZODgkBE4nr1/6xQNhiEhfu rWfrYuTiEBI4yihxtHErK4SznFHi1tpfbCBVbAI6Es8f/WMGsUUE1CVWT97NCmILC/hIzF3W zgIR95W4+30VlK0nceP7U7BeFgFVibOvXjGB2LwCphJ756wDs4WA7BW/NwLZHBycAmYSXxqd QMKMQAd9P7UGrIRZQFzi1pP5TBCHCkgs2XOeGcIWlXj5+B/YCaJAq5q73jBCxBUl9vVPZ4fo jZI4MvklO8RaQYmTM5+wTGAUnYVk7CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DFUr7XE 8wXTWZHVLGDkWMXIUVqcWpabbmSwiREYWcck2HR3MO55aXmIUYCDUYmHN2H2wmAh1sSy4src Q4zSHCxK4ryzaucFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDUff5O7qfytsXFrz4+/W4v Ztv3vi7abancTl+eCQc0fmRNWNJyc88uxfY+u1e50nPeeq4y/asu2Oix2v+elqX0bKn3mjwy s/7pXuyMbXzcdHLpMjbBLzI2StXip/d4XZw+UWOx4+OYmp+MwTVbS87/s6gr0NF3P8pRunBS 4EXW5LzkKsWCa9ZKLMUZiYZazEXFiQB+baeijQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/bhfzOQ8Y7NLf9oyHin5z7hjJUh4 Subject: Re: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 18 Jun 2014 20:49:49 -0000 --_000_CFC748A531998aceelindemericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Peter and other authors, There is sufficient support for WG adoption. Please re-publish the draft as= draft-ietf-ospf-segment-routing-extensions-00.txt. Thanks, Abhay and Acee From: Ericsson > Date: Monday, June 9, 2014 at 12:39 PM To: OSPF - OSPF WG List > Subject: [OSPF] OSPFv2 Segment Routing Draft WG Document Acceptance Poll Given the progress made in the SRING WG on problem statement and use caseWG= document adoption, Abhay and I now feel we can start a 1 week poll on adop= tion of the corresponding OSPF document. http://www.ietf.org/id/draft-psenak-ospf-segment-routing-extensions-05.txt Please indicate your support or opposition to WG adoption. Thanks, Abhay and Acee P.S. Assuming adoption of the OSPFv2 draft, we will poll for acceptance of = the OSPFv3 draft. --_000_CFC748A531998aceelindemericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <292D4C0F5F4E8A42B606C5A14C715F16@ericsson.com> Content-Transfer-Encoding: quoted-printable
Peter and other authors,

There is sufficient support for WG adoption. Please re-publish the dra= ft as draft-ietf-ospf-segment-routing-extensions-00.txt. 

Thanks,
Abhay and Acee

From: Ericsson <acee.lindem@ericsson.com>
Date: Monday, June 9, 2014 at 12:39= PM
To: OSPF - OSPF WG List <ospf@ietf.org>
Subject: [OSPF] OSPFv2 Segment Rout= ing Draft WG Document Acceptance Poll

Given the progress made in the SRING WG on problem statement and use c= aseWG document adoption, Abhay and I now feel we can start a 1 week poll on= adoption of the corresponding OSPF document. 


Please indicate your support or opposition to WG adoption.

Thanks,
Abhay and Acee
P.S. Assuming adoption of the OSPFv2 draft, we will poll for acceptanc= e of the OSPFv3 draft. 

 --_000_CFC748A531998aceelindemericssoncom_-- From nobody Sun Jun 22 22:10:54 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCC31A045D; Sun, 22 Jun 2014 22:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.451 X-Spam-Level: X-Spam-Status: No, score=-12.451 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XmetEt9JAFD; Sun, 22 Jun 2014 22:10:48 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80EB41B2991; Sun, 22 Jun 2014 22:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7780; q=dns/txt; s=iport; t=1403500248; x=1404709848; h=message-id:date:from:mime-version:to:subject; bh=Z2NiLXkaWKJYnvr+Gt0yDTf+HxKAedxNgikp2vdIBAA=; b=FcQ+Dn8bhC+U9ol0mMQ1KHj6sC33+U4EYLnQSqaPlPMGoGuLvB/1eFDB ksER1gYO4iFr2lhefFbQxkahzdfQl5i7y7r2tCDVzj0u4YhYvXXJsfakO 6/majZNqmYYnpeyKyJF902zmvPLThqXJYVp9vqvxBWKfiGWm33B5P6y3o A=; X-Files: draft-ietf-ospf-security-extension-manual-keying.txt : 6108 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQFAK+2p1OtJV2Z/2dsb2JhbABPCoMNUoNHp0YBAQEBAQEFAZo8FnWDejNEBAMEBh8BHRYLAgsDAgECAUsBDAgBAQUSiCcNqC6dUheFY4g3BgsBg06BTASKQodEiEaTY4IAgWIdgTMHFwY X-IronPort-AV: E=Sophos;i="5.01,527,1400025600"; d="txt'?scan'208,217";a="55141555" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP; 23 Jun 2014 05:10:43 +0000 Received: from AKR-M-40P0.CISCO.COM (sjc-vpn2-750.cisco.com [10.21.114.238]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5N5Ag1M004987; Mon, 23 Jun 2014 05:10:42 GMT Message-ID: <53A7B6D2.1000809@cisco.com> Date: Sun, 22 Jun 2014 22:10:42 -0700 From: Abhay Roy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ietf-secretariat@ietf.org, "adrian@olddog.co.uk" , Alia Atlas , "ospf@ietf.org" Content-Type: multipart/mixed; boundary="------------000102080803020704020405" Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/tw6XWKqOnhTiD9wiYKB6kCM3DJg Subject: [OSPF] Publication request for "Security Extension for OSPFv2 when using Manual Key Management" X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2014 05:10:51 -0000 This is a multi-part message in MIME format. --------------000102080803020704020405 Content-Type: multipart/alternative; boundary="------------030405070603060800030302" --------------030405070603060800030302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please publish draft-ietf-ospf-security-extension-manual-keying-08 as a Standards Track document. Thanks to Vishwas Manral for doing the Document Writeup (attached). Regards, -Abhay --------------030405070603060800030302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please publish draft-ietf-ospf-security-extension-manual-keying-08 as a Standards Track document. Thanks to Vishwas Manral for doing the Document Writeup (attached).

Regards,
-Abhay
--------------030405070603060800030302-- --------------000102080803020704020405 Content-Type: text/plain; charset=UTF-8; name="draft-ietf-ospf-security-extension-manual-keying.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="draft-ietf-ospf-security-extension-manual-keying.txt" (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Standards Track (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes a non backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to prevent replay attacks even on cryptographically secured messages. The draft increases the sequence number size to 8 bytes and carries it in OSPF packet trailers. Working Group Summary: There were some discussions around the technique and some additional issues with existing implementations were found, which increased the applicability of the given solution. Document Quality: The document updates RFC2328 and RFC5709. The document has existed for more than 3 years as a WG document and has undergone 9 revisions in the period. Personnel: Vishwas Manral is the document shepherd and Stewart Bryant is the responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The draft updates a critical flaw in RFC2328 which leaves it exposed to replay attacks. There has been significant review and discussion of this draft on the mailing list. There are no outstanding issues with this draft. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Strong consensus from WG with many participating in discussions. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Authors have resolved all nits. Some small nits like the RFC the document updates etc, needs to be looked at which will be caught at the next review cycle. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No, need to be updated. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). IANA Considerations section exists. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. There is no new IANA registery. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable --------------000102080803020704020405-- From nobody Tue Jun 24 00:12:51 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16FF1B283E for ; Tue, 24 Jun 2014 00:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_rQoPOE7RXZ for ; Tue, 24 Jun 2014 00:12:46 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8B31A006B for ; Tue, 24 Jun 2014 00:12:46 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B6A8918001B; Tue, 24 Jun 2014 00:11:13 -0700 (PDT) To: jmoy@casc.com, akatlas@gmail.com, adrian@olddog.co.uk, akr@cisco.com, acee.lindem@ericsson.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140624071113.B6A8918001B@rfc-editor.org> Date: Tue, 24 Jun 2014 00:11:13 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/VmKDMgZKxeU-B5ooNhaLoPeBJ-c Cc: alexander.okonnikov@gmail.com, ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] [Technical Errata Reported] RFC2328 (4022) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 07:12:48 -0000 The following errata report has been submitted for RFC2328, "OSPF Version 2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2328&eid=4022 -------------------------------------- Type: Technical Reported by: Alexander Okonnikov Section: 10.5 Original Text ------------- When receiving an Hello Packet from a neighbor on a broadcast, Point-to-MultiPoint or NBMA network, set the neighbor structure's Neighbor ID equal to the Router ID found in the packet's OSPF header. For these network types, the neighbor structure's Router Priority field, Neighbor's Designated Router field, and Neighbor's Backup Designated Router field are also set equal to the corresponding fields found in the received Hello Packet; changes in these fields should be noted for possible use in the steps below. When receiving an Hello on a point-to-point network (but not on a virtual link) set the neighbor structure's Neighbor IP address to the packet's IP source address. Corrected Text -------------- When receiving an Hello Packet from a neighbor on a broadcast, Point-to-MultiPoint or NBMA network, set the neighbor structure's Neighbor ID equal to the Router ID found in the packet's OSPF header. For broadcast and NBMA network types, the neighbor structure's Router Priority field, Neighbor's Designated Router field, and Neighbor's Backup Designated Router field are also set equal to the corresponding fields found in the received Hello Packet; changes in these fields should be noted for possible use in the steps below. When receiving an Hello on a point-to-point network (but not on a virtual link) set the neighbor structure's Neighbor IP address to the packet's IP source address. Notes ----- This is unnecessary in case of Point-to-MultiPoint network type to hold neighbor's Router Priority, DR, and BDR values. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2328 (no draft string recorded) -------------------------------------- Title : OSPF Version 2 Publication Date : April 1998 Author(s) : J. Moy Category : INTERNET STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Jun 24 00:15:33 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3031B286A for ; Tue, 24 Jun 2014 00:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CKT8GdOhM0B for ; Tue, 24 Jun 2014 00:15:28 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 772651B2856 for ; Tue, 24 Jun 2014 00:15:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A7D621801C0; Tue, 24 Jun 2014 00:13:55 -0700 (PDT) To: jmoy@casc.com, akatlas@gmail.com, adrian@olddog.co.uk, akr@cisco.com, acee.lindem@ericsson.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140624071355.A7D621801C0@rfc-editor.org> Date: Tue, 24 Jun 2014 00:13:55 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/yabeo-iS7bVGUrg3ue4ekaegcFU Cc: alexander.okonnikov@gmail.com, ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] [Editorial Errata Reported] RFC2328 (4023) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 07:15:30 -0000 The following errata report has been submitted for RFC2328, "OSPF Version 2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2328&eid=4023 -------------------------------------- Type: Editorial Reported by: Alexander Okonnikov Section: 12.4.1 Original Text ------------- o Otherwise, the link descriptions added to the router-LSA depend on the OSPF interface type. Link descriptions used for point-to-point interfaces are specified in Section 12.4.1.1, for virtual links in Section 12.4.1.2, for broadcast and NBMA interfaces in 12.4.1.3, and for Point-to-MultiPoint interfaces in 12.4.1.4. Corrected Text -------------- o Otherwise, the link descriptions added to the router-LSA depend on the OSPF interface type. Link descriptions used for point-to-point interfaces are specified in Section 12.4.1.1, for broadcast and NBMA interfaces in 12.4.1.2, for virtual links in Section 12.4.1.3, and for Point-to-MultiPoint interfaces in 12.4.1.4. Notes ----- Incorrect references. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2328 (no draft string recorded) -------------------------------------- Title : OSPF Version 2 Publication Date : April 1998 Author(s) : J. Moy Category : INTERNET STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Jun 24 07:39:41 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB2B1B2A35; Tue, 24 Jun 2014 07:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OZ0DMTPdsqC; Tue, 24 Jun 2014 07:39:35 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id B16F71B2AA8; Tue, 24 Jun 2014 07:39:31 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0CB39180450; Tue, 24 Jun 2014 07:37:57 -0700 (PDT) To: alexander.okonnikov@gmail.com, jmoy@casc.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140624143757.0CB39180450@rfc-editor.org> Date: Tue, 24 Jun 2014 07:37:57 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/vo880Geh31_UlA_bRrPXgFOkJkc Cc: ospf@ietf.org, akatlas@juniper.net, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] [Errata Verified] RFC2328 (4023) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 14:39:40 -0000 The following errata report has been verified for RFC2328, "OSPF Version 2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2328&eid=4023 -------------------------------------- Status: Verified Type: Editorial Reported by: Alexander Okonnikov Date Reported: 2014-06-24 Verified by: Alia Atlas (IESG) Section: 12.4.1 Original Text ------------- o Otherwise, the link descriptions added to the router-LSA depend on the OSPF interface type. Link descriptions used for point-to-point interfaces are specified in Section 12.4.1.1, for virtual links in Section 12.4.1.2, for broadcast and NBMA interfaces in 12.4.1.3, and for Point-to-MultiPoint interfaces in 12.4.1.4. Corrected Text -------------- o Otherwise, the link descriptions added to the router-LSA depend on the OSPF interface type. Link descriptions used for point-to-point interfaces are specified in Section 12.4.1.1, for broadcast and NBMA interfaces in 12.4.1.2, for virtual links in Section 12.4.1.3, and for Point-to-MultiPoint interfaces in 12.4.1.4. Notes ----- Incorrect references. -------------------------------------- RFC2328 (no draft string recorded) -------------------------------------- Title : OSPF Version 2 Publication Date : April 1998 Author(s) : J. Moy Category : INTERNET STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Jun 24 13:23:34 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D166B1B27DE for ; Tue, 24 Jun 2014 13:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVMRbJmZWevJ for ; Tue, 24 Jun 2014 13:23:28 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 641A11B27E4 for ; Tue, 24 Jun 2014 13:23:27 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-3d-53a98a4b9f4b Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id D2.DA.11744.B4A89A35; Tue, 24 Jun 2014 16:25:16 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0174.001; Tue, 24 Jun 2014 16:23:18 -0400 From: Acee Lindem To: RFC Editor Thread-Topic: [Technical Errata Reported] RFC2328 (4022) Thread-Index: AQHPj3u1QlnJECDid0mXvnC7YugMCJuA+FYA Date: Tue, 24 Jun 2014 20:23:17 +0000 Message-ID: References: <20140624071113.B6A8918001B@rfc-editor.org> In-Reply-To: <20140624071113.B6A8918001B@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-ID: <6BE9684503EF3E4E9FB1EEFBA0FE2615@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyuXRPgq5P18pgg00rWS1+9Nxgtvj08BKz xeGDs9gser/HWEycK2PRcu8eu0XT/q9sDuwe/1ZvY/aY8nsjq8fOWXfZPZYs+cnksWLzSkaP hrZjrAFsUVw2Kak5mWWpRfp2CVwZ23/MZy7YJV6x9MRdpgbG80JdjJwcEgImErcbH7JB2GIS F+6tB7K5OIQEjjJKTJx0iwXCWc4ocX/+fkaQKjYBHYnnj/4xg9giAloSJ7YfYQWxmQWeM0qc WZ8CYgsLmEu0NvxjgaixkGicdIoRwjaS2HD4KVgvi4CqxOw3b8FqeAXsJabu+AY0hwNombnE /EVpIGFOoNbrn16xg9iMQMd9P7WGCWKVuMStJ/OZII4WkFiy5zwzhC0q8fLxP1YIW0ni4+/5 7BD1OhILdn9ig7CtJWZNWAwV15ZYtvA1M8QJghInZz5hmcAoPgvJillI2mchaZ+FpH0WkvYF jKyrGDlKi1PLctONDDcxAmP1mASb4w7GBZ8sDzEKcDAq8fAq+KwMFmJNLCuuzD3EKM3BoiTO q1k9L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY0fri1kzvxRK+8zraxZ/9684Wf9Pvdeh DuMElxAhjs6CjvAIMc2tltHsbtJ3nu86OslUft7LJRd7z3hab3998cfWNdKyFYJP6kV+q0xr awloauVd8+vbh9cHTe+5Pzrvv19eacr9+O5nDWJvuUoPJk2d5/yCa+rJ4st3trwtt97K1adp b7T1jBJLcUaioRZzUXEiABsfkNy2AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/YjfMuM_N7yeb5BFy7u4lfQzBfUU Cc: "jmoy@casc.com" , "alexander.okonnikov@gmail.com" , OSPF List Subject: Re: [OSPF] [Technical Errata Reported] RFC2328 (4022) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 20:23:31 -0000 Hi Alia,=20 As long as you are verifying these, I agree with Errata as well. Thanks, Acee On Jun 24, 2014, at 3:11 AM, RFC Errata System = wrote: > The following errata report has been submitted for RFC2328, > "OSPF Version 2". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D2328&eid=3D4022 >=20 > -------------------------------------- > Type: Technical > Reported by: Alexander Okonnikov >=20 > Section: 10.5 >=20 > Original Text > ------------- > When receiving an Hello Packet from a neighbor on a broadcast, > Point-to-MultiPoint or NBMA network, set the neighbor > structure's Neighbor ID equal to the Router ID found in the > packet's OSPF header. For these network types, the neighbor > structure's Router Priority field, Neighbor's Designated Router > field, and Neighbor's Backup Designated Router field are also > set equal to the corresponding fields found in the received > Hello Packet; changes in these fields should be noted for > possible use in the steps below. When receiving an Hello on a > point-to-point network (but not on a virtual link) set the > neighbor structure's Neighbor IP address to the packet's IP > source address. >=20 > Corrected Text > -------------- > When receiving an Hello Packet from a neighbor on a broadcast, > Point-to-MultiPoint or NBMA network, set the neighbor > structure's Neighbor ID equal to the Router ID found in the > packet's OSPF header. For broadcast and NBMA network types, the neighbor > structure's Router Priority field, Neighbor's Designated Router > field, and Neighbor's Backup Designated Router field are also > set equal to the corresponding fields found in the received > Hello Packet; changes in these fields should be noted for > possible use in the steps below. When receiving an Hello on a > point-to-point network (but not on a virtual link) set the > neighbor structure's Neighbor IP address to the packet's IP > source address. >=20 > Notes > ----- > This is unnecessary in case of Point-to-MultiPoint network type to hold n= eighbor's Router Priority, DR, and BDR values. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC2328 (no draft string recorded) > -------------------------------------- > Title : OSPF Version 2 > Publication Date : April 1998 > Author(s) : J. Moy > Category : INTERNET STANDARD > Source : Open Shortest Path First IGP > Area : Routing > Stream : IETF > Verifying Party : IESG From nobody Tue Jun 24 13:24:24 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3901B282C for ; Tue, 24 Jun 2014 13:24:20 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hofDUr2tMUqy for ; Tue, 24 Jun 2014 13:24:17 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC06A1B282A for ; Tue, 24 Jun 2014 13:24:07 -0700 (PDT) Received: by mail-yk0-f178.google.com with SMTP id q9so522745ykb.37 for ; Tue, 24 Jun 2014 13:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aOANAwSDj5fL8TYFKRKCWNEoLldUaAjucXOI3gSxRJc=; b=JBGL+elM+110qLriYfXdxipcp5Yc5z4/DM1An7ddv+tsLJIvT5bejbUeZilXs85BDZ bmEwrc4boT+M02EB9/XFy0I0i1Bdpv/w0PzJsaHVqcTIGrXD9UdCvOUZQ9smNjpF12XI EhRRMfgPRwyAE3bQ61ivIAGWom5uioNPcXvD45yv9aFaB3+alFtL+ojxzfcQ8UP+XZH9 I0i85w9nji2iMnQIpel1VMAJ7Ei8EkJJWq8J3NRVviUhb6WKFc9gzKVrJK2KppHaFRz0 Oubv4WvWCWBEVyuYyXdA7JnyRgbHBgiPvGpsUV/Vi5bsZO6opggkNFVJbvlid7kSkoPW xRFg== MIME-Version: 1.0 X-Received: by 10.236.150.205 with SMTP id z53mr4673345yhj.75.1403641447186; Tue, 24 Jun 2014 13:24:07 -0700 (PDT) Received: by 10.170.58.10 with HTTP; Tue, 24 Jun 2014 13:24:07 -0700 (PDT) In-Reply-To: References: <20140624071113.B6A8918001B@rfc-editor.org> Date: Tue, 24 Jun 2014 16:24:07 -0400 Message-ID: From: Alia Atlas To: Acee Lindem Content-Type: multipart/alternative; boundary=20cf303a2d61da0ac304fc9abdd4 Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/y4f_8N59huanfEdqnyUsajqztHY Cc: "jmoy@casc.com" , "alexander.okonnikov@gmail.com" , OSPF List , RFC Editor Subject: Re: [OSPF] [Technical Errata Reported] RFC2328 (4022) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 20:24:20 -0000 --20cf303a2d61da0ac304fc9abdd4 Content-Type: text/plain; charset=UTF-8 Thanks! On Tue, Jun 24, 2014 at 4:23 PM, Acee Lindem wrote: > Hi Alia, > As long as you are verifying these, I agree with Errata as well. > Thanks, > Acee > > On Jun 24, 2014, at 3:11 AM, RFC Errata System > wrote: > > > The following errata report has been submitted for RFC2328, > > "OSPF Version 2". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=2328&eid=4022 > > > > -------------------------------------- > > Type: Technical > > Reported by: Alexander Okonnikov > > > > Section: 10.5 > > > > Original Text > > ------------- > > When receiving an Hello Packet from a neighbor on a broadcast, > > Point-to-MultiPoint or NBMA network, set the neighbor > > structure's Neighbor ID equal to the Router ID found in the > > packet's OSPF header. For these network types, the neighbor > > structure's Router Priority field, Neighbor's Designated Router > > field, and Neighbor's Backup Designated Router field are also > > set equal to the corresponding fields found in the received > > Hello Packet; changes in these fields should be noted for > > possible use in the steps below. When receiving an Hello on a > > point-to-point network (but not on a virtual link) set the > > neighbor structure's Neighbor IP address to the packet's IP > > source address. > > > > Corrected Text > > -------------- > > When receiving an Hello Packet from a neighbor on a broadcast, > > Point-to-MultiPoint or NBMA network, set the neighbor > > structure's Neighbor ID equal to the Router ID found in the > > packet's OSPF header. For broadcast and NBMA network types, the neighbor > > structure's Router Priority field, Neighbor's Designated Router > > field, and Neighbor's Backup Designated Router field are also > > set equal to the corresponding fields found in the received > > Hello Packet; changes in these fields should be noted for > > possible use in the steps below. When receiving an Hello on a > > point-to-point network (but not on a virtual link) set the > > neighbor structure's Neighbor IP address to the packet's IP > > source address. > > > > Notes > > ----- > > This is unnecessary in case of Point-to-MultiPoint network type to hold > neighbor's Router Priority, DR, and BDR values. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC2328 (no draft string recorded) > > -------------------------------------- > > Title : OSPF Version 2 > > Publication Date : April 1998 > > Author(s) : J. Moy > > Category : INTERNET STANDARD > > Source : Open Shortest Path First IGP > > Area : Routing > > Stream : IETF > > Verifying Party : IESG > > --20cf303a2d61da0ac304fc9abdd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks!


On Tue, Jun 24, 2014 at 4:23 PM, Acee Lindem <acee= .lindem@ericsson.com> wrote:
Hi Alia,
As long as you are verifying these, I agree with Errata as well.
Thanks,
Acee

On Jun 24, 2014, at 3:11 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:

> The following errata report has been submitted for RFC2328,
> "OSPF Version 2".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?r= fc=3D2328&eid=3D4022
>
> --------------------------------------
> Type: Technical
> Reported by: Alexander Okonnikov <alexander.okonnikov@gmail.com>
>
> Section: 10.5
>
> Original Text
> -------------
> When receiving an Hello Packet from a neighbor on a broadcast,
> Point-to-MultiPoint or NBMA network, set the neighbor
> structure's Neighbor ID equal to the Router ID found in the
> packet's OSPF header. For these network types, the neighbor
> structure's Router Priority field, Neighbor's Designated Route= r
> field, and Neighbor's Backup Designated Router field are also
> set equal to the corresponding fields found in the received
> Hello Packet; changes in these fields should be noted for
> possible use in the steps below. When receiving an Hello on a
> point-to-point network (but not on a virtual link) set the
> neighbor structure's Neighbor IP address to the packet's IP > source address.
>
> Corrected Text
> --------------
> When receiving an Hello Packet from a neighbor on a broadcast,
> Point-to-MultiPoint or NBMA network, set the neighbor
> structure's Neighbor ID equal to the Router ID found in the
> packet's OSPF header. For broadcast and NBMA network types, the ne= ighbor
> structure's Router Priority field, Neighbor's Designated Route= r
> field, and Neighbor's Backup Designated Router field are also
> set equal to the corresponding fields found in the received
> Hello Packet; changes in these fields should be noted for
> possible use in the steps below. When receiving an Hello on a
> point-to-point network (but not on a virtual link) set the
> neighbor structure's Neighbor IP address to the packet's IP > source address.
>
> Notes
> -----
> This is unnecessary in case of Point-to-MultiPoint network type to hol= d neighbor's Router Priority, DR, and BDR values.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary,= please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC2328 (no draft string recorded)
> --------------------------------------
> Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : OSPF Version = 2
> Publication Date =C2=A0 =C2=A0: April 1998
> Author(s) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : J. Moy
> Category =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: INTERNET STANDARD<= br> > Source =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Open Shortest= Path First IGP
> Area =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Routing<= br> > Stream =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: IETF
> Verifying Party =C2=A0 =C2=A0 : IESG


--20cf303a2d61da0ac304fc9abdd4-- From nobody Tue Jun 24 13:25:22 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D556D1B2827; Tue, 24 Jun 2014 13:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5_TQu0D7vRl; Tue, 24 Jun 2014 13:24:56 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBF21B27E4; Tue, 24 Jun 2014 13:24:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 097BF180203; Tue, 24 Jun 2014 13:23:22 -0700 (PDT) To: alexander.okonnikov@gmail.com, jmoy@casc.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140624202322.097BF180203@rfc-editor.org> Date: Tue, 24 Jun 2014 13:23:22 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/5AGBGCeuCFHKDUF2S7qCQ3pJyX0 Cc: ospf@ietf.org, akatlas@juniper.net, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] [Errata Verified] RFC2328 (4022) X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 20:25:02 -0000 The following errata report has been verified for RFC2328, "OSPF Version 2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2328&eid=4022 -------------------------------------- Status: Verified Type: Technical Reported by: Alexander Okonnikov Date Reported: 2014-06-23 Verified by: Alia Atlas (IESG) Section: 10.5 Original Text ------------- When receiving an Hello Packet from a neighbor on a broadcast, Point-to-MultiPoint or NBMA network, set the neighbor structure's Neighbor ID equal to the Router ID found in the packet's OSPF header. For these network types, the neighbor structure's Router Priority field, Neighbor's Designated Router field, and Neighbor's Backup Designated Router field are also set equal to the corresponding fields found in the received Hello Packet; changes in these fields should be noted for possible use in the steps below. When receiving an Hello on a point-to-point network (but not on a virtual link) set the neighbor structure's Neighbor IP address to the packet's IP source address. Corrected Text -------------- When receiving an Hello Packet from a neighbor on a broadcast, Point-to-MultiPoint or NBMA network, set the neighbor structure's Neighbor ID equal to the Router ID found in the packet's OSPF header. For broadcast and NBMA network types, the neighbor structure's Router Priority field, Neighbor's Designated Router field, and Neighbor's Backup Designated Router field are also set equal to the corresponding fields found in the received Hello Packet; changes in these fields should be noted for possible use in the steps below. When receiving an Hello on a point-to-point network (but not on a virtual link) set the neighbor structure's Neighbor IP address to the packet's IP source address. Notes ----- This is unnecessary in case of Point-to-MultiPoint network type to hold neighbor's Router Priority, DR, and BDR values. -------------------------------------- RFC2328 (no draft string recorded) -------------------------------------- Title : OSPF Version 2 Publication Date : April 1998 Author(s) : J. Moy Category : INTERNET STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Jun 30 03:19:33 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C3D1A01E2 for ; Mon, 30 Jun 2014 03:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ztgx8afNKPqg for ; Mon, 30 Jun 2014 03:19:28 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DE461A01E0 for ; Mon, 30 Jun 2014 03:19:27 -0700 (PDT) Received: from BY2PR05MB127.namprd05.prod.outlook.com (10.242.38.24) by DM2PR05MB448.namprd05.prod.outlook.com (10.141.104.152) with Microsoft SMTP Server (TLS) id 15.0.974.11; Mon, 30 Jun 2014 10:19:25 +0000 Received: from BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.129]) by BY2PR05MB127.namprd05.prod.outlook.com ([169.254.6.129]) with mapi id 15.00.0974.002; Mon, 30 Jun 2014 10:19:24 +0000 From: Shraddha Hegde To: "ospf@ietf.org" Thread-Topic: New Version Notification for draft-hegde-ospf-node-admin-tag-02.txt Thread-Index: AQHPkcu47E613GxH6kGiDzo9mTxN45uJc4cQ Date: Mon, 30 Jun 2014 10:19:23 +0000 Message-ID: <6279db1e0aba4d1e868e46334f0408b5@BY2PR05MB127.namprd05.prod.outlook.com> References: <20140627055029.11540.67650.idtracker@ietfa.amsl.com> In-Reply-To: <20140627055029.11540.67650.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [116.197.184.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0258E7CCD4 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(199002)(189002)(377424004)(377454003)(99286002)(95666004)(80022001)(66066001)(81542001)(31966008)(74662001)(74502001)(92566001)(79102001)(76482001)(77982001)(4396001)(85306003)(77096002)(46102001)(76576001)(76176999)(54356999)(83322001)(19580405001)(19580395003)(64706001)(74316001)(106116001)(106356001)(105586002)(107046002)(2351001)(50986999)(99396002)(20776003)(86362001)(81342001)(101416001)(83072002)(85852003)(87936001)(2656002)(21056001)(15202345003)(15975445006)(33646001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB448; H:BY2PR05MB127.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/y_9gSt4Uhyf2qhQKAHMRVqDT9VM Cc: "rob.shakir@bt.com" Subject: [OSPF] FW: New Version Notification for draft-hegde-ospf-node-admin-tag-02.txt X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jun 2014 10:19:30 -0000 QWNlZS9XRywNCg0KQW4gdXBkYXRlZCB2ZXJzaW9uIG9mIHRoZSBPU1BGIG5vZGUgYWRtaW4gdGFn IGhhcyBiZWVuIHB1Ymxpc2hlZC4NCg0KQWxsIHRoZSBjb21tZW50cyByZWNlaXZlZCBzbyBmYXIg aGF2ZSBiZWVuIGFkZHJlc3NlZC4NCkkgd291bGQgbGlrZSB0byBhc2sgZm9yIHRoZSBXRyBhZG9w dGlvbiBvZiB0aGUgZHJhZnQgY29uc2lkZXJpbmcNCg0KLSBDb25zZW5zdXMgYmV0d2VlbiBtdWx0 aXBsZSB2ZW5kb3JzIC0gKHBscyBzZWUgdGhlIGF1dGhvcidzIGxpc3QpDQotIFRoZSBkcmFmdCB3 YXMgcHJlc2VudGVkIGluIGxhc3QgSUVURiBpbiBPU1BGIFdHDQoNClRoYW5rcw0KU2hyYWRkaGEN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXksIEp1 bmUgMjcsIDIwMTQgMTE6MjAgQU0NClRvOiBTaHJhZGRoYSBIZWdkZTsgQW50b24gU21pcm5vdjsg QW50b24gU21pcm5vdjsgWmhlbmJpbiBMaTsgTGkgWmhlbmJpbjsgUm9iIFNoYWtpcjsgSGFubmVz IEdyZWRsZXI7IFNocmFkZGhhIEhlZ2RlOyBIYXJpc2ggUmFnaHV2ZWVyOyBSb2IgU2hha2lyOyBI YXJpc2ggUmFnaHV2ZWVyOyBIYW5uZXMgR3JlZGxlcg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1oZWdkZS1vc3BmLW5vZGUtYWRtaW4tdGFnLTAyLnR4dA0KDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1oZWdkZS1vc3BmLW5vZGUtYWRtaW4tdGFnLTAy LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTaHJhZGRoYSBIZWdkZSBh bmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1oZWdkZS1v c3BmLW5vZGUtYWRtaW4tdGFnDQpSZXZpc2lvbjoJMDINClRpdGxlOgkJQWR2ZXJ0aXNpbmcgcGVy LW5vZGUgYWRtaW5pc3RyYXRpdmUgdGFncyBpbiBPU1BGDQpEb2N1bWVudCBkYXRlOgkyMDE0LTA2 LTI2DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMQ0KVVJMOiAgICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhlZ2RlLW9z cGYtbm9kZS1hZG1pbi10YWctMDIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaGVnZGUtb3NwZi1ub2RlLWFkbWluLXRhZy8NCkh0bWxp emVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oZWdkZS1vc3BmLW5v ZGUtYWRtaW4tdGFnLTAyDQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaGVnZGUtb3NwZi1ub2RlLWFkbWluLXRhZy0wMg0KDQpBYnN0cmFjdDoN CiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIGV4dGVuc2lvbiB0byBPU1BGIHByb3RvY29s IFtSRkMyMzI4XSB0bw0KICAgYWRkIGFuIG9wdGlvbmFsIG9wZXJhdGlvbmFsIGNhcGFiaWxpdHks IHRoYXQgYWxsb3dzIHRhZ2dpbmcgYW5kDQogICBncm91cGluZyBvZiB0aGUgbm9kZXMgaW4gYW4g T1NQRiBkb21haW4uICBUaGlzIGFsbG93cw0KICAgc2ltcGxpZmljYXRpb24sZWFzZSBvZiBtYW5h Z2VtZW50IGFuZCBjb250cm9sIG92ZXIgcm91dGUgYW5kIHBhdGgNCiAgIHNlbGVjdGlvbiBiYXNl ZCBvbiBjb25maWd1cmVkIHBvbGljaWVzLg0KDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0 aGUgcHJvdG9jb2wgZXh0ZW5zaW9ucyB0byBkaXNzZW1pbmF0ZSBwZXItDQogICBub2RlIGFkbWlu LXRhZ3MgdG8gdGhlIE9TUEZ2MiBhbmQgT1NQRnYzIHByb3RvY29sLg0KDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Mon Jun 30 17:45:30 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0101A0058 for ; Mon, 30 Jun 2014 17:45:27 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abg9FeVikcP1 for ; Mon, 30 Jun 2014 17:45:26 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283E21A0061 for ; Mon, 30 Jun 2014 17:45:26 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-7c-53b1b067ef1c Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F4.CA.25146.760B1B35; Mon, 30 Jun 2014 20:45:59 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Mon, 30 Jun 2014 20:45:23 -0400 From: Acee Lindem To: OSPF - OSPF WG List Thread-Topic: IETF 90 - OSPF WG Agenda Requests Thread-Index: AQHPlMW9vc/XyAkfkE2hLS+Ldhuu5A== Date: Tue, 1 Jul 2014 00:45:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_CFD752B732063aceelindemericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyuXRPiG76ho3BBpcPKVq03LvH7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujG07JjMXLOGquHg8poHxJUcXIyeHhICJxPUpC9khbDGJC/fW s3UxcnEICRxllJhx8wQ7hLOcUWL/2eOsIFVsAjoSzx/9YwaxRQTUJVZP3g0WFxbQkljY/J4F Iq4v8fzbMnYIW0+i490lsBoWARWJ7q8/mUBsXgFTidf3OsFqGIE2fz+1BizOLCAucevJfCaI iwQkluw5zwxhi0q8fPwPbI4o0MzmrjeMEHEliTmvrwHVcAD1Rkk0fzaAGC8ocXLmE5YJjMKz kEydhVA1C0kVRImBxPtz85khbG2JZQtfQ9n6Ehu/nGWEsK0llix6xoqsZgEjxypGjtLi1LLc dCPDTYzAKDkmwea4g3HBJ8tDjAIcjEo8vAqmG4OFWBPLiitzDzFKc7AoifNqVs8LFhJITyxJ zU5NLUgtii8qzUktPsTIxMEp1cCoHLtDSJdj3c3vc/++beIMEn3cn35B+VH+RkHt/yv/5vp2 b5zFLRTYvig0u/H5hIeKlt7SnR8N5gerGt7V+pqv9GDK29gbp6ZOEBCaE60r9apIZgrjnopb E985f+KQOv/6paToG5e96m9SXOTyDN5dTr5fXx7ktaSxjDNXzzZtltPB2kMTkzcqsRRnJBpq MRcVJwIAyU/1N3MCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/RgzNQ3gqP21x9hah_FNkbe4JMU8 Subject: [OSPF] IETF 90 - OSPF WG Agenda Requests X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2014 00:45:28 -0000 --_000_CFD752B732063aceelindemericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable We will be meeting in Toronto from 13:00 =96 15:00 CDT on Monday, July 21st= , 2014. Please send agenda requests to Abhay and myself. Note that if we ha= ve already discussed presentation of your draft at IETF 90, you are already= on the agenda. Thanks, Abhay and Acee --_000_CFD752B732063aceelindemericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <91239830C2039D418D3164AEB4F65424@ericsson.com> Content-Transfer-Encoding: quoted-printable
We will be meeting in Toronto from 13:00 =96 15:00 CDT on Monday, July= 21st, 2014. Please send agenda requests to Abhay and myself. Note that if = we have already discussed presentation of your draft at IETF 90, you are al= ready on the agenda. 
Thanks,
Abhay and Acee 
--_000_CFD752B732063aceelindemericssoncom_-- From nobody Mon Jun 30 17:54:13 2014 Return-Path: X-Original-To: ospf@ietfa.amsl.com Delivered-To: ospf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284D41A0064 for ; Mon, 30 Jun 2014 17:54:12 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HR04RyKT0Ozk for ; Mon, 30 Jun 2014 17:54:10 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD00D1A0058 for ; Mon, 30 Jun 2014 17:54:10 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-5f-53b1b4e22bbe Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 9D.FB.05330.2E4B1B35; Mon, 30 Jun 2014 21:05:07 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Mon, 30 Jun 2014 20:54:09 -0400 From: Acee Lindem To: OSPF - OSPF WG List Thread-Topic: [OSPF] IETF 90 - OSPF WG Agenda Requests Thread-Index: AQHPlMb2bTvD0/7WH0myLctHEz/ssQ== Date: Tue, 1 Jul 2014 00:54:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_CFD7548932075aceelindemericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyuXSPn+7jLRuDDTo38Fq03LvH7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPndPAWPxSou3P7K1MB4TbiLkZNDQsBEovHkVkYIW0ziwr31 bCC2kMBRRol3E2y6GLmA7OWMEpd3zWQHSbAJ6Eg8f/SPGcQWEVCXWD15NyuILSxgKrF+4lNG iLiZxMRHvawQtp7E7JmzweIsAioSs363gfXyAtW/3fodrIYRaPH3U2uYQGxmAXGJW0/mM0Ec JCCxZM95ZghbVOLl439g9aJAM5u73kAdrSTx8fd8dojeKIlVPVfYIOYLSpyc+YRlAqPwLCRj ZyEpm4WkDCJuIPH+3HxmCFtbYtnC11C2vsTGL2cZIWxribeHG1HULGDkWMXIUVqcWpabbmSw iREYJ8ck2HR3MO55aXmIUYCDUYmHV8F0Y7AQa2JZcWXuIUZpDhYlcd5ZtfOChQTSE0tSs1NT C1KL4otKc1KLDzEycXBKNTC6fc54uy9qz6tXb95l7dga9VElN1f3bMpS5zkfnm3+yG75QWxX bBE/g6fA3s0iwmbVyXLx71ecvCAWx/Fuakg5Y1vccqcVGzaoPu9ZlddfP4/37Lq8OoY4jf+b lsy+wfZs6g63xa8ueH+b+EUgzo3fbeKuw487DO3W/lkuFmtm/nUTm16S1dN8JZbijERDLeai 4kQAZ7FW53QCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/8xrWm9ryMIARuj7OeAk9Nzmd5dE Subject: Re: [OSPF] IETF 90 - OSPF WG Agenda Requests X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2014 00:54:12 -0000 --_000_CFD7548932075aceelindemericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable That=92s EDT time of course - At least I won=92t be jet lagged ;^) Acee From: Ericsson > Date: Monday, June 30, 2014 at 5:45 PM To: OSPF - OSPF WG List > Subject: [OSPF] IETF 90 - OSPF WG Agenda Requests We will be meeting in Toronto from 13:00 =96 15:00 CDT on Monday, July 21st= , 2014. Please send agenda requests to Abhay and myself. Note that if we ha= ve already discussed presentation of your draft at IETF 90, you are already= on the agenda. Thanks, Abhay and Acee --_000_CFD7548932075aceelindemericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <20A53603C287C74C987E5D2DA0C87BA0@ericsson.com> Content-Transfer-Encoding: quoted-printable
That=92s EDT time of course - At least I won=92t be jet lagged ;^)&nbs= p;
Acee

From: Ericsson <acee.lindem@ericsson.com>
Date: Monday, June 30, 2014 at 5:45= PM
To: OSPF - OSPF WG List <ospf@ietf.org>
Subject: [OSPF] IETF 90 - OSPF WG A= genda Requests

We will be meeting in Toronto from 13:00 =96 15:00 CDT on Monday, July= 21st, 2014. Please send agenda requests to Abhay and myself. Note that if = we have already discussed presentation of your draft at IETF 90, you are al= ready on the agenda. 
Thanks,
Abhay and Acee 
 --_000_CFD7548932075aceelindemericssoncom_--