From nobody Wed Nov 5 17:15:44 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6861A1A4F; Wed, 5 Nov 2014 17:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.495 X-Spam-Level: X-Spam-Status: No, score=-114.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 owG5kYy8BTXN; Wed, 5 Nov 2014 17:15:38 -0800 (PST) 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 861781A1A4B; Wed, 5 Nov 2014 17:15:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6648; q=dns/txt; s=iport; t=1415236538; x=1416446138; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=g3hP0e2gZtk6HuV/vcDDLxBcvcS5J3eiJizYysaKZUU=; b=W/xAq4rrbbeUe0nKgCFcGU18+hgM7FEo0XVLk6baCLugLGNUMJCxboal 9amVFn72QjbeSupNxZuBwGlGy2zNRmtIoHH2TsS/sVFem6/APDiog0T5+ EsoUtL4XbdUjE3WVJTlEV8nKP+xkf8BTc1qxExRthAbsduJtrqVpYYWM4 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0HAOrKWlStJV2P/2dsb2JhbABbgmsjVFQFBIMCySEMh0wCHIECFgEBAQEBfYQCAQEBBAEBASAROgsMBAIBBgIRAwEBAQMCBh0DAgICJQsUAQgIAgQBDQUIAYg4AQcFmiScX5UvAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EtjzMxBwaCcTaBHgWGN4lJgiGEUYhPPYMQiieHMoI0gURsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,322,1413244800"; d="scan'208";a="369738134" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP; 06 Nov 2014 01:15:37 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sA61FbVS016011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Nov 2014 01:15:37 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Wed, 5 Nov 2014 19:15:37 -0600 From: "Nobo Akiya (nobo)" To: Sriganesh Kini , "spring@ietf.org" , "mpls@ietf.org" Thread-Topic: [spring] Fwd: [mpls] I-D Action: draft-kini-mpls-spring-entropy-label-01.txt Thread-Index: AQHP3NbQqa8eO6s3fUqRAo2zXBulvpxS+agg Date: Thu, 6 Nov 2014 01:15:36 +0000 Message-ID: References: <20140930000500.7476.1694.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.125] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/snLvF5g9T28hdRvBVnGiDzqep94 Cc: "draft-kini-mpls-spring-entropy-label@tools.ietf.org" Subject: Re: [spring] Fwd: [mpls] I-D Action: draft-kini-mpls-spring-entropy-label-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 01:15:43 -0000 SGkgU3JpLCBldCBhbCwNCg0KVGhlIHVwZGF0ZSAoMDAgdG8gMDIpIGxvb2tzIGdyZWF0LCBtYW55 IHRoYW5rcyBmb3IgcHJvZ3Jlc3NpbmcgdGhpcyENCg0KSSd2ZSBmb2xsb3dlZCB0aGUgYWxnb3Jp dGhtIGRlc2NyaWJlZCBpbiB0aGUgRmlndXJlIDIgKFNlY3Rpb24gNCkgb2YgdGhlIGRvY3VtZW50 LiBJZiBJIHVuZGVyc3Rvb2QgdGhlIGFsZ29yaXRobSBjb3JyZWN0bHksIEkgdGhpbmsgaXQgaGFz IGxvZ2ljIGVycm9ycy4NCi0gTG9vcCBjb25kaXRpb24gaXMgaW5jb3JyZWN0Lg0KLSBUb3Agb2Yg dGhlIHN0YWNrIGJlaW5nIHJlYWNoZWQgYnV0IHN0aWxsIG5lZWRpbmcgdG8gaW5zZXJ0IEVMSS9F TCBzaW5jZSB3ZSBhcmUgb3V0c2lkZSBvZiBSTEQsIGlzIG5vdCB0YWtlbiBjYXJlIG9mLg0KDQpB ZGRpdGlvbmFsbHk6DQotIHdlIHNob3VsZCBjbGFyaXR5IHRoYXQgdGhlIGxvZ2ljIG11c3Qgbm90 IGJlIGZvbGxvd2VkIGlmIChSTEQgPD0gMikuDQotIGNsYXJpZnkgdGhhdCBpbnNlcnRpb24gb2Yg RUxJL0VMIGlzIGFmdGVyIHRoZSBsYWJlbCBwb2ludGVkIGJ5IHRoZSBjdXJyZW50IGluc2VydGlv biBwb2ludC4NCi0gImNhbiBwdXNoIG1vcmUgbGFiZWxzIiBzaG91bGQgYmUgY2xhcmlmaWVkIGFz ICJjYW4gcHVzaCAyIG9yIG1vcmUgbGFiZWxzIi4NCg0KQmVsb3cgaXMgYSBzdWdnZXN0ZWQgYWxn b3JpdGhtIHVwZGF0ZSB0aGF0IGFkZHJlc3NlcyB0aGUgcG9pbnRzIGFib3ZlLg0KDQpbT0xEXQ0K ICAgICBJbml0aWFsaXplIHRoZSBjdXJyZW50IEVMIGluc2VydGlvbiBwb2ludCB0byB0aGUNCiAg ICAgICBib3R0b21tb3N0IGxhYmVsIGluIHRoZSBzdGFjayB0aGF0IGlzIEVMLWNhcGFibGUNCiAg ICAgd2hpbGUgbG9jYWwtbm9kZSBjYW4gcHVzaCBtb3JlIGxhYmVscyBPUg0KICAgICAgIHRvcCBv ZiBzdGFjayBoYXMgYmVlbiByZWFjaGVkIHsNCiAgICAgICAgIGluc2VydCBhbiBFTEkrRUwgYXQg Y3VycmVudCBpbnNlcnRpb24gcG9pbnQNCiAgICAgICAgIG1vdmUgaW5zZXJ0aW9uIHBvaW50IHVw IHVudGlsIGN1cnJlbnQgRUwgaXMgb3V0IG9mIFJMRA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEFORA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGluc2VydGlvbiBwb2ludCBpcyBFTC1jYXBhYmxlDQogICAgICAgICBzZXQgY3VycmVu dCBpbnNlcnRpb24gcG9pbnQgdG8gbmV3IGluc2VydGlvbiBwb2ludA0KICAgICB9DQoNCltORVdd DQogICAgIGlmIChSTEQgPiAyKSB7DQogICAgICAgaW5pdGlhbGl6ZSB0aGUgY3VycmVudCBpbnNl cnRpb24gcG9pbnQgdG8gdGhlDQogICAgICAgICBib3R0b21tb3N0IGxhYmVsIGluIHRoZSBzdGFj ayB0aGF0IGlzIEVMLWNhcGFibGUNCiAgICAgICBkbyB7DQogICAgICAgICBpbnNlcnQgYW4gRUxJ K0VMIGFmdGVyIHRoZSBsYWJlbCBwb2ludGVkIGJ5IHRoZSBjdXJyZW50DQogICAgICAgICAgIGlu c2VydGlvbiBwb2ludA0KICAgICAgICAgbW92ZSBpbnNlcnRpb24gcG9pbnQgdXAgdW50aWwgaW5z ZXJ0ZWQgRUwgaXMgb3V0IG9mIFJMRA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEFORA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlu c2VydGlvbiBwb2ludCBpcyBFTC1jYXBhYmxlDQogICAgICAgICBpZiBpbnNlcnRpb24gcG9pbnQg d2FzIG5vdCB1cGRhdGVkIGR1ZSB0byByZWFjaGluZyB0b3Agb2YNCiAgICAgICAgICAgdGhlIHN0 YWNrLCBicmVhayBvdXQgZnJvbSB0aGUgbG9vcA0KICAgICAgICAgZWxzZSBzZXQgY3VycmVudCBp bnNlcnRpb24gcG9pbnQgdG8gbmV3IGluc2VydGlvbiBwb2ludA0KICAgICAgIH0gd2hpbGUgbG9j YWwtbm9kZSBjYW4gcHVzaCAyIG9yIG1vcmUgbGFiZWxzDQogICAgIH0gZWxzZSB7DQogICAgICAg aW5zZXJ0IGFuIEVMSStFTCBhZnRlciB0aGUgYm90dG9tbW9zdCBsYWJlbCBpbiB0aGUgc3RhY2sN CiAgICAgICAgIHRoYXQgaXMgRUwtY2FwYWJsZQ0KICAgICB9DQoNClRoYW5rcyENCg0KLU5vYm8N Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzcHJpbmcgW21haWx0bzpz cHJpbmctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNyaWdhbmVzaCBLaW5pDQo+IFNl bnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAzMCwgMjAxNCAxOjQ4IFBNDQo+IFRvOiBzcHJpbmdAaWV0 Zi5vcmc7IG1wbHNAaWV0Zi5vcmcNCj4gQ2M6IGRyYWZ0LWtpbmktbXBscy1zcHJpbmctZW50cm9w eS1sYWJlbEB0b29scy5pZXRmLm9yZw0KPiBTdWJqZWN0OiBbc3ByaW5nXSBGd2Q6IFttcGxzXSBJ LUQgQWN0aW9uOiBkcmFmdC1raW5pLW1wbHMtc3ByaW5nLWVudHJvcHktDQo+IGxhYmVsLTAxLnR4 dA0KPiANCj4gRllJDQo+IA0KPiBDb21tZW50cyB3ZWxjb21lLg0KPiANCj4gU3JpDQo+IA0KPiAt LS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCj4gRnJvbTogPGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZz4NCj4gRGF0ZTogTW9uLCBTZXAgMjksIDIwMTQgYXQgNTowNSBQTQ0K PiBTdWJqZWN0OiBbbXBsc10gSS1EIEFjdGlvbjogZHJhZnQta2luaS1tcGxzLXNwcmluZy1lbnRy b3B5LWxhYmVsLTAxLnR4dA0KPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+IENjOiBtcGxz QGlldGYub3JnDQo+IA0KPiANCj4gDQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJs ZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPiBkaXJlY3Rvcmllcy4NCj4gwqBU aGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRj aGluZyBXb3JraW5nDQo+IEdyb3VwIG9mIHRoZSBJRVRGLg0KPiANCj4gwqAgwqAgwqAgwqAgVGl0 bGXCoCDCoCDCoCDCoCDCoCDCoDogRW50cm9weSBsYWJlbHMgZm9yIHNvdXJjZSByb3V0ZWQgc3Rh Y2tlZCB0dW5uZWxzDQo+IMKgIMKgIMKgIMKgIEF1dGhvcnPCoCDCoCDCoCDCoCDCoDogU3JpZ2Fu ZXNoIEtpbmkNCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgS2lyZWV0 aSBLb21wZWxsYQ0KPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTaXZh IFNpdmFiYWxhbg0KPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTdGVw aGFuZSBMaXRrb3dza2kNCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg Um9iIFNoYWtpcg0KPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBYaWFv aHUgWHUNCj4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgV2ltIEhlbmRy aWNreA0KPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBKZWZmIFRhbnRz dXJhDQo+IMKgIMKgIMKgIMKgIEZpbGVuYW1lwqAgwqAgwqAgwqAgOiBkcmFmdC1raW5pLW1wbHMt c3ByaW5nLWVudHJvcHktbGFiZWwtMDEudHh0DQo+IMKgIMKgIMKgIMKgIFBhZ2VzwqAgwqAgwqAg wqAgwqAgwqA6IDEwDQo+IMKgIMKgIMKgIMKgIERhdGXCoCDCoCDCoCDCoCDCoCDCoCA6IDIwMTQt MDktMjkNCj4gDQo+IEFic3RyYWN0Og0KPiDCoCDCoFNvdXJjZSByb3V0ZWQgdHVubmVsIHN0YWNr aW5nIGlzIGEgdGVjaG5pcXVlIHRoYXQgY2FuIGJlIGxldmVyYWdlZCB0bw0KPiDCoCDCoHByb3Zp ZGUgYSBtZXRob2QgdG8gc3RlZXIgYSBwYWNrZXQgdGhyb3VnaCBhIGNvbnRyb2xsZWQgc2V0IG9m DQo+IMKgIMKgc2VnbWVudHMuwqAgVGhpcyBjYW4gYmUgYXBwbGllZCB0byB0aGUgTXVsdGkgUHJv dG9jb2wgTGFiZWwgU3dpdGNoaW5nDQo+IMKgIMKgKE1QTFMpIGRhdGEgcGxhbmUuwqAgRW50cm9w eSBsYWJlbCAoRUwpIGlzIGEgdGVjaG5pcXVlIHVzZWQgaW4gTVBMUyB0bw0KPiDCoCDCoGltcHJv dmUgbG9hZCBiYWxhbmNpbmcuwqAgVGhpcyBkb2N1bWVudCBleGFtaW5lcyBhbmQgZGVzY3JpYmVz IGhvdyBFTHMNCj4gwqAgwqBhcmUgdG8gYmUgYXBwbGllZCB0byBzb3VyY2Ugcm91dGVkIHN0YWNr ZWQgdHVubmVscy4NCj4gDQo+IA0KPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBm b3IgdGhpcyBkcmFmdCBpczoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQta2luaS1tcGxzLXNwcmluZy1lbnRyb3B5LWxhYmVsLw0KPiANCj4gVGhlcmUncyBhbHNvIGEg aHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWtpbmktbXBscy1zcHJpbmctZW50cm9weS1sYWJlbC0wMQ0KPiANCj4gQSBkaWZm IGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1raW5pLW1wbHMtc3ByaW5nLWVudHJvcHktbGFi ZWwtMDENCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0K PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6 DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtcGxzIG1haWxpbmcgbGlz dA0KPiBtcGxzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbXBscw0KDQo= From nobody Tue Nov 11 11:51:16 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1F51A8903; Tue, 11 Nov 2014 11:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 CHp9FtCfKIj8; Tue, 11 Nov 2014 11:51:10 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:731]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686971A88EF; Tue, 11 Nov 2014 11:51:09 -0800 (PST) Received: from CO2PR05MB732.namprd05.prod.outlook.com (10.141.228.22) by CO2PR05MB731.namprd05.prod.outlook.com (10.141.228.21) with Microsoft SMTP Server (TLS) id 15.1.16.15; Tue, 11 Nov 2014 19:50:45 +0000 Received: from CO2PR05MB732.namprd05.prod.outlook.com ([10.141.228.22]) by CO2PR05MB732.namprd05.prod.outlook.com ([10.141.228.22]) with mapi id 15.01.0016.006; Tue, 11 Nov 2014 19:50:45 +0000 From: John Scudder To: "Andrew G. Malis" , Clarence Filsfils , Stefano Previdi Thread-Topic: [RTG-DIR] Routing Directorate QA review of draft-filsfils-spring-segment-routing-04 Thread-Index: AQHP/ejI4nB3vvSMrUilpwRhvFZTig== Date: Tue, 11 Nov 2014 19:50:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB731; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB731; x-forefront-prvs: 0392679D18 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(377454003)(164054003)(189002)(377424004)(24454002)(16236675004)(20776003)(120916001)(107046002)(64706001)(99286002)(95666004)(15202345003)(106356001)(33656002)(62966003)(77156002)(105586002)(101416001)(106116001)(54356999)(36756003)(21056001)(50986999)(82746002)(66066001)(76176999)(15975445006)(87936001)(2656002)(31966008)(46102003)(19617315012)(19580405001)(40100003)(230783001)(92566001)(19580395003)(86362001)(92726001)(99396003)(122556002)(4396001)(97736003)(83716003)(104396001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB731; H:CO2PR05MB732.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_A7168924784D436594533DA23B318506junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/spring/IspR3NcCURDnfHDRn_a5oJQlNEc Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , "" , "draft-filsfils-spring-segment-routing@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [spring] [RTG-DIR] Routing Directorate QA review of draft-filsfils-spring-segment-routing-04 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 19:51:13 -0000 --_000_A7168924784D436594533DA23B318506junipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [re-sending from proper account] Andy, Thanks very much for doing this review. Authors, Can you please (at minimum) acknowledge that you've received Andy's comment= s and (preferably) respond to them, either by updating the draft or by disc= ussing them on the SPRING list? For what it's worth, I've read through Andy= 's review and agree with his points. Thanks, --John On Oct 6, 2014, at 12:02 PM, Andrew G. Malis > wrote: Hello, I have been selected as the Routing Directorate QA reviewer for https://too= ls.ietf.org/html/draft-filsfils-spring-segment-routing-04 . The Routing Directorate QA reviews are intended to improve the quality of R= TG Area documents as the pass through the IETF process. This is the QA review at the time of the WG document adoption poll. Document: draft-filsfils-spring-segment-routing-04.txt Reviewer: Andy Malis Review Date: 2014-10-06 Working Group Adoption Poll end date: Oct 8, 2014 Intended Status: Standards Track Please find the review at: http://trac.tools.ietf.org/area/rtg/trac/wiki/WG%20adoption%20QA%20review%2= 0draft-filsfils-spring-segment-routing Cheers, Andy --_000_A7168924784D436594533DA23B318506junipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable [re-sending from proper account]

Andy,

Thanks very much for doing this review.

Authors,

Can you please (at minimum) acknowledge that you've received Andy's co= mments and (preferably) respond to them, either by updating the draft or by= discussing them on the SPRING list? For what it's worth, I've read through= Andy's review and agree with his points.

Thanks,

--John

On Oct 6, 2014, at 12:02 PM, Andrew G. Malis <agmalis@gmail.com> wrote:

Hello,

I have been sel= ected as the Routing Directorate QA reviewer for https://tools.ietf.org/html/draft-filsfils-spring-= segment-routing-04 .

The Routing Dir= ectorate QA reviews are intended to improve = the quality of RTG Area documents as the pass through the IETF = process.=

This is the QA = review at the time of the WG document adoption poll.

Document: = draft-filsfils-spring-s= egment-routing-04.txt
Reviewer: Andy = Malis
Review Date: 20= 14-10-06
Working Group A= doption Poll end date: Oct 8, 2014
Intended Status= : Standards Track

Please find the= review at:

http://trac.tools.ietf.o= rg/area/rtg/trac/wiki/WG%20adoption%20QA%20review%20draft-filsfils-spring-s= egment-routing

Cheers,
Andy


--_000_A7168924784D436594533DA23B318506junipernet_-- From nobody Tue Nov 11 12:23:23 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4871A0ABD; Tue, 11 Nov 2014 12:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 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.594, 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 1JWpPjvFSi2J; Tue, 11 Nov 2014 12:23:19 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883451A014C; Tue, 11 Nov 2014 12:23:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7439; q=dns/txt; s=iport; t=1415737399; x=1416946999; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bO2XlkUYncTH2ynhxM3r3pHThpUhMSTJT3bafroDddM=; b=Mb5xgDepc3Fvu4QJlgh623Set9ym/9VI1WwluYq89AesHPQlv7GBF8XU kN8IJDhVBWdVMYxeSvVBPP6qcrXLVz0x+/XZ+d/OVKzsxGRyHf641bAGO JQjA3BdEiz+YZOJJfb7bIvRVaCfZDAwQW59jHK2eMb15ColWddlgCb1Cd g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAMluYlStJA2L/2dsb2JhbABcgkhGVFnKOYFyh0sCgRoWAQEBAQF9hAIBAQEEeQwEAgEIEQMBAgsdByERFAkIAgQBDQUIiCQDEg3IPQ2GbgEBAQEBAQEBAQEBAQEBAQEBAQEBAReOW4IIIA0EBgEGgyeBHgWQDoIjhFOFD4NGPYMSgzKHOoZxgjaBRGwBgkoBAQE X-IronPort-AV: E=Sophos;i="5.07,362,1413244800"; d="scan'208,217";a="371318471" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-8.cisco.com with ESMTP; 11 Nov 2014 20:23:18 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sABKNIDG018556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 20:23:18 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 14:23:18 -0600 From: "Stefano Previdi (sprevidi)" To: "agmalis@gmail.com" , "Clarence Filsfils (cfilsfil)" , "jgs42@me.com" Thread-Topic: [RTG-DIR] Routing Directorate QA review of draft-filsfils-spring-segment-routing-04 Thread-Index: AQHP/eh9mkKSxUkLuECuvPUxQUnJIJxb3taz Date: Tue, 11 Nov 2014 20:23:17 +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_E0A1DE675FEC854ABF07D319E556FE64467DDF0Cxmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/kUo2cTQ7-vG6gi51wqNgJfE2tQg Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , "spring-chairs@tools.ietf.org" , "draft-filsfils-spring-segment-routing@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [spring] [RTG-DIR] Routing Directorate QA review of draft-filsfils-spring-segment-routing-04 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 20:23:21 -0000 --_000_E0A1DE675FEC854ABF07D319E556FE64467DDF0Cxmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John, I already ack'ed Andrew' s comments and will address them asap. Thanks. s. -----Original Message----- From: John Scudder [jgs42@me.com] Received: Tuesday, 11 Nov 2014, 9:48 To: Andrew G. Malis [agmalis@gmail.com]; Clarence Filsfils (cfilsfil) [cfil= sfil@cisco.com]; Stefano Previdi (sprevidi) [sprevidi@cisco.com] CC: rtg-ads@tools.ietf.org [rtg-ads@tools.ietf.org]; rtg-dir@ietf.org [rtg-= dir@ietf.org]; spring@ietf.org [spring@ietf.org]; draft-filsfils-spring-seg= ment-routing@tools.ietf.org [draft-filsfils-spring-segment-routing@tools.ie= tf.org]; {spring-chairs@tools.ietf.org} [spring-chairs@tools.ietf.org] Subject: Re: [RTG-DIR] Routing Directorate QA review of draft-filsfils-spri= ng-segment-routing-04 Andy, Thanks very much for doing this review. Authors, Can you please (at minimum) acknowledge that you've received Andy's comment= s and (preferably) respond to them, either by updating the draft or by disc= ussing them on the SPRING list? For what it's worth, I've read through Andy= 's review and agree with his points. Thanks, --John On Oct 6, 2014, at 12:02 PM, Andrew G. Malis > wrote: Hello, I have been selected as the Routing Directorate QA reviewer for https://too= ls.ietf.org/html/draft-filsfils-spring-segment-routing-04 . The Routing Directorate QA reviews are intended to improve the quality of R= TG Area documents as the pass through the IETF process. This is the QA review at the time of the WG document adoption poll. Document: draft-filsfils-spring-segment-routing-04.txt Reviewer: Andy Malis Review Date: 2014-10-06 Working Group Adoption Poll end date: Oct 8, 2014 Intended Status: Standards Track Please find the review at: http://trac.tools.ietf.org/area/rtg/trac/wiki/WG%20adoption%20QA%20review%2= 0draft-filsfils-spring-segment-routing Cheers, Andy --_000_E0A1DE675FEC854ABF07D319E556FE64467DDF0Cxmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John,

I already ack'ed Andrew' s comments and will address them asap.

Thanks.

s.

-----Original Message-----
From: John Scudder [jgs42@me.com]
Received: Tuesday, 11 Nov 2014, 9:48
To: Andrew G. Malis [agmalis@gmail.com]; Clarence Filsfils (cfilsfil= ) [cfilsfil@cisco.com]; Stefano Previdi (sprevidi) [sprevidi@cisco.com]
CC: rtg-ads@tools.ietf.org [rtg-ads@tools.ietf.org]; rtg-dir@ietf.or= g [rtg-dir@ietf.org]; spring@ietf.org [spring@ietf.org]; draft-filsfils-spr= ing-segment-routing@tools.ietf.org [draft-filsfils-spring-segment-routing@t= ools.ietf.org]; {spring-chairs@tools.ietf.org} [spring-chairs@tools.ietf.org]
Subject: Re: [RTG-DIR] Routing Directorate QA review of draft-filsfi= ls-spring-segment-routing-04
Andy,

Thanks very much for doing this review.

Authors,

Can you please (at minimum) acknowledge that you've received Andy's co= mments and (preferably) respond to them, either by updating the draft or by= discussing them on the SPRING list? For what it's worth, I've read through= Andy's review and agree with his points.

Thanks,

--John

On Oct 6, 2014, at 12:02 PM, Andrew G. Malis <agmalis@gmail.com> wrote:

Hello,

I have been se= lected as the Routing Directorate QA reviewer for https://tools.ietf.org/html/draft-filsfils-spring= -segment-routing-04 .

The Routing Di= rectorate QA reviews are intended to improve= the quality of RTG Area documents as the pass through the IETF process.

This is the QA= review at the time of the WG document adoption poll.

Document: = ;draft-filsfils-spring-= segment-routing-04.txt
Reviewer: Andy= Malis
Review Date: 2= 014-10-06
Working Group = Adoption Poll end date: Oct 8, 2014
Intended Statu= s: Standards Track

Please find th= e review at:

http://trac.tools.ietf.o= rg/area/rtg/trac/wiki/WG%20adoption%20QA%20review%20draft-filsfils-spring-s= egment-routing

Cheers,
Andy


--_000_E0A1DE675FEC854ABF07D319E556FE64467DDF0Cxmbrcdx01ciscoc_-- From nobody Tue Nov 11 13:06:36 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564281AC437; Tue, 11 Nov 2014 13:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 41JrT-419eBx; Tue, 11 Nov 2014 13:06:31 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0774.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:774]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4201AC3FD; Tue, 11 Nov 2014 13:06:26 -0800 (PST) Received: from CO2PR05MB732.namprd05.prod.outlook.com (10.141.228.22) by CO2PR05MB729.namprd05.prod.outlook.com (10.141.228.12) with Microsoft SMTP Server (TLS) id 15.1.16.15; Tue, 11 Nov 2014 21:06:02 +0000 Received: from CO2PR05MB732.namprd05.prod.outlook.com ([10.141.228.22]) by CO2PR05MB732.namprd05.prod.outlook.com ([10.141.228.22]) with mapi id 15.01.0016.006; Tue, 11 Nov 2014 21:06:02 +0000 From: John Scudder To: "Stefano Previdi (sprevidi)" Thread-Topic: [spring] [RTG-DIR] Routing Directorate QA review of draft-filsfils-spring-segment-routing-04 Thread-Index: AQHP/fNMpfOVxS4pIkuqIIGATbq0jw== Date: Tue, 11 Nov 2014 21:06:02 +0000 Message-ID: <7F5E7CA6-98B5-4E3A-8A72-621F16636E23@juniper.net> References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.182.152] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB729; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB729; x-forefront-prvs: 0392679D18 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(13464003)(377454003)(189002)(199003)(164054003)(377424004)(24454002)(41574002)(31966008)(101416001)(110136001)(2656002)(76176999)(16236675004)(4396001)(21056001)(83716003)(86362001)(87936001)(46102003)(62966003)(77156002)(50986999)(19617315012)(97736003)(99396003)(54356999)(36756003)(120916001)(15202345003)(92566001)(33656002)(106356001)(106116001)(15975445006)(20776003)(64706001)(95666004)(99286002)(82746002)(105586002)(40100003)(107046002)(230783001)(92726001)(66066001)(122556002)(19580405001)(19580395003)(7059030)(104396001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB729; H:CO2PR05MB732.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_7F5E7CA698B54E3A8A72621F16636E23junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/spring/sR-XicPgcbiaoEMLdFwuL4MByPs Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , "Clarence Filsfils \(cfilsfil\)" , "rtg-ads@tools.ietf.org" , "agmalis@gmail.com" , "jgs42@me.com" , "draft-filsfils-spring-segment-routing@tools.ietf.org" , "spring-chairs@tools.ietf.org" Subject: Re: [spring] [RTG-DIR] Routing Directorate QA review of draft-filsfils-spring-segment-routing-04 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 21:06:33 -0000 --_000_7F5E7CA698B54E3A8A72621F16636E23junipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry I missed that -- thanks! --John On Nov 11, 2014, at 10:23 AM, Stefano Previdi (sprevidi) > wrote: Hi John, I already ack'ed Andrew' s comments and will address them asap. Thanks. s. -----Original Message----- From: John Scudder [jgs42@me.com] Received: Tuesday, 11 Nov 2014, 9:48 To: Andrew G. Malis [agmalis@gmail.com]; Clarence= Filsfils (cfilsfil) [cfilsfil@cisco.com]; Stefa= no Previdi (sprevidi) [sprevidi@cisco.com] CC: rtg-ads@tools.ietf.org [rtg-ads@tools.ie= tf.org]; rtg-dir@ietf.org [rtg-dir@ietf.org]; spring@ietf.org [spring@ietf.org]; draft-filsfils-= spring-segment-routing@tools.ietf.org [draft-filsfils-spring-segment-routing@tools.ietf.o= rg]; {spring-c= hairs@tools.ietf.org} [spring-chairs@t= ools.ietf.org] Subject: Re: [RTG-DIR] Routing Directorate QA review of draft-filsfils-spri= ng-segment-routing-04 Andy, Thanks very much for doing this review. Authors, Can you please (at minimum) acknowledge that you've received Andy's comment= s and (preferably) respond to them, either by updating the draft or by disc= ussing them on the SPRING list? For what it's worth, I've read through Andy= 's review and agree with his points. Thanks, --John On Oct 6, 2014, at 12:02 PM, Andrew G. Malis > wrote: Hello, I have been selected as the Routing Directorate QA reviewer for https://too= ls.ietf.org/html/draft-filsfils-spring-segment-routing-04 . The Routing Directorate QA reviews are intended to improve the quality of R= TG Area documents as the pass through the IETF process. This is the QA review at the time of the WG document adoption poll. Document: draft-filsfils-spring-segment-routing-04.txt Reviewer: Andy Malis Review Date: 2014-10-06 Working Group Adoption Poll end date: Oct 8, 2014 Intended Status: Standards Track Please find the review at: http://trac.tools.ietf.org/area/rtg/trac/wiki/WG%20adoption%20QA%20review%2= 0draft-filsfils-spring-segment-routing Cheers, Andy _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_7F5E7CA698B54E3A8A72621F16636E23junipernet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sorry I missed that -- thanks!

--John

On Nov 11, 2014, at 10:23 AM, Stefano Previdi (sprevidi) <sprevidi@cisco.com> wrote:

Hi John,

I already ack'ed Andrew' s comments and will address them asap.

Thanks.

s.

-----Original Message-----
From: John Scudder [jgs42@me.com= ]
Received: Tuesday, 11 Nov 2014, 9:48
To: Andrew G. Malis [agmalis@gm= ail.com]; Clarence Filsfils (cfilsfil) [cfilsfil@cisco.com]; Stefano Previdi (sprevidi) [sprevidi@cisco.com]
CC: rtg-ads@tools.ietf.org= [rtg-ads@tools.ietf.org]= ; rtg-dir@ietf.org [rtg-dir@ietf.org]; spring@ietf.org [spring@ietf.org]; dra= ft-filsfils-spring-segment-routing@tools.ietf.org [draft-filsfils-spring-s= egment-routing@tools.ietf.org]; {spring-chairs@tools.ietf.= org} [spring-chairs@too= ls.ietf.org]
Subject: Re: [RTG-DIR] Routing Directorate QA review of draft-filsfi= ls-spring-segment-routing-04
Andy,

Thanks very much for doing this review.

Authors,

Can you please (at minimum) acknowledge that you've received Andy's co= mments and (preferably) respond to them, either by updating the draft or by= discussing them on the SPRING list? For what it's worth, I've read through= Andy's review and agree with his points.

Thanks,

--John

On Oct 6, 2014, at 12:02 PM, Andrew G. Malis <agmalis@gmail.com> wrote:

Hello,

I have been se= lected as the Routing Directorate QA reviewer for https://tools.ietf.org/html/draft-filsfils-spring= -segment-routing-04 .

The Routing Di= rectorate QA reviews are intended to improve= the quality of RTG Area documents as the pass through the IETF process.

This is the QA= review at the time of the WG document adoption poll.

Document: = ;draft-filsfils-spring-= segment-routing-04.txt
Reviewer: Andy= Malis
Review Date: 2= 014-10-06
Working Group = Adoption Poll end date: Oct 8, 2014
Intended Statu= s: Standards Track

Please find th= e review at:

http://trac.tools.ietf.o= rg/area/rtg/trac/wiki/WG%20adoption%20QA%20review%20draft-filsfils-spring-s= egment-routing

Cheers,
Andy


_______________________________________________
spring mailing list
spring@ietf.org
https://www.= ietf.org/mailman/listinfo/spring
--_000_7F5E7CA698B54E3A8A72621F16636E23junipernet_-- From nobody Wed Nov 12 08:32:48 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A67C1A1BAD; Wed, 12 Nov 2014 07:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fERiYzCD_wk8; Wed, 12 Nov 2014 07:50:20 -0800 (PST) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8C31A1BAC; Wed, 12 Nov 2014 07:50:20 -0800 (PST) Received: from oasis.uclouvain.be (unknown [130.104.6.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPS id B885718343B; Wed, 12 Nov 2014 16:50:13 +0100 (CET) Received: from [130.104.228.78] (130.104.228.78) by ucl-mbx04.OASIS.UCLOUVAIN.BE (10.10.10.24) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 12 Nov 2014 16:49:57 +0100 Message-ID: <546381B8.6090607@uclouvain.be> Date: Wed, 12 Nov 2014 16:50:16 +0100 From: David Lebrun User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FtvGR2KOWhujpf1jo04k6pECXKPCt5HKl" X-Originating-IP: [130.104.228.78] X-ClientProxiedBy: UCL-CAS03.OASIS.UCLOUVAIN.BE (10.10.10.43) To ucl-mbx04.OASIS.UCLOUVAIN.BE (10.10.10.24) X-Virus-Scanned: clamav-milter 0.97.7-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean Received-SPF: Pass (client IP white listed); receiver=; client-ip=130.104.6.131; helo= Received-SPF: Pass (client IP white listed); receiver=; client-ip=130.104.6.131; envelope-from= X-SGSI-MailScanner-ID: B885718343B.AE568 X-SGSI-MailScanner: Found to be clean X-SGSI-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-2.806, requis 5, autolearn=not spam, ALL_TRUSTED -2.00, BAYES_00 -1.60, RDNS_NONE 0.79) X-SGSI-From: david.lebrun@uclouvain.be X-SGSI-Spam-Status: No Archived-At: http://mailarchive.ietf.org/arch/msg/spring/esf9n50lQH_pOqh5io-kBJbU9OY X-Mailman-Approved-At: Wed, 12 Nov 2014 08:32:45 -0800 Cc: v6ops@ietf.org, "Field, Brian" , Julien Pivotto , "Dave Barach \(dbarach\)" , "Leddy, John" , "Christian Martin \(martincj\)" , Olivier Bonaventure , "Stefano Previdi \(sprevidi\)" , "Brzozowski, John" , Stephen McCarthy Subject: [spring] Supporting IPv6 Segment Routing in the Linux kernel X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 15:50:23 -0000 --FtvGR2KOWhujpf1jo04k6pECXKPCt5HKl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For the past few months we have been working on a Linux kernel implementation of the IPv6 version of Segment Routing as defined in draft-previdi-6man-segment-routing-header. We performed an interoperability demonstration with Cisco and Comcast at Bits-n-Bytes of IETF90. At this point we assume that our implementation is ready for a public release, thus enabling contributions, feedback, discussions, etc. We provide a front page for this implementation: http://www.segment-routing.org. Basically, it links to three main things:= 1. The source code hosted on github at http://github.com/segment-routing/sr-ipv6 and the userland tool http://github.com/segment-routing/seg6ctl 2. A technical report describing the implementation at http://www.segment-routing.org/sr6-doc.pdf 3. A public mailing list at https://listes-2.sipr.ucl.ac.be/sympa/info/sr6-dev to enable discussions, patch submissions, etc. The long-term goal is to make this implementation stable and mature enough for merging in the upstream Linux kernel. Moreover, we have a public testbed composed of 4 routers and 1 host, all running our SR-IPv6 implementation, to facilitate interoperability tests. We will release more information about this testbed later. Feel free to use, modify, play with the code ! David --=20 INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be --FtvGR2KOWhujpf1jo04k6pECXKPCt5HKl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlRjgb8ACgkQjbzn67sZ6AMKXgCdFRrBkDKXjP7QN3py80dQTkdC jokAnjsNfw8TE6Cl0nvu+93948Pb/OjK =Jnlg -----END PGP SIGNATURE----- --FtvGR2KOWhujpf1jo04k6pECXKPCt5HKl-- From nobody Wed Nov 12 09:08:06 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A2B1A8BBF for ; Wed, 12 Nov 2014 09:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 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.594, 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 4WW01atc_8Ei for ; Wed, 12 Nov 2014 09:07:59 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1701A8AFA for ; Wed, 12 Nov 2014 09:07:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23541; q=dns/txt; s=iport; t=1415812074; x=1417021674; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=8ORMrCq6la/2JGFZfWX9/HYu/VH/2cHQygaAWUzR1eg=; b=TayAMXBZOOPdkcmPFi5j0R1t4BxDW6ID52eeooJUFlqRzt/jFE0DkixP nNtz8+SXZCc23dLCRdP3MQ4FxHgYb+94Mk49bLk1xQ3jkT62omzHHxSWW bSQEfua/FzTWLp8KNugRm/T1F3xI7pW5qAd9fDY51uQpoh3CV+mn6OCKU E=; X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208,217";a="371937585" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP; 12 Nov 2014 17:07:53 +0000 Received: from [10.21.66.199] (sjc-vpn3-711.cisco.com [10.21.66.199]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sACH7pmS030853; Wed, 12 Nov 2014 17:07:52 GMT Message-ID: <546393E7.3000107@cisco.com> Date: Wed, 12 Nov 2014 09:07:51 -0800 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Alvaro Retana (aretana)" , "Stefano Previdi (sprevidi)" References: <228E5616-3232-47F3-A36C-00A1B1820090@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080405040007030409030801" Archived-At: http://mailarchive.ietf.org/arch/msg/spring/bT8JlYx9ZNjnWUPCuCQDEA_rIgY Cc: "draft-filsfils-spring-segment-routing@tools.ietf.org" , "spring@ietf.org" Subject: Re: [spring] IPR Claims related to draft-filsfils-spring-segment-routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 17:08:02 -0000 This is a multi-part message in MIME format. --------------080405040007030409030801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I'm not aware of any IPR on this draft Thanks Ahmed On 10/17/2014 1:23 PM, Alvaro Retana (aretana) wrote: > On 10/7/14, 11:26 AM, "Stefano Previdi (sprevidi)" > wrote: > >> IPR is in the process of being disclosed. > The IPR was filed on Oct/7, but it was done against > draft-filsfils-rtgwg-segment-routing, which is the precursor of this > draft. The filing is ok, it just took me a while to find it. > > For the WG reference: http://datatracker.ietf.org/ipr/2457/ > > > Authors: We still havenšt received an explicit answer form Clarence, > Ahmed, Stephane, Igor, Wim and Ed. [Note that some of you may have > replied for draft-filsfils-spring-segment-routing-mpls..] It would be > very nice if we can close on this requirement by Oct/23 so (if adopted) we > have time to publish the WG-titled document before the deadline. > > Thanks! > > Alvaro. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --------------080405040007030409030801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm not aware of any IPR on this draft

Thanks

Ahmed

On 10/17/2014 1:23 PM, Alvaro Retana (aretana) wrote:
On 10/7/14, 11:26 AM, "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
wrote:


IPR is in the process of being disclosed.

The IPR was filed on Oct/7, but it was done against
draft-filsfils-rtgwg-segment-routing, which is the precursor of this
draft.  The filing is ok, it just took me a while to find it.

For the WG reference:  http://datatracker.ietf.org/ipr/2457/


Authors:  We still haven¹t received an explicit answer form Clarence,
Ahmed, Stephane, Igor, Wim and Ed.  [Note that some of you may have
replied for draft-filsfils-spring-segment-routing-mpls..]  It would be
very nice if we can close on this requirement by Oct/23 so (if adopted) we
have time to publish the WG-titled document before the deadline.

Thanks!

Alvaro.

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

--------------080405040007030409030801-- From nobody Wed Nov 12 09:12:37 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D878B1A8F40 for ; Wed, 12 Nov 2014 09:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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.594, 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 vzGNGRi13GDp for ; Wed, 12 Nov 2014 09:12:29 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2BF1A9026 for ; Wed, 12 Nov 2014 09:09:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=61; q=dns/txt; s=iport; t=1415812163; x=1417021763; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/eO+BL/MktnMXWR0n6KdGxB5+8H3N0Y+1MMvk3cGvTk=; b=af8nGVlji3EyyFHGA+qduXUeXoFGx0jmtqzbSB6+F1FlAQlamcVXT8p2 vwxKJCHaRWFFVYEnTikrQCXNdTMu/b4bcxfYud8i0PZgMDlDU1H56kawV gC4W7FYn/2JJGLj44zrVA95c36I/9jTZ7eEF5NnhtvxxVywru2gwoBbO8 U=; X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="95942881" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP; 12 Nov 2014 17:09:23 +0000 Received: from [10.21.66.199] (sjc-vpn3-711.cisco.com [10.21.66.199]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sACH9Mb1007916; Wed, 12 Nov 2014 17:09:22 GMT Message-ID: <54639442.5090708@cisco.com> Date: Wed, 12 Nov 2014 09:09:22 -0800 From: Ahmed Bashandy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Alvaro Retana (aretana)" , "spring@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/spring/Yl_t53WzUYNzjOe6S5mtM7CE8Yc Cc: "draft-filsfils-spring-segment-routing-mpls@tools.ietf.org" Subject: [spring] IPR disclosure for draft-filsfils-spring-segment-routing-mpls X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 17:12:34 -0000 I'm not aware of any IPR on this draft Thanks Ahmed From nobody Wed Nov 12 09:32:50 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0FD1A0071 for ; Wed, 12 Nov 2014 09:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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.594, 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 9SdwfFSKV-UT for ; Wed, 12 Nov 2014 09:32:44 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 904941A004D for ; Wed, 12 Nov 2014 09:32:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=183; q=dns/txt; s=iport; t=1415813565; x=1417023165; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Sf4wArxNdjx7sBOmVD3w+rxDwR/9wFnXNhqbLIuz/tw=; b=eSkFv6uBEpf1cnMrnuRqftOXuhhvGjXaBcn4mz3cGffhpM49qq2lPFtN JKVFZA6I08xey+G96VG/8+n74Rcm/dstH4ey1l22Hf/jGmhvFzTIzznnS 29d5mBc2FZs7dzKjBYknOQxZ4XZzel5hY+whZ3H2Mmkj1HgvKaYAIYfxF w=; X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208";a="47426035" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 12 Nov 2014 17:32:40 +0000 Received: from [10.60.210.100] (ams-cfilsfil-8813.cisco.com [10.60.210.100]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sACHWbYs016449; Wed, 12 Nov 2014 17:32:38 GMT Message-ID: <546399B5.7060501@cisco.com> Date: Wed, 12 Nov 2014 18:32:37 +0100 From: Clarence Filsfils User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ahmed Bashandy References: <54639442.5090708@cisco.com> In-Reply-To: <54639442.5090708@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/spring/7swpYYIXPn2AjVvrB6tRHFL0n-E Cc: "Alvaro Retana \(aretana\)" , "spring@ietf.org" , "draft-filsfils-spring-segment-routing-mpls@tools.ietf.org" Subject: Re: [spring] IPR disclosure for draft-filsfils-spring-segment-routing-mpls X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 17:32:49 -0000 I'm not aware of any IPR on this draft Cheers, Clarence On 12.11.14 18:09, Ahmed Bashandy wrote: > > I'm not aware of any IPR on this draft > > Thanks > > Ahmed > > From nobody Wed Nov 12 10:40:19 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6B41ACE2F for ; Wed, 12 Nov 2014 10:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 jZmtSAqDU334 for ; Wed, 12 Nov 2014 10:40:13 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92ACC1A8AFA for ; Wed, 12 Nov 2014 10:40:13 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id D90643B4460; Wed, 12 Nov 2014 19:40:11 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id BBAA24C0AE; Wed, 12 Nov 2014 19:40:11 +0100 (CET) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Wed, 12 Nov 2014 19:40:11 +0100 From: To: "Alvaro Retana (aretana)" Thread-Topic: IPR disclosure for draft-filsfils-spring-segment-routing-mpls Thread-Index: AQHP/ptxtwicTplgbUy7FghiJs0PqZxdL1KAgAAjXKA= Date: Wed, 12 Nov 2014 18:40:11 +0000 Message-ID: <17461_1415817611_5463A98B_17461_4198_1_53C29892C857584299CBF5D05346208A07260184@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <54639442.5090708@cisco.com> <546399B5.7060501@cisco.com> In-Reply-To: <546399B5.7060501@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.12.80623 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/X15Jul2GjQTRUXRtcrzGPzwLuGk Cc: "spring@ietf.org" , "draft-filsfils-spring-segment-routing-mpls@tools.ietf.org" Subject: Re: [spring] IPR disclosure for draft-filsfils-spring-segment-routing-mpls X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 18:40:15 -0000 I'm not aware of non disclosed IPR. Thanks, Regards, Bruno > -----Original Message----- > From: Clarence Filsfils [mailto:cfilsfil@cisco.com] > Sent: Wednesday, November 12, 2014 7:33 AM > To: Ahmed Bashandy > Cc: Alvaro Retana (aretana); spring@ietf.org; draft-filsfils-spring-segme= nt- > routing-mpls@tools.ietf.org > Subject: Re: IPR disclosure for draft-filsfils-spring-segment-routing-mpls >=20 >=20 > I'm not aware of any IPR on this draft >=20 > Cheers, > Clarence >=20 > On 12.11.14 18:09, Ahmed Bashandy wrote: > > > > I'm not aware of any IPR on this draft > > > > Thanks > > > > Ahmed > > > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From Igor.Milojevic@huawei.com Wed Nov 12 13:02:25 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB69E1ACEE6 for ; Wed, 12 Nov 2014 13:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.194 X-Spam-Level: X-Spam-Status: No, score=-4.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 sSt3gAiOVD2m for ; Wed, 12 Nov 2014 13:02:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9227A1A90AF for ; Wed, 12 Nov 2014 13:02:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOS26559; Wed, 12 Nov 2014 21:02:16 +0000 (GMT) Received: from LHREML517-MBS.china.huawei.com ([169.254.5.96]) by lhreml402-hub.china.huawei.com ([10.201.5.241]) with mapi id 14.03.0158.001; Wed, 12 Nov 2014 21:02:12 +0000 From: Igor Milojevic To: "aretana@cisco.com" , "jgs@juniper.net" , "spring@ietf.org" Thread-Topic: IPR on Segment Routing Drafts Thread-Index: Ac/+u+0OpdzgbEUUSZCzToKCHPS+oA== Date: Wed, 12 Nov 2014 21:02:12 +0000 Message-ID: <77E42098F914EE48B33155CD7C9AD6E301173640@LHREML517-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.193.197] Content-Type: multipart/alternative; boundary="_000_77E42098F914EE48B33155CD7C9AD6E301173640LHREML517MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/W3hjqMw03M6jEWnItKOoVuX90fQ X-Mailman-Approved-At: Wed, 12 Nov 2014 15:17:53 -0800 Cc: "sprevidi@cisco.com" Subject: [spring] IPR on Segment Routing Drafts X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 21:04:28 -0000 --_000_77E42098F914EE48B33155CD7C9AD6E301173640LHREML517MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Following the activities on the Segment Routing - related drafts, I confirm= that I'm not aware of any IPR on draft-filsfils-spring-segment-routing and draft= -filsfils-spring-segment-routing-mpls. Due to company change, please take into notice my new contact: email: igor.milojevic@huawei.com Address: Domaniewska 50, 02-672 Warsaw, Poland Thank You, Igor Milojevic Director FBB MKTG CEE&Nordic Huawei --_000_77E42098F914EE48B33155CD7C9AD6E301173640LHREML517MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Following the activities on the Segment Routing R= 11; related drafts, I confirm that

 

I’m not aware of any IPR on draft-filsfils-spr= ing-segment-routing and draft-filsfils-spring-segment-routing-mpls.

 

 

 

Due to company change, please take into notice my ne= w contact:

 

email: igor.milojevic@huawei.com

Address: Domaniewska 50, 02-672 Warsaw, Poland =

 

 

Thank You,

 

Igor Milojevic

Director

FBB MKTG CEE&Nordic

Huawei

 

 

--_000_77E42098F914EE48B33155CD7C9AD6E301173640LHREML517MBSchi_-- From nobody Wed Nov 12 23:28:58 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979641A1ABA; Wed, 12 Nov 2014 23:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 s8h0AvLfoR9q; Wed, 12 Nov 2014 23:28:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 578AF1A1BE9; Wed, 12 Nov 2014 23:28:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141113072854.30944.17172.idtracker@ietfa.amsl.com> Date: Wed, 12 Nov 2014 23:28:54 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/AGCdY6gZPpa2cZiEW0Z2k7yHLpE Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-ipv6-use-cases-03.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 07:28:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking Working Group of the IETF. Title : IPv6 SPRING Use Cases Authors : John Brzozowski John Leddy Ida Leung Stefano Previdi Mark Townsley Christian Martin Clarence Filsfils Roberta Maglione Filename : draft-ietf-spring-ipv6-use-cases-03.txt Pages : 13 Date : 2014-11-12 Abstract: Source Packet Routing in Networking (SPRING) architecture leverages the source routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with SPRING header. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to the SPRING node or global within the SPRING domain. SPRING allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SPRING domain. The objective of this document is to illustrate some use cases that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-ipv6-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-spring-ipv6-use-cases-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-spring-ipv6-use-cases-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 13 00:25:46 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843FF1A6F71 for ; Thu, 13 Nov 2014 00:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 vqMuBek-Va6k for ; Thu, 13 Nov 2014 00:25:43 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE33A1A6F6F for ; Thu, 13 Nov 2014 00:25:42 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 1074CC0BB7; Thu, 13 Nov 2014 09:25:41 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id C50E218006E; Thu, 13 Nov 2014 09:25:40 +0100 (CET) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.17]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0210.002; Thu, 13 Nov 2014 09:25:39 +0100 From: To: DECRAENE Bruno IMT/OLN , "Alvaro Retana (aretana)" Thread-Topic: [spring] IPR disclosure for draft-filsfils-spring-segment-routing-mpls Thread-Index: AQHP/p6w0me6bUBMuESwyoiOVtgBn5xdQiyAgAD3X5A= Date: Thu, 13 Nov 2014 08:25:39 +0000 Message-ID: <16396_1415867140_54646B04_16396_10092_1_ca288def-d047-4e74-af47-fb59b233631b@OPEXCLILH05.corporate.adroot.infra.ftgroup> References: <54639442.5090708@cisco.com> <546399B5.7060501@cisco.com> <17461_1415817611_5463A98B_17461_4198_1_53C29892C857584299CBF5D05346208A07260184@PEXCVZYM11.corporate.adroot.infra.ftgroup> In-Reply-To: <17461_1415817611_5463A98B_17461_4198_1_53C29892C857584299CBF5D05346208A07260184@PEXCVZYM11.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.13.72723 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/B-GKFwncF-SXFgGum83S32fmXOY Cc: "spring@ietf.org" , "draft-filsfils-spring-segment-routing-mpls@tools.ietf.org" Subject: Re: [spring] IPR disclosure for draft-filsfils-spring-segment-routing-mpls X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 08:25:45 -0000 I'm not aware of non disclosed IPR. -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Wednesday, November 12, 2014 19:40 To: Alvaro Retana (aretana) Cc: spring@ietf.org; draft-filsfils-spring-segment-routing-mpls@tools.ietf.= org Subject: Re: [spring] IPR disclosure for draft-filsfils-spring-segment-rout= ing-mpls I'm not aware of non disclosed IPR. Thanks, Regards, Bruno > -----Original Message----- > From: Clarence Filsfils [mailto:cfilsfil@cisco.com] > Sent: Wednesday, November 12, 2014 7:33 AM > To: Ahmed Bashandy > Cc: Alvaro Retana (aretana); spring@ietf.org;=20 > draft-filsfils-spring-segment- routing-mpls@tools.ietf.org > Subject: Re: IPR disclosure for=20 > draft-filsfils-spring-segment-routing-mpls >=20 >=20 > I'm not aware of any IPR on this draft >=20 > Cheers, > Clarence >=20 > On 12.11.14 18:09, Ahmed Bashandy wrote: > > > > I'm not aware of any IPR on this draft > > > > Thanks > > > > Ahmed > > > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Nov 13 00:27:28 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB901A6F7D for ; Thu, 13 Nov 2014 00:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 nieFPdsYle66 for ; Thu, 13 Nov 2014 00:27:25 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3AFB1A6F5D for ; Thu, 13 Nov 2014 00:27:24 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 3CF672DC733; Thu, 13 Nov 2014 09:27:23 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 17B2D35C05A; Thu, 13 Nov 2014 09:27:23 +0100 (CET) Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.17]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Thu, 13 Nov 2014 09:27:23 +0100 From: To: "Alvaro Retana (aretana)" , "draft-filsfils-spring-segment-routing@tools.ietf.org" Thread-Topic: IPR Claims related to draft-filsfils-spring-segment-routing Thread-Index: AQHP1/fub1imTrTArE2x/Y4xmYwLR5xeh1dQ Date: Thu, 13 Nov 2014 08:27:23 +0000 Message-ID: <28182_1415867243_54646B6B_28182_5473_1_9E32478DFA9976438E7A22F69B08FF9217582D@OPEXCLILM34.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF9217582DOPEXCLILM34corpor_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.13.71820 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/RTxoGMLhRyyepQAqP8NmG2xtQvQ Cc: "spring@ietf.org" Subject: Re: [spring] IPR Claims related to draft-filsfils-spring-segment-routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 08:27:27 -0000 --_000_9E32478DFA9976438E7A22F69B08FF9217582DOPEXCLILM34corpor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not aware of non disclosed IPR. From: Alvaro Retana (aretana) [mailto:aretana@cisco.com] Sent: Wednesday, September 24, 2014 15:03 To: draft-filsfils-spring-segment-routing@tools.ietf.org Cc: spring@ietf.org Subject: IPR Claims related to draft-filsfils-spring-segment-routing Hi! In parallel to the WG Adoption Call for this draft, I want to formally ask = the authors (no additional contributors are listed in the latest version of= the draft) to please respond to this message indicating whether or not you= are aware of any relevant IPR beyond what has been already disclosed. The= draft will not progress (pending the results of the WG Adoption Call) unti= l we have received a response from each author. http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id=3Ddraft= -filsfils-spring-segment-routing Thanks! Alvaro. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF9217582DOPEXCLILM34corpor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I'm not aware of non disclosed IPR.

 <= /p>

 <= /p>

From: Alvaro R= etana (aretana) [mailto:aretana@cisco.com]
Sent: Wednesday, September 24, 2014 15:03
To: draft-filsfils-spring-segment-routing@tools.ietf.org
Cc: spring@ietf.org
Subject: IPR Claims related to draft-filsfils-spring-segment-routing=

 

Hi!

 

In parallel to the WG Adopt= ion Call for this draft, I want to formally ask the authors (no additi= onal contributors are listed in the latest version of the draft) to please respond to this message indicating whether or not you are aware = of any relevant IPR beyond what has been already disclosed.  The draft= will not progress (pending the results of the WG Adoption Call) until we h= ave received a response from each author.

 

 

Thanks!

 

Alvaro. 

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF9217582DOPEXCLILM34corpor_-- From nobody Thu Nov 13 12:21:24 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08471ACFD4 for ; Thu, 13 Nov 2014 12:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 wCbqARznUGpA for ; Thu, 13 Nov 2014 12:21:17 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 304801ACFB8 for ; Thu, 13 Nov 2014 12:20:08 -0800 (PST) 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 BLP44502; Thu, 13 Nov 2014 20:20:06 +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; Thu, 13 Nov 2014 20:20:05 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 14 Nov 2014 04:19:59 +0800 From: Xuxiaohu To: "spring@ietf.org" Thread-Topic: Do we really need such a diversity Thread-Index: Ac//f3ZK/nmQmNRxRXm8l2bNI6Q7tQ== Date: Thu, 13 Nov 2014 20:19:58 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082CD20D@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.47.155.145] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082CD20DNKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/au7MCRY1uB9VejzyRPJzSytWV24 Subject: [spring] Do we really need such a diversity X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 20:21:19 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082CD20DNKGEML512MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As I had mentioned at the mic, the IPv6-SR-header draft proposes to use an = ordered list of IPv6 addresses to represent an explicit path. In this way, = there is no need for any IGP extension. That's fine although I don't know w= hether such a trade-off is much worthwhile (i.e., encapsulation overhead vs= control plane change). However, in the IGP extension for SR drafts, there = are still some descriptions about the 32-bit SID. Does it mean we may come = back someday to consider how to use an ordered list of SIDs instead of an o= rdered list of IPv6 addresses to represent an explicit path. If so, I wonde= r why not directly use an ordered list of (MPLS) labels rather than an orde= r list of 32-bit SIDs. By using an ordered list of labels (i.e., a label st= ack) in the packet, the underlay could be IPv4, IPv6 and even MPLS. In othe= r words, such an SR header is transport-independent. In a word, I just wond= er whether we do need so many various solutions. Best regards, Xiaohu --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082CD20DNKGEML512MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As I had mentioned at the mic, = the IPv6-SR-header draft proposes to use an ordered list of IPv6 addresses = to represent an explicit path. In this way, there is no need for any IGP ex= tension. That’s fine although I don’t know whether such a trade-off is much worthwhile (i.e., encapsulation over= head vs control plane change). However, in the IGP extension for SR drafts,= there are still some descriptions about the 32-bit SID. Does it mean we ma= y come back someday to consider how to use an ordered list of SIDs instead of an ordered list of IPv6 addr= esses to represent an explicit path. If so, I wonder why not directly use a= n ordered list of (MPLS) labels rather than an order list of 32-bit SIDs. B= y using an ordered list of labels (i.e., a label stack) in the packet, the underlay could be IPv4, IPv6 and = even MPLS. In other words, such an SR header is transport-independent. In a= word, I just wonder whether we do need so many various solutions.

 

Best regards,=

Xiaohu

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082CD20DNKGEML512MBSchi_-- From nobody Thu Nov 13 15:13:17 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF06C1AE220 for ; Thu, 13 Nov 2014 15:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 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.594, 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 sCZ2JJ4tjpGQ for ; Thu, 13 Nov 2014 15:13:14 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB501AE21F for ; Thu, 13 Nov 2014 15:13:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5111; q=dns/txt; s=iport; t=1415920394; x=1417129994; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=9H5tvHpxk3t0q2/qKGsXmjmwvc926XTos4XpvVADbyw=; b=cJzFKhy/h/b+EGKuMyCsbstqVC9/J3E7HKV5IteTDNxxMPIZEpwvUXQQ kSYpeuac6mO4DeVYNOu57UxhD5tGD+QSlGO6eceYYHQVLl9hI0vtcjrnQ blsCPNZW4xpEE6kidocGZ2A8dCIDGWO/vp2c4+kgfQWt/NOlOfZemUC2o 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAE86ZVStJA2E/2dsb2JhbABbgkhGgS3URwKBHhYBAQEBAX2EAgEBAQR0EQQCAQgEEQILJDIdCAEBBAESCBOIJtERAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5BjOAaDJ4EeBZI6hxubQ4N8bYJLAQEB X-IronPort-AV: E=Sophos; i="5.07,380,1413244800"; d="scan'208,217"; a="96455800" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP; 13 Nov 2014 23:13:13 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sADNDD69020545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Nov 2014 23:13:13 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Thu, 13 Nov 2014 17:13:13 -0600 From: "Stefano Previdi (sprevidi)" To: "spring@ietf.org" , "xuxiaohu@huawei.com" Thread-Topic: [spring] Do we really need such a diversity Thread-Index: Ac//f3ZK/nmQmNRxRXm8l2bNI6Q7tQAF+8Z+ Date: Thu, 13 Nov 2014 23:13:12 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082CD20D@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082CD20D@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E0A1DE675FEC854ABF07D319E556FE64467E1326xmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/usC80PNyP_TZf-6xUQZ-PZXbMAw Subject: Re: [spring] Do we really need such a diversity X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 23:13:16 -0000 --_000_E0A1DE675FEC854ABF07D319E556FE64467E1326xmbrcdx01ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Xiaohu, At this stage there's no need to have shorter sid 's for ipv6 also because = the current use cases afdressed by existing implementations do not require = any igp anyway. IOW, segments do not represent igp shortest paths but rathe= r application/service instances. We MAY want to consider other sid formats but that would be another use cas= e. s. -----Original Message----- From: Xuxiaohu [xuxiaohu@huawei.com] Received: Thursday, 13 Nov 2014, 10:21 To: spring@ietf.org [spring@ietf.org] Subject: [spring] Do we really need such a diversity Hi, As I had mentioned at the mic, the IPv6-SR-header draft proposes to use an = ordered list of IPv6 addresses to represent an explicit path. In this way, = there is no need for any IGP extension. That=92s fine although I don=92t kn= ow whether such a trade-off is much worthwhile (i.e., encapsulation overhea= d vs control plane change). However, in the IGP extension for SR drafts, th= ere are still some descriptions about the 32-bit SID. Does it mean we may c= ome back someday to consider how to use an ordered list of SIDs instead of = an ordered list of IPv6 addresses to represent an explicit path. If so, I w= onder why not directly use an ordered list of (MPLS) labels rather than an = order list of 32-bit SIDs. By using an ordered list of labels (i.e., a labe= l stack) in the packet, the underlay could be IPv4, IPv6 and even MPLS. In = other words, such an SR header is transport-independent. In a word, I just = wonder whether we do need so many various solutions. Best regards, Xiaohu --_000_E0A1DE675FEC854ABF07D319E556FE64467E1326xmbrcdx01ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Xiaohu,

At this stage there's no need to have shorter sid 's for ipv6 also because = the current use cases afdressed by existing implementations do not require = any igp anyway. IOW, segments do not represent igp shortest paths but rathe= r application/service instances.

We MAY want to consider other sid formats but that would be another use cas= e.

s.

-----Original Message-----
From: Xuxiaohu [xuxiaohu@huawei.com]
Received: Thursday, 13 Nov 2014, 10:21
To: spring@ietf.org [spring@ietf.org]
Subject: [spring] Do we really need such a diversity

Hi,

 

As I had mentioned at the mic, = the IPv6-SR-header draft proposes to use an ordered list of IPv6 addresses = to represent an explicit path. In this way, there is no need for any IGP ex= tension. That=92s fine although I don=92t know whether such a trade-off is much worthwhile (i.e., encapsulation over= head vs control plane change). However, in the IGP extension for SR drafts,= there are still some descriptions about the 32-bit SID. Does it mean we ma= y come back someday to consider how to use an ordered list of SIDs instead of an ordered list of IPv6 addr= esses to represent an explicit path. If so, I wonder why not directly use a= n ordered list of (MPLS) labels rather than an order list of 32-bit SIDs. B= y using an ordered list of labels (i.e., a label stack) in the packet, the underlay could be IPv4, IPv6 and = even MPLS. In other words, such an SR header is transport-independent. In a= word, I just wonder whether we do need so many various solutions.

 

Best regards,

Xiaohu

--_000_E0A1DE675FEC854ABF07D319E556FE64467E1326xmbrcdx01ciscoc_-- From nobody Thu Nov 13 15:32:37 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FA21AE2BE for ; Thu, 13 Nov 2014 15:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 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.594, 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 oemlg4Ku6KCL for ; Thu, 13 Nov 2014 15:32:34 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935651AE2C7 for ; Thu, 13 Nov 2014 15:32:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6319; q=dns/txt; s=iport; t=1415921552; x=1417131152; h=from:to:subject:date:message-id:mime-version; bh=EQ7EZhX7cPe/35bc3BYBL8/XozYn4XNsSM9ijn4Ospw=; b=cwb2oLzLhLzk7GPV4H9wdLHWVx8LUXIs5Qg+a8aTrOB8Gq7KGnA0jYqi lfCcefSEy0a7w/YjVctPUDSq+RQeFHkR0hr/xVRPPy0V0HNyAOJe4xWzA kb3PpS6PIeQC+iQ4l99x++wPI0bqUBypS61SRskevDYrnOtC9HE5r5YRX k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYIANE+ZVStJV2c/2dsb2JhbABbgkhGgS2DBtFBAhyBAhYBAQEBAX2EAgEBAQMBI1EKBwYBCAQRAgsgAgQwHQkBBAESCBOIHQm6c5YoAQEBAQEBBAEBAQEBARyQYz6CcTaBHgWSOocbm0ODfG2CSwEBAQ X-IronPort-AV: E=Sophos; i="5.07,380,1413244800"; d="scan'208,217"; a="96460270" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP; 13 Nov 2014 23:32:31 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sADNWVDE021541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Nov 2014 23:32:31 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 13 Nov 2014 17:32:31 -0600 From: "Stefano Previdi (sprevidi)" To: "spring@ietf.org" , "xuxiaohu@huawei.com" Thread-Topic: [spring] Do we really need such a diversity Thread-Index: Ac//mhfv/nmQmNRxRXm8l2bNI6Q7tQ== Date: Thu, 13 Nov 2014 23:32:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E0A1DE675FEC854ABF07D319E556FE64467E13ECxmbrcdx01ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/P2qzt-Jd_J36EheKMj2gvK0O4HY Subject: Re: [spring] Do we really need such a diversity X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 23:32:36 -0000 --_000_E0A1DE675FEC854ABF07D319E556FE64467E13ECxmbrcdx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU3RlZmFubyBQcmV2aWRpIChzcHJl dmlkaSkgW3NwcmV2aWRpQGNpc2NvLmNvbV0NCj4gUmVjZWl2ZWQ6IFRodXJzZGF5LCAxMyBOb3Yg MjAxNCwgMTM6MTMNCj4gVG86IHNwcmluZ0BpZXRmLm9yZyBbc3ByaW5nQGlldGYub3JnXTsgeHV4 aWFvaHVAaHVhd2VpLmNvbSBbeHV4aWFvaHVAaHVhd2VpLmNvbV0NCj4gU3ViamVjdDogUkU6IFtz cHJpbmddIERvIHdlIHJlYWxseSBuZWVkIHN1Y2ggYSBkaXZlcnNpdHkNCj4NCj4gWGlhb2h1LA0K Pg0KPkF0IHRoaXMgc3RhZ2UgdGhlcmUncyBubyBuZWVkIHRvIGhhdmUgc2hvcnRlciBzaWQgJ3Mg Zm9yIGlwdjYgYWxzbyBiZWNhdXNlIHRoZSBjdXJyZW50IHVzZQ0KPiBjYXNlcyBhZmRyZXNzZWQg YnkgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIGRvIG5vdCByZXF1aXJlIGFueSBpZ3AgYW55d2F5 Lg0KDQpJIG1lYW50ICJpZ3AgZXh0ZW5zaW9ucyIgb2YgY291cnNlLi4uDQoNCnMuDQoNCj4gSU9X LCBzZWdtZW50cw0KPiBkbyBub3QgcmVwcmVzZW50IGlncCBzaG9ydGVzdCBwYXRocyBidXQgcmF0 aGVyIGFwcGxpY2F0aW9uL3NlcnZpY2UgaW5zdGFuY2VzLg0KPg0KPiBXZSBNQVkgd2FudCB0byBj b25zaWRlciBvdGhlciBzaWQgZm9ybWF0cyBidXQgdGhhdCB3b3VsZCBiZSBhbm90aGVyIHVzZSBj YXNlLg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogWHV4aWFvaHUg W3h1eGlhb2h1QGh1YXdlaS5jb21dDQoNClJlY2VpdmVkOiBUaHVyc2RheSwgMTMgTm92IDIwMTQs IDEwOjIxDQoNClRvOiBzcHJpbmdAaWV0Zi5vcmcgW3NwcmluZ0BpZXRmLm9yZ10NCg0KU3ViamVj dDogW3NwcmluZ10gRG8gd2UgcmVhbGx5IG5lZWQgc3VjaCBhIGRpdmVyc2l0eQ0KDQoNCg0KDQoN Cg0KDQoNCg0KSGksDQoNCg0KDQpBcyBJIGhhZCBtZW50aW9uZWQgYXQgdGhlIG1pYywgdGhlIElQ djYtU1ItaGVhZGVyIGRyYWZ0IHByb3Bvc2VzIHRvIHVzZSBhbiBvcmRlcmVkIGxpc3Qgb2YgSVB2 NiBhZGRyZXNzZXMgdG8gcmVwcmVzZW50IGFuIGV4cGxpY2l0IHBhdGguIEluIHRoaXMgd2F5LCB0 aGVyZSBpcyBubyBuZWVkIGZvciBhbnkgSUdQIGV4dGVuc2lvbi4gVGhhdOKAmXMgZmluZSBhbHRo b3VnaCBJIGRvbuKAmXQNCmtub3cgd2hldGhlciBzdWNoIGEgdHJhZGUtb2ZmIGlzIG11Y2ggd29y dGh3aGlsZSAoaS5lLiwgZW5jYXBzdWxhdGlvbiBvdmVyaGVhZCB2cyBjb250cm9sIHBsYW5lIGNo YW5nZSkuIEhvd2V2ZXIsIGluIHRoZSBJR1AgZXh0ZW5zaW9uIGZvciBTUiBkcmFmdHMsIHRoZXJl IGFyZSBzdGlsbCBzb21lIGRlc2NyaXB0aW9ucyBhYm91dCB0aGUgMzItYml0IFNJRC4gRG9lcyBp dCBtZWFuIHdlIG1heSBjb21lIGJhY2sgc29tZWRheSB0byBjb25zaWRlcg0KaG93IHRvIHVzZSBh biBvcmRlcmVkIGxpc3Qgb2YgU0lEcyBpbnN0ZWFkIG9mIGFuIG9yZGVyZWQgbGlzdCBvZiBJUHY2 IGFkZHJlc3NlcyB0byByZXByZXNlbnQgYW4gZXhwbGljaXQgcGF0aC4gSWYgc28sIEkgd29uZGVy IHdoeSBub3QgZGlyZWN0bHkgdXNlIGFuIG9yZGVyZWQgbGlzdCBvZiAoTVBMUykgbGFiZWxzIHJh dGhlciB0aGFuIGFuIG9yZGVyIGxpc3Qgb2YgMzItYml0IFNJRHMuIEJ5IHVzaW5nIGFuIG9yZGVy ZWQgbGlzdCBvZiBsYWJlbHMNCihpLmUuLCBhIGxhYmVsIHN0YWNrKSBpbiB0aGUgcGFja2V0LCB0 aGUgdW5kZXJsYXkgY291bGQgYmUgSVB2NCwgSVB2NiBhbmQgZXZlbiBNUExTLiBJbiBvdGhlciB3 b3Jkcywgc3VjaCBhbiBTUiBoZWFkZXIgaXMgdHJhbnNwb3J0LWluZGVwZW5kZW50LiBJbiBhIHdv cmQsIEkganVzdCB3b25kZXIgd2hldGhlciB3ZSBkbyBuZWVkIHNvIG1hbnkgdmFyaW91cyBzb2x1 dGlvbnMuDQoNCg0KDQpCZXN0IHJlZ2FyZHMsDQoNClhpYW9odQ0K --_000_E0A1DE675FEC854ABF07D319E556FE64467E13ECxmbrcdx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmO2ZvbnQtc2l6ZToxMXB0 O2NvbG9yOmJsYWNrIj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9t OiBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKSBbc3ByZXZpZGlAY2lzY28uY29tXTxicj4NCiZn dDsgUmVjZWl2ZWQ6IFRodXJzZGF5LCAxMyBOb3YgMjAxNCwgMTM6MTM8YnI+DQomZ3Q7IFRvOiBz cHJpbmdAaWV0Zi5vcmcgW3NwcmluZ0BpZXRmLm9yZ107IHh1eGlhb2h1QGh1YXdlaS5jb20gW3h1 eGlhb2h1QGh1YXdlaS5jb21dPGJyPg0KJmd0OyBTdWJqZWN0OiBSRTogW3NwcmluZ10gRG8gd2Ug cmVhbGx5IG5lZWQgc3VjaCBhIGRpdmVyc2l0eTxicj4NCiZndDsgPGJyPg0KJmd0OyBYaWFvaHUs PGJyPg0KJmd0Ozxicj4NCiZndDtBdCB0aGlzIHN0YWdlIHRoZXJlJ3Mgbm8gbmVlZCB0byBoYXZl IHNob3J0ZXIgc2lkICdzIGZvciBpcHY2IGFsc28gYmVjYXVzZSB0aGUgY3VycmVudCB1c2U8YnI+ DQomZ3Q7IGNhc2VzIGFmZHJlc3NlZCBieSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgZG8gbm90 IHJlcXVpcmUgYW55IGlncCBhbnl3YXkuPGJyPg0KPGJyPg0KSSBtZWFudCAmcXVvdDtpZ3AgZXh0 ZW5zaW9ucyZxdW90OyBvZiBjb3Vyc2UuLi48YnI+DQo8YnI+DQpzLjxicj4NCjxicj4NCiZndDsg SU9XLCBzZWdtZW50czxicj4NCiZndDsgZG8gbm90IHJlcHJlc2VudCBpZ3Agc2hvcnRlc3QgcGF0 aHMgYnV0IHJhdGhlciBhcHBsaWNhdGlvbi9zZXJ2aWNlIGluc3RhbmNlcy48YnI+DQomZ3Q7PGJy Pg0KJmd0OyBXZSBNQVkgd2FudCB0byBjb25zaWRlciBvdGhlciBzaWQgZm9ybWF0cyBidXQgdGhh dCB3b3VsZCBiZSBhbm90aGVyIHVzZSBjYXNlLjxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tIDxicj4NCjxicj4NCkZyb206IFh1eGlhb2h1IFt4dXhpYW9o dUBodWF3ZWkuY29tXTxicj4NCjxicj4NClJlY2VpdmVkOiBUaHVyc2RheSwgMTMgTm92IDIwMTQs IDEwOjIxPGJyPg0KPGJyPg0KVG86IHNwcmluZ0BpZXRmLm9yZyBbc3ByaW5nQGlldGYub3JnXTxi cj4NCjxicj4NClN1YmplY3Q6IFtzcHJpbmddIERvIHdlIHJlYWxseSBuZWVkIHN1Y2ggYSBkaXZl cnNpdHk8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQpIaSw8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpBcyBJIGhhZCBtZW50aW9uZWQgYXQg dGhlIG1pYywgdGhlIElQdjYtU1ItaGVhZGVyIGRyYWZ0IHByb3Bvc2VzIHRvIHVzZSBhbiBvcmRl cmVkIGxpc3Qgb2YgSVB2NiBhZGRyZXNzZXMgdG8gcmVwcmVzZW50IGFuIGV4cGxpY2l0IHBhdGgu IEluIHRoaXMgd2F5LCB0aGVyZSBpcyBubyBuZWVkIGZvciBhbnkgSUdQIGV4dGVuc2lvbi4gVGhh dOKAmXMgZmluZSBhbHRob3VnaCBJIGRvbuKAmXQ8YnI+DQprbm93IHdoZXRoZXIgc3VjaCBhIHRy YWRlLW9mZiBpcyBtdWNoIHdvcnRod2hpbGUgKGkuZS4sIGVuY2Fwc3VsYXRpb24gb3ZlcmhlYWQg dnMgY29udHJvbCBwbGFuZSBjaGFuZ2UpLiBIb3dldmVyLCBpbiB0aGUgSUdQIGV4dGVuc2lvbiBm b3IgU1IgZHJhZnRzLCB0aGVyZSBhcmUgc3RpbGwgc29tZSBkZXNjcmlwdGlvbnMgYWJvdXQgdGhl IDMyLWJpdCBTSUQuIERvZXMgaXQgbWVhbiB3ZSBtYXkgY29tZSBiYWNrIHNvbWVkYXkgdG8gY29u c2lkZXI8YnI+DQpob3cgdG8gdXNlIGFuIG9yZGVyZWQgbGlzdCBvZiBTSURzIGluc3RlYWQgb2Yg YW4gb3JkZXJlZCBsaXN0IG9mIElQdjYgYWRkcmVzc2VzIHRvIHJlcHJlc2VudCBhbiBleHBsaWNp dCBwYXRoLiBJZiBzbywgSSB3b25kZXIgd2h5IG5vdCBkaXJlY3RseSB1c2UgYW4gb3JkZXJlZCBs aXN0IG9mIChNUExTKSBsYWJlbHMgcmF0aGVyIHRoYW4gYW4gb3JkZXIgbGlzdCBvZiAzMi1iaXQg U0lEcy4gQnkgdXNpbmcgYW4gb3JkZXJlZCBsaXN0IG9mIGxhYmVsczxicj4NCihpLmUuLCBhIGxh YmVsIHN0YWNrKSBpbiB0aGUgcGFja2V0LCB0aGUgdW5kZXJsYXkgY291bGQgYmUgSVB2NCwgSVB2 NiBhbmQgZXZlbiBNUExTLiBJbiBvdGhlciB3b3Jkcywgc3VjaCBhbiBTUiBoZWFkZXIgaXMgdHJh bnNwb3J0LWluZGVwZW5kZW50LiBJbiBhIHdvcmQsIEkganVzdCB3b25kZXIgd2hldGhlciB3ZSBk byBuZWVkIHNvIG1hbnkgdmFyaW91cyBzb2x1dGlvbnMuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K QmVzdCByZWdhcmRzLDxicj4NCjxicj4NClhpYW9odQ0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E0A1DE675FEC854ABF07D319E556FE64467E13ECxmbrcdx01ciscoc_-- From nobody Sun Nov 16 10:13:06 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013671A06FD for ; Sun, 16 Nov 2014 10:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.133 X-Spam-Level: X-Spam-Status: No, score=-0.133 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, FRT_LOLITA1=1.865, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xW-gK4wmnQ67 for ; Sun, 16 Nov 2014 10:12:55 -0800 (PST) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A545A1A07BC for ; Sun, 16 Nov 2014 10:12:54 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id m20so2663820qcx.12 for ; Sun, 16 Nov 2014 10:12:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=6y9r6X/VcA/kdgWYFxsq0d32umABjqwn/Y0d1Pzuy4s=; b=jqdtl/LhVvrLOSEiwuTKjix4t8Lqpgq/4fdYvQkcdd5nB/lsm7fsrOaXGYBNjKXt8M 35V/8wJ7+k404VkgXcvNu40MW0YY9heysM+HoOgcGXMC/2zGixggTVvJcnnDRtnYkhIg 7AArx5LE7U0b0p7wsYtiwYPFXCOUg9r4orgTjqvDu4pkeYamto/DcunaqmMai+tMjADr AZZzM7dF9N792AVrgDcJVO2xn9IVcJKkpdqinqD75bstt3LlHHr2m0SwJlzfGSswUdOK qCWASs/8pPbFqnnggjqT9qrGQ88abjoJIWAK5Igiwwv6REiOzvqY+HnPeuzMG0SD3oI9 Do0A== MIME-Version: 1.0 X-Received: by 10.224.7.200 with SMTP id e8mr28294189qae.77.1416161573715; Sun, 16 Nov 2014 10:12:53 -0800 (PST) Received: by 10.140.94.173 with HTTP; Sun, 16 Nov 2014 10:12:53 -0800 (PST) Date: Sun, 16 Nov 2014 10:12:53 -0800 Message-ID: From: Bruno Rijsman To: spring@ietf.org Content-Type: multipart/alternative; boundary=001a11c22dc68bc8000507fdcf40 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/maYGvcUDZXM0iavxs5s4PkjVc88 Subject: [spring] Comments on draft-filsfils-spring-segment-routing-msdc-00 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 18:13:00 -0000 --001a11c22dc68bc8000507fdcf40 Content-Type: text/plain; charset=UTF-8 *See >>> below for some comments on * *draft-filsfils-spring-segment-routing-msdc-00* *-- Bruno* Tier-3 +-----+ |NODE | +->| 5 |--+ | +-----+ | Tier-2 | | Tier-2 +-----+ | +-----+ | +-----+ +------------>|NODE |--+->|NODE |--+--|NODE |-------------+ | +-----| 3 |--+ | 6 | +--| 9 |-----+ | | | +-----+ +-----+ +-----+ | | | | | | | | +-----+ +-----+ +-----+ | | | +-----+---->|NODE |--+ |NODE | +--|NODE |-----+-----+ | | | | +---| 4 |--+->| 7 |--+--| 10 |---+ | | | | | | | +-----+ | +-----+ | +-----+ | | | | | | | | | | | | | | +-----+ +-----+ | +-----+ | +-----+ +-----+ |NODE | |NODE | Tier-1 +->|NODE |--+ Tier-1 |NODE | |NODE | | 1 | | 2 | | 8 | | 11 | | 12 | +-----+ +-----+ +-----+ +-----+ +-----+ | | | | | | | | A O B O <- Servers -> Z O O O Figure 1: 5-stage Clos topology *>>> Comment #1 start. * *This figure appears to be a mixture between figure 1 (traditional topology) and figure 2 (3-stage folded Clos topology) in draft-ietf-rtgwg-bgp-routing-large-dc-00. In a proper 5-stage folded Clos topology, there would be a full mesh from each tier N to tier N+1 (e.g. node 3 would not only be connected to nodes 5 and 6 but also to nodes 7 and 8). Note that your numbering of the tiers is the reverse of the number of the tiers in draft-ietf-rtgwg-bgp-routing-large-dc-00 which causes some confusion later on in this document. Here is a suggested for a more accurate 5-stage folded Clos figure:* +-------+ +-------+ | SS1 | | SS2 | Super spine switches +-------+ +-------+ | | | | | | | | +-----------------+ | | | | | | | | +--------+ | | | | | +-----------------+ | +-----------------|-|----+ | +--------+ | | | | | +------------------------+ | | | | +---------------+ | | | | | | +---------------+ | | | | | | | | | | | | +-------+ +-------+ +-------+ +-------+ | S1 | | S2 | | S3 | | S4 | Spine switches +-------+ +-------+ +-------+ +-------+ | | | | | | | | | | | | | | | | +------+ | | | | | | +------+ +------+ | | | | | | +------+ | +----|-|-|----+ | | | | +----|-|-|----+ | | | | | | | +-------------+ | | | | | +-------------+ | | | | +------+ | | | | | | | +------+ | | | | | | | +----|-+ | | | | | | +----|-+ | | | | | | | | | | | | | | | | | | | +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ | L1 | | L2 | | L3 | | L4 | | L5 | | L6 | | L7 | | L8 | Leaf switches (ToRs) +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ | | | | | | | | | | | | | | | | | | | | | | | | O O O O O O O O O O O O O O O O O O O O O O O O Servers *>>> Comment #1 end. * o Each node is its own AS: For simple and efficient route propagation filtering, Nodes 5, 6, 7 and 8 share the same AS, Nodes 3 and 4 share the same AS, nodes 9 and 10 share the same AS. For efficient usage of the scarce 2-byte private AS pool, different tier-1 nodes might share the same AS. Without loss of generality, we will simplify these details in this document and assume that each node has its own AS. *>>> Comment #2 start.* *The above section is somewhat confusion and appears to be self-contradictory. The title says that each node has its own AS. Then the first paragraph contradicts that and says that certain nodes definitely do have the same AS number. Then the next paragraph says that certain nodes might have the same AS number. Then the final paragraph says that each node has its own AS number.* *Suggested text:* *In real-life deployments there are various ways in which AS numbers can be assigned to switches.* *One option is to use a single AS for all the switches in the entire data center. In this case IGBP sessions are used everywhere with next-hop-self policies to force the traffic along the desired path.* *Another option is to make each tier an AS and use EBGP sessions between the tiers. In this case all switches within a given tier are in the same AS and EBGP sessions are used between the tiers.* *A third option is to assign a different AS number to each switch. In this case each switch is a separate AS and EBGP sessions are used everywhere.* *In this document we assume, without loss of generality, the third option.* *>>> Comment #2 end.* o The forwarding plane at Tier-2 and Tier-1 is MPLS. o The forwarding plane at Tier-3 is either IP2MPLS (if the host sends IP traffic) or MPLS2MPLS (if the host sends MPLS- encapsulated traffic). *>>> Comment #3 start.* *The way you numbered the tiers in your diagram, MPLS is in tier-2 and tier-3, and tier-1 is either IP2MPLS or MPLS. (Note that the numbering of the tiers in your diagram is the reverse from the numbering in draft-ietf-rtgwg-bgp-routing-large-dc-00 which is likely the source of the confusion.)* *Suggested text:* *o The forwarding plane between the spine switches and the super spine switches is MPLS* *o The forwarding plane between the leaf switches (= ToR switches) and the spine switches is MPLS* *o The forwarding plane between the servers and the leaf switches (= ToR switches) may be MPLS or IP.* *>>> Comment #3 end.* In this document, we also refer to the Tier-3, Tier-2 and Tier-1 switches respectively as Spine, Leaf and ToR (top of rack) switches. When a ToR switch acts as a gateway to the "outside world", we call it a border switch. *>>> Comment #4 start.* *I believe it is common to consider the ToR switches (i.e. the switches that are connected to the servers) to be the leaf switches.* *I would suggest the following terminology:* *o ToR switch = leaf switch* *o Spine switch* *o Super spine switch* *I also believe that it is more common to number the tiers starting from the bottom (leaf) with index 0:* *o ToR switch = leaf switch = tier 0* *o Spine switch = tier 1* *o Super spine switch = tier 2* *>>> Comment #4 end.* Node 11 sends the following eBGP3107 update to Node 10: . NLRI: 1.1.1.11/32 . Label: Implicit-Null . Next-hop: Node11's interface address on the link to Node10 . AS Path: {11} . BGP-Prefix Attribute: Index 11 Node 10 receives the above update. As it is SR capable, Node10 is able to interpret the BGP-Prefix Attribute and hence allocates the label 16011 to the NLRI (instead of asking a "random/local" label from its label manager). The implicit-null label in the update signals to Node 10 that it is the penultimate hop and MUST pop the top label on the stack before forwarding traffic for this prefix to Node 11. Then, Node 10 sends the following eBGP3107 update to Node 7: . NLRI: 1.1.1.11/32 . Label: 16011 . Next-hop: Node10's interface address on the link to Node7 . AS Path: {10, 11} . BGP-Prefix Attribute: Index 11 *>>> Comment #5 start.* *As described here, this proposal requires that node 10 has a-priori knowledge of the globally significant label which must be assigned to prefix 1.1.1.11/32 .* *This is not only true for node 10, but it is also true for every other node connected to node 11 which receives prefix 1.1.1.11/32 with an implicit null label. * *From a practical operational view, it might require that every node has a-priori knowledge of the binding of MPLS labels to nodes. What this means, in effect, is that the BGP signaling only used for reachability detection, and not for distribution of label to node bindings.* *Providing each node with a-priori knowledge of label to node binding for every node in the POD may be too much of a configuration burden for most operators.* *This problem is solved later on in this draft using the I-D.keyupate-idr-bgp-prefix-sid mechanism (although the problem is still there for transition scenarios).* *Alternatively, avoiding the need for pre-configured label-to-prefix binding can also be achieved by making the following BGP implementation changes without any on-the-wire protocol change.* *1. Each ultimate hop node is configured to advertise its global label instead of implicit null.* *2. Each node which receives a BGP-LU advertisement is configured to: * *2a) Not allocate a new locally significant label when it does a next-hop self. Instead, it keeps the received label. This behavior could be restricted to a particular label block.* *2b) Pop the label (i.e. do a PHP) when it is forwarding the packet to the ultimate hop (which can be detected using the AS-path) despite the fact that the ultimate hop advertised a real label instead of an implicit null label.* *>>> Comment #5 end.* ----------------------------------------------- Incoming label | outgoing label | Outgoing or IP destination | | Interface ------------------+----------------+----------- 16011 | 16011 | ECMP{7, 8} 1.1.1.11/32 | 16011 | ECMP{7, 8} ------------------+----------------+----------- Figure 4: Node-4 Forwarding Table *>>> Comment #6 start.* *In the example topology, the spine switches were not fully meshed to the super spine switches. In a real life topology they would be fully meshed, and the ECMP set out be a 4-way ECMP set ECMP{5,6,7,8}* *>>> Comment #6 end.* ----------------------------------------------- Incoming label | outgoing label | Outgoing or IP destination | | Interface ------------------+----------------+----------- 16011 | 16011 | 10 1.1.1.11/32 | 16011 | 10 ------------------+----------------+----------- Figure 5: Node-7 Forwarding Table *>>> Comment #6 start.* *In the example topology, the spine switches were not fully meshed to the super spine switches. In a real life topology they would be fully meshed, and the ECMP set out be a 2-way ECMP set ECMP{9,10}* *>>> Comment #6 end.* 3.3. Network Design Variation A network design choice could consist of switching all the traffic through tier-2 and tier-3 as MPLS traffic. In this case, one could filter away the IP entries at nodes 4, 7 and 10. This might be beneficial in order to optimize the forwarding table size. A network design choice could consist in allowing the hosts to send MPLS-encapsulated traffic (based on EPE use-case, [I-D.filsfils-spring-segment-routing-central-epe]). For example, Node 1 would receive Node11-destined MPLS-encapsulated traffic from its attached host A and would switch this traffic on the basis of the MPLS entry for 16011 (instead of classically receiving IP traffic from A and performing an IPtoMPLS switching operation). *>>> Comment #7 start.* *It would be good to point out explicitly that the second approach allows the hosts to send a multi-label stack (for example to implement egress peer engineering as described later in this I-D). If IP forwarding is used between leaf switches, then this would require some MPLS over IP-tunnel approach (e.g. MPLS-over-GRE). Using MPLS as the base tunnel mechanism is more consistent and allows other features to be supported that cannot be implemented with MPLS-over-IP-tunnel based approaches (e.g. the capacity optimization use case described in section 4.4 of the I-D).* *>>> Comment #7 end.* From a signaling viewpoint, nothing would change as even if Node6 does not understand the BGP-Prefix Segment attribute, it does propagate it unmodified to its neighbors. From a label allocation viewpoint, the only difference is that Node7 would allocate a dynamic label to the prefix 1.1.1.11/32 (e.g. 12345) and would advertise that label to its neighbor Node4. *>>> Comment #8 start.* *There may be one change which is required on on the legacy Node7.* *We have to make sure that the MPLS label which is allocated by Node7 does not "collide" with the globally significant labels. For example, things would break if legacy Node7 happen happens to dynamically allocate a 1600x label. This can be avoided by introducing a configuration knob in the label allocation subsystem of the switch for "off-limits label blocks".* *>>> Comment #8 end.* --001a11c22dc68bc8000507fdcf40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=C2=A0

See >>> below for some comments on=C2=A0draft-filsfils-spring-segment-routing-msdc-00

=C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Tier-3

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

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |NODE |

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 +->|=C2=A0 5=C2=A0 |--+

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

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Tier-2=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 Tier-2

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

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 +------------>|NODE |--+->|NODE |--+--|NODE |-------------+

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-----|=C2=A0 3=C2=A0 |--+=C2=A0 |=C2=A0 6=C2=A0 |=C2=A0 +--|=C2=A0 9=C2=A0 |-----+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

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

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |

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

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 | +-----+---->|NODE |--+=C2=A0 |NODE | =C2=A0+--|NODE |-----+-----+ |

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0 | +---|=C2=A0 4=C2=A0 |--+->|=C2=A0 7=C2=A0 |--+--|=C2=A0 10=C2=A0 |---+ |=C2=A0=C2=A0=C2=A0=C2=A0 | |

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

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0 | |

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

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |NODE | |NODE | Tier-1=C2=A0=C2=A0 +->|NODE |--+=C2=A0=C2=A0 Tier-1 |NODE | |NODE |

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0 1=C2=A0 | |=C2=A0 2=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0 8=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 | 11=C2=A0 | |=C2=A0 12 |

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

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 | |=C2=A0=C2=A0=C2=A0=C2=A0 | |

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 A O=C2=A0=C2=A0=C2=A0=C2=A0 B O=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 <- Servers ->=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Z O=C2=A0=C2=A0=C2=A0=C2=A0 O O=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Figure 1: 5-stage Clos topology

=C2=A0

=C2=A0

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

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | SS1=C2=A0=C2=A0 |=C2=A0 | SS2=C2=A0=C2=A0 |=C2=A0 Super spine switches

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

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 | | | |=C2=A0=C2=A0=C2=A0 | | | |

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

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

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

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

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

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

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0 |=C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0 |=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0 |=C2=A0

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

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | S1 =C2=A0=C2=A0=C2=A0|=C2=A0 | S2 = =C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| S3=C2=A0=C2=A0=C2=A0 |=C2=A0 | S4=C2=A0=C2=A0=C2=A0 |=C2=A0 Spine switches

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

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | | | |=C2=A0=C2=A0=C2=A0 | | | |=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| |= | |=C2=A0=C2=A0=C2=A0 | | | |

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

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

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

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

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

= =C2=A0|=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0 =C2=A0|=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |

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

|= L1=C2=A0 |=C2=A0 | L2=C2=A0 |=C2=A0 | L3=C2=A0 |=C2=A0 | L4=C2=A0 |=C2=A0 | L5=C2=A0 |=C2=A0 | L6=C2=A0 |=C2=A0 | L7=C2=A0 |=C2=A0 | L8 =C2=A0|=C2=A0 Leaf switches (ToRs)

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

= =C2=A0| | |=C2=A0=C2=A0=C2=A0 | | |=C2=A0=C2=A0=C2=A0 | | |=C2=A0=C2=A0=C2=A0 | | |=C2=A0=C2=A0=C2=A0 | | |=C2=A0=C2=A0=C2=A0 | | |=C2=A0=C2=A0=C2=A0 | | |=C2=A0=C2=A0=C2=A0 | | |

= =C2=A0O O O=C2=A0=C2=A0=C2=A0 O O O=C2=A0=C2=A0=C2=A0 O O O=C2=A0=C2=A0=C2=A0 O O O=C2=A0=C2=A0=C2=A0 O O O=C2=A0=C2=A0=C2=A0 O O O=C2=A0=C2=A0=C2=A0 O O O=C2=A0=C2=A0=C2=A0 O O O =C2=A0=C2=A0Servers

=C2=A0

=C2=A0

=C2=A0

=C2=A0=C2=A0 o=C2=A0 Each node is its own AS:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 For simple and efficient route propagation filtering, Nodes 5,

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 6, 7 and 8 share the same AS, Nodes 3 and 4 share the same AS,

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 nodes 9 and 10 share the same AS.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 For efficient usage of the scarce 2-byte private AS pool,

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 different tier-1 nodes might share the same AS.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Without loss of generality, we will simplify these details in

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 this document and assume that each node has its own AS.

=C2=A0

=C2=A0

=C2=A0

=C2=A0=C2=A0 o=C2=A0 The forwarding plane at Tier-2 and Tier-1 is MPLS.

=C2=A0

=C2=A0=C2=A0 o=C2=A0 The forwarding plane at Tier-3 is either IP2MPLS (if the host

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 sends IP traffic) or MPLS2MPLS (if the host sends MPLS-

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 encapsulated traffic).

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0=C2=A0 In this document, we also refer to the Tier-3, Tier-2 and Tier-1

=C2=A0=C2=A0 switches respectively as Spine, Leaf and ToR (top of rack) switches.=

=C2=A0=C2=A0 When a ToR switch acts as a gateway to the "outside world", we call

=C2=A0=C2=A0 it a border switch.

=C2=A0

=C2=A0

=C2=A0

=C2=A0=C2=A0 Node 11 sends the following eBGP3107 update to Node 10:

=C2=A0

=C2=A0=C2=A0 . NLRI:=C2=A0 1.1.1.11/32

=C2=A0=C2=A0 . Label: Implicit-Null

=C2=A0=C2=A0 . Next-hop: Node11's interface address on the link to Node10

=C2=A0=C2=A0 . AS Path: {11}

=C2=A0=C2=A0 . BGP-Prefix Attribute: Index 11

=C2=A0

=C2=A0=C2=A0 Node 10 receives the above update.=C2=A0 As it is SR capable, Node10 is

=C2=A0=C2=A0 able to interpret the BGP-Prefix Attribute and hence allocates the

=C2=A0=C2=A0 label 16011 to the NLRI (instead of asking a "random/local" label

=C2=A0=C2=A0 from its label manager).=C2=A0 The implicit-null label in the update

=C2=A0=C2=A0 signals to Node 10 that it is the penultimate hop and MUST pop the

=C2=A0=C2=A0 top label on the stack before forwarding traffic for this prefix to

=C2=A0=C2=A0 Node 11.

=C2=A0

=C2=A0=C2=A0 Then, Node 10 sends the following eBGP3107 update to Node 7:

=C2=A0

=C2=A0=C2=A0 . NLRI:=C2=A0 1.1.1.11/32

=C2=A0=C2=A0 . Label: 16011

=C2=A0=C2=A0 . Next-hop: Node10's interface address on the link to Node7

=C2=A0=C2=A0 . AS Path: {10, 11}

=C2=A0=C2=A0 . BGP-Prefix Attribute: Index 11

=C2=A0

1.1.1.11/32.

1.1.1.11/32 with an implicit null label.=C2=A0

=C2=A0

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

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Incoming label=C2=A0=C2=A0=C2=A0 | outgoing label | Outgoing

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or IP destination |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Interface

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

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 16011=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 16011=C2=A0=C2=A0=C2=A0=C2=A0 | ECMP{7, 8}

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A01.1.1.11/32=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 16011=C2=A0=C2=A0=C2=A0=C2=A0 | ECMP{7, 8}

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

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Figure 4: Node-4 Forwarding Table

=C2=A0

=C2=A0

=C2=A0

=C2=A0

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

=C2=A0 =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Incoming label=C2= =A0=C2=A0=C2=A0 | outgoing label | Outgoing

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 or IP destination |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Interface

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

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 16011=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 16011=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 10

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.1.1.11/32=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 16011=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 10

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

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Figure 5: Node-7 Forwarding Table

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

3.3.=C2=A0 Network Design Variation

=C2=A0

=C2=A0=C2=A0 A network design choice could consist of switching all the traffic

=C2=A0=C2=A0 through tier-2 and tier-3 as MPLS traffic.=C2=A0 In this case, one could

=C2=A0=C2=A0 filter away the IP entries at nodes 4, 7 and 10.=C2=A0 This might be=

=C2=A0=C2=A0 beneficial in order to optimize the forwarding table size.

=C2=A0

=C2=A0=C2=A0 A network design choice could consist in allowing the hosts to send

=C2=A0=C2=A0 MPLS-encapsulated traffic (based on EPE use-case,

=C2=A0=C2=A0 [I-D.filsfils-spring-segment-routing-central-epe]).=C2=A0 For example,

=C2=A0=C2=A0 Node 1 would receive Node11-destined MPLS-encapsulated traffic from

=C2=A0=C2=A0 its attached host A and would switch this traffic on the basis of the

=C2=A0=C2=A0 MPLS entry for 16011 (instead of classically receiving IP traffic

=C2=A0=C2=A0 from A and performing an IPtoMPLS switching operation).

=C2=A0

=C2=A0

=C2=A0=C2=A0 From a signaling viewpoint, nothing would change as even if Node6

=C2=A0=C2=A0 does not understand the BGP-Prefix Segment attribute, it does

=C2=A0=C2=A0 propagate it unmodified to its neighbors.

=C2=A0

=C2=A0=C2=A0 From a label allocation viewpoint, the only difference is that Node7

=C2=A0=C2=A0 would allocate a dynamic label to the prefix 1.1.1.11/32 (e.g.

=C2=A0=C2=A0 12345) and would advertise that label to its neighbor Node4.

=C2=A0

=C2=A0

=C2=A0

--001a11c22dc68bc8000507fdcf40-- From nobody Sun Nov 16 11:14:58 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030011A1A8C for ; Sun, 16 Nov 2014 11:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9sDXD2lFtbw for ; Sun, 16 Nov 2014 11:14:53 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35A01A1A8A for ; Sun, 16 Nov 2014 11:14:52 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id rp18so615053iec.25 for ; Sun, 16 Nov 2014 11:14:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wyfCRtyVr5Nxw5RDsYb3fz1aSV25ulLE2YO+HTtlV0Q=; b=cQqY0cArwFlT4h+9LhJB53MXX213H+3cVmjf8Hub1yfXN43VubmXlYZr2FhlquUi1Q EElUOTk0QRjnShXLp9Ez0G2UdrplUI5F2U2o4Z6It/0SbUcg8hwnO/FayJ0YikECpQfI LAs1QcwvbXwKjgaRGmAXGeJoYu5ZO66gCI82babCGUiYbCaLe2iRxHWZe4PcBQEs7w7Q 6fyLBHqAsw4InnXngIxvSPTO7+V2XExLqjP5ERAhGchODev0DMeOl3Yt5fimkwR6vJnX 9EdqdhAThUKMz0mbiGK069rkEufCRrXZImsmVzn1GLjUi2LUOg8vQnnHCPjzeoqeNals pNoA== MIME-Version: 1.0 X-Received: by 10.50.138.197 with SMTP id qs5mr20921917igb.17.1416165292119; Sun, 16 Nov 2014 11:14:52 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.107.171.149 with HTTP; Sun, 16 Nov 2014 11:14:51 -0800 (PST) In-Reply-To: References: Date: Sun, 16 Nov 2014 20:14:51 +0100 X-Google-Sender-Auth: 1jN_Sgbdkj3tZDpNNwCyyRhZCtM Message-ID: From: Robert Raszuk To: "spring@ietf.org" Content-Type: multipart/alternative; boundary=089e010d9e322e1f510507fead76 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/AXNR4nQohQXfk5UIZ3HT9wxNC64 Cc: Bruno Rijsman Subject: Re: [spring] Comments on draft-filsfils-spring-segment-routing-msdc-00 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2014 19:14:55 -0000 --089e010d9e322e1f510507fead76 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, While I do agree with all comments made by Bruno below I have few a bit higher level questions to the applicability of this work. 1. Assume I have CLOS non blocking DC fabric. Why would I want to complicate life by breaking full ECMP rather then utilize it as efficiently as possible ? Two uses cases are known: link/node "overload" as well as weighted ECMP. But one solution for those is already provided in draft-lapukhov-bgp-sdn-00= . 2. Assume my service for tenant virtualization is an overlay based. Same for appliances & storage clusters. Why it is the transport network role to steer packets between my services rather then pure overlay solution (example: draft-rfernando-bess-service-chaining-00 or any similar analogy) ? By proper prefix advertisement there is already sufficient mechanism to enforce flow via required services. So if my overlay starts on compute nodes and are orchestrated by openstack + network overlay how would the transport be able to properly guide the flows as well as properly apply source based headers to packets involved ? 3. As we are providing a case for EBGP based DC fabric it seems to me that we can easily use various BGP traffic engineering well known by ISPs methods used every day globally to switch to particular destinations along the paths which operator requires. Simple use of LPM + eBGP policy gives so much control today on shipping hardware that I find it really puzzling why to load a new operational burden on top. Best, R. =E2=80=8B> =E2=80=8B On Sun, Nov 16, 2014 at 7:12 PM, Bruno Rijsman wrote: > > > *See >>> below for some comments on * > *draft-filsfils-spring-segment-routing-msdc-00* > > *-- Bruno* > --089e010d9e322e1f510507fead76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
<= br>
While I do agree with all comments made by= Bruno below I have few a bit higher level questions to the applicability o= f this work.


1. Assume I have CLOS non blocking DC fa= bric. Why would I want to complicate life by breaking full ECMP rather then= utilize it as efficiently as possible ?=C2=A0

Two uses cases are known: link/node &quo= t;overload" as well as weighted ECMP. But one solution for those is al= ready provided in draft-lapukhov-bgp-sdn-00.
<= br>

2. Assum= e my service for tenant virtualization is an overlay based. Same for applia= nces & storage clusters. Why it is the transport network role to steer = packets between my services rather then pure overlay solution (example: dra= ft-rfernando-bess-service-chaining-00 or any similar analogy) ?=C2=A0
=

By proper prefix = advertisement there is already sufficient mechanism to enforce flow via req= uired services.=C2=A0

So if my overlay starts on compute nodes and are orchestrated by = openstack + network overlay how would the transport be able to properly gui= de the flows as well as properly apply source based headers to packets invo= lved ?=C2=A0


3. As we are providing a case for EBGP b= ased DC fabric it seems to me that we can easily use various BGP traffic en= gineering well known by ISPs methods used every day globally to switch to p= articular destinations along the paths which operator requires. Simple use = of LPM + eBGP policy gives so much control today on shipping hardware that = I find it really puzzling why to load a new operational burden on top.=C2= =A0


Best,
R.


=E2=80=8B> =E2=80=8BOn Sun, Nov 16, 2014 at 7:12 PM, Bruno Rijsman <brunorijsman@gmai= l.com> wrote:

=C2=A0

See >>> below for some comments on=C2=A0draft-filsfils-spring-segment-routing-msdc-00

Thread-Topic: [spring] Do we really need such a diversity Thread-Index: Ac//mhfv/nmQmNRxRXm8l2bNI6Q7tQD3KvlQ Date: Tue, 18 Nov 2014 21:59:35 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F444E48@eusaamb105.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008633F444E48eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyuXRPrK5NRnaIwZMuHov1ux8xWRy/8JvR gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4MrYdMyoYJ97xd+eaewNjAdcuxg5OSQETCQm XrzPDGGLSVy4t56ti5GLQ0jgCKPEx48gCRBnOZDz9AUrSBWbgJ7Ex6k/2UFsEQFTifMzzoN1 MwuoSyzbf4EFxBYWsJD4fvY/M0SNpcSsa2tZIWwjiT3LHwJt4OBgEVCVeNKnAxLmFfCVWPj0 EViJkICPRP++nWBjOIHiK2buZAOxGYGO+35qDRPEKnGJW0/mM0EcLSCxZM95qAdEJV4+/scK YStJTFp6jhWiPl/iyq6fLBC7BCVOznzCMoFRdBaSUbOQlM1CUjYL6FJmAU2J9bv0IUoUJaZ0 P2SHsDUkWufMZUcWX8DIvoqRo7Q4tSw33chgEyMwoo5JsOnuYNzz0vIQowAHoxIP7wbXrBAh 1sSy4srcQ4zSHCxK4ryzaucFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBcdEPz1tTaQ0ec pWfs3XChXegU49VUVq/TTw6fuJrGfPz2pdcydQ3tV7Sfv3q0xbK31OPN2uTUrvNZi6b8WVyy dM/5DuE/0reObflVkX+WsZE/2+bynwN/M9ufPDtd91+y4HbFlP1P7630Cf75/9FOpsKISHVG ZfXCjO2M0u4+Mms2O4n17bnTp8RSnJFoqMVcVJwIAM335FuJAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/spring/iHVzm-5HEy-H_GbKWek8swD7iok Cc: "spring@ietf.org" Subject: Re: [spring] Do we really need such a diversity X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 21:59:39 -0000 --_000_1B502206DFA0C544B7A60469152008633F444E48eusaamb105erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3RlZmFubywNCg0KPT09PT09PT09PT09PT09DQo+QXQgdGhpcyBzdGFnZSB0aGVyZSdzIG5v IG5lZWQgdG8gaGF2ZSBzaG9ydGVyIHNpZCAncyBmb3IgaXB2NiBhbHNvIGJlY2F1c2UgdGhlIGN1 cnJlbnQgdXNlDQo+IGNhc2VzIGFmZHJlc3NlZCBieSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMg ZG8gbm90IHJlcXVpcmUgYW55IGlncCBhbnl3YXkuDQpJIG1lYW50ICJpZ3AgZXh0ZW5zaW9ucyIg b2YgY291cnNlLi4uDQpzLg0KPT09PT09PT09PT09PT09PT0NCg0KV2UgaGF2ZSBJR1AgZXh0ZW5z aW9ucyBmb3IgTVBMUyBkYXRhIHBsYW5lIChldmVuIGZvciBJUHY2KSBidXQgSSBzYXcgc29tZSBl eHRlbnNpb25zIGZvciBJUHY2IGRhdGEgcGxhbmU/DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1pc2lzLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25zLTAzDQoNCg0KU2Vj dGlvbiAyLjINCg0KICBBbiBpcHY2IGFkZHJlc3MgU0lEIGlzIGVuY29kZWQgaW4gMTYgb2N0ZXRz IChJUHY2IEFkai1TSUQgaXMgZGVmaW5lZA0KICAgaW4gW0ktRC5wcmV2aWRpLTZtYW4tc2VnbWVu dC1yb3V0aW5nLWhlYWRlcl0pLg0KDQpDb3VsZCB5b3UgcGxlYXNlIGNsYXJpZnk/IEkgcHJlc3Vt ZSB0aGlzIGlzIG9ubHkgZm9yIElQdjYgQURKIFNJRHM/DQoNCi0tDQpVbWEgQy4NCg0KDQoNCg0K --_000_1B502206DFA0C544B7A60469152008633F444E48eusaamb105erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkg U3RlZmFubyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj49PT09PT09PT09PT09 PT08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQom Z3Q7QXQgdGhpcyBzdGFnZSB0aGVyZSdzIG5vIG5lZWQgdG8gaGF2ZSBzaG9ydGVyIHNpZCAncyBm b3IgaXB2NiBhbHNvIGJlY2F1c2UgdGhlIGN1cnJlbnQgdXNlPGJyPg0KJmd0OyBjYXNlcyBhZmRy ZXNzZWQgYnkgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIGRvIG5vdCByZXF1aXJlIGFueSBpZ3Ag YW55d2F5Ljxicj4NCkkgbWVhbnQgJnF1b3Q7aWdwIGV4dGVuc2lvbnMmcXVvdDsgb2YgY291cnNl Li4uPGJyPg0Kcy48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPj09PT09PT09PT09PT09PT09PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBoYXZlIElHUCBleHRlbnNp b25zIGZvciBNUExTIGRhdGEgcGxhbmUgKGV2ZW4gZm9yIElQdjYpIGJ1dCBJIHNhdyBzb21lIGV4 dGVuc2lvbnMgZm9yIElQdjYgZGF0YSBwbGFuZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXNpcy1z ZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9ucy0wMyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtaXNpcy1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9ucy0wMzwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWN0aW9uIDIuMg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjE0LjRwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNC40cHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDtBbiBpcHY2IGFkZHJlc3MgU0lEIGlzIGVu Y29kZWQgaW4gMTYgb2N0ZXRzIChJUHY2IEFkai1TSUQgaXMgZGVmaW5lZDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNC40cHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgaW4gW0ktRC5wcmV2aWRpLTZtYW4t c2VnbWVudC1yb3V0aW5nLWhlYWRlcl0pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNC40cHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q291bGQgeW91IHBsZWFz ZSBjbGFyaWZ5PyBJIHByZXN1bWUgdGhpcyBpcyBvbmx5IGZvciBJUHY2IEFESiBTSURzPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VW1hIEMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1B502206DFA0C544B7A60469152008633F444E48eusaamb105erics_-- From nobody Tue Nov 18 14:00:36 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFB11A90D5 for ; Tue, 18 Nov 2014 14:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 GolYlf1MdopX for ; Tue, 18 Nov 2014 14:00:23 -0800 (PST) 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 A92241A90D9 for ; Tue, 18 Nov 2014 13:59:58 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-b4-546b65e944c8 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F1.9C.25146.9E56B645; Tue, 18 Nov 2014 16:29:46 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Tue, 18 Nov 2014 16:59:56 -0500 From: Uma Chunduri To: Robert Raszuk , "spring@ietf.org" Thread-Topic: [spring] Comments on draft-filsfils-spring-segment-routing-msdc-00 Thread-Index: AQHQAdGgPJmoN3aT0k+7hKBYaPSjXJxm7hyQ Date: Tue, 18 Nov 2014 21:59:56 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F444E5E@eusaamb105.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008633F444E5Eeusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZXLonUPdVanaIQcMEVoul87YzWjQtbGK2 OH7hN6MDs8fOWXfZPZYs+cnksXvjAqYA5igum5TUnMyy1CJ9uwSujAPz/zAWdDQwVjz9/YW5 gfFCTRcjJ4eEgInExR3PmCFsMYkL99azdTFycQgJHGGUWDCtnwkkISSwnFHiwukCEJtNQE/i 49Sf7CC2iICXxLx3i9lAbGYBLYkNU1axgNjCAoESdxY/Y4GoCZLoWf2JGcI2ktj1bCEriM0i oCpx6fElsDivgK/EiSu/2CEWT2eUmHFrKZDDwcEJNKjrVjZIDSPQcd9PrWGC2CUucevJfCaI owUkluw5D/WAqMTLx/9YIWwliUlLz7FC1OdLTOq6zASxS1Di5MwnLBMYRWchGTULSdksJGWz gK5gFtCUWL9LH6JEUWJK90N2CFtDonXOXHZk8QWM7KsYOUqLU8ty040MNzECI+2YBJvjDsYF nywPMQpwMCrx8G5wzQoRYk0sK67MPcQozcGiJM6rWT0vWEggPbEkNTs1tSC1KL6oNCe1+BAj EwenVAOjIssmS7NvGTZt9m94L++XqH298aqsz+yLUjPvJ+vd3Cr9uI1le6hU+7XjUg0vStQP CFp0/1BRebDEaaLvl4Q1U3c5xShwb+PQj33edPU7R7++rcENIUX/fSJGpXPkvn/Q0PXwdf+V sknkRarWN7EOU1azuTqPpzo196wLWe2h9+aIrZbZsilKLMUZiYZazEXFiQBCWzZClQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/spring/3fJtYZrBQzfQE6juFGpqIvEb188 Cc: Bruno Rijsman Subject: Re: [spring] Comments on draft-filsfils-spring-segment-routing-msdc-00 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 22:00:28 -0000 --_000_1B502206DFA0C544B7A60469152008633F444E5Eeusaamb105erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBTaW1wbGUgdXNlIG9mIExQTSArIGVCR1AgcG9saWN5IGdpdmVzIHNvIG11Y2ggY29udHJvbCB0 b2RheSBvbiBzaGlwcGluZyBoYXJkd2FyZSB0aGF0DQo+IEkgZmluZCBpdCByZWFsbHkgcHV6emxp bmcgd2h5IHRvIGxvYWQgYSBuZXcgb3BlcmF0aW9uYWwgYnVyZGVuIG9uIHRvcC4NCg0KVGhhbmtz IGZvciB0aGUgY2xhcmlmaWNhdGlvbi4NCkl04oCZcyBub3QgYWJvdXQgcHJvdmlzaW9uaW5nIGds b2JhbGx5IHVuaXF1ZSBzaWQgaW5kZXggYnV0IHlvdSBtZWFudCAgcHVzaGluZyBzdGF0ZSB0byBU T1Igb3IgRU9SIHN3aXRjaGVzIHRvIHByb3ZpZGUgdGhlIFNSIGVuY2Fwc3VsYXRpb24uDQoNCi0t DQpVbWEgQy4NCg0KRnJvbTogc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50OiBTdW5kYXksIE5vdmVtYmVyIDE2LCAy MDE0IDExOjE1IEFNDQpUbzogc3ByaW5nQGlldGYub3JnDQpDYzogQnJ1bm8gUmlqc21hbg0KU3Vi amVjdDogUmU6IFtzcHJpbmddIENvbW1lbnRzIG9uIGRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zZWdt ZW50LXJvdXRpbmctbXNkYy0wMA0KDQpIaSwNCg0KV2hpbGUgSSBkbyBhZ3JlZSB3aXRoIGFsbCBj b21tZW50cyBtYWRlIGJ5IEJydW5vIGJlbG93IEkgaGF2ZSBmZXcgYSBiaXQgaGlnaGVyIGxldmVs IHF1ZXN0aW9ucyB0byB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGlzIHdvcmsuDQoNCg0KMS4gQXNz dW1lIEkgaGF2ZSBDTE9TIG5vbiBibG9ja2luZyBEQyBmYWJyaWMuIFdoeSB3b3VsZCBJIHdhbnQg dG8gY29tcGxpY2F0ZSBsaWZlIGJ5IGJyZWFraW5nIGZ1bGwgRUNNUCByYXRoZXIgdGhlbiB1dGls aXplIGl0IGFzIGVmZmljaWVudGx5IGFzIHBvc3NpYmxlID8NCg0KVHdvIHVzZXMgY2FzZXMgYXJl IGtub3duOiBsaW5rL25vZGUgIm92ZXJsb2FkIiBhcyB3ZWxsIGFzIHdlaWdodGVkIEVDTVAuIEJ1 dCBvbmUgc29sdXRpb24gZm9yIHRob3NlIGlzIGFscmVhZHkgcHJvdmlkZWQgaW4gZHJhZnQtbGFw dWtob3YtYmdwLXNkbi0wMC4NCg0KDQoyLiBBc3N1bWUgbXkgc2VydmljZSBmb3IgdGVuYW50IHZp cnR1YWxpemF0aW9uIGlzIGFuIG92ZXJsYXkgYmFzZWQuIFNhbWUgZm9yIGFwcGxpYW5jZXMgJiBz dG9yYWdlIGNsdXN0ZXJzLiBXaHkgaXQgaXMgdGhlIHRyYW5zcG9ydCBuZXR3b3JrIHJvbGUgdG8g c3RlZXIgcGFja2V0cyBiZXR3ZWVuIG15IHNlcnZpY2VzIHJhdGhlciB0aGVuIHB1cmUgb3Zlcmxh eSBzb2x1dGlvbiAoZXhhbXBsZTogZHJhZnQtcmZlcm5hbmRvLWJlc3Mtc2VydmljZS1jaGFpbmlu Zy0wMCBvciBhbnkgc2ltaWxhciBhbmFsb2d5KSA/DQoNCkJ5IHByb3BlciBwcmVmaXggYWR2ZXJ0 aXNlbWVudCB0aGVyZSBpcyBhbHJlYWR5IHN1ZmZpY2llbnQgbWVjaGFuaXNtIHRvIGVuZm9yY2Ug ZmxvdyB2aWEgcmVxdWlyZWQgc2VydmljZXMuDQoNClNvIGlmIG15IG92ZXJsYXkgc3RhcnRzIG9u IGNvbXB1dGUgbm9kZXMgYW5kIGFyZSBvcmNoZXN0cmF0ZWQgYnkgb3BlbnN0YWNrICsgbmV0d29y ayBvdmVybGF5IGhvdyB3b3VsZCB0aGUgdHJhbnNwb3J0IGJlIGFibGUgdG8gcHJvcGVybHkgZ3Vp ZGUgdGhlIGZsb3dzIGFzIHdlbGwgYXMgcHJvcGVybHkgYXBwbHkgc291cmNlIGJhc2VkIGhlYWRl cnMgdG8gcGFja2V0cyBpbnZvbHZlZCA/DQoNCg0KMy4gQXMgd2UgYXJlIHByb3ZpZGluZyBhIGNh c2UgZm9yIEVCR1AgYmFzZWQgREMgZmFicmljIGl0IHNlZW1zIHRvIG1lIHRoYXQgd2UgY2FuIGVh c2lseSB1c2UgdmFyaW91cyBCR1AgdHJhZmZpYyBlbmdpbmVlcmluZyB3ZWxsIGtub3duIGJ5IElT UHMgbWV0aG9kcyB1c2VkIGV2ZXJ5IGRheSBnbG9iYWxseSB0byBzd2l0Y2ggdG8gcGFydGljdWxh ciBkZXN0aW5hdGlvbnMgYWxvbmcgdGhlIHBhdGhzIHdoaWNoIG9wZXJhdG9yIHJlcXVpcmVzLiBT aW1wbGUgdXNlIG9mIExQTSArIGVCR1AgcG9saWN5IGdpdmVzIHNvIG11Y2ggY29udHJvbCB0b2Rh eSBvbiBzaGlwcGluZyBoYXJkd2FyZSB0aGF0IEkgZmluZCBpdCByZWFsbHkgcHV6emxpbmcgd2h5 IHRvIGxvYWQgYSBuZXcgb3BlcmF0aW9uYWwgYnVyZGVuIG9uIHRvcC4NCg0KDQpCZXN0LA0KUi4N Cg0KDQrigIs+IOKAiw0KT24gU3VuLCBOb3YgMTYsIDIwMTQgYXQgNzoxMiBQTSwgQnJ1bm8gUmlq c21hbiA8YnJ1bm9yaWpzbWFuQGdtYWlsLmNvbTxtYWlsdG86YnJ1bm9yaWpzbWFuQGdtYWlsLmNv bT4+IHdyb3RlOg0KDQpTZWUgPj4+IGJlbG93IGZvciBzb21lIGNvbW1lbnRzIG9uIGRyYWZ0LWZp bHNmaWxzLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXNkYy0wMA0KDQotLSBCcnVubw0K --_000_1B502206DFA0C544B7A60469152008633F444E5Eeusaamb105erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+IFNpbXBsZSB1c2Ugb2YgTFBNICYjNDM7IGVCR1AgcG9s aWN5IGdpdmVzIHNvIG11Y2ggY29udHJvbCB0b2RheSBvbiBzaGlwcGluZyBoYXJkd2FyZSB0aGF0 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsgSSBmaW5kIGl0IHJl YWxseSBwdXp6bGluZyB3aHkgdG8gbG9hZCBhIG5ldyBvcGVyYXRpb25hbCBidXJkZW4gb24gdG9w LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JdOKAmXMgbm90IGFib3V0IHByb3Zpc2lvbmluZyBnbG9i YWxseSB1bmlxdWUgc2lkIGluZGV4IGJ1dCB5b3UgbWVhbnQgJm5ic3A7cHVzaGluZyBzdGF0ZSB0 byBUT1Igb3IgRU9SIHN3aXRjaGVzIHRvIHByb3ZpZGUgdGhlIFNSIGVuY2Fwc3VsYXRpb24uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5VbWEgQy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNwcmluZyBbbWFpbHRvOnNwcmluZy1i b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnQgUmFzenVrPGJyPg0K PGI+U2VudDo8L2I+IFN1bmRheSwgTm92ZW1iZXIgMTYsIDIwMTQgMTE6MTUgQU08YnI+DQo8Yj5U bzo8L2I+IHNwcmluZ0BpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gQnJ1bm8gUmlqc21hbjxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW3NwcmluZ10gQ29tbWVudHMgb24gZHJhZnQtZmlsc2ZpbHMt c3ByaW5nLXNlZ21lbnQtcm91dGluZy1tc2RjLTAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPldoaWxlIEkgZG8gYWdyZWUgd2l0aCBhbGwgY29tbWVudHMgbWFkZSBieSBC cnVubyBiZWxvdyBJIGhhdmUgZmV3IGEgYml0IGhpZ2hlciBsZXZlbCBxdWVzdGlvbnMgdG8gdGhl IGFwcGxpY2FiaWxpdHkgb2YgdGhpcyB3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjEuIEFzc3VtZSBJIGhhdmUgQ0xPUyBub24gYmxv Y2tpbmcgREMgZmFicmljLiBXaHkgd291bGQgSSB3YW50IHRvIGNvbXBsaWNhdGUgbGlmZSBieSBi cmVha2luZyBmdWxsIEVDTVAgcmF0aGVyIHRoZW4gdXRpbGl6ZSBpdCBhcyBlZmZpY2llbnRseSBh cyBwb3NzaWJsZSA/Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPlR3byB1c2VzIGNhc2VzIGFyZSBrbm93bjogbGluay9ub2RlICZxdW90 O292ZXJsb2FkJnF1b3Q7IGFzIHdlbGwgYXMgd2VpZ2h0ZWQgRUNNUC4gQnV0IG9uZSBzb2x1dGlv biBmb3IgdGhvc2UgaXMgYWxyZWFkeSBwcm92aWRlZCBpbiBkcmFmdC1sYXB1a2hvdi1iZ3Atc2Ru LTAwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjIuIEFzc3VtZSBteSBzZXJ2aWNlIGZvciB0ZW5hbnQgdmlydHVhbGl6YXRpb24gaXMgYW4g b3ZlcmxheSBiYXNlZC4gU2FtZSBmb3IgYXBwbGlhbmNlcyAmYW1wOyBzdG9yYWdlIGNsdXN0ZXJz LiBXaHkgaXQgaXMgdGhlIHRyYW5zcG9ydCBuZXR3b3JrIHJvbGUgdG8gc3RlZXIgcGFja2V0cyBi ZXR3ZWVuIG15IHNlcnZpY2VzIHJhdGhlciB0aGVuIHB1cmUNCiBvdmVybGF5IHNvbHV0aW9uIChl eGFtcGxlOiBkcmFmdC1yZmVybmFuZG8tYmVzcy1zZXJ2aWNlLWNoYWluaW5nLTAwIG9yIGFueSBz aW1pbGFyIGFuYWxvZ3kpID8mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+QnkgcHJvcGVyIHByZWZpeCBhZHZlcnRpc2VtZW50IHRoZXJl IGlzIGFscmVhZHkgc3VmZmljaWVudCBtZWNoYW5pc20gdG8gZW5mb3JjZSBmbG93IHZpYSByZXF1 aXJlZCBzZXJ2aWNlcy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+U28gaWYgbXkgb3ZlcmxheSBzdGFydHMgb24gY29tcHV0ZSBub2Rl cyBhbmQgYXJlIG9yY2hlc3RyYXRlZCBieSBvcGVuc3RhY2sgJiM0MzsgbmV0d29yayBvdmVybGF5 IGhvdyB3b3VsZCB0aGUgdHJhbnNwb3J0IGJlIGFibGUgdG8gcHJvcGVybHkgZ3VpZGUgdGhlIGZs b3dzIGFzIHdlbGwgYXMgcHJvcGVybHkgYXBwbHkgc291cmNlIGJhc2VkIGhlYWRlcnMNCiB0byBw YWNrZXRzIGludm9sdmVkID8mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4zLiBBcyB3ZSBhcmUgcHJvdmlkaW5nIGEgY2FzZSBmb3Ig RUJHUCBiYXNlZCBEQyBmYWJyaWMgaXQgc2VlbXMgdG8gbWUgdGhhdCB3ZSBjYW4gZWFzaWx5IHVz ZSB2YXJpb3VzIEJHUCB0cmFmZmljIGVuZ2luZWVyaW5nIHdlbGwga25vd24gYnkgSVNQcyBtZXRo b2RzIHVzZWQgZXZlcnkgZGF5IGdsb2JhbGx5IHRvIHN3aXRjaCB0byBwYXJ0aWN1bGFyDQogZGVz dGluYXRpb25zIGFsb25nIHRoZSBwYXRocyB3aGljaCBvcGVyYXRvciByZXF1aXJlcy4gU2ltcGxl IHVzZSBvZiBMUE0gJiM0MzsgZUJHUCBwb2xpY3kgZ2l2ZXMgc28gbXVjaCBjb250cm9sIHRvZGF5 IG9uIHNoaXBwaW5nIGhhcmR3YXJlIHRoYXQgSSBmaW5kIGl0IHJlYWxseSBwdXp6bGluZyB3aHkg dG8gbG9hZCBhIG5ldyBvcGVyYXRpb25hbCBidXJkZW4gb24gdG9wLiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkJlc3QsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5SLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYW1icmlhIE1hdGgmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPuKAizwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZndDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FtYnJpYSBNYXRoJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij7igIs8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwgTm92IDE2LCAyMDE0 IGF0IDc6MTIgUE0sIEJydW5vIFJpanNtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpicnVub3JpanNt YW5AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YnJ1bm9yaWpzbWFuQGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMyRjU0OTYiPlNlZSAmZ3Q7Jmd0OyZndDsgYmVsb3cg Zm9yIHNvbWUgY29tbWVudHMgb24mbmJzcDtkcmFmdC1maWxzZmlscy1zcHJpbmctc2VnbWVudC1y b3V0aW5nLW1zZGMtMDA8L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHA+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMyRjU0OTYiPi0t IEJydW5vPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1B502206DFA0C544B7A60469152008633F444E5Eeusaamb105erics_-- From nobody Tue Nov 18 14:26:32 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C941A9163 for ; Tue, 18 Nov 2014 14:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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.594, 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 byGy2rEV8lRS for ; Tue, 18 Nov 2014 14:26:29 -0800 (PST) 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 56AB11A9132 for ; Tue, 18 Nov 2014 14:26:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1105; q=dns/txt; s=iport; t=1416349589; x=1417559189; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bRDfuXEyeRtx8B/xKuqK5Gw+jGoJ/89WtAlnvj7XLMA=; b=MTUD9hq2JMxsbzFDpu3UwEHwwvf7wliS4pH5RThHQg5rME8aHsbtBk43 9AThdveuTjSAuKC5+SF1n7hkg9UVHnYv6qBaik0BGa0bHIXbsYOU/dfS1 zPCmGGDQveEphxAFv0C3FTRO0jH7a3QRay05FT1URPdoFNb/WEQBsnkGN E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAGTGa1StJV2d/2dsb2JhbABbgw5VXcwmh0cCgRMWAQEBAQF9hAMBAQMBOjoFBQsCAQg2EDIlAQEEDog9CQ3RcwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEkCYRAR0zB4MtgR4BBJJPhF2HKoEzg1WRcYN7gXw5gQMBAQE X-IronPort-AV: E=Sophos;i="5.07,412,1413244800"; d="scan'208";a="373388172" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 18 Nov 2014 22:26:29 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sAIMQSW4015524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Nov 2014 22:26:28 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.182]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Tue, 18 Nov 2014 16:26:28 -0600 From: "Stefano Previdi (sprevidi)" To: Uma Chunduri Thread-Topic: [spring] Do we really need such a diversity Thread-Index: Ac//mhfv/nmQmNRxRXm8l2bNI6Q7tQD3KvlQAA6N4gA= Date: Tue, 18 Nov 2014 22:26:28 +0000 Message-ID: References: <1B502206DFA0C544B7A60469152008633F444E48@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008633F444E48@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.88.107] Content-Type: text/plain; charset="us-ascii" Content-ID: <08CF74FD9F08E24AB2DB17A24F660081@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/yoaTDcMuQ_-LbaMNiPxINPdvb0w Cc: "spring@ietf.org" Subject: Re: [spring] Do we really need such a diversity X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 22:26:31 -0000 On Nov 18, 2014, at 10:59 PM, Uma Chunduri wrote: > Hi Stefano, > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >At this stage there's no need to have shorter sid 's for ipv6 also becau= se the current use > > cases afdressed by existing implementations do not require any igp anyw= ay. > I meant "igp extensions" of course... > s. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =20 > We have IGP extensions for MPLS data plane (even for IPv6) but I saw some= extensions for IPv6 data plane? > https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-03 > =20 > =20 > Section 2.2 > =20 > An ipv6 address SID is encoded in 16 octets (IPv6 Adj-SID is defined > in [I-D.previdi-6man-segment-routing-header]). > =20 > Could you please clarify? I presume this is only for IPv6 ADJ SIDs? correct. As I stated in my original email, the use-case we are working at d= oes not require any igp extension because it's more about using sr as an ov= erlay on top of an infrastructure. s. =20 > =20 > -- > Uma C. > =20 >=20 >=20 >=20 From nobody Thu Nov 20 10:09:47 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A161A1BEF for ; Thu, 20 Nov 2014 09:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.095 X-Spam-Level: X-Spam-Status: No, score=-115.095 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.594, 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 5e0anr-8i5Ca for ; Thu, 20 Nov 2014 09:29:08 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A1241A1BC8 for ; Thu, 20 Nov 2014 09:29:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1907; q=dns/txt; s=iport; t=1416504548; x=1417714148; h=from:to:cc:subject:date:message-id:mime-version; bh=gKMcpiPuy8DdCamSnOW/1dq1JG9c4xzzckKHeqoJjSE=; b=PDU1zx6Xb7WY7MrB551qGqCoekT3nco1uunkiV8YuNlZ3ZmRgwNu09Rh vg2FnAojZCeh/7f6R9I60O/+t1It95f290b3tpHdp3KiMLbfMt3HTJWJs uzm0O1K+6KnQAvbI7gMUOLREZHdzNFqzt9m1QajsR7XNX3jklqBKCmh2R w=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcHADAkblStJA2I/2dsb2JhbABagw5VWQTLV4dJgQkWAQEBAQFyC4QJeRIBgQAnBA4TiDMN1SoBAQEBAQEBAQEBAQEBAQEBAQEWBJEIgzSBHgWSV4IhgVJrhyyWe4N7bQGBR4EDAQEB X-IronPort-AV: E=Sophos;i="5.07,425,1413244800"; d="asc'?scan'208";a="98592659" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-7.cisco.com with ESMTP; 20 Nov 2014 17:29:07 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sAKHT7bB016019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Nov 2014 17:29:07 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Thu, 20 Nov 2014 11:29:07 -0600 From: "Fred Baker (fred)" To: "draft-previdi-6man-segment-routing-header@tools.ietf.org" Thread-Topic: Next Segment in draft-previdi-6man-segment-routing-header Thread-Index: AQHQBOd8UvxDVNGgk06oV/juY+vuEw== Date: Thu, 20 Nov 2014 17:29:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.118] Content-Type: multipart/signed; boundary="Apple-Mail=_4D7A7A3E-C81D-46FD-98B1-8A2C3FF13D67"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/8vkoaw1qMgY9Q2lwxFrhyLDpzsI X-Mailman-Approved-At: Thu, 20 Nov 2014 10:09:38 -0800 Cc: "spring@ietf.org" Subject: [spring] Next Segment in draft-previdi-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 17:29:13 -0000 --Apple-Mail=_4D7A7A3E-C81D-46FD-98B1-8A2C3FF13D67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I=92m looking at th definition of Next Segment: o Next Segment (originally defined as "Segments Left" in [RFC2460]): index, in the Segment List, of the next active segment (according to terminology defined in [I-D.filsfils-spring-segment-routing]) in the SRH. Note that this differs from the semantic defined in the Routing Header specification ([RFC2460] defines it as "Segments Left"). Therefore, in the Segment Routing context, the "Segments Left" field is renamed as "Next Segment". o Last Segment: index, in the Segment List, of the next active segment of the last segment of the path in the SRH. Some of the recent discussions highlight how this interacts poorly with = https://tools.ietf.org/html/rfc2460#section-4.4, in that the receiving = host will ignore the routing header if Segments Left =3D=3D 0, but not = if the same set of bits but renamed as Next Segment is equal to Last = Segment. Could you walk through the argument for the redefinition? I think you = might simplify the discussion if the receiving host can ignore the = Routing Header, which would require that you use =93Segments Left=94 = rather than =93Next Segment=94. --Apple-Mail=_4D7A7A3E-C81D-46FD-98B1-8A2C3FF13D67 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUbiTgbjEdbHIsm0MRAvUeAJ9uTEC3b4ZkZg9mNZJE2NOBpRQxCgCg9S8b TMGYBlKj0dciM2bGUC/Q470= =4NZy -----END PGP SIGNATURE----- --Apple-Mail=_4D7A7A3E-C81D-46FD-98B1-8A2C3FF13D67-- From nobody Thu Nov 20 14:32:01 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDB51A064C for ; Thu, 20 Nov 2014 14:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 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.594, 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 27aDzpOBq9ka for ; Thu, 20 Nov 2014 14:31:55 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C41E1A6F2F for ; Thu, 20 Nov 2014 14:31:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5768; q=dns/txt; s=iport; t=1416522714; x=1417732314; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2ZFaRpeqkMpvrp1K+5slpEAFbtzeq0K37+gucE38VjQ=; b=OMYK4ajb+vEpDWYC8VbpOPrbc3DB0IPyh/CNxylW+JrXj5Fj5iU5PT/G cDQQ6+doWwXrDhA46ebKwGGr7ttBoYkYdUl4drqsV/6ikSoh9o1zWLdOR hBbmBZZ0ESbq9iOkdhv3gRmedgUuMH5tz7kiHopfXmgo+Pz23mdAv332H M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoHAP5qblStJA2L/2dsb2JhbABagkhGVVkEunuOeYFoh0kCgQgWAQEBAQFyC4QDAQEEHVwQAgEIEi0HMhQDDgIEDgWIQQ3VAwEBAQEBBQEBAQEBAQEBARmRCAeESwWQLYIqhF6HLIEzPYMYjWqECYN7bYFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,426,1413244800"; d="scan'208,217";a="373971207" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP; 20 Nov 2014 22:31:53 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sAKMVrpn013242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Nov 2014 22:31:53 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.180]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Thu, 20 Nov 2014 16:31:53 -0600 From: "Alvaro Retana (aretana)" To: "draft-filsfils-spring-segment-routing@tools.ietf.org" Thread-Topic: [spring] WG Adoption Call for draft-filsfils-spring-segment-routing Thread-Index: AQHP6kdkqfWP3LGVIECUqoyW3FdPlJw0zrEAgDWRDgA= Date: Thu, 20 Nov 2014 22:31:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_D093D4FF76BC4aretanaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/Jce0Y3Nf1pfKMP_aRIE3bxpUXvc Cc: "spring@ietf.org" Subject: Re: [spring] WG Adoption Call for draft-filsfils-spring-segment-routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 22:31:59 -0000 --_000_D093D4FF76BC4aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! We have reached consensus on adopting this draft, and received IPR statemen= ts from all the authors. Authors: Please republish this draft as draft-ietf-spring-architecture Thanks! Alvaro. On 10/17/14, 4:30 PM, "Alvaro Retana (aretana)" > wrote: Reference: http://datatracker.ietf.org/ipr/2457/ On 10/17/14, 4:17 PM, "Alvaro Retana (aretana)" > wrote: Hi! So far we haven=92t received any objection to the adoption of this document= . Given that the authors have a recent IPR disclosure, we=92re going to close= this call for adoption on Oct/23, 2014. For reference, this is the most = recent IPR disclosure. Thanks! Alvaro. On 9/24/14, 9:01 AM, "Alvaro Retana (aretana)" > wrote: Hi! This message officially starts the call for adoption for draft-filsfils-spr= ing-segment-routing. Please indicate your position about adopting this draft by end-of-day on Oc= tober 8, 2014. Some additional background: This draft presents the 'Segment Routing Archi= tecture'; it focuses on the terminology and general architecture. draft-fi= lsfils-spring-segment-routing-mpls (for which there is separate call for ad= option) describes the instantiation of Segment Routing on the MPLS data pla= ne. http://tools.ietf.org/html/draft-filsfils-spring-segment-routing Thanks! Alvaro. --_000_D093D4FF76BC4aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <70EBB706EF971449836EBA3102EA6C3F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi!

We have reached consensus on adopting this draft, and received IPR sta= tements from all the authors.


Authors:  Please republish this draft as draft-ietf-spring-archit= ecture

Thanks!

Alvaro.

On 10/17/14, 4:30 PM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:


On 10/17/14, 4:17 PM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

Hi!

So far we haven=92t received any objection to the adoption of this doc= ument.

Given that the authors have a recent IPR disclosure, we=92re going to = close this call for adoption on Oct/23, 2014.  For reference,  th= is is the most recent IPR disclosure.

Thanks!

Alvaro.

On 9/24/14, 9:01 AM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

Hi!

This message officially starts the call for adoption for draft-fi= lsfils-spring-segment-routing.

Please indicate your position about adopting this draft by end-of-day = on October 8, 2014.

Some additional background:  This draft presents the 'Segment Rou= ting Architecture'; it focuses on the terminology and general architecture.=  draft-filsfils-spring-segment-routing-mpls (for which there is separ= ate call for adoption) describes the instantiation of Segment Routing on the MPLS data plane.


Thanks!

Alvaro.
 --_000_D093D4FF76BC4aretanaciscocom_-- From nobody Thu Nov 20 14:35:39 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58B61A88E5 for ; Thu, 20 Nov 2014 14:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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.594, 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 pecjRxxisjv5 for ; Thu, 20 Nov 2014 14:35:35 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FCD01A88D7 for ; Thu, 20 Nov 2014 14:35:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1458; q=dns/txt; s=iport; t=1416522934; x=1417732534; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=v1zEBTIOCR8Ee7hII3yfAWImJS0PRKbl7+0+QBI/f/E=; b=Ww5MHwwpdGoHKg2FCiSvGxAcagcMlnAITvvLtVaSExTo/TyN7tm7mqcw f29y9Mrl1iiJY/b1O77gRca6VvpBbpz0tfvyVwlo+Zyo7SQ0blQrvLUJi tnZPX5LTI0oEIkeIHntomzgajCH6ASqtDEiurE5cxx/eaP8f6/ri9gtlI 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlALAGpsblStJV2P/2dsb2JhbABagw5VWQSDAshQCoZ0VQIcaRYBAQEBAXILhAMBAQQBAQExOgsQAgEIHCgCAiULJQIEDgWIQQ2hGpxqBpZzAQEBAQEBAQEBAQEBAQEBAQEBARmBJ48uMweCcYFaBZAtgiqEXocsgTM9gxiNaoQJg3ttgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,426,1413244800"; d="scan'208";a="98666975" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP; 20 Nov 2014 22:35:33 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sAKMZXHx011951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Nov 2014 22:35:33 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.180]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Thu, 20 Nov 2014 16:35:33 -0600 From: "Alvaro Retana (aretana)" To: "saku@ytti.fi" Thread-Topic: [spring] IPR Claims related to draft-filsfils-spring-segment-routing-mpls Thread-Index: AQHP1/iPGeXWHBcyB0uy5DIe6qCkOZwlKgKAgA/MY4CANY7/gA== Date: Thu, 20 Nov 2014 22:35:33 +0000 Message-ID: References: <7B4A6E74-CBD2-4123-8907-9AADF7F6E506@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: text/plain; charset="euc-kr" Content-ID: <589033D59BB7394481BFA7472ED87F6C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/fJunQ336RJNcBYrRfcYZ6p-GNB0 Cc: "spring@ietf.org" , "draft-filsfils-spring-segment-routing-mpls@tools.ietf.org" Subject: Re: [spring] IPR Claims related to draft-filsfils-spring-segment-routing-mpls X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 22:35:37 -0000 U2FrdToNCg0KSGkhDQoNCkkgYmVsaWV2ZSB5b3UgYXJlIHRoZSBvbmx5IGF1dGhvciB3aG8gaGFz bqGvdCByZXBsaWVkIHdpdGggYW4gSVBSIHN0YXRlbWVudA0KcmVsYXRlZCB0byB0aGlzIGRyYWZ0 IChJIGRpZCBzZWUgeW91ciByZXBseSBmb3INCmRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zZWdtZW50 LXJvdXRpbmcpLiAgQ2FuIHlvdSBwbGVhc2UgcmVwbHkgaW5kaWNhdGluZw0Kd2hldGhlciB5b3Ug a25vdyBvZiBhbnkgSVBSIG90aGVyIHRoYW4gd2FzIGhhcyBhbHJlYWR5IGJlZW4gZGlzY2xvc2Vk Pw0KDQpUaGFua3MhDQoNCkFsdmFyby4NCg0KT24gMTAvMTcvMTQsIDQ6NDEgUE0sICJBbHZhcm8g UmV0YW5hIChhcmV0YW5hKSIgPGFyZXRhbmFAY2lzY28uY29tPiB3cm90ZToNCg0KPk9uIDEwLzcv MTQsIDExOjI2IEFNLCAiU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkiIDxzcHJldmlkaUBjaXNj by5jb20+DQo+d3JvdGU6DQo+DQo+PklQUiBpcyBpbiB0aGUgcHJvY2VzcyBvZiBiZWluZyBkaXNj bG9zZWQuDQo+DQo+VGhlIElQUiB3YXMgZmlsZWQgb24gT2N0LzcuDQo+DQo+Rm9yIHRoZSBXRyBy ZWZlcmVuY2U6IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMjQ1NC8NCj4NCj4NCj5B dXRob3JzOiAgV2Ugc3RpbGwgaGF2ZW6p9nQgcmVjZWl2ZWQgYW4gZXhwbGljaXQgYW5zd2VyIGZy b20gQ2xhcmVuY2UsDQo+QWhtZWQsIEJydW5vLCBTdGVwaGFuZSwgSWdvciwgU2FrdSBhbmQgRWQu ICBJdCB3b3VsZCBiZSBuaWNlIGlmIHdlIGNhbg0KPmNsb3NlIG9uIHRoaXMgcmVxdWlyZW1lbnQg YnkgT2N0LzIzIHNvIChpZiBhZG9wdGVkKSB3ZSBoYXZlIHRpbWUgdG8NCj5wdWJsaXNoIHRoZSBX Ry10aXRsZWQgZG9jdW1lbnQgYmVmb3JlIHRoZSBkZWFkbGluZS4NCj4NCj5UaGFua3MhDQo+DQo+ QWx2YXJvLg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+c3ByaW5nIG1haWxpbmcgbGlzdA0KPnNwcmluZ0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQoNCg== From nobody Fri Nov 21 12:13:21 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17EA51A6F3F for ; Fri, 21 Nov 2014 12:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 3wZro7lcD0Hr for ; Fri, 21 Nov 2014 12:13:17 -0800 (PST) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89C71A6F39 for ; Fri, 21 Nov 2014 12:13:16 -0800 (PST) Received: by mail-ig0-f182.google.com with SMTP id hn15so238645igb.3 for ; Fri, 21 Nov 2014 12:13:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wt/QFJ2c14smn3cGYWmqCBd41au0wNkhYDkgVORVVwg=; b=YefDNZqI97pPnQB+pWRCbeTUemxrwVQsyH1avzhN527SIjXZyLzi4y2SZEuT1D0gKc UOdaTWz6V+5Jbs1Dv0uRyWCpocLQTyCSmUZdSpLQVs34A1qvzP0VJ4w3KIhiI4T967zi jir6YYhWaQH/mKKzlBMq3/88Gd4VRp68X9cK2frgtVI//X/Dya0PZ6ShxFmJW62Fb14J VU5WJrp/jdUhjCelKYVuzeuX7PUN7C8WjTl4HNw9tHG7fsmlaAkbiw1DVWxk3A6ehG6o AC/fU6I3VPKz+al+gpu1cL+UabbNN6E49K89V0Q1Hjn61ljy/lc7yG7sOWOJ/8OTUcSK 47/Q== X-Gm-Message-State: ALoCoQnvI1ydPhwBta9HrrpgJCd7L3zYvuYpN6hgQYHgHF405bDbUKDGOxI9c3qdd9pxm4Nn752W MIME-Version: 1.0 X-Received: by 10.43.170.134 with SMTP id nq6mr14806893icc.30.1416600795713; Fri, 21 Nov 2014 12:13:15 -0800 (PST) Received: by 10.107.6.215 with HTTP; Fri, 21 Nov 2014 12:13:15 -0800 (PST) In-Reply-To: References: Date: Fri, 21 Nov 2014 22:13:15 +0200 Message-ID: From: Saku Ytti To: "Alvaro Retana (aretana)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/Jhp-HN5LibjBxl8p8Xr_31VY6dc Cc: "spring@ietf.org" , "draft-filsfils-spring-segment-routing-mpls@tools.ietf.org" Subject: Re: [spring] IPR Claims related to draft-filsfils-spring-segment-routing-mpls X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 20:13:20 -0000 Not aware of any IPR claims. On 24 September 2014 16:07, Alvaro Retana (aretana) wrote: > Hi! > > In parallel to the WG Adoption Call for this draft, I want to formally ask > the authors (no additional contributors are listed in the latest version of > the draft) to please respond to this message indicating whether or not you > are aware of any relevant IPR. So far there are no related disclosures. > The draft will not progress (pending the results of the WG Adoption Call) > until we have received a response from each author. > > Thanks! > > Alvaro. -- ++ytti From nobody Fri Nov 21 12:18:13 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8011A6FB0 for ; Fri, 21 Nov 2014 12:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 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.594, 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 zpBF0aGGdkWO for ; Fri, 21 Nov 2014 12:18:09 -0800 (PST) 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 DE1691A6F0E for ; Fri, 21 Nov 2014 12:18:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3306; q=dns/txt; s=iport; t=1416601086; x=1417810686; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Bj3+RYQkkpQHveXNzrjVtoNwxYxkSiYUSGpcFINcJIE=; b=Lg+ieH2YjsAZzi7tkd8bVzRu+auVXKXjfGG0qCTf06ImTRF98hX+l5v/ S/40qujaIOIiOpgtEcAU9VqHIhcwcNeKEsxTkfWTTDRiaGZaejqrjKnhm CZ3d4FTojqF6uCFIOeDHeTtXh3aAVDbcC5/gxNcOwD3k5GgFlfIYahFVz A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcFAMqdb1StJV2Y/2dsb2JhbABcgkhGVVkEyiyBbIZrAoEFFgEBAQEBfYQDAQEEHVwQAgEIBA4tBzIUAw4CBA4FiEENzWsBAQEBAQEEAQEBAQEBAQEBGZELB4ROBZA3gi2EZYcxgTQ/gxqNfYQJg314gUiBAwEBAQ X-IronPort-AV: E=Sophos; i="5.07,432,1413244800"; d="scan'208,217"; a="98998937" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP; 21 Nov 2014 20:18:06 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sALKI69b002780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Nov 2014 20:18:06 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.180]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Fri, 21 Nov 2014 14:18:05 -0600 From: "Alvaro Retana (aretana)" To: "draft-filsfils-spring-segment-routing-mpls@tools.ietf.org" Thread-Topic: [spring] WG Adoption Call for draft-filsfils-spring-segment-routing-mpls Thread-Index: AQHP1/iB/rpWjvUy80KKMiEjZbS5Rpxr8U+A Date: Fri, 21 Nov 2014 20:18:05 +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.117.15.3] Content-Type: multipart/alternative; boundary="_000_D09507C776E6Earetanaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/3AuomuAzjYv1HiwViiIozHb22lc Cc: "spring@ietf.org" Subject: Re: [spring] WG Adoption Call for draft-filsfils-spring-segment-routing-mpls X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 20:18:11 -0000 --_000_D09507C776E6Earetanaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! We finally received all the IPR statements for this draft..there is consens= us to adopt. Authors: Please repost as draft-ietf-spring-architecture-mpls Thanks! Alvaro. On 9/24/14, 9:07 AM, "Alvaro Retana (aretana)" > wrote: Hi! This message officially starts the call for adoption for draft-filsfils-spr= ing-segment-routing-mpls. Please indicate your position about adopting this draft by end-of-day on Oc= tober 8, 2014. Some additional background: This draft describes the instantiation of Segm= ent Routing on the MPLS data plane. The Segment Routing Architecture is pr= esented in draft-filsfils-spring-segment-routing (for which there is a sepa= rate call for adoption) http://tools.ietf.org/html/draft-filsfils-spring-segment-routing-mpls Thanks! Alvaro. --_000_D09507C776E6Earetanaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi!

We finally received all the IPR statements for this draft..there is co= nsensus to adopt.

Authors:  Please repost as draft-ietf-spring-architecture-mpls

Thanks!

Alvaro.

On 9/24/14, 9:07 AM, "Alvaro Retana (aretana)" <aretana@cisco.com> wrote:

Hi!

This message officially starts the call for adoption for draft-fi= lsfils-spring-segment-routing-mpls.

Please indicate your position about adopting this draft by end-of-day = on October 8, 2014.

Some additional background:  This draft describes the instan= tiation of Segment Routing on the MPLS data plane.  The Segment Routin= g Architecture is presented in draft-filsfils-spring-segment-routing (for w= hich there is a separate call for adoption)


Thanks!

Alvaro.
 --_000_D09507C776E6Earetanaciscocom_-- From nobody Sun Nov 23 23:58:33 2014 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8C11A1BF1 for ; Sun, 23 Nov 2014 23:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.644 X-Spam-Level: X-Spam-Status: No, score=-12.644 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_LOLITA1=1.865, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 EiMs0zvlEXyh for ; Sun, 23 Nov 2014 23:58:26 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B0621A1BEB for ; Sun, 23 Nov 2014 23:58:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=60629; q=dns/txt; s=iport; t=1416815906; x=1418025506; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Mjsjx9ckwIJ7cF0odo089rr8jIJZLEIYmrcbCQcLxEo=; b=EbheCTC5o+n145xfbV0OVWaaTxMXw2OVVWFz++AvCVyCd2bj6hJmcS6I RdBnUwZxwW4ZDFV7S3MbQ8g8dzWaBn59MdBErZzeC8WLPPcQ/665Nhdud CQs+5CO32e9FWOFUTwW86W8HtNnCVHMK0xToPqrjrJKLF04lDdEbp97E/ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AokHAKrjclStJV2U/2dsb2JhbABbgmsjVVm6AI8rgWIBCYYVVQJFWRYBAQEBAX2EAwEBAwEBAQEXDSQBIgYFEAIBCBMlAQYHIQQCCxQRAgQOBRmIEwMJCQEMvjwBiG4NhkIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjk6COQQHgy+BHwWGTolsgi6HN4JNghWBNI4gSAOCcYQKg314AYJKAQEB X-IronPort-AV: E=Sophos; i="5.07,447,1413244800"; d="scan'208,217"; a="99481045" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP; 24 Nov 2014 07:58:25 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sAO7wP0e005145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Nov 2014 07:58:25 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Mon, 24 Nov 2014 01:58:25 -0600 From: "Jakob Heitz (jheitz)" To: Bruno Rijsman Thread-Topic: [spring] Comments on draft-filsfils-spring-segment-routing-msdc-00 Thread-Index: AQHQAcj9RgrffES8+0OzKzaFCQOjD5xvdUYt Date: Mon, 24 Nov 2014 07:58:24 +0000 Message-ID: <7BDD5980-3C17-4CEC-9B62-53D4F8D89ED6@cisco.com> 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_7BDD59803C174CEC9B6253D4F8D89ED6ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/fs_YXwc4gwtME3uAgBLH6P1tECU Cc: "spring@ietf.org" Subject: Re: [spring] Comments on draft-filsfils-spring-segment-routing-msdc-00 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 07:58:32 -0000 --_000_7BDD59803C174CEC9B6253D4F8D89ED6ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding the confusion about the AS numbers: Each node is indeed its own AS. However, to conserve AS numbers, some nodes= share AS numbers. It seems like a contradiction, but it works anyway. The = routers that share AS numbers are not in the same AS, because they do not h= ave iBGP sessions connecting them and they do not have congruent routes as = routers in the same AS would have. -- Jakob Heitz. On Nov 16, 2014, at 10:13 AM, Bruno Rijsman > wrote: See >>> below for some comments on draft-filsfils-spring-segment-routing-ms= dc-00 -- Bruno Tier-3 +-----+ |NODE | +->| 5 |--+ | +-----+ | Tier-2 | | Tier-2 +-----+ | +-----+ | +-----+ +------------>|NODE |--+->|NODE |--+--|NODE |-------------+ | +-----| 3 |--+ | 6 | +--| 9 |-----+ | | | +-----+ +-----+ +-----+ | | | | | | | | +-----+ +-----+ +-----+ | | | +-----+---->|NODE |--+ |NODE | +--|NODE |-----+-----+ | | | | +---| 4 |--+->| 7 |--+--| 10 |---+ | | | | | | | +-----+ | +-----+ | +-----+ | | | | | | | | | | | | | | +-----+ +-----+ | +-----+ | +-----+ +-----+ |NODE | |NODE | Tier-1 +->|NODE |--+ Tier-1 |NODE | |NODE | | 1 | | 2 | | 8 | | 11 | | 12 | +-----+ +-----+ +-----+ +-----+ +-----+ | | | | | | | | A O B O <- Servers -> Z O O O Figure 1: 5-stage Clos topology >>> Comment #1 start. This figure appears to be a mixture between figure 1 (traditional topology)= and figure 2 (3-stage folded Clos topology) in draft-ietf-rtgwg-bgp-routin= g-large-dc-00. In a proper 5-stage folded Clos topology, there would be a = full mesh from each tier N to tier N+1 (e.g. node 3 would not only be conne= cted to nodes 5 and 6 but also to nodes 7 and 8). Note that your numbering= of the tiers is the reverse of the number of the tiers in draft-ietf-rtgwg= -bgp-routing-large-dc-00 which causes some confusion later on in this docum= ent. Here is a suggested for a more accurate 5-stage folded Clos figure: +-------+ +-------+ | SS1 | | SS2 | Super spine switches +-------+ +-------+ | | | | | | | | +-----------------+ | | | | | | | | +--------+ | | | | | +-----------------+ | +-----------------|-|----+ | +--------+ | | | | | +------------------------+ | | | | +---------------+ | | | | | | +---------------+ | | | | | | | | | | | | +-------+ +-------+ +-------+ +-------+ | S1 | | S2 | | S3 | | S4 | Spine sw= itches +-------+ +-------+ +-------+ +-------+ | | | | | | | | | | | | | | | | +------+ | | | | | | +------+ +------+ | | | | | | +------+ | +----|-|-|----+ | | | | +----|-|-|----+ | | | | | | | +-------------+ | | | | | +-------------+ | | | | +------+ | | | | | | | +------+ | | | | | | | +----|-+ | | | | | | +----|-+ | | | | | | | | | | | | | | | | | | | +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ | L1 | | L2 | | L3 | | L4 | | L5 | | L6 | | L7 | | L8 | Lea= f switches (ToRs) +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ | | | | | | | | | | | | | | | | | | | | | | | | O O O O O O O O O O O O O O O O O O O O O O O O Ser= vers >>> Comment #1 end. o Each node is its own AS: For simple and efficient route propagation filtering, Nodes 5, 6, 7 and 8 share the same AS, Nodes 3 and 4 share the same AS, nodes 9 and 10 share the same AS. For efficient usage of the scarce 2-byte private AS pool, different tier-1 nodes might share the same AS. Without loss of generality, we will simplify these details in this document and assume that each node has its own AS. >>> Comment #2 start. The above section is somewhat confusion and appears to be self-contradictor= y. The title says that each node has its own AS. Then the first paragraph= contradicts that and says that certain nodes definitely do have the same A= S number. Then the next paragraph says that certain nodes might have the s= ame AS number. Then the final paragraph says that each node has its own AS = number. Suggested text: In real-life deployments there are various ways in which AS numbers can be = assigned to switches. One option is to use a single AS for all the switches in the entire data ce= nter. In this case IGBP sessions are used everywhere with next-hop-self po= licies to force the traffic along the desired path. Another option is to make each tier an AS and use EBGP sessions between the= tiers. In this case all switches within a given tier are in the same AS an= d EBGP sessions are used between the tiers. A third option is to assign a different AS number to each switch. In this c= ase each switch is a separate AS and EBGP sessions are used everywhere. In this document we assume, without loss of generality, the third option. >>> Comment #2 end. o The forwarding plane at Tier-2 and Tier-1 is MPLS. o The forwarding plane at Tier-3 is either IP2MPLS (if the host sends IP traffic) or MPLS2MPLS (if the host sends MPLS- encapsulated traffic). >>> Comment #3 start. The way you numbered the tiers in your diagram, MPLS is in tier-2 and tier-= 3, and tier-1 is either IP2MPLS or MPLS. (Note that the numbering of the t= iers in your diagram is the reverse from the numbering in draft-ietf-rtgwg-= bgp-routing-large-dc-00 which is likely the source of the confusion.) Suggested text: o The forwarding plane between the spine switches and the super spine switc= hes is MPLS o The forwarding plane between the leaf switches (=3D ToR switches) and the= spine switches is MPLS o The forwarding plane between the servers and the leaf switches (=3D ToR s= witches) may be MPLS or IP. >>> Comment #3 end. In this document, we also refer to the Tier-3, Tier-2 and Tier-1 switches respectively as Spine, Leaf and ToR (top of rack) switches. When a ToR switch acts as a gateway to the "outside world", we call it a border switch. >>> Comment #4 start. I believe it is common to consider the ToR switches (i.e. the switches that= are connected to the servers) to be the leaf switches. I would suggest the following terminology: o ToR switch =3D leaf switch o Spine switch o Super spine switch I also believe that it is more common to number the tiers starting from the= bottom (leaf) with index 0: o ToR switch =3D leaf switch =3D tier 0 o Spine switch =3D tier 1 o Super spine switch =3D tier 2 >>> Comment #4 end. Node 11 sends the following eBGP3107 update to Node 10: . NLRI: 1.1.1.11/32 . Label: Implicit-Null . Next-hop: Node11's interface address on the link to Node10 . AS Path: {11} . BGP-Prefix Attribute: Index 11 Node 10 receives the above update. As it is SR capable, Node10 is able to interpret the BGP-Prefix Attribute and hence allocates the label 16011 to the NLRI (instead of asking a "random/local" label from its label manager). The implicit-null label in the update signals to Node 10 that it is the penultimate hop and MUST pop the top label on the stack before forwarding traffic for this prefix to Node 11. Then, Node 10 sends the following eBGP3107 update to Node 7: . NLRI: 1.1.1.11/32 . Label: 16011 . Next-hop: Node10's interface address on the link to Node7 . AS Path: {10, 11} . BGP-Prefix Attribute: Index 11 >>> Comment #5 start. As described here, this proposal requires that node 10 has a-priori knowled= ge of the globally significant label which must be assigned to prefix 1.1.1= .11/32. This is not only true for node 10, but it is also true for every other node= connected to node 11 which receives prefix 1.1.1.11/32= with an implicit null label. >From a practical operational view, it might require that every node has a-p= riori knowledge of the binding of MPLS labels to nodes. What this means, i= n effect, is that the BGP signaling only used for reachability detection, a= nd not for distribution of label to node bindings. Providing each node with a-priori knowledge of label to node binding for ev= ery node in the POD may be too much of a configuration burden for most oper= ators. This problem is solved later on in this draft using the I-D.keyupate-idr-bg= p-prefix-sid mechanism (although the problem is still there for transition = scenarios). Alternatively, avoiding the need for pre-configured label-to-prefix binding= can also be achieved by making the following BGP implementation changes wi= thout any on-the-wire protocol change. 1. Each ultimate hop node is configured to advertise its global label inste= ad of implicit null. 2. Each node which receives a BGP-LU advertisement is configured to: 2a) Not allocate a new locally significant label when it does a next-hop se= lf. Instead, it keeps the received label. This behavior could be restrict= ed to a particular label block. 2b) Pop the label (i.e. do a PHP) when it is forwarding the packet to the u= ltimate hop (which can be detected using the AS-path) despite the fact that= the ultimate hop advertised a real label instead of an implicit null label= . >>> Comment #5 end. ----------------------------------------------- Incoming label | outgoing label | Outgoing or IP destination | | Interface ------------------+----------------+----------- 16011 | 16011 | ECMP{7, 8} 1.1.1.11/32 | 16011 | ECMP= {7, 8} ------------------+----------------+----------- Figure 4: Node-4 Forwarding Table >>> Comment #6 start. In the example topology, the spine switches were not fully meshed to the su= per spine switches. In a real life topology they would be fully meshed, an= d the ECMP set out be a 4-way ECMP set ECMP{5,6,7,8} >>> Comment #6 end. ----------------------------------------------- Incoming label | outgoing label | Outgoing or IP destination | | Interface ------------------+----------------+----------- 16011 | 16011 | 10 1.1.1.11/32 | 16011 | 1= 0 ------------------+----------------+----------- Figure 5: Node-7 Forwarding Table >>> Comment #6 start. In the example topology, the spine switches were not fully meshed to the su= per spine switches. In a real life topology they would be fully meshed, an= d the ECMP set out be a 2-way ECMP set ECMP{9,10} >>> Comment #6 end. 3.3. Network Design Variation A network design choice could consist of switching all the traffic through tier-2 and tier-3 as MPLS traffic. In this case, one could filter away the IP entries at nodes 4, 7 and 10. This might be beneficial in order to optimize the forwarding table size. A network design choice could consist in allowing the hosts to send MPLS-encapsulated traffic (based on EPE use-case, [I-D.filsfils-spring-segment-routing-central-epe]). For example, Node 1 would receive Node11-destined MPLS-encapsulated traffic from its attached host A and would switch this traffic on the basis of the MPLS entry for 16011 (instead of classically receiving IP traffic from A and performing an IPtoMPLS switching operation). >>> Comment #7 start. It would be good to point out explicitly that the second approach allows th= e hosts to send a multi-label stack (for example to implement egress peer e= ngineering as described later in this I-D). If IP forwarding is used betwe= en leaf switches, then this would require some MPLS over IP-tunnel approach= (e.g. MPLS-over-GRE). Using MPLS as the base tunnel mechanism is more con= sistent and allows other features to be supported that cannot be implemente= d with MPLS-over-IP-tunnel based approaches (e.g. the capacity optimization= use case described in section 4.4 of the I-D). >>> Comment #7 end. From a signaling viewpoint, nothing would change as even if Node6 does not understand the BGP-Prefix Segment attribute, it does propagate it unmodified to its neighbors. From a label allocation viewpoint, the only difference is that Node7 would allocate a dynamic label to the prefix 1.1.1.11/32 (e.g. 12345) and would advertise that label to its neighbor Node4. >>> Comment #8 start. There may be one change which is required on on the legacy Node7. We have to make sure that the MPLS label which is allocated by Node7 does n= ot "collide" with the globally significant labels. For example, things wou= ld break if legacy Node7 happen happens to dynamically allocate a 1600x lab= el. This can be avoided by introducing a configuration knob in the label a= llocation subsystem of the switch for "off-limits label blocks". >>> Comment #8 end. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_7BDD59803C174CEC9B6253D4F8D89ED6ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Regarding the confusion about the AS numbers:
Each node is indeed its own AS. However, to conserve AS numbers, some = nodes share AS numbers. It seems like a contradiction, but it works anyway.= The routers that share AS numbers are not in the same AS, because they do = not have iBGP sessions connecting them and they do not have congruent routes as routers in the same AS would= have.

--
Jakob Heitz.


On Nov 16, 2014, at 10:13 AM, Bruno Rijsman <brunorijsman@gmail.com> wrote:

 

See >>> below for some comments on <= i>draft-fils= fils-spring-segment-routing-msdc-00

-- Bru= no

 

 

     =             &nb= sp;            =      Tier-3

     =             &nb= sp;            =     +-----+

     =             &nb= sp;            =     |NODE |

     =             &nb= sp;            = +->|  5  |--+

     =             &nb= sp;             = ;|  +-----+  |

     =             &nb= sp;     Tier-2  |     &nb= sp;     |   Tier-2

     =             &nb= sp;    +-----+  |  +-----+  |=   +-----+

     =    +------------>|NODE |--+->|NODE |--+--|NODE = |-------------+

     =    |       +-----|  3 = ; |--+  |  6  |  +--|  9  |-----+=        |

     =    |       |    = ; +-----+     +-----+   =   +-----+     |    &nb= sp;  |

     =    |       |    = ;            &n= bsp;            = ;            | =       |

     =    |       |    = ; +-----+     +-----+   =   +-----+     |    &nb= sp;  |

     =    | +-----+---->|NODE |--+  |NODE |  &#= 43;--|NODE |-----+-----+ |

     =    | |     | +---|  4  |--+= ->|  7  |--+--|  10  |---+ |  &nbs= p;  | |

     =    | |     | |   +-----+&nb= sp; |  +-----+  |  +-----+   | |&n= bsp;    | |

     =    | |     | |     &= nbsp;      |      &n= bsp;    |        &nb= sp;   | |     | |

     = +-----+ +-----+        =   |  +-----+  |     &n= bsp;    +-----+ +-----+

     = |NODE | |NODE | Tier-1   +->|NODE |--+   Ti= er-1 |NODE | |NODE |

     = |  1  | |  2  |      &nb= sp;      |  8  |    =          | 11  | |  12 |<= /span>

     = +-----+ +-----+       &= nbsp;     +-----+     =         +-----+ +-----+<= /span>

     =    | |     | |     &= nbsp;           &nbs= p;            &= nbsp;      | |     | |<= /p>

     =    A O     B O     &= nbsp;      <- Servers ->   &n= bsp;        Z O     = O O

 

     =             &nb= sp;    Figure 1: 5-stage Clos topology

 

 

>&g= t;> Comment #1 start. 

 =

This f= igure appears to be a mixture between figure 1 (traditional topology) and f= igure 2 (3-stage folded Clos topology) in draft-ietf-rtgwg-bgp-routing-larg= e-dc-00.  In a proper 5-stage folded Clos topology, there would be a full mesh from each tier N to tier N+1= (e.g. node 3 would not only be connected to nodes 5 and 6 but also to node= s 7 and 8).  Note that your numbering of the tiers is the reverse of t= he number of the tiers in draft-ietf-rtgwg-bgp-routing-large-dc-00 which causes some confusion later on in this document. Here is a suggested= for a more accurate 5-stage folded Clos figure:

 =

 &nb= sp;            =             +---= ----+  +-------+

 &nb= sp;            =             | SS1&nb= sp;  |  | SS2   |  Super spine switches

 &nb= sp;            =             +---= ----+  +-------+

 &nb= sp;            =              | = | | |    | | | |

 &nb= sp;       +-----------------+ | | |&n= bsp;   | | | |

 &nb= sp;       |     &nbs= p;    +--------+ | |    | | | +--= ---------------+

 &nb= sp;       |   +----------------= -|-|----+ | +--------+       = ;   |

 &nb= sp;       |   |   &n= bsp;  |          | +-= -----------------------+   |

 &nb= sp;       |   |    &= nbsp; |          +---= ------------+   |      |  = |

 &nb= sp;       |   |   &n= bsp;  |   +---------------+    &= nbsp; |   |      |   |<= /p>

 &nb= sp;       |   |    &= nbsp; |   |         =             &nb= sp;|   |      |   | 

 &nb= sp;     +-------+  +-------+ =             &nb= sp;    +-------+  +-------+

 &nb= sp;     | S1    |  | S2   = ; |            =       | S3    |  | S4&nbs= p;   |  Spine switches

 &nb= sp;     +-------+  +-------+ =              &n= bsp;   +-------+  +-------+

 &nb= sp;      | | | |    | | | | &n= bsp;            &nbs= p;     | | | |    | | | |

 = 3;------+ | | |    | | | +------+   &n= bsp;+------+ | | |    | | | +------+<= /p>

 |&n= bsp;  +----|-|-|----+ | |      &= nbsp; |    |   +----|-|-|----+ | | &n= bsp;      |

 |&n= bsp;  |    | | +-------------+   | &n= bsp;  |   |    | | +-------------= 3;   |

 |&n= bsp;  |    | +------+ | |    |&n= bsp;  |    |   |    | +---= ---+ | |    |   |

 | &= nbsp; |    |   +----|-+ |  =   |   |    |   |    = |   +----|-+ |    |   |

 |&n= bsp;  |    |   |    | &nb= sp; |    |   |    |   |&n= bsp;   |   |    |   | &nb= sp;  |   |

+----= -+  +-----+  +-----+  +-----+&nb= sp; +-----+  +-----+  +-----+  += -----+

| L1 = ; |  | L2  |  | L3  |  | L4  |  | L5&nbs= p; |  | L6  |  | L7  |  | L8  |  Leaf sw= itches (ToRs)

+----= -+  +-----+  +-----+  +-----+&nb= sp; +-----+  +-----+  +-----+  += -----+

 | |= |    | | |    | | |    | | |&= nbsp;   | | |    | | |    | | |&nbs= p;   | | |

 O O= O    O O O    O O O    O O O&= nbsp;   O O O    O O O    O O O&nbs= p;   O O O   Servers

 

>&g= t;> Comment #1 end. 

 

 

   o  Each node= is its own AS:

 

     =     For simple and efficient route propagation filtering, No= des 5,

     =     6, 7 and 8 share the same AS, Nodes 3 and 4 share the sa= me AS,

     =     nodes 9 and 10 share the same AS.

 

     =     For efficient usage of the scarce 2-byte private AS pool= ,

     =     different tier-1 nodes might share the same AS.

 

     =     Without loss of generality, we will simplify these detai= ls in

     =     this document and assume that each node has its own AS.<= /span>

 

>&g= t;> Comment #2 start.

 =

The ab= ove section is somewhat confusion and appears to be self-contradictory.&nbs= p; The title says that each node has its own AS.  Then the first parag= raph contradicts that and says that certain nodes definitely do have the same AS number.  Then the next paragraph= says that certain nodes might have the same AS number. Then the final para= graph says that each node has its own AS number.

 =

Sugges= ted text:

 =

In rea= l-life deployments there are various ways in which AS numbers can be assign= ed to switches.

 =

One op= tion is to use a single AS for all the switches in the entire data center.&= nbsp; In this case IGBP sessions are used everywhere with next-hop-self pol= icies to force the traffic along the desired path.

 =

Anothe= r option is to make each tier an AS and use EBGP sessions between the tiers= . In this case all switches within a given tier are in the same AS and EBGP= sessions are used between the tiers.

 =

A thir= d option is to assign a different AS number to each switch. In this case ea= ch switch is a separate AS and EBGP sessions are used everywhere.

 =

In thi= s document we assume, without loss of generality, the third option.<= /i>

 =

>&g= t;> Comment #2 end.

 

 

   o  The forwa= rding plane at Tier-2 and Tier-1 is MPLS.

 

   o  The forwa= rding plane at Tier-3 is either IP2MPLS (if the host

     = sends IP traffic) or MPLS2MPLS (if the host sends MPLS-

     = encapsulated traffic).

 

>&g= t;> Comment #3 start.

 =

The wa= y you numbered the tiers in your diagram, MPLS is in tier-2 and tier-3, and= tier-1 is either IP2MPLS or MPLS.  (Note that the numbering of the ti= ers in your diagram is the reverse from the numbering in draft-ietf-rtgwg-bgp-routing-large-dc-00 which is likely = the source of the confusion.)

 =

Sugges= ted text:

 =

o The = forwarding plane between the spine switches and the super spine switches is= MPLS

 =

o The = forwarding plane between the leaf switches (=3D ToR switches) and the spine= switches is MPLS

 =

o The = forwarding plane between the servers and the leaf switches (=3D ToR switche= s) may be MPLS or IP.

 

>&g= t;> Comment #3 end.

 

 

   In this document,= we also refer to the Tier-3, Tier-2 and Tier-1

   switches respecti= vely as Spine, Leaf and ToR (top of rack) switches.

   When a ToR switch= acts as a gateway to the "outside world", we call

   it a border switc= h.

 

>&g= t;> Comment #4 start.

 =

I beli= eve it is common to consider the ToR switches (i.e. the switches that are c= onnected to the servers) to be the leaf switches.

 =

I woul= d suggest the following terminology:

o ToR = switch =3D leaf switch

o Spin= e switch

o Supe= r spine switch

 =

I also= believe that it is more common to number the tiers starting from the botto= m (leaf) with index 0:

o ToR = switch =3D leaf switch =3D tier 0

o Spin= e switch =3D tier 1

o Supe= r spine switch =3D tier 2

 

>&g= t;> Comment #4 end.

 

   Node 11 sends the= following eBGP3107 update to Node 10:

 

   . NLRI:  1.1.1.11/32

   . Label: Implicit= -Null

   . Next-hop: Node1= 1's interface address on the link to Node10

   . AS Path: {11}

   . BGP-Prefix Attr= ibute: Index 11

 

   Node 10 receives = the above update.  As it is SR capable, Node10 is

   able to interpret= the BGP-Prefix Attribute and hence allocates the

   label 16011 to th= e NLRI (instead of asking a "random/local" label

   from its label ma= nager).  The implicit-null label in the update

   signals to Node 1= 0 that it is the penultimate hop and MUST pop the

   top label on the = stack before forwarding traffic for this prefix to

   Node 11.

 

   Then, Node 10 sen= ds the following eBGP3107 update to Node 7:

 

   . NLRI:  1.1.1.11/32

   . Label: 16011

   . Next-hop: Node1= 0's interface address on the link to Node7

   . AS Path: {10, 1= 1}

   . BGP-Prefix Attr= ibute: Index 11

 

>&g= t;> Comment #5 start.

 =

As des= cribed here, this proposal requires that node 10 has a-priori knowledge of = the globally significant label which must be assigned to prefix 1.1.1.11/32.

 =

This i= s not only true for node 10, but it is also true for every other node conne= cted to node 11 which receives prefix 1.1.1.11/32 with an im= plicit null label. 

 =

From a= practical operational view, it might require that every node has a-priori = knowledge of the binding of MPLS labels to nodes.  What this means, in= effect, is that the BGP signaling only used for reachability detection, and not for distribution of label to node= bindings.

 =

Provid= ing each node with a-priori knowledge of label to node binding for every no= de in the POD may be too much of a configuration burden for most operators.=

 =

This p= roblem is solved later on in this draft using the I-D.keyupate-idr-bgp-pref= ix-sid mechanism (although the problem is still there for transition scenar= ios).

 =

Altern= atively, avoiding the need for pre-configured label-to-prefix binding can a= lso be achieved by making the following BGP implementation changes without = any on-the-wire protocol change.

 =

1. Eac= h ultimate hop node is configured to advertise its global label instead of = implicit null.

 =

2. Eac= h node which receives a BGP-LU advertisement is configured to:

 =

2a) No= t allocate a new locally significant label when it does a next-hop self.&nb= sp; Instead, it keeps the received label.  This behavior could be rest= ricted to a particular label block.

 =

2b) Po= p the label (i.e. do a PHP) when it is forwarding the packet to the ultimat= e hop (which can be detected using the AS-path) despite the fact that the u= ltimate hop advertised a real label instead of an implicit null label.

 =

>&g= t;> Comment #5 end.

 

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

     =          Incoming label  =   | outgoing label | Outgoing

     =          or IP destination | &= nbsp;           &nbs= p;  | Interface

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

     =             &nb= sp; 16011        |   &nbs= p;  16011     | ECMP{7, 8}

     =            1.1.1.11/32     = |      16011     | ECMP{7, 8}<= /span>

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

 

     =             &nb= sp;   Figure 4: Node-4 Forwarding Table

 

>&g= t;> Comment #6 start.

 =

In the= example topology, the spine switches were not fully meshed to the super sp= ine switches.  In a real life topology they would be fully meshed, and= the ECMP set out be a 4-way ECMP set ECMP{5,6,7,8}

 

>&g= t;> Comment #6 end.

 

 

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

      = ;        Incoming label  =   | outgoing label | Outgoing

     =          or IP destination | &= nbsp;           &nbs= p;  | Interface

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

     =             &nb= sp; 16011        |   &nbs= p;  16011     |    10

     =            1.1.1.11/32     |      160= 11     |    10

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

 

     =             &nb= sp;   Figure 5: Node-7 Forwarding Table

 

 

>&g= t;> Comment #6 start.

 =

In the= example topology, the spine switches were not fully meshed to the super sp= ine switches.  In a real life topology they would be fully meshed, and= the ECMP set out be a 2-way ECMP set ECMP{9,10}

 

>&g= t;> Comment #6 end.

 =

 

 

3.3.  Network Design Vari= ation

 

   A network design = choice could consist of switching all the traffic

   through tier-2 an= d tier-3 as MPLS traffic.  In this case, one could

   filter away the I= P entries at nodes 4, 7 and 10.  This might be

   beneficial in ord= er to optimize the forwarding table size.

 

   A network design = choice could consist in allowing the hosts to send

   MPLS-encapsulated= traffic (based on EPE use-case,

   [I-D.filsfils-spr= ing-segment-routing-central-epe]).  For example,

   Node 1 would rece= ive Node11-destined MPLS-encapsulated traffic from

   its attached host= A and would switch this traffic on the basis of the

   MPLS entry for 16= 011 (instead of classically receiving IP traffic

   from A and perfor= ming an IPtoMPLS switching operation).

 

>&g= t;> Comment #7 start.

 =

It wou= ld be good to point out explicitly that the second approach allows the host= s to send a multi-label stack (for example to implement egress peer enginee= ring as described later in this I-D).  If IP forwarding is used between leaf switches, then this would require so= me MPLS over IP-tunnel approach (e.g. MPLS-over-GRE).  Using MPLS as t= he base tunnel mechanism is more consistent and allows other features to be= supported that cannot be implemented with MPLS-over-IP-tunnel based approaches (e.g. the capacity optimization = use case described in section 4.4 of the I-D).

 

>&g= t;> Comment #7 end.

 =

   From a signaling = viewpoint, nothing would change as even if Node6

   does not understa= nd the BGP-Prefix Segment attribute, it does

   propagate it unmo= dified to its neighbors.

 

   From a label allo= cation viewpoint, the only difference is that Node7

   would allocate a = dynamic label to the prefix 1.1.1.11/32 (e.g.

   12345) and would = advertise that label to its neighbor Node4.

 

>&g= t;> Comment #8 start.

 =

There = may be one change which is required on on the legacy Node7.

 =

We hav= e to make sure that the MPLS label which is allocated by Node7 does not &qu= ot;collide" with the globally significant labels.  For example, t= hings would break if legacy Node7 happen happens to dynamically allocate a 1600x label.  This can be avoided by introd= ucing a configuration knob in the label allocation subsystem of the switch = for "off-limits label blocks".

 

>&g= t;> Comment #8 end.

 

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