From nobody Mon Apr 4 11:04:54 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD1912D5E1; Mon, 4 Apr 2016 11:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eq-ZVrQAYXRU; Mon, 4 Apr 2016 11:04:51 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA8812D564; Mon, 4 Apr 2016 11:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3688; q=dns/txt; s=iport; t=1459793090; x=1461002690; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VBDeLpbi1TAgh0ij+yn/2ucwPHPRUjuLnWYJL43Ed8s=; b=L0KaLngtdQcXduzk/lWn5zM0aTV/W7rlJiUQHW972WwmEluP2POKf+IF y9jEiHA7n19hlqrFjwum2JsIJHCwDXYwH6oEg6pko3g1ODpKPJqBxx6Xp f1x+CFH8NO9Pfi1kCNeHI2GRbYqrHDfVE9yUETh9km3A1iNS2PHu+WHZl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQCRrAJX/5RdJa1cgzdTfQa5EYIPA?= =?us-ascii?q?Q2BciGFbAIcgR44FAEBAQEBAQFlJ4RBAQEBAwEjEUUFCwIBCBgCAiYCAgIwFRA?= =?us-ascii?q?CBA4FG4gECA6sLpE9AQEBAQEBAQEBAQEBAQEBAQEBAQEBEQR8hSSBdYJVhA8RA?= =?us-ascii?q?YMeK4IrBYdvkBIBhXKIFYFohE2IWo8ZAR4BAUKCBAUUFYE1bAGGcTZ+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,441,1454976000"; d="scan'208";a="257264404" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2016 18:04:47 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u34I4kcw004776 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2016 18:04:46 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 4 Apr 2016 14:04:46 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Mon, 4 Apr 2016 14:04:46 -0400 From: "Stefano Previdi (sprevidi)" To: Terry Manderson Thread-Topic: Terry Manderson's Discuss on draft-ietf-spring-problem-statement-06: (with DISCUSS) Thread-Index: AQHRUmcdxC2ezwZ2TkO7N4Ho08MbY5961yuA Date: Mon, 4 Apr 2016 18:04:46 +0000 Message-ID: <6031147B-E0A8-444A-A6D5-228DA237BEA1@cisco.com> References: <20160119031137.13393.62898.idtracker@ietfa.amsl.com> In-Reply-To: <20160119031137.13393.62898.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.240.12] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "spring-chairs@ietf.org" , The IESG , "Pierre Francois \(pifranco\)" , "Alvaro Retana \(aretana\)" , "draft-ietf-spring-problem-statement@ietf.org" Subject: Re: [spring] Terry Manderson's Discuss on draft-ietf-spring-problem-statement-06: (with DISCUSS) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 04 Apr 2016 18:04:52 -0000 SGkgVGVycnksDQoNCg0Kc29ycnkgZm9yIGNvbWluZyBiYWNrIGxhdGUgb24gdGhpcy4gU2VlIGJl bG93Og0KDQoNCj4gT24gSmFuIDE5LCAyMDE2LCBhdCA0OjExIEFNLCBUZXJyeSBNYW5kZXJzb24g PHRlcnJ5Lm1hbmRlcnNvbkBpY2Fubi5vcmc+IHdyb3RlOg0KPiANCj4gVGVycnkgTWFuZGVyc29u IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1p ZXRmLXNwcmluZy1wcm9ibGVtLXN0YXRlbWVudC0wNjogRGlzY3Vzcw0KPiANCj4gV2hlbiByZXNw b25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8g YWxsDQo+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAo RmVlbCBmcmVlIHRvIGN1dCB0aGlzDQo+IGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIu KQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0 YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJv dXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9j dW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhl cmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc3ByaW5n LXByb2JsZW0tc3RhdGVtZW50Lw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NV U1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFRoYW5rcyBmb3IgcHV0dGluZyBpbiB0aGUgZWZm b3J0IGluIHdyaXRpbmcgdGhpcy4gRmlyc3RseSwgSSBjb25jdXIgd2l0aA0KPiBCZW5vaXQncyBv YnNlcnZhdGlvbiBhYm91dCB0ZXh0IHRha2VuIGZyb20gdGhlIGNoYXJ0ZXIgYW5kIGxhaWQgaW4g dG8gdGhlDQo+IGRvY3VtZW50IHZlcmJhdGltLiBUaGF0IHRlbmRzIG5vdCB0byBoZWxwIHRoZSBy ZWFkZXIgYW5kIGEgbGFyZ2UNCj4gYXNzdW1wdGlvbiBpcyBtYWRlIHRoYXQgdGhlIHJlYWRlciB1 bmRlcnN0YW5kcyB0aGUgY29uY2VybnMgb2Ygc291cmNlDQo+IGJhc2VkIHJvdXRpbmcgZm9yIHBh cnRpdGlvbmluZyBWUE5zLCBmYXN0IHJlLXJvdXRlLCBURSwgc2lnbmFsbGluZywgYW5kDQo+IHNv IG9uLg0KDQoNCnllcywgdGhlIGNvLWF1dGhvcnMgYXNzdW1lIHRoYXQgdGhlIHJlYWRlciBpcyBh bHJlYWR5IGZhbWlsaWFyIHdpdGggY29uY2VwdHMgc3VjaCBhcyBzb3VyY2Ugcm91dGluZywgVEUs IFZQTiwg4oCmDQoNCk1heWJlIHdlIGNhbiBhZGQgcmVmZXJlbmNlcy9wb2ludGVycyB0byByZWxl dmFudCBkb2N1bWVudHMuDQoNCg0KPiBQbGVhc2UgY29uc2lkZXIgcmV3cml0aW5nIHRoZSBpbnRy byBhbmQgb3RoZXIgcGFydHMgdG8gaGVscCB3aXRoDQo+IHVuZGVyc3RhbmRpbmcgKGZvciBleGFt cGxlIGluIDMuMiBGYXN0IFJlcm91dGU7IG1pY3JvcGxvb3AgYXZvaWRhbmNlIGlzDQo+IGxpc3Rl ZCBhcyBhIHJlcXVpcmVtZW50LCBob3dldmVyIGEgc2Vuc2libGUgY292ZXJhZ2Ugb2YgbWljcm9s b29wDQo+IGF2b2lkYW5jZSBpcyBub3QgZm91bmQgaW4gdGhlIGRyYWZ0LCBub3IgaW4gdGhlIG5l YXJieSByZWZlcmVuY2VkDQo+IHNwcmluZy1yZXNpbGllbmN5LXVzZS1jYXNlcykuDQoNCg0KSW5k ZWVkLiBXZSB3aWxsIHB1dCBhZGRpdGlvbmFsIHRleHQgb24gbWljcm9sb29wLWF2b2lkYW5jZSBp biBkcmFmdC1pZXRmLXNwcmluZy1yZXNpbGllbmN5LXVzZS1jYXNlcy4NCg0KDQoNCj4gVGhpcyBh bHNvIGxlYXZlcyBtZSBzY3JhdGNoaW5nIG15IGhlYWQgYXMNCj4gdG8gd2h5IHdlIGRvbid0IHNl ZSB0aGlzIGRvY3VtZW50IGFuZCB0aGUgcmVzaWxpZW5jeS11c2UtY2FzZXMgKGFuZA0KPiBvdGhl cnMpIGF0IHRoZSBzYW1lIHRpbWUgd2hlbiB0aGV5IGFyZSBhbGlnbmVkPyBPciByZXN0cnVjdHVy ZSB0aGUNCj4gZG9jdW1lbnQgdG8gYmUgbW9yZSBpbmZvcm1hdGl2ZSBvbiB0aGVzZSBmYWNldHMg aW4gdGhlIGZpcnN0IGNhc2UuDQo+IA0KPiBDYW4gdGhlIGRvY3VtZW50IGFsc28gYmUgZXhwbGlj aXQgdGhhdCB3aGlsZSB0aGUgU1BSSU5HIHByb2JsZW0vc29sdXRpb24NCj4gc3BhY2UgbmVlZHMg dG8gYmUgY29nbmlzYW50IG9mIGF1dG9ub21vdXMgc3lzdGVtcyB0aGF0IHNoYXJlDQo+IHBvbGlj eS9pbnRlcm9wZXJhdGUgYWNyb3NzIGJvdW5kYXJpZXMgdGhlIHByaW1hcnkgcG9ydCBvZiBjYWxs IGlzIGluDQo+IHJlZ2FyZCB0byB0aGUgSUdQLiBUaGlzIHdpbGwgY2VydGFpbmx5IGFpZGUgaW4g cmVzdHJhaW5pbmcgZXZlcnlvbmUgKGVzcC4NCj4gdGhlIHJlYWRlcikgZnJvbSB0cnlpbmcgdG8g Ym9pbCB0aGUgJ2ludGVybmV0IG9jZWFuJy4gKHRoaXMgYXQgbGVhc3QNCj4gc2hvdWxkIGJlIGVh c3kgdG8gYWRkcmVzcyA6KQ0KDQoNCkkgYWdyZWUuIFdlIGhhdmUgc2lnbmlmaWNhbnRseSByZXZp c2VkIHRoZSBzZWN1cml0eSBzZWN0aW9uLiBJdCBub3cgdGFsa3MgYWJvdXQgdHJ1c3QgYm91bmRh cmllcy4NCg0Kcy4NCg0K From nobody Tue Apr 5 04:22:40 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED1112D0C6; Tue, 5 Apr 2016 04:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMuJk4Qg3yQ1; Tue, 5 Apr 2016 04:22:31 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25D8212D0A9; Tue, 5 Apr 2016 04:22:31 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 5 Apr 2016 04:22:29 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1130.005; Tue, 5 Apr 2016 04:22:28 -0700 From: Terry Manderson To: "Stefano Previdi (sprevidi)" Thread-Topic: Terry Manderson's Discuss on draft-ietf-spring-problem-statement-06: (with DISCUSS) Thread-Index: AQHRUmcpQxMTlwfYuUmJ5pioOJ8ubJ97CXsAgAHJiYA= Date: Tue, 5 Apr 2016 11:22:27 +0000 Message-ID: References: <20160119031137.13393.62898.idtracker@ietfa.amsl.com> <6031147B-E0A8-444A-A6D5-228DA237BEA1@cisco.com> In-Reply-To: <6031147B-E0A8-444A-A6D5-228DA237BEA1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3542736141_12046215" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "spring-chairs@ietf.org" , The IESG , "Pierre Francois \(pifranco\)" , "Alvaro Retana \(aretana\)" , "draft-ietf-spring-problem-statement@ietf.org" Subject: Re: [spring] Terry Manderson's Discuss on draft-ietf-spring-problem-statement-06: (with DISCUSS) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 05 Apr 2016 11:22:33 -0000 --B_3542736141_12046215 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Stefano,=20 Thank you for addressing my DISCUSS, when I see a rev of this document that addresses these items I will review and likely clear the discuss. Cheers Terry=20 On 5/04/2016, 4:04 AM, "Stefano Previdi (sprevidi)" wrote: >Hi Terry, > > >sorry for coming back late on this. See below: > > >> On Jan 19, 2016, at 4:11 AM, Terry Manderson >> wrote: >>=20 >> Terry Manderson has entered the following ballot position for >> draft-ietf-spring-problem-statement-06: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to=20 >>https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/ >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >>=20 >> Thanks for putting in the effort in writing this. Firstly, I concur with >> Benoit's observation about text taken from the charter and laid in to >>the >> document verbatim. That tends not to help the reader and a large >> assumption is made that the reader understands the concerns of source >> based routing for partitioning VPNs, fast re-route, TE, signalling, and >> so on. > > >yes, the co-authors assume that the reader is already familiar with >concepts such as source routing, TE, VPN, =8A > >Maybe we can add references/pointers to relevant documents. > > >> Please consider rewriting the intro and other parts to help with >> understanding (for example in 3.2 Fast Reroute; microploop avoidance is >> listed as a requirement, however a sensible coverage of microloop >> avoidance is not found in the draft, nor in the nearby referenced >> spring-resiliency-use-cases). > > >Indeed. We will put additional text on microloop-avoidance in >draft-ietf-spring-resiliency-use-cases. > > > >> This also leaves me scratching my head as >> to why we don't see this document and the resiliency-use-cases (and >> others) at the same time when they are aligned? Or restructure the >> document to be more informative on these facets in the first case. >>=20 >> Can the document also be explicit that while the SPRING problem/solution >> space needs to be cognisant of autonomous systems that share >> policy/interoperate across boundaries the primary port of call is in >> regard to the IGP. This will certainly aide in restraining everyone >>(esp. >> the reader) from trying to boil the 'internet ocean'. (this at least >> should be easy to address :) > > >I agree. We have significantly revised the security section. It now talks >about trust boundaries. > >s. > --B_3542736141_12046215 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFAOP Rc/AAs4lEvJMtB+tEPSqJPahMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE2MDQwNTExMjIyMVowDQYJKoZIhvcNAQEBBQAEggEAU5lgrkk7Mo33PQWMoAG0 GNDShlVPZKik/vP19NNrZ8ae8pTwOoFpQcwwxoSBwMW9b3K99A8RyYSPV63sBt686tqCw0ow MDNIpBBLJ2o+BJYrkbu+wV07a6JWWkzxoqfa/FXZufLLxK5LExBCGGrtgMJerCPMn65R7ijs r9GwA3pcZWAcoGKOUcRMltXNbCl536Cqj/pVhkhVwS11AU21dLMIYjom7mv9So3bQuW38OUl 3ox3cVQer3a+lrurCW7r9Pd20wJ6tfAkyAPLwa3tKyfyLlAJ5mDvY52RVDmuTADoNfy8FaqQ 7hAkk+mr6P8Y3rhEn0wi7j99oNGGSdrPBA== --B_3542736141_12046215-- From nobody Wed Apr 6 00:57:15 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D16F12D0B6; Wed, 6 Apr 2016 00:57:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160406075711.24979.10383.idtracker@ietfa.amsl.com> Date: Wed, 06 Apr 2016 00:57:11 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-03.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 07:57:11 -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 of the IETF. Title : Use-cases for Resiliency in SPRING Authors : Pierre Francois Clarence Filsfils Bruno Decraene Rob Shakir Filename : draft-ietf-spring-resiliency-use-cases-03.txt Pages : 8 Date : 2016-04-06 Abstract: This document describes the use cases for resiliency in SPRING networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-resiliency-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 Wed Apr 6 03:56:08 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A0512D702; Wed, 6 Apr 2016 03:56:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160406105607.25030.14382.idtracker@ietfa.amsl.com> Date: Wed, 06 Apr 2016 03:56:07 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-problem-statement-08.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 10:56:07 -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 of the IETF. Title : SPRING Problem Statement and Requirements Authors : Stefano Previdi Clarence Filsfils Bruno Decraene Stephane Litkowski Martin Horneffer Rob Shakir Filename : draft-ietf-spring-problem-statement-08.txt Pages : 18 Date : 2016-04-06 Abstract: The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions. Source-based routing mechanisms have previously been specified for network protocols, but have not seen widespread adoption. In this context, the term 'source' means 'the point at which the explicit route is imposed' and therefore it is not limited to the originator of the packet (i.e.: the node imposing the explicit route may be the ingress node of an operator's network). This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture for unicast traffic. Multicast use- cases and requirements are out of scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-problem-statement-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-problem-statement-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 6 04:01:02 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D8012D866; Wed, 6 Apr 2016 04:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NErEDd-fjCfU; Wed, 6 Apr 2016 04:00:59 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC4D12D197; Wed, 6 Apr 2016 04:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3576; q=dns/txt; s=iport; t=1459940459; x=1461150059; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zBT6Vtpm1sWpvHM7QwGprNBx/Jjm/rhByKVnudcCYnM=; b=Ui/Uhia6W3S196lpfvYFdJ57AMjIXkApwndJSWRrxtA0glBTCdLziyYH k/SG94eHE6cQNFRUSKUdzfwSKuuEA6Q2FnkZotPtg4i4BEwKFSZP871k6 gGZdXwVNEXEmUDDZ+D+Pxxy2omOLm19PR5hQ+m2B4AQYs/y8JgRTJQGN6 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgDq6wRX/4gNJK1cgzdTfQa4PIIPA?= =?us-ascii?q?Q2BciGFbAKBQjgUAQEBAQEBAWUnhEEBAQEDAXkFCwIBCBguMiUCBA4FG4gECA7?= =?us-ascii?q?AWwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhiGBdQiCToQPEQEcNIJ5gisFh2+QE?= =?us-ascii?q?gGFdYgVgWeETYhajyABHgEBQoIEBRQVgTVsAYc+Nn4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,447,1454976000"; d="scan'208";a="90594302" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Apr 2016 11:00:57 +0000 Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u36B0vDa004363 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2016 11:00:57 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Apr 2016 07:00:56 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Wed, 6 Apr 2016 07:00:56 -0400 From: "Stefano Previdi (sprevidi)" To: Terry Manderson Thread-Topic: Terry Manderson's Discuss on draft-ietf-spring-problem-statement-06: (with DISCUSS) Thread-Index: AQHRUmcdxC2ezwZ2TkO7N4Ho08MbY5961yuAgAEh84CAAYxKAA== Date: Wed, 6 Apr 2016 11:00:56 +0000 Message-ID: <0A732A61-7D81-4485-833D-9FAFD1EB8A74@cisco.com> References: <20160119031137.13393.62898.idtracker@ietfa.amsl.com> <6031147B-E0A8-444A-A6D5-228DA237BEA1@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.69.136] Content-Type: text/plain; charset="Windows-1252" Content-ID: <770A9560875EB644B074CD8B46116EF3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "spring-chairs@ietf.org" , The IESG , "Pierre Francois \(pifranco\)" , "Alvaro Retana \(aretana\)" , "draft-ietf-spring-problem-statement@ietf.org" Subject: Re: [spring] Terry Manderson's Discuss on draft-ietf-spring-problem-statement-06: (with DISCUSS) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 06 Apr 2016 11:01:01 -0000 Hi Terry, We just updated draft-ietf-spring-resiliency-use-cases with more introducto= ry text on FR/Microloop-avoidance and updated the reference to the draft in= draft-ietf-spring-problem-statement. Thanks. s. > On Apr 5, 2016, at 1:22 PM, Terry Manderson w= rote: >=20 > Stefano,=20 >=20 > Thank you for addressing my DISCUSS, when I see a rev of this document > that addresses these items I will review and likely clear the discuss. >=20 > Cheers > Terry=20 >=20 > On 5/04/2016, 4:04 AM, "Stefano Previdi (sprevidi)" > wrote: >=20 >> Hi Terry, >>=20 >>=20 >> sorry for coming back late on this. See below: >>=20 >>=20 >>> On Jan 19, 2016, at 4:11 AM, Terry Manderson >>> wrote: >>>=20 >>> Terry Manderson has entered the following ballot position for >>> draft-ietf-spring-problem-statement-06: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to=20 >>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/ >>>=20 >>>=20 >>>=20 >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>>=20 >>> Thanks for putting in the effort in writing this. Firstly, I concur wit= h >>> Benoit's observation about text taken from the charter and laid in to >>> the >>> document verbatim. That tends not to help the reader and a large >>> assumption is made that the reader understands the concerns of source >>> based routing for partitioning VPNs, fast re-route, TE, signalling, and >>> so on. >>=20 >>=20 >> yes, the co-authors assume that the reader is already familiar with >> concepts such as source routing, TE, VPN, =8A >>=20 >> Maybe we can add references/pointers to relevant documents. >>=20 >>=20 >>> Please consider rewriting the intro and other parts to help with >>> understanding (for example in 3.2 Fast Reroute; microploop avoidance is >>> listed as a requirement, however a sensible coverage of microloop >>> avoidance is not found in the draft, nor in the nearby referenced >>> spring-resiliency-use-cases). >>=20 >>=20 >> Indeed. We will put additional text on microloop-avoidance in >> draft-ietf-spring-resiliency-use-cases. >>=20 >>=20 >>=20 >>> This also leaves me scratching my head as >>> to why we don't see this document and the resiliency-use-cases (and >>> others) at the same time when they are aligned? Or restructure the >>> document to be more informative on these facets in the first case. >>>=20 >>> Can the document also be explicit that while the SPRING problem/solutio= n >>> space needs to be cognisant of autonomous systems that share >>> policy/interoperate across boundaries the primary port of call is in >>> regard to the IGP. This will certainly aide in restraining everyone >>> (esp. >>> the reader) from trying to boil the 'internet ocean'. (this at least >>> should be easy to address :) >>=20 >>=20 >> I agree. We have significantly revised the security section. It now talk= s >> about trust boundaries. >>=20 >> s. >>=20 From nobody Wed Apr 6 06:36:55 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1484412D514; Wed, 6 Apr 2016 06:36:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Terry Manderson" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160406133654.24967.8951.idtracker@ietfa.amsl.com> Date: Wed, 06 Apr 2016 06:36:54 -0700 Archived-At: Cc: pifranco@cisco.com, aretana@cisco.com, draft-ietf-spring-problem-statement@ietf.org, spring-chairs@ietf.org, spring@ietf.org Subject: [spring] Terry Manderson's No Objection on draft-ietf-spring-problem-statement-08: (with COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 13:36:54 -0000 Terry Manderson has entered the following ballot position for draft-ietf-spring-problem-statement-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the update in addressing my concerns in this rev, clearing my DISCUSS. From nobody Wed Apr 6 08:37:38 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395DA12D542; Wed, 6 Apr 2016 08:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4eHF2aMAY-5; Wed, 6 Apr 2016 08:37:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5F412D528; Wed, 6 Apr 2016 08:37:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLQ92283; Wed, 06 Apr 2016 15:37:28 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 6 Apr 2016 16:37:27 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 6 Apr 2016 23:37:21 +0800 From: Xuxiaohu To: "spring@ietf.org" Thread-Topic: Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkBgULgoheUag70W81YSz/dG9Vg== Date: Wed, 6 Apr 2016 15:37:21 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.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.212.198.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.57052D39.0008, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c66893d3ade0d7a0417cd6f057135152 Archived-At: Cc: "mpls@ietf.org" Subject: [spring] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 06 Apr 2016 15:37:34 -0000 Hi all, According to suggestions from SPRING co-chairs, I would clarify the intenti= on of this draft (https://tools.ietf.org/html/draft-xu-spring-islands-conne= ction-over-ip-05) as follows. If I understood the current MPLS-SR specification (https://tools.ietf.org/h= tml/draft-ietf-spring-segment-routing-mpls) correctly, the IGP next-hop for= a given /32 or /128 prefix FEC (i.e., node segment prefix) is taken as the= next-hop of the received MPLS packet belonging to that FEC. When the IGP n= ext-hop for that FEC is a non-MPLS node, the outgoing label for that FEC is= lacked. As a result, the received MPLS packet belonging to that FEC would = be dropped BY DEFAULT according to the following specification as quoted fr= om RFC3031: "3.22. Lack of Outgoing Label When a labeled packet is traveling along an LSP, it may occasionally happen that it reaches an LSR at which the ILM does not map the packet's incoming label into an NHLFE, even though the incoming label is itself valid. This can happen due to transient conditions, or due to an error at the LSR which should be the packet's next hop. It is tempting in such cases to strip off the label stack and attempt to forward the packet further via conventional forwarding, based on its network layer header. However, in general this is not a safe procedure: - If the packet has been following an explicitly routed LSP, this could result in a loop. - The packet's network header may not contain enough information to enable this particular LSR to forward it correctly. Unless it can be determined (through some means outside the scope of this document) that neither of these situations obtains, the only safe procedure is to discard the packet." In the T-LDP or L-BGP case, the next-hop for the MPLS packet belong to a gi= ven prefix FEC is not the IGP next-hop of that FEC anymore. For instance, i= n the T-LDP case, the next-hop is the T-LDP peer, and in the L-BGP case, th= e next-hop is the L-BGP peer. As a result, if T-LDP peers or L-BGP peers ar= e not directly connected and are separated by an IP network, the LSP signal= ed by T-LDP or L-BGP could be transported over that IP network.=20 The situation in MPLS-SR is a little bit complex since the outgoing label f= or a given /32 or /128 prefix FEC could be learnt either from the IGP next-= hop of that FEC or the originator of that FEC due to the IGP flooding prope= rty. In the former case, the IGP next-hop for a given FEC is taken as the n= ext-hop of the received MPLS packet belonging to that FEC; in the latter ca= se, the originator of that FEC is taken as the next-hop of the MPLS packet = belonging to that FEC. The former case is straightforward to understand and= has been described in the current MPLS-SR draft. the latter case is a bit = hard to understand and has not been described in the current MPLS-SR drafts= . In fact, the latter case belongs to the "remote label distribution peer" = case as defined in RFC3031, see below: "When two LSRs are IGP neighbors, we will refer to them as "local label distribution peers". When two LSRs may be label distribution peers, but are not IGP neighbors, we will refer to them as "remote label distribution peers." In a word, this draft (https://tools.ietf.org/html/draft-xu-spring-islands-= connection-over-ip-05) describes the remote label distribution peer mode wh= ich is useful for incremental deployment purpose. I would like to hear from SPRING and MPLS WGs whether the remote label dist= ribution peer mode is valid for MPLS-SR and whether we need a draft to desc= ribe the remote label distribution peer mode for MPLS-SR. Best regards, Xiaohu= From nobody Wed Apr 6 13:48:49 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990B612D5E3; Wed, 6 Apr 2016 13:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69DyZ_ovCo18; Wed, 6 Apr 2016 13:48:45 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0771.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:771]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C50312D58C; Wed, 6 Apr 2016 13:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EIfqJz2CN9hxxtQ9uaEXsUcE6UUoP7rz+wmqvfcNoco=; b=YODEdA4yohgpSgmNmlE11o22RB1+FzdgF7PGHQU0Rg7TDt9x6hIb0/q/a1eaWzPPHEpnIR2ilfsk8QPGxHbJlbdB06VuBOO8fSH/eQATrJTSgRh52d4LXOyOWGQJ8sC3jlr1yQZJ2ag/Ixq/6UxdKmy/fO70HhQdok5xpAS3ffE= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.33.33] (66.129.241.12) by CO2PR05MB793.namprd05.prod.outlook.com (10.141.226.15) with Microsoft SMTP Server (TLS) id 15.1.447.15; Wed, 6 Apr 2016 20:48:27 +0000 To: Xuxiaohu , "spring@ietf.org" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> From: Eric C Rosen Message-ID: <57057618.8020604@juniper.net> Date: Wed, 6 Apr 2016 16:48:24 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: SN1PR11CA0026.namprd11.prod.outlook.com (10.164.10.36) To CO2PR05MB793.namprd05.prod.outlook.com (10.141.226.15) X-MS-Office365-Filtering-Correlation-Id: b268b78d-e198-4ffc-0fb5-08d35e5cce60 X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB793; 2:zlOnuBnKQX5dDLkY/n44itHxUvqbfSSMnZY5qYsAhU6ads6Wv89e0iTLKpT8WHt19WooEivelkcG2/VbflA225CvL2Xr5KmbS7B7y95uw+pV4Pv4BdfBPT4GSfoMFPKYUzIMQuQGG6Cv94TAL9yuOATJgOwu+IQ/LTkDiWPClABh0kkqnycCdg++JHK+wekm; 3:pUG4ig795OOeFtvkMK11e55ymg5fDH0iHhlJOV9RffBvpXld7ovb1L1/QBH0mEq6sjycKhIOgDfE/ggsPctzuaxMNVSCzAhDIx4dWQglgKwmMZu+rDoffDA/2zf22dzU; 25:8CyO8z2iYukwujeWRv2Miqr7BXXHXso4MY1G80gwlnQiFqXdMAA3JOtOJGx1A8FgcbjM1qvf4YWUeIXRiJtKoKiRlhHfosgb1TI/trkVDr4zUFnMMFApo7lYQkihlyqKClwEJgG5EMZIUfRk4UrB54PN8Seyqo8uMkXOFLd8OKsGwqznSEqNcAr1A8DLu6w269G2hvHwnHc6Sn+Eak9CEor98Pbc9k4h1/yBHm28j8G+jGkM+XrsPJrVNK3T1oh3Ys+MEeI9SHoCX4hG3FI5UlW86aEqiultkFPD+DuL18A5AG4AE2Fw3yDwpnIaiap6jUKNMLTaxB5k/xghE8le9IeN+hOOZGcXrpNdrJ+Fh0bsM9lMcl15uUWHqmMeeiwtsTVl9CWhQeEbzi5hHxXW6KZGvvfPzRNBMQHcOtNv+vGwaGjceJXAsHl5VktQUqivsqnXC0N/MBpnDu1YaPDmcQBA9czjsaxxzii0lgo/V3lMtEe4jECKDjlVqxtTFCD9rXSOO9xe5cxe1y/xH4uLpDqKdcMb57VdSkLvnKjSFa4LHb1p9wpbxaN978qVPTDs7lYzxWYS3m04b6qeWb8FBuPheGZVzhbVnl6/RBdqAsI= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB793; X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB793; 20:tJ99vAZhP9Ggfw4ihzFkOVvdwCzV+TuLln6U1zJDggF22V0858JcienZ0Cu1aLEZgoOGzPUhsfk/gzfDJl7I07i8BCNM9ezBxAb19KcEAEnknLOSTTHdGKEgEmy2jWoXmOvcaGD+HsRrzODHar3VzM/R1jsb6+4WPFWzk724BH++9a/hbfKPBFZeXl1973LTlKQnnQOhFqp+hA8eAgb9QtpHXR8qEGdgf+NfooFihtVWykL2aUNP113ulncNTA33kYG+cmYzbP83TvB7f6tYgISCm7KG/ksZEU3vQTqHQ6hUpMjCbF6D3SLhTcEyO6twVgRYnstF69py1msg3jNSerBUCswSyMe06gomXy2eAj7SVDEWrlGrsDJ4c/PzS2njXY7JkXqe4/UXcJo17yjGWurSGeSZrusqp+/1Cc6NBedQvG3tEB0FZVUrMCKq5doyCku1IPj1OOMWwZLctvWRBPymQmkrxMXLMqzpGf26odCrO0K6dHbdqJG+cO4fEAmt; 4:7/1/kV4N5BwPzPW1TRTAEzTfBAZgChUenKY4j636dK72WJU4fiCU5aRztY8pmmxG0ZM7hH6M5mwS67C9eBILADPUH4uDgNPq/vOUrN45L+rDNB9SkK1TKRzq9G+ypGCRCkNofywYwYUOX5FneksOWDV3MHq2HkNqcRAMaOoOrSDSr8jkNoBTUxRm4SKtBm1LQGTI1xXQITvxyZxGFt9hwfMMHmYqsk2jm33BHj1ij+3xKpXdeOrJNxsbAW/zn3xrKyOlRtpjdOGrM6e1fTOzWkoNiicjrxTesMzWTTOZ80xog0IsOefS69hyiNleUpe8NSCm0OdNJ9OcqKdmo9bJcl5TMGSnWLwgyAwNF7TihgeMb3vGMaLvF2y3HyeGkpWODtquPK09VqiRAOgke53Zrg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CO2PR05MB793; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB793; X-Forefront-PRVS: 0904004ECB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(377454003)(24454002)(77096005)(5001770100001)(4001350100001)(189998001)(122286003)(59896002)(50466002)(1096002)(83506001)(6116002)(3846002)(586003)(2950100001)(65806001)(36756003)(230700001)(64126003)(65956001)(66066001)(47776003)(117636001)(4326007)(230783001)(92566002)(86362001)(54356999)(87266999)(2906002)(65816999)(50986999)(99136001)(81166005)(23746002)(42186005)(5004730100002)(2501003)(5008740100001)(76176999)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB793; H:[172.29.33.33]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CO2PR05MB793; 23:hdgHqhHRKlpTjBI7WnoNAHVfY308Q/CoZR22N5?= =?Windows-1252?Q?CPi5aTbhD5vMQgee+zMmPnnvOhu39t+pNpWrbKMl11BvLXvSru2gUSWR?= =?Windows-1252?Q?FRd/TXzkn2Z+7fQUqocKLs/Qm4TWwSEDdQKiS4ZlnghhW4yB/sDQqdgW?= =?Windows-1252?Q?3LmFtSYpk19n9Vnu7zqo9+p2Pk+GgXFiBhEWGUYqXMc3N1GTivGMiEhl?= =?Windows-1252?Q?+zuJ88xpMfj3NsdHR/EvuOtrtkOFgX3naDoc1p+menYbHUUc30m4943M?= =?Windows-1252?Q?J4KoEgE1SDlfl92HzQytnqdZIm/EudHWr3zWLSHTqpadb72RRS0HODAE?= =?Windows-1252?Q?DgaPcels/jnyrqe3VO2D9Uop6pmcB0UFQmcL3qrnLG6UeuBMWR/kxRiL?= =?Windows-1252?Q?0j2wD4YB6qNylvP3oPxW2zaukTnLS/s1ByhHOvAotzgSROIfo28StmSg?= =?Windows-1252?Q?oxJ03dCaJYiLEHuNaiYCPF7Af5O2DlMn8qw7cE1TT6T1/tTOQlxBxMul?= =?Windows-1252?Q?L3iUihBGnZVwPV9rQB6jUd5Gpfh+ZH/GmUPyCOsEK5X0++5URNV4SGrQ?= =?Windows-1252?Q?EBd1ibbuMiL3siSeauw0QtwwNIqw8IAzw49dB7rmac+GXVkQRjP6xqnO?= =?Windows-1252?Q?k2+smJZbXakXdau+twlaLX+0OcFWzd7Oe2EwoLl6xm8WfR951hpJuBED?= =?Windows-1252?Q?DdsoYSTOwKU69ljVCMROWj+ANLhaSkspCEI8yDO9GAkhdq9ecEs7INMb?= =?Windows-1252?Q?ebnGDTR49F7fQeB7rr+zKoDi7d6q9yPHsZWZftJViX0e29xiGRjGtiDf?= =?Windows-1252?Q?5hNnEAZl9JPYuqg4hUF8Eful2wg3Kho4/3Mxy0UASKYixnaPpDvvSp2N?= =?Windows-1252?Q?TYf10WKwAkAUuGkTXPz/Ni1gaupxkkp247PzF0Oen3QVhn7WNQiwcvpc?= =?Windows-1252?Q?v/oRctiaESXJCyP84b8SVdcmQ9COW9irWmdV7nJHwcb8cGnpP73GLE++?= =?Windows-1252?Q?D0i2VuP+B60VASYOSgawltJ50qdqho6buSc4qDeNMd0NBlq+y9tyalL+?= =?Windows-1252?Q?TP6U6X9kc9FUuQ1mqcTUsXga9TrRjbp70oRzNREfJFNQO1a734rNSiyL?= =?Windows-1252?Q?NGZApNSF/4l4gW49xAivtb08vwfobh6IUuPnO/tfb8fkdQCc1BpidnlB?= =?Windows-1252?Q?2VJNGPXTOZkzdRY2pS7UGWcR8k2++wNiSaXP7Sbm1lf7c7nvse?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR05MB793; 5:JE2VI1Nu/LOr3prt4L0e4AUCNIxif0cXXonA3hOQNRrVysUnTF5hXBysFLJNy3z5+v5J7p49hdA/dUWr/AUF09Q2O0vadW8AKx+R20Zzkhs1d83AS4IUBE/5UDIdLWz1GUnHAiBnEalAqAQJGyZoLQ==; 24:/ETnA7QGQRtNv2WE7sXzqH5nEtZMr1XGwSIR4m4U+o2k4B+AcTkVmwpALaq3zFWPXX11osXsn6I2AYD0RqdKkyhZtOpMGDOQVXqIlm9Xqa4= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2016 20:48:27.4744 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB793 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [spring] [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 06 Apr 2016 20:48:47 -0000 On 4/6/2016 11:37 AM, Xuxiaohu wrote: > The situation in MPLS-SR is a little bit complex since the outgoing label for a given /32 or /128 prefix FEC could be learnt either from the IGP next-hop of that FEC or the originator of that FEC due to the IGP flooding property. In the former case, the IGP next-hop for a given FEC is taken as the next-hop of the received MPLS packet belonging to that FEC; in the latter case, the originator of that FEC is taken as the next-hop of the MPLS packet belonging to that FEC ... the latter case belongs to the "remote label distribution peer" case as defined in RFC3031 I don't believe this is correct. In SR, the fact that label L was advertised by node N does not imply that a packet with L at the top of the stack needs to be tunneled to N. In the typical case, the packet would just follow the IGP best path, and all the intermediate nodes would be expected to recognize the label at the top of the stack. If the intermediate nodes are expected to recognize the label, this is not the "remote label distribution peer case". You seem to be positing a case where two nodes are in the same IGP domain, and same SPRING domain, but there is no LSP that can be used to transport packets from one to the other. It would be somewhat unusual to have an IGP domain in which some nodes support MPLS and some don't. In BIER, we do accommodate this sort of situation, where some of the nodes in the BIER domain do not support BIER. But I don't know whether that sort of scenario needs to be supported for MPLS-SR. Do you have a particular use case in mind? From nobody Wed Apr 6 16:57:10 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6D412D161; Wed, 6 Apr 2016 16:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8uuq9K9hNKY; Wed, 6 Apr 2016 16:57:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D7B12D15B; Wed, 6 Apr 2016 16:57:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLR20989; Wed, 06 Apr 2016 23:57:00 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Apr 2016 00:56:59 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Thu, 7 Apr 2016 07:56:56 +0800 From: Xuxiaohu To: Eric C Rosen , "spring@ietf.org" Thread-Topic: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkBgULgoheUag70W81YSz/dG9Vp985QYAgAC0wMo= Date: Wed, 6 Apr 2016 23:56:55 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5383EC@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com>, <57057618.8020604@juniper.net> In-Reply-To: <57057618.8020604@juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.197.116] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5705A24D.0143, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ae67004a65fe6487a6f4468fd7610936 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [spring] [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 06 Apr 2016 23:57:08 -0000 SGkgRXJpYywNCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLiBZb3VyIG9ic2VydmF0 aW9uIGlzIGNvcnJlY3QgdGhhdCBJJ20gIHBvc2l0aW5nIGEgY2FzZSB3aGVyZSB0d28gbm9kZXMg YXJlIGluIHRoZSBzYW1lIElHUCBkb21haW4sIGFuZCBzYW1lIFNQUklORyBkb21haW4sIGJ1dCB0 aGVyZSBpcyBubyBMU1AgdGhhdCBjYW4gYmUgdXNlZCB0bw0KdHJhbnNwb3J0IHBhY2tldHMgZnJv bSBvbmUgdG8gdGhlIG90aGVyLg0KDQpPbmUgcGFydGljdWxhciB1c2UgY2FzZSBpbiBtaW5kIGlz IHRoZSBNUExTLVNSIGJhc2VkIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgd2hlcmUgdGhlIHNl cnZpY2UgZnVuY3Rpb24gcGF0aCBpcyByZXByZXNlbnRlZCBieSBhIHN0YWNrIG9mIGxhYmVscyAo c2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1zZmMtdXNpbmctbXBscy1z cHJpbmcpLiBJbiBvdGhlciB3b3JkcywgdGhlIFNGQyBlbmNhcHN1bGF0aW9uIGhlYWRlciBpcyBy ZWFsaXplZCBpbiB0aGUgZm9ybSBvZiBhbiBNUExTIGxhYmVsIHN0YWNrLiBPbmUgb2YgdGhlIG1h am9yIHJlcXVpcmVtZW50IGZvciB0aGUgU0ZDIGVuY2Fwc3VsYXRpb24gaGVhZGVyIGlzIHRyYW5z cG9ydC1pbmRlcGVuZGFuY3kuIFRoYXQgbWVhbnMgdGhlIFNGQyBlbmNhcHN1bGF0aW9uIGhlYWRl ciBpbiB0aGUgZm9ybSBvZiBhbiBNUExTIGxhYmVsIHN0YWNrIHNob3VsZCBiZSBhYmxlIHRvIGJl IHRyYW5zcG9ydGVkIG92ZXIgSVAgbmV0d29ya3MuIFRvIG1lZXQgdGhlIGFib3ZlIHJlcXVpcmVt ZW50LCBvbmUgTVBMUy1TUiBub2RlIChlLmcuLCBzZXJ2aWNlIGNsYXNzaWZpZXIgb3IgU0ZGKSBz aG91bGQgYmUgYWJsZSB0byBmb3J3YXJkIGEgcmVjZWl2ZWQgTVBMUyBwYWNrZXQgdG8gYW5vdGhl ciBNUExTLVNSIG5vZGUgKGUuZy4sIFNGRikgd2hpY2ggaXMgaW5kaWNhdGVkIGJ5IHRoZSB0b3Ag bGFiZWwgb2YgdGhlIHJlY2VpdmVkIHBhY2tldCB2aWEgYW4gSVAtYmFzZWQgdHVubmVsLCB3aGVu IHRoZSBJR1AgbmV4dC1ob3AgdG93YXJkcyB0aGUgbGF0dGVyIE1QTFMtU1Igbm9kZSBpcyBhIG5v bi1NUExTIG5vZGUuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IEVyaWMgQyBSb3NlbiBbZXJvc2VuQGp1 bmlwZXIubmV0XQ0Kt6LLzcqxvOQ6IDIwMTbE6jTUwjfI1SA0OjQ4DQrK1bz+yMs6IFh1eGlhb2h1 OyBzcHJpbmdAaWV0Zi5vcmcNCrOty806IG1wbHNAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbbXBsc10g Q2xhcmlmaWNhdGlvbiBvbiB0aGUgbW90aXZhdGlvbiBvZiBkcmFmdC14dS1zcHJpbmctaXNsYW5k cy1jb25uZWN0aW9uLW92ZXItaXAtMDUNCg0KT24gNC82LzIwMTYgMTE6MzcgQU0sIFh1eGlhb2h1 IHdyb3RlOg0KPiBUaGUgc2l0dWF0aW9uIGluIE1QTFMtU1IgaXMgYSBsaXR0bGUgYml0IGNvbXBs ZXggc2luY2UgdGhlIG91dGdvaW5nIGxhYmVsIGZvciBhIGdpdmVuIC8zMiBvciAvMTI4IHByZWZp eCBGRUMgY291bGQgYmUgbGVhcm50IGVpdGhlciBmcm9tIHRoZSBJR1AgbmV4dC1ob3Agb2YgdGhh dCBGRUMgb3IgdGhlIG9yaWdpbmF0b3Igb2YgdGhhdCBGRUMgZHVlIHRvIHRoZSBJR1AgZmxvb2Rp bmcgcHJvcGVydHkuIEluIHRoZSBmb3JtZXIgY2FzZSwgdGhlIElHUCBuZXh0LWhvcCBmb3IgYSBn aXZlbiBGRUMgaXMgdGFrZW4gYXMgdGhlIG5leHQtaG9wIG9mIHRoZSByZWNlaXZlZCBNUExTIHBh Y2tldCBiZWxvbmdpbmcgdG8gdGhhdCBGRUM7IGluIHRoZSBsYXR0ZXIgY2FzZSwgdGhlIG9yaWdp bmF0b3Igb2YgdGhhdCBGRUMgaXMgdGFrZW4gYXMgdGhlIG5leHQtaG9wIG9mIHRoZSBNUExTIHBh Y2tldCBiZWxvbmdpbmcgdG8gdGhhdCBGRUMgLi4uIHRoZSBsYXR0ZXIgY2FzZSBiZWxvbmdzIHRv IHRoZSAicmVtb3RlIGxhYmVsIGRpc3RyaWJ1dGlvbiBwZWVyIiBjYXNlIGFzIGRlZmluZWQgaW4g UkZDMzAzMQ0KDQpJIGRvbid0IGJlbGlldmUgdGhpcyBpcyBjb3JyZWN0LiAgSW4gU1IsIHRoZSBm YWN0IHRoYXQgbGFiZWwgTCB3YXMNCmFkdmVydGlzZWQgYnkgbm9kZSBOIGRvZXMgbm90IGltcGx5 IHRoYXQgYSBwYWNrZXQgd2l0aCBMIGF0IHRoZSB0b3Agb2YNCnRoZSBzdGFjayBuZWVkcyB0byBi ZSB0dW5uZWxlZCB0byBOLiAgSW4gdGhlIHR5cGljYWwgY2FzZSwgdGhlIHBhY2tldA0Kd291bGQg anVzdCBmb2xsb3cgdGhlIElHUCBiZXN0IHBhdGgsIGFuZCBhbGwgdGhlIGludGVybWVkaWF0ZSBu b2Rlcw0Kd291bGQgYmUgZXhwZWN0ZWQgdG8gcmVjb2duaXplIHRoZSBsYWJlbCBhdCB0aGUgdG9w IG9mIHRoZSBzdGFjay4gIElmDQp0aGUgaW50ZXJtZWRpYXRlIG5vZGVzIGFyZSBleHBlY3RlZCB0 byByZWNvZ25pemUgdGhlIGxhYmVsLCAgdGhpcyBpcyBub3QNCnRoZSAicmVtb3RlIGxhYmVsIGRp c3RyaWJ1dGlvbiBwZWVyIGNhc2UiLg0KDQpZb3Ugc2VlbSB0byBiZSBwb3NpdGluZyBhIGNhc2Ug d2hlcmUgdHdvIG5vZGVzIGFyZSBpbiB0aGUgc2FtZSBJR1ANCmRvbWFpbiwgYW5kIHNhbWUgU1BS SU5HIGRvbWFpbiwgYnV0IHRoZXJlIGlzIG5vIExTUCB0aGF0IGNhbiBiZSB1c2VkIHRvDQp0cmFu c3BvcnQgcGFja2V0cyBmcm9tIG9uZSB0byB0aGUgb3RoZXIuICAgSXQgd291bGQgYmUgc29tZXdo YXQgdW51c3VhbA0KdG8gaGF2ZSBhbiBJR1AgZG9tYWluIGluIHdoaWNoIHNvbWUgbm9kZXMgc3Vw cG9ydCBNUExTIGFuZCBzb21lIGRvbid0Lg0KSW4gQklFUiwgd2UgZG8gYWNjb21tb2RhdGUgdGhp cyBzb3J0IG9mIHNpdHVhdGlvbiwgd2hlcmUgc29tZSBvZiB0aGUNCm5vZGVzIGluIHRoZSBCSUVS IGRvbWFpbiBkbyBub3Qgc3VwcG9ydCBCSUVSLiAgQnV0IEkgZG9uJ3Qga25vdyB3aGV0aGVyDQp0 aGF0IHNvcnQgb2Ygc2NlbmFyaW8gbmVlZHMgdG8gYmUgc3VwcG9ydGVkIGZvciBNUExTLVNSLiAg RG8geW91IGhhdmUgYQ0KcGFydGljdWxhciB1c2UgY2FzZSBpbiBtaW5kPw== From nobody Thu Apr 7 15:39:55 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEF712D169; Thu, 7 Apr 2016 15:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cm-rP-DqUkkv; Thu, 7 Apr 2016 15:39:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A80F12D118; Thu, 7 Apr 2016 15:39:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHA09445; Thu, 07 Apr 2016 22:39:46 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Apr 2016 23:39:46 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Fri, 8 Apr 2016 06:39:41 +0800 From: Xuxiaohu To: Eric C Rosen , "spring@ietf.org" Thread-Topic: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkBgULgoheUag70W81YSz/dG9Vp985QYAgAI0iT4= Date: Thu, 7 Apr 2016 22:39:41 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com>, <57057618.8020604@juniper.net> In-Reply-To: <57057618.8020604@juniper.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.197.222] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5706E1B3.002F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0e4d05dc9241ebb9e9634874a34d1850 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [spring] [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 07 Apr 2016 22:39:50 -0000 SGkgRXJpYywNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8 /sjLOiBFcmljIEMgUm9zZW4gW2Vyb3NlbkBqdW5pcGVyLm5ldF0NCreiy83KsbzkOiAyMDE2xOo0 1MI3yNUgNDo0OA0KytW8/sjLOiBYdXhpYW9odTsgc3ByaW5nQGlldGYub3JnDQqzrcvNOiBtcGxz QGlldGYub3JnDQrW98ziOiBSZTogW21wbHNdIENsYXJpZmljYXRpb24gb24gdGhlIG1vdGl2YXRp b24gb2YgZHJhZnQteHUtc3ByaW5nLWlzbGFuZHMtY29ubmVjdGlvbi1vdmVyLWlwLTA1DQoNCk9u IDQvNi8yMDE2IDExOjM3IEFNLCBYdXhpYW9odSB3cm90ZToNCj4gVGhlIHNpdHVhdGlvbiBpbiBN UExTLVNSIGlzIGEgbGl0dGxlIGJpdCBjb21wbGV4IHNpbmNlIHRoZSBvdXRnb2luZyBsYWJlbCBm b3IgYSBnaXZlbiAvMzIgb3IgLzEyOCBwcmVmaXggRkVDIGNvdWxkIGJlIGxlYXJudCBlaXRoZXIg ZnJvbSB0aGUgSUdQIG5leHQtaG9wIG9mIHRoYXQgRkVDIG9yIHRoZSBvcmlnaW5hdG9yIG9mIHRo YXQgRkVDIGR1ZSB0byB0aGUgSUdQIGZsb29kaW5nIHByb3BlcnR5LiBJbiB0aGUgZm9ybWVyIGNh c2UsIHRoZSBJR1AgbmV4dC1ob3AgZm9yIGEgZ2l2ZW4gRkVDIGlzIHRha2VuIGFzIHRoZSBuZXh0 LWhvcCBvZiB0aGUgcmVjZWl2ZWQgTVBMUyBwYWNrZXQgYmVsb25naW5nIHRvIHRoYXQgRkVDOyBp biB0aGUgbGF0dGVyIGNhc2UsIHRoZSBvcmlnaW5hdG9yIG9mIHRoYXQgRkVDIGlzIHRha2VuIGFz IHRoZSBuZXh0LWhvcCBvZiB0aGUgTVBMUyBwYWNrZXQgYmVsb25naW5nIHRvIHRoYXQgRkVDIC4u LiB0aGUgbGF0dGVyIGNhc2UgYmVsb25ncyB0byB0aGUgInJlbW90ZSBsYWJlbCBkaXN0cmlidXRp b24gcGVlciIgY2FzZSBhcyBkZWZpbmVkIGluIFJGQzMwMzENCg0KSSBkb24ndCBiZWxpZXZlIHRo aXMgaXMgY29ycmVjdC4gIEluIFNSLCB0aGUgZmFjdCB0aGF0IGxhYmVsIEwgd2FzDQphZHZlcnRp c2VkIGJ5IG5vZGUgTiBkb2VzIG5vdCBpbXBseSB0aGF0IGEgcGFja2V0IHdpdGggTCBhdCB0aGUg dG9wIG9mDQp0aGUgc3RhY2sgbmVlZHMgdG8gYmUgdHVubmVsZWQgdG8gTi4gIEluIHRoZSB0eXBp Y2FsIGNhc2UsIHRoZSBwYWNrZXQNCg0KW1hpYW9odV0gVGhlIEZFQyBhc3NvY2lhdGVkIHRoZSBh Ym92ZSBsYWJlbCBMIGlzIHRoZSAvMzIgb3IgMTI4LyBwcmVmaXggb2Ygbm9kZSBOLiBXaGVuIHRo ZSBJR1AgbmV4dC1ob3AgdG93YXJkcyB0aGF0IEZFQyBpcyBhIG5vbi1NUExTIG5vZGUsIHRoZSBM U1IgcmVjZWl2aW5nIHRoZSBhYm92ZSBNUExTIHBhY2tldCB3aXRoIHRvcCBsYWJlbCBvZiBMIGlz IGRlc2lyZWQgdG8gZm9yd2FyZCB0aGF0IE1QTFMgcGFja2V0IHRvd2FyZHMgbm9kZSBOIHZpYSBh biBJUC1iYXNlZCB0dW5uZWwuIEluIHRoaXMgY2FzZSwgdGhlIG5vZGUgTiBpcyB0aGUgcmVtb3Rl IHBlZXIgZm9yIHRoYXQgRkVDLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KDQp3b3VsZCBq dXN0IGZvbGxvdyB0aGUgSUdQIGJlc3QgcGF0aCwgYW5kIGFsbCB0aGUgaW50ZXJtZWRpYXRlIG5v ZGVzDQp3b3VsZCBiZSBleHBlY3RlZCB0byByZWNvZ25pemUgdGhlIGxhYmVsIGF0IHRoZSB0b3Ag b2YgdGhlIHN0YWNrLiAgSWYNCnRoZSBpbnRlcm1lZGlhdGUgbm9kZXMgYXJlIGV4cGVjdGVkIHRv IHJlY29nbml6ZSB0aGUgbGFiZWwsICB0aGlzIGlzIG5vdA0KdGhlICJyZW1vdGUgbGFiZWwgZGlz dHJpYnV0aW9uIHBlZXIgY2FzZSIuDQoNCllvdSBzZWVtIHRvIGJlIHBvc2l0aW5nIGEgY2FzZSB3 aGVyZSB0d28gbm9kZXMgYXJlIGluIHRoZSBzYW1lIElHUA0KZG9tYWluLCBhbmQgc2FtZSBTUFJJ TkcgZG9tYWluLCBidXQgdGhlcmUgaXMgbm8gTFNQIHRoYXQgY2FuIGJlIHVzZWQgdG8NCnRyYW5z cG9ydCBwYWNrZXRzIGZyb20gb25lIHRvIHRoZSBvdGhlci4gICBJdCB3b3VsZCBiZSBzb21ld2hh dCB1bnVzdWFsDQp0byBoYXZlIGFuIElHUCBkb21haW4gaW4gd2hpY2ggc29tZSBub2RlcyBzdXBw b3J0IE1QTFMgYW5kIHNvbWUgZG9uJ3QuDQpJbiBCSUVSLCB3ZSBkbyBhY2NvbW1vZGF0ZSB0aGlz IHNvcnQgb2Ygc2l0dWF0aW9uLCB3aGVyZSBzb21lIG9mIHRoZQ0Kbm9kZXMgaW4gdGhlIEJJRVIg ZG9tYWluIGRvIG5vdCBzdXBwb3J0IEJJRVIuICBCdXQgSSBkb24ndCBrbm93IHdoZXRoZXINCnRo YXQgc29ydCBvZiBzY2VuYXJpbyBuZWVkcyB0byBiZSBzdXBwb3J0ZWQgZm9yIE1QTFMtU1IuICBE byB5b3UgaGF2ZSBhDQpwYXJ0aWN1bGFyIHVzZSBjYXNlIGluIG1pbmQ/ From nobody Thu Apr 7 18:28:07 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C1512D1CF; Thu, 7 Apr 2016 18:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rh_BvNwswAxz; Thu, 7 Apr 2016 18:28:03 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A7812D126; Thu, 7 Apr 2016 18:28:02 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-92-570702dbe1cd Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id E8.5A.30335.BD207075; Fri, 8 Apr 2016 03:01:15 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0248.002; Thu, 7 Apr 2016 21:28:01 -0400 From: Uma Chunduri To: Xuxiaohu , Eric C Rosen , "spring@ietf.org" Thread-Topic: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkR6Kh266HVaFkUy+fRZ9moMOGJ9/Rn2w Date: Fri, 8 Apr 2016 01:28:00 +0000 Message-ID: <1B502206DFA0C544B7A6046915200863580003D6@eusaamb106.ericsson.se> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com>, <57057618.8020604@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZXLonRPc2E3u4wcazBhbrNnxgtri1dCWr xfELvxkttp5fxejA4tFy5C2rx5IlP5k8rjddZQ9gjuKySUnNySxLLdK3S+DK6H90iLXglHLF nT8bGRsYryh1MXJySAiYSCy93skKYYtJXLi3nq2LkYtDSOAoo8SdjxOZIJxljBLvZs9lBKli E9CT+Dj1JzuILSKQIzHx0TKgDg4OZgFliVN3ZUDCwgJpEnNmHGOBKEmXuH3/I1iJiICRxJ+N +SBhFgEViRnz74NN5BXwlbi0fT7U3iOMEl9/tYAlOAXCJHpfnmUGsRmBjvt+ag0TiM0sIC5x 68l8JoijBSSW7DnPDGGLSrx8/A/qGSWJOa+vMUPUa0nMa/gN1asoMaX7ITvEYkGJkzOfsExg FJuFZOwsJC2zkLTMQtKygJFlFSNHaXFBTm66kcEmRmAMHZNg093BeH+65yFGAQ5GJR7eB22s 4UKsiWXFlbmHGCU4mJVEeN+ysIcL8aYkVlalFuXHF5XmpBYfYpTmYFES520M/hcmJJCeWJKa nZpakFoEk2Xi4JRqYLSWy+RarBZ/4/jEVfe5Sj/unp0owrZLJZ0zT3Xu5bBfpd3y++o9l3/w PSYc6Rl82lg73GmDzeU5XqKO73j89cVXsbyabuhyxUnMa+mniwem1JgG3v6m/eijjXKEd8w1 mVJHxtc/l2VsTChg3y6+p0T4s8PBoPVGmnXOQbIPd2+YUP67K3qDpBJLcUaioRZzUXEiAMGm Jc2dAgAA Archived-At: Cc: "mpls@ietf.org" Subject: Re: [spring] [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 08 Apr 2016 01:28:05 -0000 PiBJdCB3b3VsZCBiZSBzb21ld2hhdCB1bnVzdWFsDQo+IHRvIGhhdmUgYW4gSUdQIGRvbWFpbiBp biB3aGljaCBzb21lIG5vZGVzIHN1cHBvcnQgTVBMUyBhbmQgc29tZSBkb24ndC4NCg0KTWF5IGJl IHRydWUgd2l0aCBub24tU1IgYW5kIHRyYWRpdGlvbmFsICBNUExTLiANCkJ1dCB3aXRoIFNSIEkg YW0gd29ya2luZyB3aXRoIG9uZSBjdXN0b21lciB3aGVyZSBNUExTIChhcyBTUiBkYXRhIHBsYW5l KSBpcyBicm91Z2h0IGludG8gdGhlaXIgcHVyZSBJR1AtSVAgZG9tYWluLg0KV2l0aCBzdGF0aWMg UFcgbGFiZWxzIChpbm5lciBsYWJlbCkgIGN1cnJlbnRseSBwdXJlIHNvZnQgR1JFIGVuY2FwIGlz IGJlaW5nIHVzZWQgKGZvciB0cmFuc3BvcnQpICBidXQgU1IgaXMgYmVpbmcgcGxhbm5lZCBmcm9t IEVQRyB0byBjZWxsIHNpdGUgcm91dGVycyBldmVudHVhbGx5LiANClBsYW5uaW5nIHNsb3cgdXBn cmFkZSBmb3Igc29tZSBvZiB0aGUgTUJIIG5vZGVzIHdpdGggU1ItTVBMUyBkYXRhIHBsYW5lLiAg SW4gdGhpcyBjYXNlIGl0cyBxdWl0ZSBwb3NzaWJsZSB0byB1c2UgKGluIGZ1dHVyZSkgbm9uLXNo b3J0ZXN0IHBhdGggU1IgbGFiZWwgc3RhY2suDQpUaHghDQotLQ0KVW1hIEMuDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBtcGxzIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgWHV4aWFvaHUNClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwNywgMjAx NiAzOjQwIFBNDQpUbzogRXJpYyBDIFJvc2VuOyBzcHJpbmdAaWV0Zi5vcmcNCkNjOiBtcGxzQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW21wbHNdIENsYXJpZmljYXRpb24gb24gdGhlIG1vdGl2YXRp b24gb2YgZHJhZnQteHUtc3ByaW5nLWlzbGFuZHMtY29ubmVjdGlvbi1vdmVyLWlwLTA1DQoNCkhp IEVyaWMsDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7I yzogRXJpYyBDIFJvc2VuIFtlcm9zZW5AanVuaXBlci5uZXRdDQq3osvNyrG85DogMjAxNsTqNNTC N8jVIDQ6NDgNCsrVvP7IyzogWHV4aWFvaHU7IHNwcmluZ0BpZXRmLm9yZw0Ks63LzTogbXBsc0Bp ZXRmLm9yZw0K1vfM4jogUmU6IFttcGxzXSBDbGFyaWZpY2F0aW9uIG9uIHRoZSBtb3RpdmF0aW9u IG9mIGRyYWZ0LXh1LXNwcmluZy1pc2xhbmRzLWNvbm5lY3Rpb24tb3Zlci1pcC0wNQ0KDQpPbiA0 LzYvMjAxNiAxMTozNyBBTSwgWHV4aWFvaHUgd3JvdGU6DQo+IFRoZSBzaXR1YXRpb24gaW4gTVBM Uy1TUiBpcyBhIGxpdHRsZSBiaXQgY29tcGxleCBzaW5jZSB0aGUgb3V0Z29pbmcgDQo+IGxhYmVs IGZvciBhIGdpdmVuIC8zMiBvciAvMTI4IHByZWZpeCBGRUMgY291bGQgYmUgbGVhcm50IGVpdGhl ciBmcm9tIA0KPiB0aGUgSUdQIG5leHQtaG9wIG9mIHRoYXQgRkVDIG9yIHRoZSBvcmlnaW5hdG9y IG9mIHRoYXQgRkVDIGR1ZSB0byB0aGUgDQo+IElHUCBmbG9vZGluZyBwcm9wZXJ0eS4gSW4gdGhl IGZvcm1lciBjYXNlLCB0aGUgSUdQIG5leHQtaG9wIGZvciBhIA0KPiBnaXZlbiBGRUMgaXMgdGFr ZW4gYXMgdGhlIG5leHQtaG9wIG9mIHRoZSByZWNlaXZlZCBNUExTIHBhY2tldCANCj4gYmVsb25n aW5nIHRvIHRoYXQgRkVDOyBpbiB0aGUgbGF0dGVyIGNhc2UsIHRoZSBvcmlnaW5hdG9yIG9mIHRo YXQgRkVDIA0KPiBpcyB0YWtlbiBhcyB0aGUgbmV4dC1ob3Agb2YgdGhlIE1QTFMgcGFja2V0IGJl bG9uZ2luZyB0byB0aGF0IEZFQyAuLi4gDQo+IHRoZSBsYXR0ZXIgY2FzZSBiZWxvbmdzIHRvIHRo ZSAicmVtb3RlIGxhYmVsIGRpc3RyaWJ1dGlvbiBwZWVyIiBjYXNlIA0KPiBhcyBkZWZpbmVkIGlu IFJGQzMwMzENCg0KSSBkb24ndCBiZWxpZXZlIHRoaXMgaXMgY29ycmVjdC4gIEluIFNSLCB0aGUg ZmFjdCB0aGF0IGxhYmVsIEwgd2FzIGFkdmVydGlzZWQgYnkgbm9kZSBOIGRvZXMgbm90IGltcGx5 IHRoYXQgYSBwYWNrZXQgd2l0aCBMIGF0IHRoZSB0b3Agb2YgdGhlIHN0YWNrIG5lZWRzIHRvIGJl IHR1bm5lbGVkIHRvIE4uICBJbiB0aGUgdHlwaWNhbCBjYXNlLCB0aGUgcGFja2V0DQoNCltYaWFv aHVdIFRoZSBGRUMgYXNzb2NpYXRlZCB0aGUgYWJvdmUgbGFiZWwgTCBpcyB0aGUgLzMyIG9yIDEy OC8gcHJlZml4IG9mIG5vZGUgTi4gV2hlbiB0aGUgSUdQIG5leHQtaG9wIHRvd2FyZHMgdGhhdCBG RUMgaXMgYSBub24tTVBMUyBub2RlLCB0aGUgTFNSIHJlY2VpdmluZyB0aGUgYWJvdmUgTVBMUyBw YWNrZXQgd2l0aCB0b3AgbGFiZWwgb2YgTCBpcyBkZXNpcmVkIHRvIGZvcndhcmQgdGhhdCBNUExT IHBhY2tldCB0b3dhcmRzIG5vZGUgTiB2aWEgYW4gSVAtYmFzZWQgdHVubmVsLiBJbiB0aGlzIGNh c2UsIHRoZSBub2RlIE4gaXMgdGhlIHJlbW90ZSBwZWVyIGZvciB0aGF0IEZFQy4NCg0KQmVzdCBy ZWdhcmRzLA0KWGlhb2h1DQoNCg0Kd291bGQganVzdCBmb2xsb3cgdGhlIElHUCBiZXN0IHBhdGgs IGFuZCBhbGwgdGhlIGludGVybWVkaWF0ZSBub2RlcyB3b3VsZCBiZSBleHBlY3RlZCB0byByZWNv Z25pemUgdGhlIGxhYmVsIGF0IHRoZSB0b3Agb2YgdGhlIHN0YWNrLiAgSWYgdGhlIGludGVybWVk aWF0ZSBub2RlcyBhcmUgZXhwZWN0ZWQgdG8gcmVjb2duaXplIHRoZSBsYWJlbCwgIHRoaXMgaXMg bm90IHRoZSAicmVtb3RlIGxhYmVsIGRpc3RyaWJ1dGlvbiBwZWVyIGNhc2UiLg0KDQpZb3Ugc2Vl bSB0byBiZSBwb3NpdGluZyBhIGNhc2Ugd2hlcmUgdHdvIG5vZGVzIGFyZSBpbiB0aGUgc2FtZSBJ R1AgZG9tYWluLCBhbmQgc2FtZSBTUFJJTkcgZG9tYWluLCBidXQgdGhlcmUgaXMgbm8gTFNQIHRo YXQgY2FuIGJlIHVzZWQgdG8NCnRyYW5zcG9ydCBwYWNrZXRzIGZyb20gb25lIHRvIHRoZSBvdGhl ci4gICBJdCB3b3VsZCBiZSBzb21ld2hhdCB1bnVzdWFsDQp0byBoYXZlIGFuIElHUCBkb21haW4g aW4gd2hpY2ggc29tZSBub2RlcyBzdXBwb3J0IE1QTFMgYW5kIHNvbWUgZG9uJ3QuDQpJbiBCSUVS LCB3ZSBkbyBhY2NvbW1vZGF0ZSB0aGlzIHNvcnQgb2Ygc2l0dWF0aW9uLCB3aGVyZSBzb21lIG9m IHRoZSBub2RlcyBpbiB0aGUgQklFUiBkb21haW4gZG8gbm90IHN1cHBvcnQgQklFUi4gIEJ1dCBJ IGRvbid0IGtub3cgd2hldGhlciB0aGF0IHNvcnQgb2Ygc2NlbmFyaW8gbmVlZHMgdG8gYmUgc3Vw cG9ydGVkIGZvciBNUExTLVNSLiAgRG8geW91IGhhdmUgYSBwYXJ0aWN1bGFyIHVzZSBjYXNlIGlu IG1pbmQ/DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscw0K From nobody Fri Apr 8 05:44:46 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F48212D7E7 for ; Fri, 8 Apr 2016 05:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRpEs_o13xFZ for ; Fri, 8 Apr 2016 05:44:44 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::759]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842CB12D711 for ; Fri, 8 Apr 2016 05:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=k13iryjVZ96HnBQZ8GY+Ley3qrTrN0DuagkhW3MfYt4=; b=LLXbGh03WUHK2l2L55SNAVNiSIQO4C8QKAT0PfBo/6LyBUSQlKtZRQcEyQJajhZHz8nTZiiC0z2u0q5sp15ahTEx7CuNOg7AgELChTzm+fHIiuP3aaEBYPUO0pnzWpee1Mg4vlL7L9OWQ2538p34s03Y0TMhD0bHV6cNXzov0ZY= Received: from BY2PR05MB614.namprd05.prod.outlook.com (10.141.218.148) by BY2PR05MB613.namprd05.prod.outlook.com (10.141.218.145) with Microsoft SMTP Server (TLS) id 15.1.447.15; Fri, 8 Apr 2016 12:44:27 +0000 Received: from BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) by BY2PR05MB614.namprd05.prod.outlook.com ([10.141.218.148]) with mapi id 15.01.0447.029; Fri, 8 Apr 2016 12:44:26 +0000 From: Chris Bowers To: "spring@ietf.org" Thread-Topic: comment on draft-ginsberg-spring-conflict-resolution-00.txt Thread-Index: AdGRei3SbivypuFnTQaH2BFo593PjQ== Date: Fri, 8 Apr 2016 12:44:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.239.14] x-ms-office365-filtering-correlation-id: d9ddbef4-cb22-480b-2859-08d35fab8525 x-microsoft-exchange-diagnostics: 1; BY2PR05MB613; 5:n2ViWlCAhM+MYW3mzT3Ivgci0gh7+p+Oe8frKvtIDWS/Sbk4qLnuZFlxE5DrV1BYJfr1949KfPrv8af687jdlJCaq7aMfEYFo3sr9zfcAp73g3tKrhOvwqnZL66370cbDXHG1MROodeW9KFi3kFEtA==; 24:BTbfmxO2++rlx1vWqN0mOzcxM6uWV2CTvn32pA2zIcwycCxhQULMV1+dChD0+vCOOF8cUolIS9BNDwVA+moV3cmD0buyGr6hwhQh1gvg9EM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB613; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BY2PR05MB613; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB613; x-forefront-prvs: 0906E83A25 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189998001)(3280700002)(107886002)(110136002)(3660700001)(5004730100002)(2906002)(1730700002)(66066001)(2501003)(81166005)(19580395003)(74316001)(99286002)(5003600100002)(15975445007)(122556002)(230783001)(5640700001)(5002640100001)(92566002)(76576001)(1096002)(1220700001)(77096005)(3846002)(86362001)(102836003)(586003)(6116002)(450100001)(9686002)(164054004)(5008740100001)(229853001)(2351001)(2900100001)(87936001)(50986999)(10400500002)(54356999)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB613; H:BY2PR05MB614.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR05MB6142EDCED9EF0A5186A66A3A9910BY2PR05MB614namprd_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2016 12:44:26.4879 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB613 Archived-At: Subject: [spring] comment on draft-ginsberg-spring-conflict-resolution-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 08 Apr 2016 12:44:45 -0000 --_000_BY2PR05MB6142EDCED9EF0A5186A66A3A9910BY2PR05MB614namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors and WG, It seems to me that this document should explicitly state how to handle pre= fixes and SIDs advertised with different values of the SR-algorithm field. = Here SR-algorithm refers to SPF or Strict SPF, and not the Preference Algo= rithm defined in this draft. Presumably receiving two identical prefixes with different algorithm fields= and different SIDs does not constitute a prefix conflict. It would be go= od to make the expected behavior explicit in the text. Thanks, Chris --_000_BY2PR05MB6142EDCED9EF0A5186A66A3A9910BY2PR05MB614namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Authors and WG,
 
It seems to me that this document should explicitly state how to handl= e prefixes and SIDs advertised with different values of the SR-algorithm fi= eld.  Here SR-algorithm refers to SPF or Strict SPF, and not the Prefe= rence Algorithm defined in this draft.
 
Presumably receiving two identical prefixes with different algorithm f= ields and different SIDs  does not constitute a prefix conflict. = It would be good to make the expected behavior explicit in the text.
 
Thanks,
Chris
 
 --_000_BY2PR05MB6142EDCED9EF0A5186A66A3A9910BY2PR05MB614namprd_-- From nobody Fri Apr 8 06:12:45 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C8F12D897 for ; Fri, 8 Apr 2016 06:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8qbP4Ex8eOe for ; Fri, 8 Apr 2016 06:12:42 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5228C12D694 for ; Fri, 8 Apr 2016 06:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7103; q=dns/txt; s=iport; t=1460121161; x=1461330761; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=yB1QdnVi2Zq5yJzk/Hrzr/VlZyJ1QyKip6vwCQjs5/I=; b=QaV29jUIo7q64YGsHk6x//rDYi3v9uqdEWZIr8UvittHMcCj4XeG2nJk 04f3+YMTntrMF8LpaVj/Rm0brfyflysnOiw1lI4XsRDxOjnfoj6vuriru jKpJbN+z/vnzXmc2yMX+F/97YOFd+w5PgdpeGSj6Jv7RJEriWqn/kgMjJ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAgBCrQdX/4wNJK1cgmtMU30GtUyEc?= =?us-ascii?q?wENgXOGDQKBNDgUAQEBAQEBAWUnhEEBAQEELVwCAQgOAwQBASgHMhQJCAEBBAE?= =?us-ascii?q?SCIgfwEQBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGES4R1hSAFkxmEawGOBI8Uj?= =?us-ascii?q?yQBHgEBQoNnbIg7fgEBAQ?= X-IronPort-AV: E=Sophos; i="5.24,449,1454976000"; d="scan'208,217"; a="89659603" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2016 13:12:40 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u38DCeiY009058 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 13:12:40 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 08:12:39 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 08:12:39 -0500 From: "Les Ginsberg (ginsberg)" To: Chris Bowers , "spring@ietf.org" Thread-Topic: comment on draft-ginsberg-spring-conflict-resolution-00.txt Thread-Index: AdGRei3SbivypuFnTQaH2BFo593PjQAHg3EQ Date: Fri, 8 Apr 2016 13:12:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.126.203] Content-Type: multipart/alternative; boundary="_000_bd75e6f7e1a5445a85409e0e447e1d81XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] comment on draft-ginsberg-spring-conflict-resolution-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 08 Apr 2016 13:12:44 -0000 --_000_bd75e6f7e1a5445a85409e0e447e1d81XCHALN001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chris - Agreed. I will include that in the upcoming revision. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Chris Bowers Sent: Friday, April 08, 2016 5:44 AM To: spring@ietf.org Subject: [spring] comment on draft-ginsberg-spring-conflict-resolution-00.t= xt Authors and WG, It seems to me that this document should explicitly state how to handle pre= fixes and SIDs advertised with different values of the SR-algorithm field. = Here SR-algorithm refers to SPF or Strict SPF, and not the Preference Algo= rithm defined in this draft. Presumably receiving two identical prefixes with different algorithm fields= and different SIDs does not constitute a prefix conflict. It would be go= od to make the expected behavior explicit in the text. Thanks, Chris --_000_bd75e6f7e1a5445a85409e0e447e1d81XCHALN001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Chris –<= /span>

 <= /p>

Agreed.=

I will include that in th= e upcoming revision.

 <= /p>

    Les

 <= /p>

 <= /p>

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Chris Bowers
Sent: Friday, April 08, 2016 5:44 AM
To: spring@ietf.org
Subject: [spring] comment on draft-ginsberg-spring-conflict-resoluti= on-00.txt

 

Authors and WG,

 

It seems to me that this document shoul= d explicitly state how to handle prefixes and SIDs advertised with differen= t values of the SR-algorithm field.  Here SR-algorithm refers to SPF or Strict SPF, and not the Preference Algorithm defined in this dra= ft.

 

Presumably receiving two identical pref= ixes with different algorithm fields and different SIDs  does not cons= titute a prefix conflict.  It would be good to make the expected behavior explicit in the text.

 

Thanks,

Chris

 

--_000_bd75e6f7e1a5445a85409e0e447e1d81XCHALN001ciscocom_-- From nobody Mon Apr 11 11:51:13 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB19812D815; Mon, 11 Apr 2016 11:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpVjUjDujyew; Mon, 11 Apr 2016 11:51:08 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0718.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:718]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7B212E2C4; Mon, 11 Apr 2016 11:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=k3L2eQ2m1uyFhRipxdnTyo4g4CCDnO99oA8YuEU23JM=; b=Waja2R5ihUUFBpYVXHkhL8h1Z5chR61vsZx0LDizUrVELLvHgBRr5EQRPNkU9ovcxar7bO9K10MOa7lBfZlnjptpvClu7vylqMtKhcsr7MthWw36e37kYVhL8pBsHJZpcSRjrCTXvJ9neXnsz89U5gt1lLmkmaLjWVg0XxupAlM= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.33.153] (66.129.241.12) by BLUPR05MB787.namprd05.prod.outlook.com (10.141.209.146) with Microsoft SMTP Server (TLS) id 15.1.453.26; Mon, 11 Apr 2016 18:50:47 +0000 To: Xuxiaohu , "spring@ietf.org" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> <57057618.8020604@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> From: Eric C Rosen Message-ID: <570BF204.6050301@juniper.net> Date: Mon, 11 Apr 2016 14:50:44 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: CY1PR12CA0010.namprd12.prod.outlook.com (10.160.137.20) To BLUPR05MB787.namprd05.prod.outlook.com (10.141.209.146) X-MS-Office365-Filtering-Correlation-Id: 4e4b20d1-a84f-48b1-d612-08d3623a3299 X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB787; 2:dPwsddEmD2C6CghbHbM/dX1qTrrNNMyj17j1827NZh/L26kh++cA78WoFxhkoZW7gLnKMz/tSDLc9aCzUQfp8xbM6F4dX++2Pr+Gt0d6QD4lPUXXYqW9AHbIq1HGN7DNXq6I8qGe6MDhfUPpYo94WFY+tkKTvIQ3WaWu/P2f1m8vaH7JvNnHADvpYH9xpOSj; 3:iGCOnw4M1cp7epouTPuBRDRXPc9jE6Gub4oF8ue0b05xZb9z/XSCrjw+DiSa5nt+LKxarEtlffbSCB50ca2kY+//mFfJaiksuhwaNY3sCU1GZwsLLtiFExnb2rNNflaY; 25:vAaho+YcdvhQd8zjWYlK1Q22URniYA06yoB3DW/uHEpYAp7wEEv0UhrAl0XuHOf6eXQqU++VqmarenUsulLlnsO/dr2BAg78FWOY0Efx/Hxti/pgdnIeYEOTlZUd27+JY0OWPp6+1D95B8hwovpppSovIPYwe7Zg5KNeAVProv4dLrmcApK/K1qi5lUhzIWuDRcPtRlOv3FaF3urvRqJam1qBn0ewCzPWhPyhb3pInJfjM6XwUzBu8iOD00gdXu9g6ZYWPTtjveL+HlSIFlYtaWXOQ4G1wpaQ/5OrswyDnzZQguzamSh6Hthcfr90XtIgrLitVYP3fQXMo472aCwWw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB787; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB787; 20:4mX4XK6uggJ7g/01ccvc1EokAGKakGbLAFAclGxqcjI9Rd8rWmbK6FCMsnGk83jneX+AxVc8DghKtyslxq5ml628+ctky01oENy+HX6BE4lD1pf/ZfBthMp9UvWSd2TdMxzFbOFWZbsbFhDtu80GwnVDekcrkXEZU2+x1XoyCkS1mdWTt2UlHlNQ71S/7/IbPe2z8MbcdcynCVdgGquNQU35wliI+TctUIwnu9kYvmazQ2mx/WTEPlA1AqFrxEgXC1+cW9P5Xpqa+CChdiypa3cm56p/yqrT/CcgRvTaafU84QePAMA3UAWjzlmbU3xLaVxOyH3UxTum4m3UcT6j1Wc5DmkGNX6EtAWYmX7HYLOmVoZGGSdxER0IMQxyVUN2xUTLhwTK98vQPS88g3dECvVFn28YKnMXYjRzv6fdqr0TqSj8yryVA2V/LIkhksfnRvquOlfyREPYLZAxys3sKT5e9SvWQ7RYqHhBDKVQFLD2s+sL5Ki2J2R+P5RwBjSE; 4:1jbGutPmT+jj4J7hzGD87OV7TYkefWhTD7vEjrifIRhLbVUEsfSlXMVsLpxarcma+lqnQjaFghOeCUOYHFapGURu9bjsXG2ptNeomLynP5VU0BO9ozbG3kzCPSrQgw7UoGDNdpP9f0+8bIWZbi897DZ+5O4nNPQaUjTtuKrntdTse0C5lpfvVnZS234q/6L8BAV0HOta60HSv3ruY0Iitdw0ymKEe6O8X6xD8ceoR7CnzMUp2EJegnNLQfwltfJ8+ziotc/+9HF4R/2vsSkAWUwJJehtjqp0kfBTonBmpV4RMRfPkZ0Ji8yhi3jeBvQTyhBaBuaIfv3+KM6JXuWaTZpQVqZxNs/9D86Vr4coqCdc8RUvkxzlBK17BrQRRpry75h9GD7R0NZkUxqtJBdE+g== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BLUPR05MB787; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB787; X-Forefront-PRVS: 09090B6B69 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(24454002)(377454003)(586003)(1096002)(81166005)(80316001)(36756003)(2501003)(230783001)(33656002)(4001350100001)(6116002)(59896002)(2906002)(5001770100001)(83506001)(42186005)(230700001)(47776003)(3846002)(65816999)(50986999)(86362001)(87266999)(54356999)(76176999)(5004730100002)(23676002)(2950100001)(50466002)(92566002)(4326007)(77096005)(189998001)(66066001)(5008740100001)(65956001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB787; H:[172.29.33.153]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTFVQUjA1TUI3ODc7MjM6YVNnTnEzU203ZXNVZVV1NWE4NWxXWDVlSyto?= =?utf-8?B?WWxMTW92aDdFS1NxaTl3TlBwL0JXeHhSTVgwYm4zT3FxNHlVdmdPRi93Qm9k?= =?utf-8?B?clZ3bklsTHR3MEFXd3ZvU2xSR3NDMmtpUEZjM05jRER1elBnVUJicFFzS1JI?= =?utf-8?B?cjF5d0VVVkFGUjN2QTlWVkcvUk9NV2pCa0J5Q1htaEVuRkVNWWNCMkJZS0Uw?= =?utf-8?B?RTZROFY2azhCVFNYek9sTmxPeHRpb1VGNmNrVWRpRjc1STdaKzV1Y2ttZEJv?= =?utf-8?B?VFhPTVNqakpmSFByRmdiRWJkWFJoTzNzNDdZOHFmaVhHQ2NCZGhLNzBsdVpo?= =?utf-8?B?QU9MekFyeDZYWWJqd1pvK3hNUXozMmt3RElabWpjNFpGaWV3OUhIaVNKQUpH?= =?utf-8?B?Tlhkd0ZMcm5YdjR4ZUh0d1pjaitHV1BaQUN6eWV5cm5zNHRtSlVuNDkvUkdn?= =?utf-8?B?d0pTOEFvTjRGeERqMENoT2E5OEtoeVZDY1ArTFdKVExuUW5MNmVMR3NwYUh3?= =?utf-8?B?bXNHRnArWGZIUGhHYTZzU09IbzFYbjdYdkZtbUlOZ3YxM29HNjFFSFloRTM3?= =?utf-8?B?bFR1Ny9pMlROcXhTZ0x1UHBrM1h6QlhJYks4WXlVZ2ZHZWlMZ1dxNU9RWXFa?= =?utf-8?B?Q2dBaHM0YmVCbFNaRlFaSXlZTzZYWmRwRUhTcVVDYlpOQXBRdlJvcGZKOER6?= =?utf-8?B?WHc4S2tlaStRcUZDTU5Gd2wyZ0ROeU1rbGFPeE1wdDFYMlJQUURaWE1FTXZF?= =?utf-8?B?VVc4TnVXTDJXc3MxTXp6U05Uc2ZxU0gvRHhyQXB0Ukk2QWY4aERBdXJodmJW?= =?utf-8?B?c3dibE5BWUdKMVhqS1Y4Zi9TTGdaNEtkYjJRSWt5MWtjUWU4UXFITGk5Z3B4?= =?utf-8?B?ZzdzTnY2ZVhIbTNSU3VwZmQ5ZldUUHVzYnBDNHVLY2FBWm9TMWJwWGdtVHVO?= =?utf-8?B?ckNJRFVxNFVhSmtnbUVqMlpHVDFwMGQ4MkFOK3F4SGhvRkhGdVQ3cWgyWWlm?= =?utf-8?B?NE9KQ1NuTGsrNWF5bFJWRUR1RVQ1dHhpS1BrRUdSVm5XWlJmOXJlaHVJeFd1?= =?utf-8?B?SC9ndExXYmlnYm1YVnpUNXhQNkNUQ01nYmd3Nk9uenVvNGlkL2FTbjJUVE5J?= =?utf-8?B?MXdVUm1vR1lSV2sycUdVU1pIUi8yRE5URmlob2Q1RTByRWFkZ205OTFKZlBo?= =?utf-8?B?UVlzZ0JPaTQzakVCVjFlNWIzbFliWVU5WjUxd1VkdTdCU1ZyYnBmTmRadzIr?= =?utf-8?B?eWtVRFIyVzZ4SU1aTWxydFN2ZXlLZHZzVWgvMVFBdWx3TWExOGVvNithNmZI?= =?utf-8?B?SVFJcHcydnhIaWVXRndFZXdJRmxzb0p5ZVVxcnI4SWxBZ3g4S01kUHVCWEtD?= =?utf-8?B?UXJsWXg0RTB6S3NqTGN1aEFsNmt5UGxqcUVjQ251Ymw3Z3FWT2tuemNFRXB4?= =?utf-8?Q?a7sJI=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB787; 5:WvHoAdOnx4YxKmsaRXTjpv6CmQqBhDdb/kaLyVj9tbk+NkRPWDTx5bEHAaeLR3mpgGFrbuPXx69shHtqwsOU/ZAOP+O/LhpCypG6wOvn+yt+yrIfKX1FDPgERt1gzPKxptke/saneGUvN/kxphoTIg==; 24:WHvSJg0KK5yRXcQmTUK+L0vW0u/kLtVtBmtdqpRWecVDKsjRHvqDe5AxmieM3zQTpUwj2XW7bb+yBSsviLzvFmsffMeMYZ2zFzig3eTkUAc= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Apr 2016 18:50:47.7345 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB787 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [spring] [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 11 Apr 2016 18:51:10 -0000 On 4/7/2016 6:39 PM, Xuxiaohu wrote: > [Xiaohu] The FEC associated the above label L is the /32 or 128/ prefix of node N. When the IGP next-hop towards that FEC is a non-MPLS node, the LSR receiving the above MPLS packet with top label of L is desired to forward that MPLS packet towards node N via an IP-based tunnel. In this case, the node N is the remote peer for that FEC. Yes, in this case, the tunnel's receive endpoint can be regarded as a remote label distribution peer of the tunnel's transmit endpoint. However, in the above case I don't think it is obvious that you want to IP-tunnel the packet to N. You might just want to tunnel it around the non-MPLS node. In that case, the tunnel's receive endpoint can still be regarded as a remote label distribution peer of the transmit endpoint, but the receive endpoint is not N. From nobody Mon Apr 11 11:58:44 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C146012F314; Mon, 11 Apr 2016 11:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6-XaXSVQXxJ; Mon, 11 Apr 2016 11:58:39 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0115.outbound.protection.outlook.com [65.55.169.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B86312F312; Mon, 11 Apr 2016 11:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jeqy2oOgQyL5AWuKIzRtTorYS+pEJkJOZR6/Vdzo45k=; b=Tkpf4V5UUk2RS9cCnqSn2o5CTQCt2hoAS4j7lF8+o398IyOrbNvzneo06GhrYzATzEJZNDLF5fjwy8cs91p8MW2MYr47wrWp2warU9xzBa+Jj/p8Wl9DeJS3nTeTszkF2NmjlXVCTobpx0/LjjUXllw9S/QswLcq7HqddFBZqFk= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.33.153] (66.129.241.12) by BY2PR05MB790.namprd05.prod.outlook.com (10.141.225.20) with Microsoft SMTP Server (TLS) id 15.1.453.26; Mon, 11 Apr 2016 18:58:36 +0000 To: Uma Chunduri , Xuxiaohu , "spring@ietf.org" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> <57057618.8020604@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> <1B502206DFA0C544B7A6046915200863580003D6@eusaamb106.ericsson.se> From: Eric C Rosen Message-ID: <570BF3D8.5080601@juniper.net> Date: Mon, 11 Apr 2016 14:58:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1B502206DFA0C544B7A6046915200863580003D6@eusaamb106.ericsson.se> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: CY1PR12CA0051.namprd12.prod.outlook.com (10.163.230.19) To BY2PR05MB790.namprd05.prod.outlook.com (10.141.225.20) X-MS-Office365-Filtering-Correlation-Id: 909d53a4-4826-4ade-ff33-08d3623b4a4d X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB790; 2:wy6vc9HMAZJOSK4VZauJS6MKXi/1f+i4yfEAr50DyNoEWRB9JjOLLvhZ0Ubbu9fXOnf5hhEr6RedC/HNldn39f8DvEy00IRgH95rA9Ar0B6pO+Qo+PYyr6uEKvY3DxT9cbNz+6ji1Xlz2eA/9ZA1+K6Pz3yJoBdwbZGDEcvN/HWgOt4OWpqCaB3LAK2HRyy0; 3:k1yL2tdSkjrjjoTyi6+W4fo+ta5CNRIAXKOpXsDPZQtZDTXnF0LPlUgqAQVYES5Xas1EBHfMwTu5JeyMcGOc7nZvYdb8R3CWd5Q23v+IfmvUJnDHSfMfiK4jCZBTBwxu; 25:EKPVsFnajiola3dxGClXfE3InMkvAFVs82eIJPZ27JExSAhNHy+dnepADchcrUT5fAi9SlpA5JF329NRvphNKVqLVtd7ABwjbBF3s2Psi12LurG2jQWVkGdjdF8UOm0J0a/6d0cnFMwlZrS0H8K5PmzEZ/Db/0ytd5nkDv5oVt/7WXrPu0hPovHOpoYbov4/DNRdXwZ97cFGT8zQNdoTBYd5vnRrtS+DGXMkEzZuPIFQ1nFWOXjxq44L3Q+rGPNrvnQhKqhUyg6wzeNaJj5xq9O+pdGZyCmDntUPShRDaBqiESVLJzacAo3ziAPBDfCsuIWMl/Qx6cgCO7lRpgjceg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB790; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB790; 20:cVpMZ9DCOdpFuX1KbeFrYDtBYYEtCHQnDZWvXzR3Y5crvKgtJ62hSl+HhqGSro/l7qzwEPqlc3NBGFKyFkmMIX7rQ+JOXmr8GMmcjOWPY19kdL3NAEzljJeSi+4v6oeafV7xcXo4ZGpHgmJsdg3f2VeOoopgBXSktZE+3D1viijctxpYy7cUZzPnbPsLDM3TBLi9hpxpvmPpRs20aamovpiyZiJGn24sR1Xl4lzv8gXg2CA0sShylv5KaxHHutJK7t4L4PKM+eE4iFRpo83k0P8Tvz8A4uibNaf0VOiCKc5F4f18mJVIZlWFwJbPs129j/UklZrXzTZXpLIpuKHDPsXqz7ghG+6+7lc02ziT1tzAy0tP05JfJWxTsrTOMJFQwpsTJF147Grsbi2U+1HBFiQ9Xda7J44XSdTMUjmc/M52rFr5DkcyOYQiUmBQQ57WaubpHeRrYLX6s3Br14/bNJyU3UIbDtzYkDYGKQfFGSg2bgnvAEmkNWS70rxRJl2t; 4:BCnWcV2BUB++gckJTMnXYV6YW+dqTAncaFJSctg+nwN5P5xg1WZJKMlZyrlTb/FeXeGbLPR6g5v08ASwxy8golOgfnMgqTwaNsqCAMcqTCG72kTYxKz18l/jc+U5udo9myua2Q0nvctjIhB5K24bmHivKkIJ/9iU8WmvO42nescHxS6+puP5MVIRL48ZXCtGhq8RDlDsx/d7gbMSQ3Jgz4Vq0628P0huAdh1r9gRJbZ0XBzi8hwi0GRkK7uiprJ18o6Qe26OMyqISl6LAnt/HCj90Z0cZ8QasuOyTD2OH0JuyH/Zs9ACBKWwuXc6R3osJtYweR6RXStTcX0PYqf+N1Zf3xEhrk7ikvXbUMI4JPJ3xaTSpC1vJQXr/fRwHcTjfSLEkUhW61lNPl9SXhXciA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BY2PR05MB790; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB790; X-Forefront-PRVS: 09090B6B69 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(87266999)(54356999)(50986999)(65816999)(50466002)(76176999)(92566002)(189998001)(230700001)(81166005)(4326007)(5004730100002)(2906002)(33656002)(42186005)(80316001)(5001770100001)(586003)(5008740100001)(36756003)(6116002)(3846002)(2501003)(1096002)(2950100001)(77096005)(66066001)(230783001)(59896002)(65956001)(93886004)(86362001)(23676002)(47776003)(83506001)(4001350100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB790; H:[172.29.33.153]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJQUjA1TUI3OTA7MjM6WjJzdzVDVWkrVnFrK1dHMTJ0OFAvaHRDVUxM?= =?utf-8?B?YTU0Y1RNVGRXYStKVTJFK0xjNEkvT0QyU1BveEY1ODFtMUVLVmNSdzloY1lu?= =?utf-8?B?S0RRR3VEeE4zZmJSQVJENldvN2lEMU1ETjJMV3FIMkUzNFNXYTJZYS9RaWlH?= =?utf-8?B?czFJUlZQa2h3UzJ5N0t2ZTVwUXJFMFBReTFWVHBvQmI0Qzg4WXZSR1JKMVpz?= =?utf-8?B?YmkvYmtrRUZ0bEdQVGdTNW1MSXJ4aTlPSXNtU1VlVXAyZ2NLK096b21GR1Vo?= =?utf-8?B?VTlrWUt2V3htVDVMd2dKMEIvSFVKRFJKdHpUenI4VGY4Z2J6c2lEUWVHWkdV?= =?utf-8?B?Witrc0JxeWdJaVFhb21ab0R1cTE3SC9JQ3I4TE5yRFN6cDVjczdOaFZsZ3NI?= =?utf-8?B?MzBxYnUxS0ZFeFppRHY0c3BLQlZiY29DV2NXbENKQzZuY2xrSkVMNDBrNGNj?= =?utf-8?B?cmFMZ2dEaGhPaWFONUJ4V081eVdacUZzbGdDdDlYaUd5RUt4amNpaFBXOEFX?= =?utf-8?B?UmFkYVZNcDRQYzBpN3BYdmd0L3UxREVmaG1YZCtKZUVnYlJoWk50cm4yTXl5?= =?utf-8?B?K25EckNrQ3lYSVozOGFLMHYyOXVNV2xwbVR5NXVMNTFrWGhSalQvVDY4YmJY?= =?utf-8?B?Tk5CeVFwYWRoR3RKWmpuNHlLUXZCZm5vS2Zlc01iOWR2MUh1a3VyU0ZjUkFN?= =?utf-8?B?b0NTclYrSU03cENZVjZxc2JtQ0p5Q0o5NzBKb0M0Tk5nZjhaWlVkaklOSE11?= =?utf-8?B?OW5BOGhhcWpUWC8xSlgxVUxFei9yWjNLYVNqNzdSUFFEdzZIZmtDaDQyM0ZO?= =?utf-8?B?eUVKTzQybkxBSzdnMy9iUnp4K1lSQXFLczQ0b01qUlZEQnRUT0EwSzljRUVq?= =?utf-8?B?WmRpZWVLeGRjR1AybDMwVVEweTdER0E5Q3hIaS96RThWdEtwdTJRSEhxM0lM?= =?utf-8?B?TXFQTnRNcjJzSUIxRXVtWkk2MDlCTkM4bG92ZUlxOG80UnJqc3k2emJMeDBk?= =?utf-8?B?U2kveTBLREZEbGNaRExEMzN5ZElTQjA3VmhSV3RoM1JKOW9ZVGh5RGEzSkFI?= =?utf-8?B?QVNDTWkvOHdtNzZWTElCc2VGQVlLakpRS0JaVjNVTTFjalFRZ0FObFJQakhL?= =?utf-8?B?TmlFYTlHZmtEcHB5aW5SVHZhMjJ6WnVHaGYzQXRvNWVQU21KMDF5S0RTR0tv?= =?utf-8?B?NDY2L1J0WUNzRFFwSDV3c0kxL0NkcUFRNlJoS3lxWDJIcHdvaHNnSUFBWUlY?= =?utf-8?B?Q3p0cVpzL2ZpdTNtT294QmFVNCsxRW5iNllOTG41RzFFUnE1UkNqSWxiUm8y?= =?utf-8?B?bzJpZ0ZIcHVFeHBwNSthdmxnMVg0SytXdXp5aGZTbnR3d290VkVkdG5BS2Fs?= =?utf-8?B?R3RtVStKTVRmTE1BNzMrb1VHWnFieGl2RjczU2c9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB790; 5:WDyvFCMz4e9xlSoYjT6VYe2Sdr7IXHRi/EZk6F1ig98jI2IdWn10iydBe0gPAObpb451XaHAhSmBMClUTXRDUijUNVgoyHfEh6QMiQwwgfrMDfg5VNo1yY6CK1M9QIxoEaREbYSUfL2zvj7wp3WI0Q==; 24:rTALhHbezrVE0WFZazsQGTvbjQwuLoKNXnbEcLWXlvAy4z6av7diSzzrgyn1W29mtuB9uNU2yRGOgngWHJn+yPja8wSUN3C+RaOcmjfwbUY= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Apr 2016 18:58:36.9683 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB790 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [spring] [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 11 Apr 2016 18:58:41 -0000 >> [Eric] It would be somewhat unusual to have an IGP domain in which some nodes support MPLS and some don't. > [Uma] May be true with non-SR and traditional MPLS. > But with SR I am working with one customer where MPLS (as SR data plane) is brought into their pure IGP-IP domain. > With static PW labels (inner label) currently pure soft GRE encap is being used (for transport) but SR is being planned from EPG to cell site routers eventually. > Planning slow upgrade for some of the MBH nodes with SR-MPLS data plane. In this case its quite possible to use (in future) non-shortest path SR label stack. > > Interesting. But I'm not sure which of two scenarios you are describing: 1. There is always an MPLS path from ingress to egress, but the shortest path may not consist entirely of MPLS-capable nodes. 2. There isn't always an MPLS path from ingress to egress. So if the ingress creates an MPLS packet, some intermediate node may need to re-encapsulate the packet in IP, in order to get the packet delivered to the egress node. Or is the scenario different from either of these two? From nobody Mon Apr 11 14:45:14 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB3412F36D; Mon, 11 Apr 2016 14:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cTQ-APoWn7o; Mon, 11 Apr 2016 14:45:11 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484A212F2F1; Mon, 11 Apr 2016 14:45:11 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-d3-570c14704bac Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 7B.C5.30335.0741C075; Mon, 11 Apr 2016 23:17:36 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0248.002; Mon, 11 Apr 2016 17:45:09 -0400 From: Uma Chunduri To: Eric C Rosen , Xuxiaohu , "spring@ietf.org" Thread-Topic: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkR6Kh266HVaFkUy+fRZ9moMOGJ9/Rn2wgAYinAD//+k4MA== Date: Mon, 11 Apr 2016 21:45:08 +0000 Message-ID: <1B502206DFA0C544B7A6046915200863580216EE@eusaamb105.ericsson.se> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> <57057618.8020604@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> <1B502206DFA0C544B7A6046915200863580003D6@eusaamb106.ericsson.se> <570BF3D8.5080601@juniper.net> In-Reply-To: <570BF3D8.5080601@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZXLonQbdAhCfc4PhaOYt1Gz4wW9xaupLV 4viF34wWW8+vYnRg8Wg58pbVY8mSn0we15uusgcwR3HZpKTmZJalFunbJXBlfDiylbGgSaRi z4FXLA2MB4S7GDk5JARMJD4smscCYYtJXLi3nq2LkYtDSOAoo8TKt7OYIJzljBJr3j5kAqli E9CT+Dj1JzuILSKQIzG57xZQBwcHs4CyxKm7MiBhYYE0iTkzjrFAlKRL3L7/kQ3CdpL4dfsF I0g5i4CqxM5JIiBhXgFfieu3NrJCrWKSeHb0AtgqTgFtiatf37OC2IxAx30/tQYsziwgLnHr yXwmiKMFJJbsOc8MYYtKvHz8jxXCVpTY1z+dHeI0TYn1u/QhWhUlpnQ/ZIfYKyhxcuYTlgmM YrOQTJ2F0DELSccsJB0LGFlWMXKUFhfk5KYbGWxiBMbPMQk23R2M96d7HmIU4GBU4uFVYOUO F2JNLCuuzD3EKMHBrCTCWynJEy7Em5JYWZValB9fVJqTWnyIUZqDRUmctzH4X5iQQHpiSWp2 ampBahFMlomDU6qB0cWvf8e0GzaHVAPuhodttXuYwZu1KJh7TeHPskyZ/w4Rv5b7a2tJt/32 5ayoWfHmroivqL24d9n1aafmymk9sNpx9Un6Fvl7+1LDO2YfKmHuc5xgc/FZ9P+jqh/beb6d yttU/Vv7QtantRsDY/TSNHdf+bv+jOUqaUMXh8J7duyLcyInBT4IV2Ipzkg01GIuKk4EAKQk o3GbAgAA Archived-At: Cc: "mpls@ietf.org" Subject: Re: [spring] [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 11 Apr 2016 21:45:13 -0000 SW4tbGluZSBbVW1hXToNCg0KLS0NClVtYSBDLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBFcmljIEMgUm9zZW4gW21haWx0bzplcm9zZW5AanVuaXBlci5uZXRdIA0KU2Vu dDogTW9uZGF5LCBBcHJpbCAxMSwgMjAxNiAxMTo1OSBBTQ0KVG86IFVtYSBDaHVuZHVyaTsgWHV4 aWFvaHU7IHNwcmluZ0BpZXRmLm9yZw0KQ2M6IG1wbHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb bXBsc10gQ2xhcmlmaWNhdGlvbiBvbiB0aGUgbW90aXZhdGlvbiBvZiBkcmFmdC14dS1zcHJpbmct aXNsYW5kcy1jb25uZWN0aW9uLW92ZXItaXAtMDUNCg0KDQo+PiBbRXJpY10gSXQgd291bGQgYmUg c29tZXdoYXQgdW51c3VhbCB0byBoYXZlIGFuIElHUCBkb21haW4gaW4gd2hpY2ggc29tZSBub2Rl cyBzdXBwb3J0IE1QTFMgYW5kIHNvbWUgZG9uJ3QuDQo+IFtVbWFdIE1heSBiZSB0cnVlIHdpdGgg bm9uLVNSIGFuZCB0cmFkaXRpb25hbCAgTVBMUy4NCj4gQnV0IHdpdGggU1IgSSBhbSB3b3JraW5n IHdpdGggb25lIGN1c3RvbWVyIHdoZXJlIE1QTFMgKGFzIFNSIGRhdGEgcGxhbmUpIGlzIGJyb3Vn aHQgaW50byB0aGVpciBwdXJlIElHUC1JUCBkb21haW4uDQo+IFdpdGggc3RhdGljIFBXIGxhYmVs cyAoaW5uZXIgbGFiZWwpICBjdXJyZW50bHkgcHVyZSBzb2Z0IEdSRSBlbmNhcCBpcyBiZWluZyB1 c2VkIChmb3IgdHJhbnNwb3J0KSAgYnV0IFNSIGlzIGJlaW5nIHBsYW5uZWQgZnJvbSBFUEcgdG8g Y2VsbCBzaXRlIHJvdXRlcnMgZXZlbnR1YWxseS4NCj4gUGxhbm5pbmcgc2xvdyB1cGdyYWRlIGZv ciBzb21lIG9mIHRoZSBNQkggbm9kZXMgd2l0aCBTUi1NUExTIGRhdGEgcGxhbmUuICBJbiB0aGlz IGNhc2UgaXRzIHF1aXRlIHBvc3NpYmxlIHRvIHVzZSAoaW4gZnV0dXJlKSBub24tc2hvcnRlc3Qg cGF0aCBTUiBsYWJlbCBzdGFjay4NCj4NCj4NCkludGVyZXN0aW5nLiAgQnV0IEknbSBub3Qgc3Vy ZSB3aGljaCBvZiB0d28gc2NlbmFyaW9zIHlvdSBhcmUgZGVzY3JpYmluZzoNCg0KMS4gVGhlcmUg aXMgYWx3YXlzIGFuIE1QTFMgcGF0aCBmcm9tIGluZ3Jlc3MgdG8gZWdyZXNzLCBidXQgdGhlIHNo b3J0ZXN0IHBhdGggbWF5IG5vdCBjb25zaXN0IGVudGlyZWx5IG9mIE1QTFMtY2FwYWJsZSBub2Rl cy4NCg0KMi4gVGhlcmUgaXNuJ3QgYWx3YXlzIGFuIE1QTFMgcGF0aCBmcm9tIGluZ3Jlc3MgdG8g ZWdyZXNzLiAgU28gaWYgdGhlIGluZ3Jlc3MgY3JlYXRlcyBhbiBNUExTIHBhY2tldCwgc29tZSBp bnRlcm1lZGlhdGUgbm9kZSBtYXkgbmVlZCB0byByZS1lbmNhcHN1bGF0ZSB0aGUgcGFja2V0ICBp biBJUCwgaW4gb3JkZXIgdG8gZ2V0IHRoZSBwYWNrZXQgZGVsaXZlcmVkIHRvIHRoZSBlZ3Jlc3Mg bm9kZS4NCg0KT3IgaXMgdGhlIHNjZW5hcmlvIGRpZmZlcmVudCBmcm9tIGVpdGhlciBvZiB0aGVz ZSB0d28/DQoNCltVbWFdOiBJIHdhcyBkZXNjcmliaW5nIG1vcmUgb2YgIzIuIEhvd2V2ZXIgIzEg aXMgb25lIG9mIHRoZSBjYXNlcy4gDQogICAgICAgICAgICAgIEluICMyIGFzIHRoZSBzaG9ydGVz dCBwYXRoIG5laWdoYm9yIGRvZXNuJ3Qgc3VwcG9ydCBTUiAoYW5kIG5vIG91dGdvaW5nIExEUC9S U1ZQIGxhYmVsKSBhbmQgaXQgcmVjb2duaXplcyB0aGUgc2FtZSwgaXQgZW5jYXBzdWxhdGVzIGlu IElQIG9yIA0KICAgICAgICAgICAgICBhcyBwZXIgdGhlICBlZ3Jlc3Mgbm9kZSBOJ3MgdHVubmVs IGRlLWNhcHN1bGF0aW9uIGNhcGFiaWxpdGllcy4gDQogICAgICAgICAgICAgIFRoZXJlIGlzIG5v IGFkZGl0aW9uYWwgY29tcHV0YXRpb24gcmVxdWlyZWQgaGVyZSBhbmQgIGl0cyBzdGlsbCBzaG9y dGVzdCBwYXRoIHRvd2FyZHMgZWdyZXNzIGJ1dCBub3QgbGFiZWxlZC4gDQoNCg== From nobody Mon Apr 11 14:46:40 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB17012D16B; Mon, 11 Apr 2016 14:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Js95Av0SKn6b; Mon, 11 Apr 2016 14:46:33 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FB312B033; Mon, 11 Apr 2016 14:46:33 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-e1-570c1b10a345 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 32.4A.22441.01B1C075; Mon, 11 Apr 2016 23:45:53 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Mon, 11 Apr 2016 17:46:31 -0400 From: Uma Chunduri To: Eric C Rosen , Xuxiaohu , "spring@ietf.org" Thread-Topic: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkR6Kh266HVaFkUy+fRZ9moMOGJ+FZusA///mJkA= Date: Mon, 11 Apr 2016 21:46:31 +0000 Message-ID: <1B502206DFA0C544B7A604691520086358022705@eusaamb105.ericsson.se> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> <57057618.8020604@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> <570BF204.6050301@juniper.net> In-Reply-To: <570BF204.6050301@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZXLonSldQmifc4PJ5Lot1Gz4wW9xaupLV 4viF34wWW8+vYnRg8Wg58pbVY8mSn0we15uusgcwR3HZpKTmZJalFunbJXBlLHvzhbWgV6Bi 35ILbA2Mx3m6GDk5JARMJOY/2sICYYtJXLi3nq2LkYtDSOAoo8TJiw+gnOWMEufXNLCDVLEJ 6El8nPoTzBYRyJGY3HcLqIiDg1lAWeLUXRmQsLBAmsScGcdYIErSJW7f/8gGYVtJPH/TzAhi swioSnzvf8gEYvMK+EpMfrmTCWLXY0aJ22/ugiU4BbQl1m35C2YzAl33/dQaMJtZQFzi1pP5 TBBXC0gs2XOeGcIWlXj5+B8rhK0osa9/OjtEvY7Egt2f2CBsbYllC18zQywWlDg58wnLBEax WUjGzkLSMgtJyywkLQsYWVYxcpQWF+TkphsZbmIERtExCTbHHYx7ez0PMQpwMCrx8CqwcocL sSaWFVfmHmKU4GBWEuGtlOQJF+JNSaysSi3Kjy8qzUktPsQozcGiJM7rHfkvTEggPbEkNTs1 tSC1CCbLxMEp1cBYzrKgW/dPUEuP+BptM/ODNlXb2T81T2bIZdbUXLPn7oWIJxIT4jxnbi5c vCRWNtPn6t+D19PubHRRTMp7X7IoPOPE3TPtk4/E/HwcuETrPIujwmaXb2/W7TFWWhtf3sa2 4s4h/mc72uJ3nzombeD85evP+uwnBzbejWx2vJSXlR7P6fb82bz1SizFGYmGWsxFxYkAOKnP 0p4CAAA= Archived-At: Cc: "mpls@ietf.org" Subject: Re: [spring] [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 11 Apr 2016 21:46:36 -0000 Hi Eric, Quick response In-line [Uma]: -- Uma C. -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric C Rosen Sent: Monday, April 11, 2016 11:51 AM To: Xuxiaohu; spring@ietf.org Cc: mpls@ietf.org Subject: Re: [mpls] Clarification on the motivation of draft-xu-spring-isla= nds-connection-over-ip-05 On 4/7/2016 6:39 PM, Xuxiaohu wrote: > [Xiaohu] The FEC associated the above label L is the /32 or 128/ prefix o= f node N. When the IGP next-hop towards that FEC is a non-MPLS node, the LS= R receiving the above MPLS packet with top label of L is desired to forward= that MPLS packet towards node N via an IP-based tunnel. In this case, the = node N is the remote peer for that FEC. Yes, in this case, the tunnel's receive endpoint can be regarded as a remot= e label distribution peer of the tunnel's transmit endpoint. However, in the above case I don't think it is obvious that you want to IP-= tunnel the packet to N. =20 You might just want to tunnel it around the=20 non-MPLS node. In that case, the tunnel's receive endpoint can still=20 be regarded as a remote label distribution peer of the transmit endpoint, b= ut the receive endpoint is not N. [Uma]: Sure, this can be done; if at all if there is a shortest path node = towards N (supporting MPLS/SR) and if we can tunnel to that node yes, packe= t can be delivered to N eventually. However, this involves (additional computation/adjustment) c= omputation by all the boarder nodes to deliver it to the shortest SR node t= owards N. In that case, actually I would have expected operator to put= that additional node Label as the top label instead of N. If the former ha= s to happen operator has to=20 exercise how this should happen through a knob ..(apart from= the additional work on the boarder node). =20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From nobody Mon Apr 11 17:23:11 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B3912D734; Mon, 11 Apr 2016 17:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P377ktsvJxiy; Mon, 11 Apr 2016 17:23:06 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23E4F12D748; Mon, 11 Apr 2016 17:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11884; q=dns/txt; s=iport; t=1460420586; x=1461630186; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0N3D5npgpPjjS2Sk0b53JGAMw/sz/zcnpq/344krXLE=; b=VkDejO+pkJJD+ts3zSW6Z1603UjhAnL5GwaCsW2FXvWbxo/nJCe1hfTt LOc4ER0giT/48utJ3wDcDLg4rEjRFzTV7jl64M02tyPa1AEGZCKhyp5Je APyP9kKjpFLsADlhh53MeZq8Kzg2EA7CgDwnFvpejcw2hIFds9EKaxvkr 0=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnBQB/PwxX/4oNJK1dgmtMgVAGtWqFA?= =?us-ascii?q?YFyhg0CgTA5EwEBAQEBAQFlJ4RBAQEBAwEjVgULAgEIGCoCAjIlAgQOBQ6IEQi?= =?us-ascii?q?tdZIlAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQiGIYF1CIJOhz8rgisFmAQBgyOBZ?= =?us-ascii?q?okCjw2PJQEiAj6CMoE1bIkHfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,471,1454976000"; d="asc'?scan'208,217";a="260310481" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Apr 2016 00:23:02 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u3C0N2Fm030948 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2016 00:23:02 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 11 Apr 2016 20:23:01 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Mon, 11 Apr 2016 20:23:01 -0400 From: "Carlos Pignataro (cpignata)" To: Xuxiaohu Thread-Topic: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkR5txOXaaHM/6UCWJNsvqUTm05+Fw8EA Date: Tue, 12 Apr 2016 00:23:01 +0000 Message-ID: <86F4B67F-6792-4342-A89B-1275AC443202@cisco.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> <57057618.8020604@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.101.176] Content-Type: multipart/signed; boundary="Apple-Mail=_FBC78056-BC74-4EFE-A392-288FE2300AD4"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" , Eric C Rosen Subject: Re: [spring] [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 12 Apr 2016 00:23:07 -0000 --Apple-Mail=_FBC78056-BC74-4EFE-A392-288FE2300AD4 Content-Type: multipart/alternative; boundary="Apple-Mail=_22140C43-088F-4D41-9086-F9E3882BA056" --Apple-Mail=_22140C43-088F-4D41-9086-F9E3882BA056 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 7, 2016, at 6:39 PM, Xuxiaohu wrote: >=20 > On 4/6/2016 11:37 AM, Xuxiaohu wrote: >> The situation in MPLS-SR is a little bit complex since the outgoing = label for a given /32 or /128 prefix FEC could be learnt either from the = IGP next-hop of that FEC or the originator of that FEC due to the IGP = flooding property. In the former case, the IGP next-hop for a given FEC = is taken as the next-hop of the received MPLS packet belonging to that = FEC; in the latter case, the originator of that FEC is taken as the = next-hop of the MPLS packet belonging to that FEC ... the latter case = belongs to the "remote label distribution peer" case as defined in = RFC3031 >=20 > I don't believe this is correct. In SR, the fact that label L was > advertised by node N does not imply that a packet with L at the top of > the stack needs to be tunneled to N. In the typical case, the packet >=20 > [Xiaohu] The FEC associated the above label L is the /32 or 128/ = prefix of node N. When the IGP next-hop towards that FEC is a non-MPLS = node, the LSR receiving the above MPLS packet with top label of L is = desired to forward that MPLS packet towards node N via an IP-based = tunnel. In this case, the node N is the remote peer for that FEC. >=20 Is this really a =E2=80=9Cremote label distribution peer=E2=80=9D? Or a = local one by way of the forwarding adjacency of an IP Tunnel as a = logical MPLS-enabled interface (towards N or bypassing the old router)? Thanks, =E2=80=94 Carlos. > Best regards, > Xiaohu --Apple-Mail=_22140C43-088F-4D41-9086-F9E3882BA056 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 7, 2016, at 6:39 PM, Xuxiaohu <xuxiaohu@huawei.com>= wrote:

On 4/6/2016 11:37 AM, Xuxiaohu wrote:
The situation in MPLS-SR is = a little bit complex since the outgoing label for a given /32 or /128 = prefix FEC could be learnt either from the IGP next-hop of that FEC or = the originator of that FEC due to the IGP flooding property. In the = former case, the IGP next-hop for a given FEC is taken as the next-hop = of the received MPLS packet belonging to that FEC; in the latter case, = the originator of that FEC is taken as the next-hop of the MPLS packet = belonging to that FEC ... the latter case belongs to the "remote label = distribution peer" case as defined in RFC3031

I don't believe this is correct.  In SR, = the fact that label L was
advertised by node N does not imply that = a packet with L at the top of
the stack needs to be tunneled to N. =  In the typical case, the packet

[Xiaohu] The FEC associated the above label L is = the /32 or 128/ prefix of node N. When the IGP next-hop towards that FEC = is a non-MPLS node, the LSR receiving the above MPLS packet with top = label of L is desired to forward that MPLS packet towards node N via an = IP-based tunnel. In this case, the node N is the remote peer for that = FEC.


Is this really a =E2=80=9Cremote label = distribution peer=E2=80=9D? Or a local one by way of the forwarding = adjacency of an IP Tunnel as a logical MPLS-enabled interface (towards N = or bypassing the old router)?

Thanks,

=E2=80=94= Carlos.

Best regards,
Xiaohu

= --Apple-Mail=_22140C43-088F-4D41-9086-F9E3882BA056-- --Apple-Mail=_FBC78056-BC74-4EFE-A392-288FE2300AD4 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 iQIcBAEBCAAGBQJXDD/kAAoJEIXgpQGOZny93gAP/3Aw0ayjP2ljsafeSXLpFo1g CCyV4KCsrl6h4R3qt2igLqQ+1yOwjsGxmoHdJRaQ6BOxbEPtQ/yanR0dIxObXFjd gdsXjo5l1DaIJCFSsCHjJzoBfF8vwj4zlGudIO604z3e1EGR/7CAtbURcj5R5EA5 mjfNlrzSqLeyRiBEbjEXfCqJ7vb4tpIl2BvJmxUuo0pdPdLF4gENiUhfbjP4+HxF kki3iL0ud1ceZ6wcMdDqGz8END1GSK2nIMXCdVLEslobi6g9c2yUcj4K2JXDzHg8 B3So9a0kIj8aAbZ7SKnYnNo6dq8XN1ttNoRVUAmg6KPXGlN6VK9DtsTZcEXseRpv pGomhZ8sUPmMgTWWY0ThciLqk27Pi23WdTaNHlOK8MgEtyhDqP8yZk6HIHtoTEra 6HqnWpyKVXZOoudAyEVeyQmdbmiaoRqk004pUGqY6tUmvV8zCPMhR5cz6AyUB6Fa U4fz0ucAqBHV/bPMNCgA2Gv28z00YIB6Mk3TKb5qSlIM2aF+G+aqkrSXxD5lozFP 2l9J//PIS6CGOd1YKouWt3qSwB19IM3MlsRdm+smeuRzPcpmVsYtwcc51QdfEYHh 6HeAWDlXyZ1kQwEUVsush4SHlAnhzx2U9Xq7a48bTiQ+BpdiR9eVs04wH3IvsSAv DpGR5xH+SZ2Dhd8TRA6o =fhXG -----END PGP SIGNATURE----- --Apple-Mail=_FBC78056-BC74-4EFE-A392-288FE2300AD4-- From nobody Tue Apr 12 03:08:05 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EA812E55E; Tue, 12 Apr 2016 03:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPDzcOMQ2Bhh; Tue, 12 Apr 2016 03:08:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F17A812E500; Tue, 12 Apr 2016 03:08:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHE85678; Tue, 12 Apr 2016 10:07:57 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 12 Apr 2016 11:07:57 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 12 Apr 2016 18:07:51 +0800 From: Xuxiaohu To: Uma Chunduri , Eric C Rosen , "spring@ietf.org" Thread-Topic: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkBgULgoheUag70W81YSz/dG9Vp985QYAgAI0iT6ABYY/AIAAMR2AgAFUO4A= Date: Tue, 12 Apr 2016 10:07:50 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53933F@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> <57057618.8020604@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> <570BF204.6050301@juniper.net> <1B502206DFA0C544B7A604691520086358022705@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A604691520086358022705@eusaamb105.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.570CC8FE.015F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6bd99262ea2d76e94853e1e05ac2cff1 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [spring] [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 12 Apr 2016 10:08:02 -0000 > -----Original Message----- > From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] > Sent: Tuesday, April 12, 2016 5:47 AM > To: Eric C Rosen; Xuxiaohu; spring@ietf.org > Cc: mpls@ietf.org > Subject: RE: [mpls] Clarification on the motivation of > draft-xu-spring-islands-connection-over-ip-05 >=20 > Hi Eric, >=20 > Quick response In-line [Uma]: >=20 > -- > Uma C. >=20 >=20 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Eric C Rosen > Sent: Monday, April 11, 2016 11:51 AM > To: Xuxiaohu; spring@ietf.org > Cc: mpls@ietf.org > Subject: Re: [mpls] Clarification on the motivation of > draft-xu-spring-islands-connection-over-ip-05 >=20 > On 4/7/2016 6:39 PM, Xuxiaohu wrote: > > [Xiaohu] The FEC associated the above label L is the /32 or 128/ prefix= of node > N. When the IGP next-hop towards that FEC is a non-MPLS node, the LSR > receiving the above MPLS packet with top label of L is desired to forward= that > MPLS packet towards node N via an IP-based tunnel. In this case, the node= N is > the remote peer for that FEC. >=20 > Yes, in this case, the tunnel's receive endpoint can be regarded as a rem= ote label > distribution peer of the tunnel's transmit endpoint. >=20 > However, in the above case I don't think it is obvious that you want to I= P-tunnel > the packet to N. > You might just want to tunnel it around the > non-MPLS node. In that case, the tunnel's receive endpoint can still > be regarded as a remote label distribution peer of the transmit endpoint,= but the > receive endpoint is not N. >=20 > [Uma]: Sure, this can be done; if at all if there is a shortest path nod= e towards > N (supporting MPLS/SR) and if we can tunnel to that node yes, packet can = be > delivered to N eventually. > However, this involves (additional computation/adjustment) > computation by all the boarder nodes to deliver it to the shortest SR nod= e > towards N. > In that case, actually I would have expected operator to p= ut > that additional node Label as the top label instead of N. If the former h= as to > happen operator has to > exercise how this should happen through a knob ..(apart fr= om > the additional work on the boarder node). Agree with Uma. There is no need to introduce any complexity to the SPF alg= orithm by taking N as the remote peer. Best regards, Xiaohu >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Apr 12 03:15:13 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A8512EA4E; Tue, 12 Apr 2016 03:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMiY48S0daIn; Tue, 12 Apr 2016 03:15:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D1C612EAB6; Tue, 12 Apr 2016 03:05:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLX93296; Tue, 12 Apr 2016 10:05:23 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 12 Apr 2016 11:05:14 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 12 Apr 2016 18:05:08 +0800 From: Xuxiaohu To: "Carlos Pignataro (cpignata)" Thread-Topic: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 Thread-Index: AQHRkBgULgoheUag70W81YSz/dG9Vp985QYAgAI0iT6ABeMWgIABJ9Ug Date: Tue, 12 Apr 2016 10:05:08 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53932F@NKGEML515-MBX.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> <57057618.8020604@juniper.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538844@NKGEML515-MBX.china.huawei.com> <86F4B67F-6792-4342-A89B-1275AC443202@cisco.com> In-Reply-To: <86F4B67F-6792-4342-A89B-1275AC443202@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53932FNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.570CC863.01BB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6e2ba583e0e62352372d91647ccbbba9 Archived-At: Cc: "mpls@ietf.org" , "spring@ietf.org" , Eric C Rosen Subject: Re: [spring] [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 12 Apr 2016 10:15:09 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53932FNKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNp c2NvLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDEyLCAyMDE2IDg6MjMgQU0NClRvOiBYdXhp YW9odQ0KQ2M6IEVyaWMgQyBSb3Nlbjsgc3ByaW5nQGlldGYub3JnOyBtcGxzQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW21wbHNdIENsYXJpZmljYXRpb24gb24gdGhlIG1vdGl2YXRpb24gb2YgZHJh ZnQteHUtc3ByaW5nLWlzbGFuZHMtY29ubmVjdGlvbi1vdmVyLWlwLTA1DQoNCg0KT24gQXByIDcs IDIwMTYsIGF0IDY6MzkgUE0sIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPG1haWx0bzp4 dXhpYW9odUBodWF3ZWkuY29tPj4gd3JvdGU6DQoNCk9uIDQvNi8yMDE2IDExOjM3IEFNLCBYdXhp YW9odSB3cm90ZToNCg0KVGhlIHNpdHVhdGlvbiBpbiBNUExTLVNSIGlzIGEgbGl0dGxlIGJpdCBj b21wbGV4IHNpbmNlIHRoZSBvdXRnb2luZyBsYWJlbCBmb3IgYSBnaXZlbiAvMzIgb3IgLzEyOCBw cmVmaXggRkVDIGNvdWxkIGJlIGxlYXJudCBlaXRoZXIgZnJvbSB0aGUgSUdQIG5leHQtaG9wIG9m IHRoYXQgRkVDIG9yIHRoZSBvcmlnaW5hdG9yIG9mIHRoYXQgRkVDIGR1ZSB0byB0aGUgSUdQIGZs b29kaW5nIHByb3BlcnR5LiBJbiB0aGUgZm9ybWVyIGNhc2UsIHRoZSBJR1AgbmV4dC1ob3AgZm9y IGEgZ2l2ZW4gRkVDIGlzIHRha2VuIGFzIHRoZSBuZXh0LWhvcCBvZiB0aGUgcmVjZWl2ZWQgTVBM UyBwYWNrZXQgYmVsb25naW5nIHRvIHRoYXQgRkVDOyBpbiB0aGUgbGF0dGVyIGNhc2UsIHRoZSBv cmlnaW5hdG9yIG9mIHRoYXQgRkVDIGlzIHRha2VuIGFzIHRoZSBuZXh0LWhvcCBvZiB0aGUgTVBM UyBwYWNrZXQgYmVsb25naW5nIHRvIHRoYXQgRkVDIC4uLiB0aGUgbGF0dGVyIGNhc2UgYmVsb25n cyB0byB0aGUgInJlbW90ZSBsYWJlbCBkaXN0cmlidXRpb24gcGVlciIgY2FzZSBhcyBkZWZpbmVk IGluIFJGQzMwMzENCg0KSSBkb24ndCBiZWxpZXZlIHRoaXMgaXMgY29ycmVjdC4gIEluIFNSLCB0 aGUgZmFjdCB0aGF0IGxhYmVsIEwgd2FzDQphZHZlcnRpc2VkIGJ5IG5vZGUgTiBkb2VzIG5vdCBp bXBseSB0aGF0IGEgcGFja2V0IHdpdGggTCBhdCB0aGUgdG9wIG9mDQp0aGUgc3RhY2sgbmVlZHMg dG8gYmUgdHVubmVsZWQgdG8gTi4gIEluIHRoZSB0eXBpY2FsIGNhc2UsIHRoZSBwYWNrZXQNCg0K W1hpYW9odV0gVGhlIEZFQyBhc3NvY2lhdGVkIHRoZSBhYm92ZSBsYWJlbCBMIGlzIHRoZSAvMzIg b3IgMTI4LyBwcmVmaXggb2Ygbm9kZSBOLiBXaGVuIHRoZSBJR1AgbmV4dC1ob3AgdG93YXJkcyB0 aGF0IEZFQyBpcyBhIG5vbi1NUExTIG5vZGUsIHRoZSBMU1IgcmVjZWl2aW5nIHRoZSBhYm92ZSBN UExTIHBhY2tldCB3aXRoIHRvcCBsYWJlbCBvZiBMIGlzIGRlc2lyZWQgdG8gZm9yd2FyZCB0aGF0 IE1QTFMgcGFja2V0IHRvd2FyZHMgbm9kZSBOIHZpYSBhbiBJUC1iYXNlZCB0dW5uZWwuIEluIHRo aXMgY2FzZSwgdGhlIG5vZGUgTiBpcyB0aGUgcmVtb3RlIHBlZXIgZm9yIHRoYXQgRkVDLg0KDQoN CklzIHRoaXMgcmVhbGx5IGEg4oCccmVtb3RlIGxhYmVsIGRpc3RyaWJ1dGlvbiBwZWVy4oCdPyBP ciBhIGxvY2FsIG9uZSBieSB3YXkgb2YgdGhlIGZvcndhcmRpbmcgYWRqYWNlbmN5IG9mIGFuIElQ IFR1bm5lbCBhcyBhIGxvZ2ljYWwgTVBMUy1lbmFibGVkIGludGVyZmFjZSAodG93YXJkcyBOIG9y IGJ5cGFzc2luZyB0aGUgb2xkIHJvdXRlcik/DQoNCltYaWFvaHVdIHdoYXTigJlzIHRoZSBkaWZm ZXJlbmNlIGJldHdlZW4gdGhlIGFib3ZlIHR3bz8NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoN ClRoYW5rcywNCg0K4oCUIENhcmxvcy4NCg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53932FNKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEg MSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6 MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7 DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBj bSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQ2Fy bG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIFttYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tXQ0KPGJy Pg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEFwcmlsIDEyLCAyMDE2IDg6MjMgQU08YnI+DQo8Yj5U bzo8L2I+IFh1eGlhb2h1PGJyPg0KPGI+Q2M6PC9iPiBFcmljIEMgUm9zZW47IHNwcmluZ0BpZXRm Lm9yZzsgbXBsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21wbHNdIENsYXJp ZmljYXRpb24gb24gdGhlIG1vdGl2YXRpb24gb2YgZHJhZnQteHUtc3ByaW5nLWlzbGFuZHMtY29u bmVjdGlvbi1vdmVyLWlwLTA1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBBcHIgNywgMjAxNiwgYXQgNjozOSBQTSwgWHV4 aWFvaHUgJmx0OzxhIGhyZWY9Im1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tIj54dXhpYW9odUBo dWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PbiA0LzYvMjAxNiAxMTozNyBBTSwgWHV4aWFvaHUg d3JvdGU6PGJyIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87 dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIHNpdHVhdGlvbiBpbiBNUExTLVNSIGlz IGEgbGl0dGxlIGJpdCBjb21wbGV4IHNpbmNlIHRoZSBvdXRnb2luZyBsYWJlbCBmb3IgYSBnaXZl biAvMzIgb3IgLzEyOCBwcmVmaXggRkVDIGNvdWxkIGJlIGxlYXJudCBlaXRoZXIgZnJvbSB0aGUg SUdQIG5leHQtaG9wIG9mDQogdGhhdCBGRUMgb3IgdGhlIG9yaWdpbmF0b3Igb2YgdGhhdCBGRUMg ZHVlIHRvIHRoZSBJR1AgZmxvb2RpbmcgcHJvcGVydHkuIEluIHRoZSBmb3JtZXIgY2FzZSwgdGhl IElHUCBuZXh0LWhvcCBmb3IgYSBnaXZlbiBGRUMgaXMgdGFrZW4gYXMgdGhlIG5leHQtaG9wIG9m IHRoZSByZWNlaXZlZCBNUExTIHBhY2tldCBiZWxvbmdpbmcgdG8gdGhhdCBGRUM7IGluIHRoZSBs YXR0ZXIgY2FzZSwgdGhlIG9yaWdpbmF0b3Igb2YgdGhhdCBGRUMgaXMgdGFrZW4NCiBhcyB0aGUg bmV4dC1ob3Agb2YgdGhlIE1QTFMgcGFja2V0IGJlbG9uZ2luZyB0byB0aGF0IEZFQyAuLi4gdGhl IGxhdHRlciBjYXNlIGJlbG9uZ3MgdG8gdGhlICZxdW90O3JlbW90ZSBsYWJlbCBkaXN0cmlidXRp b24gcGVlciZxdW90OyBjYXNlIGFzIGRlZmluZWQgaW4gUkZDMzAzMTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48YnI+DQpJIGRvbid0IGJlbGlldmUgdGhpcyBpcyBjb3JyZWN0LiAmbmJz cDtJbiBTUiwgdGhlIGZhY3QgdGhhdCBsYWJlbCBMIHdhczxicj4NCmFkdmVydGlzZWQgYnkgbm9k ZSBOIGRvZXMgbm90IGltcGx5IHRoYXQgYSBwYWNrZXQgd2l0aCBMIGF0IHRoZSB0b3Agb2Y8YnI+ DQp0aGUgc3RhY2sgbmVlZHMgdG8gYmUgdHVubmVsZWQgdG8gTi4gJm5ic3A7SW4gdGhlIHR5cGlj YWwgY2FzZSwgdGhlIHBhY2tldDxicj4NCjxicj4NCltYaWFvaHVdIFRoZSBGRUMgYXNzb2NpYXRl ZCB0aGUgYWJvdmUgbGFiZWwgTCBpcyB0aGUgLzMyIG9yIDEyOC8gcHJlZml4IG9mIG5vZGUgTi4g V2hlbiB0aGUgSUdQIG5leHQtaG9wIHRvd2FyZHMgdGhhdCBGRUMgaXMgYSBub24tTVBMUyBub2Rl LCB0aGUgTFNSIHJlY2VpdmluZyB0aGUgYWJvdmUgTVBMUyBwYWNrZXQgd2l0aCB0b3AgbGFiZWwg b2YgTCBpcyBkZXNpcmVkIHRvIGZvcndhcmQgdGhhdCBNUExTIHBhY2tldCB0b3dhcmRzIG5vZGUg TiB2aWENCiBhbiBJUC1iYXNlZCB0dW5uZWwuIEluIHRoaXMgY2FzZSwgdGhlIG5vZGUgTiBpcyB0 aGUgcmVtb3RlIHBlZXIgZm9yIHRoYXQgRkVDLjxiciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JcyB0aGlzIHJlYWxseSBhIOKAnHJlbW90ZSBs YWJlbCBkaXN0cmlidXRpb24gcGVlcuKAnT8gT3IgYSBsb2NhbCBvbmUgYnkgd2F5IG9mIHRoZSBm b3J3YXJkaW5nIGFkamFjZW5jeSBvZiBhbiBJUCBUdW5uZWwgYXMgYSBsb2dpY2FsIE1QTFMtZW5h YmxlZCBpbnRlcmZhY2UgKHRvd2FyZHMgTiBvciBieXBhc3NpbmcgdGhlIG9sZCByb3V0ZXIpPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjE2LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bWGlhb2h1XSB3aGF04oCZcyB0aGUg ZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBhYm92ZSB0d28/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTYuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlhpYW9odTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+4oCUIENhcmxvcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkJlc3QgcmVnYXJkcyw8YnI+DQpYaWFvaHU8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D53932FNKGEML515MBXchi_-- From nobody Tue Apr 12 13:49:20 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC7612D9DC for ; Tue, 12 Apr 2016 13:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.506 X-Spam-Level: X-Spam-Status: No, score=-15.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twqM7T9J78Qa for ; Tue, 12 Apr 2016 13:49:17 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8826012D693 for ; Tue, 12 Apr 2016 13:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13406; q=dns/txt; s=iport; t=1460494157; x=1461703757; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=OaJV5MpTGToScp1nWPHyEbWKRk41VCPUg9JkblHBZQ0=; b=NWXTDnvlqBniihCQmbUs39mbesoD+C6/RPprqVacNw8C+1fTYEskPZLe zEF9lUW65pF8w2I2hIZfLEBmFuA5aoO9jLHAdQL44rcXZp/rDhnL7xsxj QnhbyalplrVkX2wsAdkZeHjYFq9KxKSdPDz7SfRKnH5tiSJOr75DnsggJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BbAgCiXg1X/4gNJK1egmtMU30GtW+Ec?= =?us-ascii?q?wENgXYkhWoCHIEeOBQBAQEBAQEBZRwLhEEBAQEEIwpKDgQCAQgRBAEBKAMCAgI?= =?us-ascii?q?wFAcBAQUDAgQTCIgfAQ6wCpINAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYhhEuEb?= =?us-ascii?q?IJTglYFjVCFS4RtAYV2iA+Bbk6EAIhbjyYBHgEBQoIygTVsAYkGAX0BAQE?= X-IronPort-AV: E=Sophos; i="5.24,476,1454976000"; d="scan'208,217"; a="92851895" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Apr 2016 20:49:16 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3CKnGSf021006 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 12 Apr 2016 20:49:16 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 12 Apr 2016 15:49:15 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Tue, 12 Apr 2016 15:49:15 -0500 From: "Les Ginsberg (ginsberg)" To: "spring@ietf.org" Thread-Topic: New Version Notification for draft-ginsberg-spring-conflict-resolution-01.txt Thread-Index: AQHRlPwMx+rPL72iJUKQZoTc4xsSdJ+GznDw Date: Tue, 12 Apr 2016 20:49:15 +0000 Message-ID: References: <20160412203823.32270.61116.idtracker@ietfa.amsl.com> In-Reply-To: <20160412203823.32270.61116.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [171.69.35.101] Content-Type: multipart/alternative; boundary="_000_a9d03afcf97e4aef81d289f6a41f35f4XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [spring] FW: New Version Notification for draft-ginsberg-spring-conflict-resolution-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 12 Apr 2016 20:49:19 -0000 --_000_a9d03afcf97e4aef81d289f6a41f35f4XCHALN001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9sa3MgLQ0KDQoNCg0KTmV3IHZlcnNpb24gb2YgdGhlIGNvbmZsaWN0IHJlc29sdXRpb24gZHJh ZnQgaGFzIGJlZW4gcG9zdGVkLg0KVGhhbnggZm9yIGFsbCB0aGUgdmFsdWFibGUgaW5wdXQgLSB3 ZSBoYXZlIGRvbmUgb3VyIGJlc3QgdG8gcmVzcG9uZCB0byBhbGwgY29tbWVudHMgcmVjZWl2ZWQu DQoNCg0KDQogICBMZXMNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnXQ0KU2VudDogVHVlc2RheSwgQXByaWwgMTIsIDIwMTYgMTozOCBQTQ0KVG86IFBldGVyIFBz ZW5hayAocHBzZW5hayk7IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpOyBNYXJ0aW4gUGlsa2E7IFN0 ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWdpbnNiZXJnLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uLTAxLnR4dA0K DQoNCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1naW5zYmVyZy1zcHJpbmctY29u ZmxpY3QtcmVzb2x1dGlvbi0wMS50eHQNCg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBMZXMgR2luc2JlcmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQoN Cg0KTmFtZTogICAgICAgICAgICAgICAgICBkcmFmdC1naW5zYmVyZy1zcHJpbmctY29uZmxpY3Qt cmVzb2x1dGlvbg0KDQpSZXZpc2lvbjogICAgICAgICAgICAgIDAxDQoNClRpdGxlOiAgICAgICAg ICAgICAgICAgICAgICBTZWdtZW50IFJvdXRpbmcgQ29uZmxpY3QgUmVzb2x1dGlvbg0KDQpEb2N1 bWVudCBkYXRlOiAgICAgICAgICAgICAgIDIwMTYtMDQtMTINCg0KR3JvdXA6ICAgICAgICAgICAg ICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQoNClBhZ2VzOiAgICAgICAgICAgICAgICAgICAx NQ0KDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWdpbnNiZXJnLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uLTAxLnR4dA0KDQpTdGF0 dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ2luc2Jl cmctc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24vDQoNCkh0bWxpemVkOiAgICAgICBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2luc2Jlcmctc3ByaW5nLWNvbmZsaWN0LXJlc29s dXRpb24tMDENCg0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1naW5zYmVyZy1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbi0wMQ0KDQoNCg0K QWJzdHJhY3Q6DQoNCiAgIEluIHN1cHBvcnQgb2YgU2VnbWVudCBSb3V0aW5nIChTUikgcm91dGlu ZyBwcm90b2NvbHMgYWR2ZXJ0aXNlIGENCg0KICAgdmFyaWV0eSBvZiBpZGVudGlmaWVycyB1c2Vk IHRvIGRlZmluZSB0aGUgc2VnbWVudHMgd2hpY2ggZGlyZWN0DQoNCiAgIGZvcndhcmRpbmcgb2Yg cGFja2V0cy4gIEluIGNhc2VzIHdoZXJlIHRoZSBpbmZvcm1hdGlvbiBhZHZlcnRpc2VkIGJ5DQoN CiAgIGEgZ2l2ZW4gcHJvdG9jb2wgaW5zdGFuY2UgaXMgZWl0aGVyIGludGVybmFsbHkgaW5jb25z aXN0ZW50IG9yDQoNCiAgIGNvbmZsaWN0cyB3aXRoIGFkdmVydGlzZW1lbnRzIGZyb20gYW5vdGhl ciBwcm90b2NvbCBpbnN0YW5jZSBhIG1lYW5zDQoNCiAgIG9mIGFjaGlldmluZyBjb25zaXN0ZW50 IGZvcndhcmRpbmcgYmVoYXZpb3IgaW4gdGhlIG5ldHdvcmsgaXMNCg0KICAgcmVxdWlyZWQuICBU aGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIHBvbGljaWVzIHVzZWQgdG8gcmVzb2x2ZSB0aGVzZQ0K DQogICBvY2N1cnJlbmNlcy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz aW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmcuDQoNCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg== --_000_a9d03afcf97e4aef81d289f6a41f35f4XCHALN001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1z b1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBs YWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkZvbGtzIC08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+TmV3IHZl cnNpb24gb2YgdGhlIGNvbmZsaWN0IHJlc29sdXRpb24gZHJhZnQgaGFzIGJlZW4gcG9zdGVkLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbnggZm9yIGFsbCB0aGUgdmFs dWFibGUgaW5wdXQgLSB3ZSBoYXZlIGRvbmUgb3VyIGJlc3QgdG8gcmVzcG9uZCB0byBhbGwgY29t bWVudHMgcmVjZWl2ZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyBMZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N CkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZ10gPGJyPg0KU2VudDogVHVlc2RheSwgQXByaWwgMTIsIDIwMTYgMTozOCBQTTxicj4N ClRvOiBQZXRlciBQc2VuYWsgKHBwc2VuYWspOyBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKTsgTWFy dGluIFBpbGthOyBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKTxicj4NClN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZ2luc2Jlcmctc3ByaW5nLWNvbmZsaWN0LXJl c29sdXRpb24tMDEudHh0PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1naW5z YmVyZy1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbi0wMS50eHQ8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg TGVzIEdpbnNiZXJnIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+TmFtZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgZHJhZnQtZ2luc2Jlcmctc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb248 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJldmlzaW9uOiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAwMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ VGl0bGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlZ21lbnQgUm91dGluZyBDb25mbGljdCBSZXNvbHV0aW9uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Eb2N1bWVudCBkYXRlOiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyMDE2LTA0LTEyPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5Hcm91cDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5QYWdlczombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgMTU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPlVSTDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWdpbnNiZXJnLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uLTAxLnR4dCI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWdpbnNiZXJnLXNwcmluZy1j b25mbGljdC1yZXNvbHV0aW9uLTAxLnR4dDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5TdGF0dXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWdpbnNiZXJnLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uLyI+DQo8c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ2luc2Jlcmctc3ByaW5nLWNvbmZsaWN0LXJlc29s dXRpb24vPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi Pkh0bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2luc2Jlcmctc3ByaW5nLWNvbmZsaWN0 LXJlc29sdXRpb24tMDEiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1naW5zYmVyZy1z cHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbi0wMTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5EaWZmOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtZ2luc2Jlcmctc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRp b24tMDEiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5v bmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1naW5zYmVyZy1zcHJp bmctY29uZmxpY3QtcmVzb2x1dGlvbi0wMTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkFic3RyYWN0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7IEluIHN1cHBvcnQgb2YgU2VnbWVudCBSb3V0aW5nIChTUikgcm91dGlu ZyBwcm90b2NvbHMgYWR2ZXJ0aXNlIGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyB2YXJpZXR5IG9mIGlkZW50aWZpZXJzIHVzZWQgdG8gZGVmaW5l IHRoZSBzZWdtZW50cyB3aGljaCBkaXJlY3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyBmb3J3YXJkaW5nIG9mIHBhY2tldHMuJm5ic3A7IEluIGNh c2VzIHdoZXJlIHRoZSBpbmZvcm1hdGlvbiBhZHZlcnRpc2VkIGJ5PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgYSBnaXZlbiBwcm90b2NvbCBpbnN0 YW5jZSBpcyBlaXRoZXIgaW50ZXJuYWxseSBpbmNvbnNpc3RlbnQgb3I8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBjb25mbGljdHMgd2l0aCBhZHZl cnRpc2VtZW50cyBmcm9tIGFub3RoZXIgcHJvdG9jb2wgaW5zdGFuY2UgYSBtZWFuczxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IG9mIGFjaGlldmlu ZyBjb25zaXN0ZW50IGZvcndhcmRpbmcgYmVoYXZpb3IgaW4gdGhlIG5ldHdvcmsgaXM8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyByZXF1aXJlZC4m bmJzcDsgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBwb2xpY2llcyB1c2VkIHRvIHJlc29sdmUg dGhlc2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyBvY2N1cnJlbmNlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIElFVEYgU2VjcmV0YXJpYXQ8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_a9d03afcf97e4aef81d289f6a41f35f4XCHALN001ciscocom_-- From nobody Tue Apr 12 13:52:48 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7C212DE59 for ; Tue, 12 Apr 2016 13:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pt_HVoxsrwka for ; Tue, 12 Apr 2016 13:52:45 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F3ED12DF1F for ; Tue, 12 Apr 2016 13:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=468; q=dns/txt; s=iport; t=1460494364; x=1461703964; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=vf8RbvowxH85KuJ9FAmU2ruBXjhG5bOaHec6PUG1A1E=; b=f5OAZJBh+CGvMspI0ZByBKmx2xpqpHrdY8fEBhEW/WHxCH8mC0IVQhVB lwebp8EK8XQrCaOwCyB91K5ioq8BB1mz2hSg5RqVubuzeR+S4IZ0hFKG3 nYE+X8qHku75AigT/W+DJc4Ys80La8gtI63uPR6s9YvtLp43c4aJrCWaA s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAgDJXw1X/4kNJK1egzeBVrpiAQ2Bd?= =?us-ascii?q?oYsgR44FAEBAQEBAQFlHAuESCMRVwEiAiYCBDAVEQEEG4gfAaA8j12SCwEBAQE?= =?us-ascii?q?GAQEBAQEbfIUlhEuHP4JWBZgIAYEsjFmBWAGNPmyOOgEeAQFCg2eJcwF9AQEB?= X-IronPort-AV: E=Sophos;i="5.24,476,1454976000"; d="scan'208";a="91064701" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Apr 2016 20:52:34 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u3CKqYRu021346 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 12 Apr 2016 20:52:34 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 12 Apr 2016 15:52:33 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Tue, 12 Apr 2016 15:52:33 -0500 From: "Les Ginsberg (ginsberg)" To: "spring@ietf.org" Thread-Topic: Request for WG adoption of draft-ginsberg-spring-conflict-resolution-01.txt Thread-Index: AdGU/PQNkPlJCZKaR2m1KUOQW4lqYQ== Date: Tue, 12 Apr 2016 20:52:33 +0000 Message-ID: <7b761ae1a3df45f5b26a10f2df9e161e@XCH-ALN-001.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [171.69.35.101] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [spring] Request for WG adoption of draft-ginsberg-spring-conflict-resolution-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 12 Apr 2016 20:52:47 -0000 V0cgY2hhaXJzIC0NCg0KVGhlIGF1dGhvcnMgYXJlIGZvcm1hbGx5IHJlcXVlc3RpbmcgV0cgYWRv cHRpb24gb2YgdGhpcyBkcmFmdC4NCg0KTm90ZSB0aGF0IHdlIGFyZSBub3Qgc3VnZ2VzdGluZyBm dXJ0aGVyIGNoYW5nZXMgdG8gdGhlIGRyYWZ0IG1heSBub3QgYmUgcmVxdWlyZWQgLSBidXQgZ2l2 ZW4gdGhlIGludGVyZXN0IHNob3duIGl0IHNlZW1zIGNsZWFyIHRvIHVzIHRoYXQgdGhlIFdHIGlz IGludGVyZXN0ZWQgaW4gYWRkcmVzc2luZyB0aGlzIHByb2JsZW0gYW5kIHRoYXQgdGhlIGRyYWZ0 IGlzIGhlYWRlZCBpbiB0aGUgcmlnaHQgZGlyZWN0aW9uLg0KVGhhbnguDQoNCiAgICBMZXMNCg0K From nobody Tue Apr 12 15:27:31 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2941812D0CC; Tue, 12 Apr 2016 15:27:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Deborah Brungard" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160412222730.32190.87882.idtracker@ietfa.amsl.com> Date: Tue, 12 Apr 2016 15:27:30 -0700 Archived-At: Cc: pifranco@cisco.com, aretana@cisco.com, draft-ietf-spring-problem-statement@ietf.org, spring-chairs@ietf.org, spring@ietf.org Subject: [spring] Deborah Brungard's Abstain on draft-ietf-spring-problem-statement-08: (with COMMENT) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 22:27:30 -0000 Deborah Brungard has entered the following ballot position for draft-ietf-spring-problem-statement-08: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my Discuss and improving Section 3.3. I still find the various comparisons on using a distributed approach vs. a centralized controller as lacking in accuracy and a poor justification for SPRING. Just say simply you do not want to use a distributed control plane. This is not the first time that IETF had this requirement for one of their data planes. I won't block publication, so my "Abstain" position. From nobody Tue Apr 12 22:13:15 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61F112DC5E for ; Tue, 12 Apr 2016 22:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAkMKCMK6S0P for ; Tue, 12 Apr 2016 22:13:11 -0700 (PDT) Received: from mail-pa0-x242.google.com (mail-pa0-x242.google.com [IPv6:2607:f8b0:400e:c03::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6709B12DC50 for ; Tue, 12 Apr 2016 22:13:11 -0700 (PDT) Received: by mail-pa0-x242.google.com with SMTP id hb4so2961158pac.1 for ; Tue, 12 Apr 2016 22:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to; bh=5l/dPDL525ZKy8Z/FMDjdQ2rT4QhE5qRYcRKQvGOTBQ=; b=tlLlh6s1fD8oc9OBrHz56ZU0RqsHL2+u1d59k5/f2VmZV6DdovBC+9PjGvPfNplsTO Vz2AEr+3ZBRrEDMlkRUUEJJfdjXpJF6r0yZmmmhp+VsPU52vVzXIKkopOvnfxSHKb+hw JKRNrW4/0OUFUvbaczCo5gUGln/U/d7M7VikFVe6shhUI52cRHNZt/wvDGNXk17lt2pe EUvPLHiDQzODqEGSYo9J7uTKgT/Jg8VEa5SOsBafh2XEVtQFuknDglZPW0IF/dVmP9Fa rN3SAnM24p56PHvpl/yRXcofe38CterRI+UWteSxwgUFuX+k8S5vbk/s2b//Ebv/awan 6uNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to; bh=5l/dPDL525ZKy8Z/FMDjdQ2rT4QhE5qRYcRKQvGOTBQ=; b=WQO1ELKBKcvzHNjlQFsYZxbmVTYerT+stmoJq/0cAi7XR86Hp9kSZUDxTkSbP7UlUe YmrPLwQaObe5LK+FNoGoxx2yPLO4PLc+Md+8FE8aOLAqZys17xSSEpTiCT3QRy92Lixg t9OdFeggEGjyO3rcSTxLI3pfo34zNHaIqzSsAqd0T+hjc0cF/hX+fBYHRSwI+C67ERtW 0hZAPb5UYpRSPewjOYNfHWCSBSejuB04tKRPrtamV5E9/99v65TSWVyz6xmGBJ9V/OTW Y510CZLpUtH715DXCILCtOEhh3fdxpCQLUVVY9r3FnRwFhHzIyAqBDcH4Z4LbBOIO+um dbwg== X-Gm-Message-State: AOPr4FWedPeNMpDsZyF8b9nDcGWdvXl60oM6hwMY65KZPjJlElBM+DsBCXFud8kMMVGRMA== X-Received: by 10.66.66.77 with SMTP id d13mr10255628pat.75.1460524391012; Tue, 12 Apr 2016 22:13:11 -0700 (PDT) Received: from [192.168.1.235] ([103.6.157.63]) by smtp.gmail.com with ESMTPSA id x64sm47426495pfa.72.2016.04.12.22.13.09 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Apr 2016 22:13:10 -0700 (PDT) References: <20160412232933.32190.91791.idtracker@ietfa.amsl.com> To: spring@ietf.org From: Pushpasis Sarkar X-Forwarded-Message-Id: <20160412232933.32190.91791.idtracker@ietfa.amsl.com> Message-ID: <570DD564.1030505@gmail.com> Date: Wed, 13 Apr 2016 10:43:08 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160412232933.32190.91791.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------030706090206030908040406" Archived-At: Subject: [spring] Fwd: New Version Notification for draft-psarkar-spring-mpls-anycast-segments-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 13 Apr 2016 05:13:14 -0000 This is a multi-part message in MIME format. --------------030706090206030908040406 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi All, We just posted this with a new version number to avoid expiry. Comments and suggestions are welcome :) Thanks and Regards, -Pushpasis -------- Forwarded Message -------- Subject: New Version Notification for draft-psarkar-spring-mpls-anycast-segments-02.txt Date: Tue, 12 Apr 2016 16:29:33 -0700 From: internet-drafts@ietf.org To: Martin Horneffer , Pushpasis Sarkar , Hannes Gredler , Clarence Filsfils , Bruno Decraene , Stefano Previdi A new version of I-D, draft-psarkar-spring-mpls-anycast-segments-02.txt has been successfully submitted by Hannes Gredler and posted to the IETF repository. Name: draft-psarkar-spring-mpls-anycast-segments Revision: 02 Title: Anycast Segments in MPLS based Segment Routing Document date: 2016-04-13 Group: Individual Submission Pages: 19 URL: https://www.ietf.org/internet-drafts/draft-psarkar-spring-mpls-anycast-segments-02.txt Status: https://datatracker.ietf.org/doc/draft-psarkar-spring-mpls-anycast-segments/ Htmlized: https://tools.ietf.org/html/draft-psarkar-spring-mpls-anycast-segments-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-psarkar-spring-mpls-anycast-segments-02 Abstract: Instead of forwarding to a specific device or to all devices in a group, anycast addresses, let network devices forward a packet to (or steer it through) one or more topologically nearest devices in a specific group of network devices. The use of anycast addresses has been extended to the Segment Routing (SR) network, wherein a group of SR-capable devices can represent a anycast address, by having the same Segment Routing Global Block (SRGB) provisioned on all the devices and each one of them advertising the same anycast prefix segment (or Anycast SID). This document describes a proposal for implementing anycast prefix segments in a MPLS-based SR network, without the need to have the same SRGB block (label ranges) provisioned across all the member devices in the group. Each node can be provisioned with a separate SRGB from the label range supported by the specfic hardware platform. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------030706090206030908040406 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi All,

We just posted this with a new version number to avoid expiry. Comments and suggestions are welcome :)

Thanks and Regards,
-Pushpasis

-------- Forwarded Message --------
Subject: New Version Notification for draft-psarkar-spring-mpls-anycast-segments-02.txt
Date: Tue, 12 Apr 2016 16:29:33 -0700
From: internet-drafts@ietf.org
To: Martin Horneffer <Martin.Horneffer@telekom.de>, Pushpasis Sarkar <pushpasis.ietf@gmail.com>, Hannes Gredler <hannes@gredler.at>, Clarence Filsfils <cfilsfil@cisco.com>, Bruno Decraene <bruno.decraene@orange.com>, Stefano Previdi <sprevidi@cisco.com> 


A new version of I-D, draft-psarkar-spring-mpls-anycast-segments-02.txt
has been successfully submitted by Hannes Gredler and posted to the
IETF repository.

Name:		draft-psarkar-spring-mpls-anycast-segments
Revision:	02
Title:		Anycast Segments in MPLS based Segment Routing
Document date:	2016-04-13
Group:		Individual Submission
Pages:		19
URL:            https://www.ietf.org/internet-drafts/draft-psarkar-spring-mpls-anycast-segments-02.txt
Status:         https://datatracker.ietf.org/doc/draft-psarkar-spring-mpls-anycast-segments/
Htmlized:       https://tools.ietf.org/html/draft-psarkar-spring-mpls-anycast-segments-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-psarkar-spring-mpls-anycast-segments-02

Abstract:
   Instead of forwarding to a specific device or to all devices in a
   group, anycast addresses, let network devices forward a packet to (or
   steer it through) one or more topologically nearest devices in a
   specific group of network devices.  The use of anycast addresses has
   been extended to the Segment Routing (SR) network, wherein a group of
   SR-capable devices can represent a anycast address, by having the
   same Segment Routing Global Block (SRGB) provisioned on all the
   devices and each one of them advertising the same anycast prefix
   segment (or Anycast SID).

   This document describes a proposal for implementing anycast prefix
   segments in a MPLS-based SR network, without the need to have the
   same SRGB block (label ranges) provisioned across all the member
   devices in the group.  Each node can be provisioned with a separate
   SRGB from the label range supported by the specfic hardware platform.


                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--------------030706090206030908040406-- From nobody Wed Apr 13 00:56:56 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7164412E15C; Wed, 13 Apr 2016 00:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBAgWP5JNKIc; Wed, 13 Apr 2016 00:56:54 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B61D12E157; Wed, 13 Apr 2016 00:56:54 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id BB1FE201A8; Wed, 13 Apr 2016 09:56:52 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.72]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 999F11C006B; Wed, 13 Apr 2016 09:56:52 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0279.002; Wed, 13 Apr 2016 09:56:51 +0200 From: To: "spring@ietf.org" , "draft-ginsberg-spring-conflict-resolution@ietf.org" Thread-Topic: draft-ginsberg-spring-conflict-resolution - IPR Call Thread-Index: AdGVWfO+jYDfBBCkSeuvYrRPTUg40g== Date: Wed, 13 Apr 2016 07:56:51 +0000 Message-ID: <17961_1460534212_570DFBC4_17961_1664_1_53C29892C857584299CBF5D05346208A0F86CD00@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [spring] draft-ginsberg-spring-conflict-resolution - IPR Call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 13 Apr 2016 07:56:55 -0000 Working Group, The authors of draft-ginsberg-spring-conflict-resolution believe that the d= ocument is ready to be considered for working adoption. This mail starts the IPR poll. Are you aware of any IPR that applies to draft-ginsberg-spring-conflict-res= olution? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The= response needs to be sent to the SPRING wg mailing list. The document will= not advance to the next stage until a response has been received from each= author and contributor. If you are on the SPRING WG email list but are not listed as an author or c= ontributor, then please explicitly respond only if you are aware of any IPR= that has not yet been disclosed in conformance with IETF rules. Thanks, -- Bruno, John ___________________________________________________________________________= ______________________________________________ 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 Wed Apr 13 07:14:44 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B7512D09F; Wed, 13 Apr 2016 07:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRTU4zZwZSCy; Wed, 13 Apr 2016 07:14:40 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63A2212D0BF; Wed, 13 Apr 2016 07:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2509; q=dns/txt; s=iport; t=1460556880; x=1461766480; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=izuqqySaabn1kKlrSYiT0RymzkUf+VaVvpXcVG0kXaE=; b=ATbgFR/kFYn6r95LxpLP/2uioLdvN2WaJtMX1UuAcKVz8RHct4yMllx6 QUD3sPbEIQRlgl93cEw2RlauHTl0Nf64JymtbSWZAxGVCO3aP0bum1hAv snkF9JmiIIVAiow/jsbLpIn8hf524aRt7z1fJHQ/hJXkpG29fz9IIbqNK g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgACVA5X/5ldJa1egzeBUAa6RgENg?= =?us-ascii?q?XSGDgKBPzgUAQEBAQEBAWUnhEEBAQEEOjQGEQQCAQgRBAEBHwkHMhQJCAEBBAE?= =?us-ascii?q?SCIggwygBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGES4QPEAIBhXMFmAgBjgWBb?= =?us-ascii?q?oROiFuPJgEeAQFCg2dsiHx+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,479,1454976000"; d="scan'208";a="96867642" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Apr 2016 14:14:39 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u3DEEd2R001147 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Apr 2016 14:14:39 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Apr 2016 09:14:38 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Wed, 13 Apr 2016 09:14:38 -0500 From: "Les Ginsberg (ginsberg)" To: "bruno.decraene@orange.com" , "spring@ietf.org" , "draft-ginsberg-spring-conflict-resolution@ietf.org" Thread-Topic: draft-ginsberg-spring-conflict-resolution - IPR Call Thread-Index: AdGVWfO+jYDfBBCkSeuvYrRPTUg40gANL4UQ Date: Wed, 13 Apr 2016 14:14:38 +0000 Message-ID: <30f115b6a5a6417d8b4a9bbc30d7a015@XCH-ALN-001.cisco.com> References: <17961_1460534212_570DFBC4_17961_1664_1_53C29892C857584299CBF5D05346208A0F86CD00@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <17961_1460534212_570DFBC4_17961_1664_1_53C29892C857584299CBF5D05346208A0F86CD00@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.79.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - IPR Call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 13 Apr 2016 14:14:43 -0000 Support (as co-author). I am not aware of any relevant IPR. Les > -----Original Message----- > From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] > Sent: Wednesday, April 13, 2016 12:57 AM > To: spring@ietf.org; draft-ginsberg-spring-conflict-resolution@ietf.org > Subject: draft-ginsberg-spring-conflict-resolution - IPR Call >=20 > Working Group, >=20 > The authors of draft-ginsberg-spring-conflict-resolution believe that the > document is ready to be considered for working adoption. >=20 > This mail starts the IPR poll. >=20 > Are you aware of any IPR that applies to draft-ginsberg-spring-conflict- > resolution? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules (see= RFCs > 3979, 4879, 3669 and 5378 for more details)? >=20 > If you are listed as a document author or contributor please respond to t= his > email regardless of whether or not you are aware of any relevant IPR. The > response needs to be sent to the SPRING wg mailing list. The document wil= l > not advance to the next stage until a response has been received from eac= h > author and contributor. >=20 > If you are on the SPRING WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any = IPR > that has not yet been disclosed in conformance with IETF rules. >=20 > Thanks, > -- Bruno, John >=20 >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. L= es > messages electroniques etant susceptibles d'alteration, Orange decline to= ute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. From nobody Wed Apr 13 07:25:43 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA47412D978; Wed, 13 Apr 2016 07:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0jBdGxCdzU8; Wed, 13 Apr 2016 07:25:39 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 300CD12D972; Wed, 13 Apr 2016 07:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2178; q=dns/txt; s=iport; t=1460557539; x=1461767139; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=ppKThauclwGSlmNaq0iD3cVWZ1Eekuqbzg0frj1F4Gc=; b=lJnXiGGZe17LLc9MOZ6QrzwDGyrwGB6e6OrDItH+/ZpKtiYW5fg5AOKv 4PYqxKuxIhBegp0dT3PFEilq0mO1nPKCDFrbE140+KqasuS55u/MXqotC UBljJBMLZLFUNzxQfnuliaIdX/w4AuMtKzN7edeoPVA1t/fUTu1qqdhoC 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpBADHVQ5X/xbLJq1ehQe8ToYOAoILA?= =?us-ascii?q?QEBAQEBZieEQgEBBDg2BgQRCxgJFg8JAwIBAgFFBgEMBgIBAYgkwyABAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARmGIYRLhA8QAgGFcwEEmAiODYFnhE6DBYVWjydig2k6MIl6A?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.24,479,1454976000"; d="scan'208";a="635165752" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Apr 2016 14:25:36 +0000 Received: from [10.61.205.241] ([10.61.205.241]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3DEPaWl013876; Wed, 13 Apr 2016 14:25:36 GMT Message-ID: <570E56E0.9080007@cisco.com> Date: Wed, 13 Apr 2016 16:25:36 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: bruno.decraene@orange.com, "spring@ietf.org" , "draft-ginsberg-spring-conflict-resolution@ietf.org" References: <17961_1460534212_570DFBC4_17961_1664_1_53C29892C857584299CBF5D05346208A0F86CD00@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <17961_1460534212_570DFBC4_17961_1664_1_53C29892C857584299CBF5D05346208A0F86CD00@OPEXCLILM21.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - IPR Call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 13 Apr 2016 14:25:41 -0000 Hi Bruno, I am not aware of any IPR that applies to this draft. thanks, Peter On 4/13/16 09:56 , bruno.decraene@orange.com wrote: > Working Group, > > The authors of draft-ginsberg-spring-conflict-resolution believe that the document is ready to be considered for working adoption. > > This mail starts the IPR poll. > > Are you aware of any IPR that applies to draft-ginsberg-spring-conflict-resolution? > > If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. The response needs to be sent to the SPRING wg mailing list. The document will not advance to the next stage until a response has been received from each author and contributor. > > If you are on the SPRING WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, > -- Bruno, John > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > . > From nobody Wed Apr 13 07:50:54 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5808E12E320; Wed, 13 Apr 2016 07:50:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160413145053.6079.85364.idtracker@ietfa.amsl.com> Date: Wed, 13 Apr 2016 07:50:53 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-msdc-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 14:50:53 -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 of the IETF. Title : BGP-Prefix Segment in large-scale data centers Authors : Clarence Filsfils Stefano Previdi Jon Mitchell Ebben Aries Petr Lapukhov Filename : draft-ietf-spring-segment-routing-msdc-01.txt Pages : 23 Date : 2016-04-13 Abstract: This document describes the motivation and benefits for applying segment routing in the data-center. It describes the design to deploy segment routing in the data-center, for both the MPLS and IPv6 dataplanes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-msdc/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-msdc-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 13 07:51:57 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4B212E357 for ; Wed, 13 Apr 2016 07:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvZCx633ULq9 for ; Wed, 13 Apr 2016 07:51:52 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0290912E351 for ; Wed, 13 Apr 2016 07:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1387; q=dns/txt; s=iport; t=1460559111; x=1461768711; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=4nLMSIPalJ4nkKWn5itgegjw7AZHnS9aRhbkyNbP5p8=; b=jdiix0yGtJpGjRwr6SAM50tRJNWYn0ifzCJ5WsLzDI2cL6SVDAGJmqRK jsT1cVmVGiuCyY7IT4HlKa6IZKtxdDagSuvQQTROPEDtl+gepXfSrPuVv PXxmIWsulNes+1lSdwdO3Hxo6b4mmAzwF7rBEesM3k9JWESyPmoW6omBI o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgBUXA5X/49dJa1egzdTfQa6RgENg?= =?us-ascii?q?XQkhWoCgT84FAEBAQEBAQFlJ4RBAQEBAwE6PQcLAgEIGB4QMiUCBBOIIAgOwyM?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGBdQiCToQ9gy2CKwWNUIo4AYV2iBaBZ?= =?us-ascii?q?06EAIhbjyYBHgEBQoNnbAGIe34BAQE?= X-IronPort-AV: E=Sophos;i="5.24,479,1454976000"; d="scan'208";a="96013769" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Apr 2016 14:51:51 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u3DEposv001941 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 Apr 2016 14:51:51 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Apr 2016 10:51:49 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Wed, 13 Apr 2016 10:51:49 -0400 From: "Stefano Previdi (sprevidi)" To: SPRING WG Thread-Topic: New Version Notification for draft-ietf-spring-segment-routing-msdc-01.txt Thread-Index: AQHRlZPjTYd3euFxvE6pEaY0fvIpSp+IP+sA Date: Wed, 13 Apr 2016 14:51:49 +0000 Message-ID: <7715642F-79EE-4754-ACCE-A2270BFB6780@cisco.com> References: <20160413145053.6079.97070.idtracker@ietfa.amsl.com> In-Reply-To: <20160413145053.6079.97070.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.205.213] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] New Version Notification for draft-ietf-spring-segment-routing-msdc-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 13 Apr 2016 14:51:54 -0000 just a refresh with updated references. Any comments/feedbakc is welcome. Thanks. s. > On Apr 13, 2016, at 4:50 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-ietf-spring-segment-routing-msdc-01.txt > has been successfully submitted by Stefano Previdi and posted to the > IETF repository. >=20 > Name: draft-ietf-spring-segment-routing-msdc > Revision: 01 > Title: BGP-Prefix Segment in large-scale data centers > Document date: 2016-04-13 > Group: spring > Pages: 23 > URL: https://www.ietf.org/internet-drafts/draft-ietf-spring-se= gment-routing-msdc-01.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-spring-segmen= t-routing-msdc/ > Htmlized: https://tools.ietf.org/html/draft-ietf-spring-segment-rou= ting-msdc-01 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-seg= ment-routing-msdc-01 >=20 > Abstract: > This document describes the motivation and benefits for applying > segment routing in the data-center. It describes the design to > deploy segment routing in the data-center, for both the MPLS and IPv6 > dataplanes. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Wed Apr 13 07:53:14 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15F112E3A7; Wed, 13 Apr 2016 07:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GPqXWdbFQIE; Wed, 13 Apr 2016 07:53:11 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B93B12E351; Wed, 13 Apr 2016 07:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2990; q=dns/txt; s=iport; t=1460559191; x=1461768791; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qlTYlKuRukIu4cbH04+Qw4AO3b8TwmsWAF4qPH8L3Kw=; b=JbTLfLF5NRRoHSLwl8hM8QM4OmUM9QdX9lPZGzLxrQeocuGpZ8Y9KVYv nQN2+cxcWhpM7TlEnNgHnEr5Ll0QRL0U/3cA1jzHWyCEWPFmaqBlDxbDA QJmoKq8JensSwE9jXC3I8zb0+B9q4JhG7R/bffmkfIGJjSmGmYGxQb30b 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgCvXA5X/5hdJa1egzeBUAa6RgENg?= =?us-ascii?q?XSGDgIcgSM4FAEBAQEBAQFlHAuEQQEBAQMBIxE6BgUFCwIBCBgCAiYCAgIwFRA?= =?us-ascii?q?BAQQOBYggCLBnkkkBAQEBAQEBAQEBAQEBAQEBAQEBAQEVfIUlgXUIgk6EDxACA?= =?us-ascii?q?RsYgmorgisFmAgBjgyBZ4ROiFuPJgEeAQFCg2dsiHx+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,480,1454976000"; d="scan'208";a="259453777" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Apr 2016 14:53:10 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3DErAHk027386 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Apr 2016 14:53:10 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Apr 2016 10:53:09 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Wed, 13 Apr 2016 10:53:09 -0400 From: "Stefano Previdi (sprevidi)" To: "bruno.decraene@orange.com" Thread-Topic: draft-ginsberg-spring-conflict-resolution - IPR Call Thread-Index: AdGVWfO+jYDfBBCkSeuvYrRPTUg40gAW8TqA Date: Wed, 13 Apr 2016 14:53:09 +0000 Message-ID: References: <17961_1460534212_570DFBC4_17961_1664_1_53C29892C857584299CBF5D05346208A0F86CD00@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <17961_1460534212_570DFBC4_17961_1664_1_53C29892C857584299CBF5D05346208A0F86CD00@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.205.213] Content-Type: text/plain; charset="utf-8" Content-ID: <3235B20006DF3144AFBD048F02A7057F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "draft-ginsberg-spring-conflict-resolution@ietf.org" Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - IPR Call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 13 Apr 2016 14:53:13 -0000 SeKAmW0gbm90IGF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0byB0aGlzIGRyYWZ0Lg0KDQp0aGFu a3MuDQpzLg0KDQoNCg0KPiBPbiBBcHIgMTMsIDIwMTYsIGF0IDk6NTYgQU0sIGJydW5vLmRlY3Jh ZW5lQG9yYW5nZS5jb20gd3JvdGU6DQo+IA0KPiBXb3JraW5nIEdyb3VwLA0KPiANCj4gVGhlIGF1 dGhvcnMgb2YgZHJhZnQtZ2luc2Jlcmctc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24gYmVsaWV2 ZSB0aGF0IHRoZSBkb2N1bWVudCBpcyByZWFkeSB0byBiZSBjb25zaWRlcmVkIGZvciB3b3JraW5n IGFkb3B0aW9uLg0KPiANCj4gVGhpcyBtYWlsIHN0YXJ0cyB0aGUgSVBSIHBvbGwuDQo+IA0KPiBB cmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LWdpbnNiZXJnLXNw cmluZy1jb25mbGljdC1yZXNvbHV0aW9uPw0KPiANCj4gSWYgc28sIGhhcyB0aGlzIElQUiBiZWVu IGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5 NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscyk/DQo+IA0KPiBJZiB5b3Ug YXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgcmVz cG9uZCB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBh d2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiBUaGUgcmVzcG9uc2UgbmVlZHMgdG8gYmUgc2VudCB0 byB0aGUgU1BSSU5HIHdnIG1haWxpbmcgbGlzdC4gVGhlIGRvY3VtZW50IHdpbGwgbm90IGFkdmFu Y2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBm cm9tIGVhY2ggYXV0aG9yIGFuZCBjb250cmlidXRvci4NCj4gDQo+IElmIHlvdSBhcmUgb24gdGhl IFNQUklORyBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3Ig Y29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBh cmUgYXdhcmUgb2YgYW55IElQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNv bmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy4NCj4gDQo+IFRoYW5rcywNCj4gLS0gQnJ1bm8sIEpv aG4NCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9p bnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91 IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCj4gcGFzIGV0cmUgZGlmZnVzZXMsIGV4 cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNl IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCj4gYSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCj4gT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl cmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPiANCj4gVGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5m b3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCj4gdGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+ IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0K PiBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+IFRo YW5rIHlvdS4NCj4gDQoNCg== From nobody Wed Apr 13 09:29:32 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9A212B017; Wed, 13 Apr 2016 09:29:26 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160413162926.6122.47138.idtracker@ietfa.amsl.com> Date: Wed, 13 Apr 2016 09:29:26 -0700 Archived-At: Cc: spring@ietf.org, spring-chairs@ietf.org, The IESG , pifranco@cisco.com, aretana@cisco.com, draft-ietf-spring-problem-statement@ietf.org, rfc-editor@rfc-editor.org Subject: [spring] Document Action: 'SPRING Problem Statement and Requirements' to Informational RFC (draft-ietf-spring-problem-statement-08.txt) X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 16:29:26 -0000 The IESG has approved the following document: - 'SPRING Problem Statement and Requirements' (draft-ietf-spring-problem-statement-08.txt) as Informational RFC This document is the product of the Source Packet Routing in Networking Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/ Technical Summary This document lists requirements and main use-cases to be considered in the design of architectures aimed at reaching the goals of the SPRING working group. It highlights the importance of supporting both MPLS and IPv6 data-planes. Working Group Summary This document is actually a solution to a controversy at the early days of SPRING, where problem description and solutions were tied in single documents. Once the separation occurred there were no items where the consensus was rough. Document Quality A large number of vendors and operator have supported the adoption of this draft, and are also participating in the development of solutions. Personnel Pierre Francois is the Document Shepherd. Alvaro Retana is the Responsible Area Director. From nobody Wed Apr 13 11:38:33 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4616312D6D0; Wed, 13 Apr 2016 11:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPZg0rnk3DX7; Wed, 13 Apr 2016 11:38:31 -0700 (PDT) Received: from amalka.pantheon.sk (amalka.pantheon.sk [46.229.239.144]) by ietfa.amsl.com (Postfix) with ESMTP id E287212D9D7; Wed, 13 Apr 2016 11:32:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by amalka.pantheon.sk (Postfix) with ESMTP id 4106A281AC; Wed, 13 Apr 2016 20:32:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at pantheon.sk Received: from amalka.pantheon.sk ([127.0.0.1]) by localhost (amalka.pantheon.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNXULLkPoZKf; Wed, 13 Apr 2016 20:32:42 +0200 (CEST) Received: from XMBX3.pantheon.local (fw.pantheon.sk [46.229.239.141]) by amalka.pantheon.sk (Postfix) with ESMTPS; Wed, 13 Apr 2016 20:32:42 +0200 (CEST) Received: from XMBX1.pantheon.local (10.10.4.5) by XMBX3.pantheon.local (10.10.4.8) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 13 Apr 2016 20:32:42 +0200 Received: from XMBX1.pantheon.local ([10.10.4.5]) by XMBX1.pantheon.local ([10.10.4.5]) with mapi id 15.00.1178.000; Wed, 13 Apr 2016 20:32:41 +0200 From: Martin Pilka To: "bruno.decraene@orange.com" , "spring@ietf.org" , "draft-ginsberg-spring-conflict-resolution@ietf.org" Thread-Topic: draft-ginsberg-spring-conflict-resolution - IPR Call Thread-Index: AdGVWfO+jYDfBBCkSeuvYrRPTUg40g== Date: Wed, 13 Apr 2016 18:32:41 +0000 Message-ID: <49983b321bb64677b82368f31013db04@XMBX1.pantheon.local> References: <17961_1460534212_570DFBC4_17961_1664_1_53C29892C857584299CBF5D05346208A0F86CD00@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [91.127.107.51] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - IPR Call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 13 Apr 2016 18:38:32 -0000 SGVsbG8gQnJ1bm8sDQpJIGFtIGFsc28gbm90IGF3YXJlIG9mIGFueSBJUFIgcmVsYXRlZCB0byB0 aGlzIGRyYWZ0Lg0KVGhhbmtzLA0KTWFydGluDQoNCg0KT24gMTMvMDQvMTYgMDk6NTcsIGJydW5v LmRlY3JhZW5lQG9yYW5nZS5jb20gd3JvdGU6DQo+IFdvcmtpbmcgR3JvdXAsDQo+DQo+IFRoZSBh dXRob3JzIG9mIGRyYWZ0LWdpbnNiZXJnLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uIGJlbGll dmUgdGhhdCB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgdG8gYmUgY29uc2lkZXJlZCBmb3Igd29ya2lu ZyBhZG9wdGlvbi4NCj4NCj4gVGhpcyBtYWlsIHN0YXJ0cyB0aGUgSVBSIHBvbGwuDQo+DQo+IEFy ZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtZ2luc2Jlcmctc3By aW5nLWNvbmZsaWN0LXJlc29sdXRpb24/DQo+DQo+IElmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBk aXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5 LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpPw0KPg0KPiBJZiB5b3UgYXJl IGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgcmVzcG9u ZCB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2Fy ZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiBUaGUgcmVzcG9uc2UgbmVlZHMgdG8gYmUgc2VudCB0byB0 aGUgU1BSSU5HIHdnIG1haWxpbmcgbGlzdC4gVGhlIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2Ug dG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9t IGVhY2ggYXV0aG9yIGFuZCBjb250cmlidXRvci4NCj4NCj4gSWYgeW91IGFyZSBvbiB0aGUgU1BS SU5HIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250 cmlidXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBh d2FyZSBvZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9y bWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLg0KPg0KPiBUaGFua3MsDQo+IC0tIEJydW5vLCBKb2huDQo+ DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4NCj4gQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1 dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQo+IHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMg b3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdl IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQo+IGEgbCdleHBlZGl0ZXVyIGV0IGxl IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVj dHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQo+IE9yYW5nZSBkZWNs aW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZv cm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4NCj4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCj4gdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+IElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiBBcyBlbWFp bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0 IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+IFRoYW5rIHlvdS4N Cj4NCj4NCg0KTWFydGluUGlsa2ENCg0KDQpNbHluc2vDqSBOaXZ5IDU2IC8gODIxIDA1IEJyYXRp c2xhdmEgLyBTbG92YWtpYQ0KKzQyMSA5MDggNzY3IDAwOSAvIG1hcnRpbi5waWxrYUBwYW50aGVv bi50ZWNoDQpyZWNlcHRpb246ICs0MjEgMiAyMDYgNjUgMTExIC8gd3d3LnBhbnRoZW9uLnNrDQpb bG9nb10NCg== From nobody Thu Apr 14 00:49:51 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D7912E15F; Thu, 14 Apr 2016 00:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkrDjxRR95V7; Thu, 14 Apr 2016 00:49:46 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B4112DD25; Thu, 14 Apr 2016 00:49:44 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 7BA802C4B01F7; Thu, 14 Apr 2016 07:49:41 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u3E7nfgl007157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Apr 2016 07:49:42 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u3E7nRoE022281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Apr 2016 09:49:40 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.115]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 14 Apr 2016 09:49:34 +0200 From: "Henderickx, Wim (Nokia - BE)" To: EXT Martin Pilka , "bruno.decraene@orange.com" , "spring@ietf.org" , "draft-ginsberg-spring-conflict-resolution@ietf.org" Thread-Topic: [spring] draft-ginsberg-spring-conflict-resolution - IPR Call Thread-Index: AQHRliIvjYDfBBCkSeuvYrRPTUg40g== Date: Thu, 14 Apr 2016 07:49:33 +0000 Message-ID: <816B87CE-3999-49CF-8425-F1A1A2A4E783@alcatel-lucent.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151008 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - IPR Call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 14 Apr 2016 07:49:48 -0000 QXMgcmV2aWV3ZXIgbm90IGF3YXJlIG9uIElQUiByZWxhdGVkIHRvIHRoaXMgZHJhZnQNCg0KDQoN Cg0KT24gMTMvMDQvMTYgMjA6MzIsICJzcHJpbmcgb24gYmVoYWxmIG9mIEVYVCBNYXJ0aW4gUGls a2EiIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbWFydGluLnBpbGthQHBh bnRoZW9uLnRlY2g+IHdyb3RlOg0KDQo+SGVsbG8gQnJ1bm8sDQo+SSBhbSBhbHNvIG5vdCBhd2Fy ZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhpcyBkcmFmdC4NCj5UaGFua3MsDQo+TWFydGluDQo+ DQo+DQo+T24gMTMvMDQvMTYgMDk6NTcsIGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20gd3JvdGU6 DQo+PiBXb3JraW5nIEdyb3VwLA0KPj4NCj4+IFRoZSBhdXRob3JzIG9mIGRyYWZ0LWdpbnNiZXJn LXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uIGJlbGlldmUgdGhhdCB0aGUgZG9jdW1lbnQgaXMg cmVhZHkgdG8gYmUgY29uc2lkZXJlZCBmb3Igd29ya2luZyBhZG9wdGlvbi4NCj4+DQo+PiBUaGlz IG1haWwgc3RhcnRzIHRoZSBJUFIgcG9sbC4NCj4+DQo+PiBBcmUgeW91IGF3YXJlIG9mIGFueSBJ UFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0LWdpbnNiZXJnLXNwcmluZy1jb25mbGljdC1yZXNvbHV0 aW9uPw0KPj4NCj4+IElmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxp YW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1 Mzc4IGZvciBtb3JlIGRldGFpbHMpPw0KPj4NCj4+IElmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9j dW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwg cmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFu dCBJUFIuIFRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBTUFJJTkcgd2cgbWFp bGluZyBsaXN0LiBUaGUgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFn ZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5k IGNvbnRyaWJ1dG9yLg0KPj4NCj4+IElmIHlvdSBhcmUgb24gdGhlIFNQUklORyBXRyBlbWFpbCBs aXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHRoZW4g cGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUgb2YgYW55IElQ UiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdpdGggSUVU RiBydWxlcy4NCj4+DQo+PiBUaGFua3MsDQo+PiAtLSBCcnVubywgSm9obg0KPj4NCj4+DQo+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pg0KPj4gQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBj b250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg ZXQgbmUgZG9pdmVudCBkb25jDQo+PiBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIg ZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KPj4gYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCj4+IE9yYW5nZSBkZWNsaW5l IHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1l IG91IGZhbHNpZmllLiBNZXJjaS4NCj4+DQo+PiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0 aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KPj4gdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+PiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4+IEFzIGVt YWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRo YXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4+IFRoYW5rIHlv dS4NCj4+DQo+Pg0KPg0KPk1hcnRpblBpbGthDQo+DQo+DQo+TWx5bnNrw6kgTml2eSA1NiAvIDgy MSAwNSBCcmF0aXNsYXZhIC8gU2xvdmFraWENCj4rNDIxIDkwOCA3NjcgMDA5IC8gbWFydGluLnBp bGthQHBhbnRoZW9uLnRlY2gNCj5yZWNlcHRpb246ICs0MjEgMiAyMDYgNjUgMTExIC8gd3d3LnBh bnRoZW9uLnNrDQo+W2xvZ29dDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj5zcHJpbmcgbWFpbGluZyBsaXN0DQo+c3ByaW5nQGlldGYub3JnDQo+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg== From nobody Thu Apr 14 00:50:39 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A8912E159 for ; Thu, 14 Apr 2016 00:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-DBeWEW-WPo for ; Thu, 14 Apr 2016 00:50:37 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1450112E13F for ; Thu, 14 Apr 2016 00:50:37 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 55C0A4038D for ; Thu, 14 Apr 2016 09:50:35 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.72]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 394841A0066 for ; Thu, 14 Apr 2016 09:50:35 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0279.002; Thu, 14 Apr 2016 09:50:34 +0200 From: To: "spring@ietf.org" Thread-Topic: draft-ginsberg-spring-conflict-resolution - WG adoption call Thread-Index: AdGWIcRdLnRAPWN3Qn6eVontUw9C0A== Date: Thu, 14 Apr 2016 07:50:34 +0000 Message-ID: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 14 Apr 2016 07:50:38 -0000 Dear WG, As we discussed at our meeting last week, working group adoption has been r= equested for draft-ginsberg-spring-conflict-resolution. Please reply to the list with your comments, including although not limited= to whether or not you support adoption. Thanks, --John and Bruno ___________________________________________________________________________= ______________________________________________ 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 Apr 14 00:55:12 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5D812E28B for ; Thu, 14 Apr 2016 00:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toet75jffdwZ for ; Thu, 14 Apr 2016 00:55:09 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 506C412E29B for ; Thu, 14 Apr 2016 00:55:09 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 22DA7403EA for ; Thu, 14 Apr 2016 09:55:08 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 0677E1A0071 for ; Thu, 14 Apr 2016 09:55:08 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0279.002; Thu, 14 Apr 2016 09:55:07 +0200 From: To: "spring@ietf.org" Thread-Topic: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call Thread-Index: AdGWIcRdLnRAPWN3Qn6eVontUw9C0AAAMhXQ Date: Thu, 14 Apr 2016 07:55:07 +0000 Message-ID: <10411_1460620508_570F4CDC_10411_96_23_53C29892C857584299CBF5D05346208A0F86E45F@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 14 Apr 2016 07:55:11 -0000 > From: bruno.decraene@orange.com > Sent: Thursday, April 14, 2016 9:51 AM >=20 > Dear WG, >=20 > As we discussed at our meeting last week, working group adoption has been > requested for draft-ginsberg-spring-conflict-resolution. > Please reply to the list with your comments, including although not limit= ed to > whether or not you support adoption. We will end the call on April 29, 2016. =20 > Thanks, >=20 > --John and Bruno >=20 >=20 >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. L= es > messages electroniques etant susceptibles d'alteration, Orange decline to= ute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > 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. >=20 > _______________________________________________ > 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 Apr 14 01:48:40 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C0112DFD8 for ; Thu, 14 Apr 2016 01:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaCKQQpvkVUh for ; Thu, 14 Apr 2016 01:48:37 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2DAA12D973 for ; Thu, 14 Apr 2016 01:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1673; q=dns/txt; s=iport; t=1460623716; x=1461833316; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+XORzqucXcQYvVNMicDoKN4bX9q5S0wZLH+tzQmEbdI=; b=fAcu4mH13ziHDHseRvtKmdPX1RjxQncGJ/FPJzqQoE++62qaZ7Dqfgwl fr2oYaFkGtWjSqzcjuOesaOozV8CbbnsMnXhH9VIqwiPF2AyBLA1bhS/A ry9qa1ROItZ8GaBHc+5YwRMJ51HBLxsDjahzNuQKLU9/52pMJLe0zRgHB 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgBkWA9X/4oNJK1egzhTfQa6KgENg?= =?us-ascii?q?XEXC4UiSgKBNTgUAQEBAQEBAWUcC4RBAQEBAwEBAQE3NAsFCwIBCBgeECcLJQE?= =?us-ascii?q?BBA4FiCEIDsJCAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGIYF1glaEDwoHARyDL?= =?us-ascii?q?YIrBZgLAY4MgWeETohbjygBHgEBQoNnbIg9CRcffgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,484,1454976000"; d="scan'208";a="97028644" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Apr 2016 08:48:35 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u3E8mZns028398 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 08:48:36 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 04:48:35 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Thu, 14 Apr 2016 04:48:34 -0400 From: "Stefano Previdi (sprevidi)" To: "bruno.decraene@orange.com" Thread-Topic: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call Thread-Index: AdGWIcRdLnRAPWN3Qn6eVontUw9C0AAKi78A Date: Thu, 14 Apr 2016 08:48:34 +0000 Message-ID: References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.70.63] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 14 Apr 2016 08:48:38 -0000 as co-author, I support the WG adoption of this draft s. > On Apr 14, 2016, at 9:50 AM, bruno.decraene@orange.com wrote: >=20 > Dear WG, >=20 > As we discussed at our meeting last week, working group adoption has been= requested for draft-ginsberg-spring-conflict-resolution. > Please reply to the list with your comments, including although not limit= ed to whether or not you support adoption. >=20 > Thanks, >=20 > --John and Bruno >=20 >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Thu Apr 14 01:59:09 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE8112DAC6 for ; Thu, 14 Apr 2016 01:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzZRlW55jPWK for ; Thu, 14 Apr 2016 01:59:06 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5380612E2B9 for ; Thu, 14 Apr 2016 01:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1600; q=dns/txt; s=iport; t=1460624345; x=1461833945; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=GIRg/7bzvYeU9MU1ZmQf/bXGhwwNJlF/EfJ1eojc0Fk=; b=WcA0X5PmTTkphR4xQ8xDKRrJT+nzLujBSOiALm1lCHCiIZQX8jywuTgf P9W1XofDbzTU+jPj+YINrbrmM6uMAD3hG9RDfMTo+3Zya/8tVY0AYgFVE xLjpCbYYjRlRggQtPQfbvYtBm+vBBAjEfFDyAH1LPLIKubi9MYFWLI9Do M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAgB3Ww9X/xbLJq1ehAsDerowAQ2Bc?= =?us-ascii?q?RcLhSJKAoFtFAEBAQEBAQFlJ4RCAQEEAQEBNTYKEQsYCRYPCQMCAQIBFTAGAQw?= =?us-ascii?q?GAgEBiCUOwjkBAQEBAQEBAQEBAQEBAQEBAQEBEwSGIYRLhA8KBwGFdAEEmAuOD?= =?us-ascii?q?YFnhE6DBYVWjykeAQFCg2k6MIg9CReBHQEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,484,1454976000"; d="scan'208";a="676743198" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2016 08:58:42 +0000 Received: from [10.61.207.131] ([10.61.207.131]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3E8wdcr018217; Thu, 14 Apr 2016 08:58:41 GMT Message-ID: <570F5BBD.9030205@cisco.com> Date: Thu, 14 Apr 2016 10:58:37 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: bruno.decraene@orange.com, "spring@ietf.org" References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 14 Apr 2016 08:59:08 -0000 Support the WG adoption as co-author. thanks, Peter On 4/14/16 09:50 , bruno.decraene@orange.com wrote: > Dear WG, > > As we discussed at our meeting last week, working group adoption has been requested for draft-ginsberg-spring-conflict-resolution. > Please reply to the list with your comments, including although not limited to whether or not you support adoption. > > Thanks, > > --John and Bruno > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > . > From nobody Thu Apr 14 04:02:44 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40C412E35A for ; Thu, 14 Apr 2016 04:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3YmD9xzkxVD for ; Thu, 14 Apr 2016 04:02:41 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 677CD12E354 for ; Thu, 14 Apr 2016 04:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2452; q=dns/txt; s=iport; t=1460631761; x=1461841361; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=fAnm2s1aiwgGoMGcz5ReKO4xEzKhgx692RXDQR9anjM=; b=b3l7GUU3SApljLpcPQ6NIATT42dxZdSUZkXndvXch3/yxho20SGQOQIg q2Az/Xzs6BcopQ5WNv0jicNZYLKpxwHUHJvzQ8bhy35PjHaOT6x9N8Wji WQQKna47JA/Wpn3868ID+nA9jV7IAAdje3/FoL/5xFMLe7r1zkxVKmoQz I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgBHeA9X/5FdJa1egzhTfQa6KQENg?= =?us-ascii?q?XEXC4UiSgIcgRg4FAEBAQEBAQFlJ4RCAQEEAQEBIBE6GwIBCBoCJgICAiULFRA?= =?us-ascii?q?CBAESiCkOr2iSPwEBAQEBAQEBAQEBAQEBAQEBAQEBEgR8iXCEDwoHAYMeglYFm?= =?us-ascii?q?AsBjgyBZ4ROiFuPKAEeAQFCggQZgUpsiD0JFx9+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,484,1454976000"; d="scan'208";a="93655526" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2016 11:02:40 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u3EB2eTj020402 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 11:02:40 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 07:02:39 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Thu, 14 Apr 2016 07:02:39 -0400 From: "Acee Lindem (acee)" To: "spring@ietf.org" , Bruno Decraene Thread-Topic: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call Thread-Index: AQHRlj0oFGz6l+6VmUS3NUWQ2tt0ig== Date: Thu, 14 Apr 2016 11:02:39 +0000 Message-ID: References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.202] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 14 Apr 2016 11:02:42 -0000 SSBzdXBwb3J0IFdHIGFkb3B0aW9uLiBUaGUgY29uZmxpY3QgcmVzb2x1dGlvbiBkb2N1bWVudCBp cyByZXF1aXJlZCBmb3INCnN0YW5kYXJkIFNJRCBjb25mbGljdCBlcnJvciBoYW5kbGluZyBhY3Jv c3MgYWxsIHByb3RvY29scyBhbmQgdmVuZG9ycy4NClRoYW5rcywNCkFjZWUNCg0KT24gNC8xNC8x NiwgMzo1MCBBTSwgInNwcmluZyBvbiBiZWhhbGYgb2YgYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNv bSINCjxzcHJpbmctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYnJ1bm8uZGVjcmFlbmVA b3JhbmdlLmNvbT4gd3JvdGU6DQoNCj5EZWFyIFdHLA0KPg0KPkFzIHdlIGRpc2N1c3NlZCBhdCBv dXIgbWVldGluZyBsYXN0IHdlZWssIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gaGFzIGJlZW4NCj5y ZXF1ZXN0ZWQgZm9yIGRyYWZ0LWdpbnNiZXJnLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uLg0K PlBsZWFzZSByZXBseSB0byB0aGUgbGlzdCB3aXRoIHlvdXIgY29tbWVudHMsIGluY2x1ZGluZyBh bHRob3VnaCBub3QNCj5saW1pdGVkIHRvIHdoZXRoZXIgb3Igbm90IHlvdSBzdXBwb3J0IGFkb3B0 aW9uLg0KPg0KPlRoYW5rcywNCj4NCj4tLUpvaG4gYW5kIEJydW5vDQo+DQo+DQo+DQo+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPg0KPkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVu aXIgZGVzIGluZm9ybWF0aW9ucw0KPmNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg bmUgZG9pdmVudCBkb25jDQo+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMg c2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleg0KPnJlY3UgY2UgbWVzc2FnZSBwYXIgZXJy ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJl IGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcw0KPmVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCj5PcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZQ0KPm91 IGZhbHNpZmllLiBNZXJjaS4NCj4NCj5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZA0KPmluZm9ybWF0aW9uIHRoYXQg bWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQo+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+SWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZA0K PmRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj5BcyBlbWFpbHMgbWF5 IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUN Cj5iZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj5UaGFuayB5b3UuDQo+DQo+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zcHJpbmcg bWFpbGluZyBsaXN0DQo+c3ByaW5nQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zcHJpbmcNCg0K From nobody Thu Apr 14 08:22:15 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1632012E49D; Thu, 14 Apr 2016 08:22:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160414152211.6872.11971.idtracker@ietfa.amsl.com> Date: Thu, 14 Apr 2016 08:22:11 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-ldp-interop-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 15:22:11 -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 of the IETF. Title : Segment Routing interworking with LDP Authors : Clarence Filsfils Stefano Previdi Ahmed Bashandy Bruno Decraene Stephane Litkowski Filename : draft-ietf-spring-segment-routing-ldp-interop-01.txt Pages : 16 Date : 2016-04-14 Abstract: A Segment Routing (SR) node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SR domain. The Segment Routing architecture can be directly applied to the MPLS data plane with no change in the forwarding plane. This drafts describes how Segment Routing operates in a network where LDP is deployed and in the case where SR-capable and non-SR-capable nodes coexist. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-ldp-interop-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 14 08:24:57 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A849212DCCB for ; Thu, 14 Apr 2016 08:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcfOpylamsvs for ; Thu, 14 Apr 2016 08:24:54 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2A712D85D for ; Thu, 14 Apr 2016 08:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3650; q=dns/txt; s=iport; t=1460647493; x=1461857093; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ORuyMOBDT9JjVc0dmhDEIhZXfF0MSAgHg1a5zFBPGhs=; b=BrOIniAYptaRSpK8Orba/8EyM3DHz/3RzQ22ZBQz4aFXPXEHXUSky3Nh M9GoNfVL9BZV0vH3zeX6Ph0dWFXGBPdc+m2xTEXUsYAflfEXNrsyTHRua pFAFXIAub0NvHDfAgQ3PercZZM5SMsjWoP0xYjaJqwlRo/NcOpwW+Lq9m k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BpAgD4tA9X/49dJa1egzhTfQa6KQENg?= =?us-ascii?q?XEXDYVqAhyBHTgUAQEBAQEBAWUnhEEBAQEDAQEBASAROhALAgEIEgYCAiYCAgI?= =?us-ascii?q?lCxUCDgIEEwmIGAgOsB+SMwEBAQEBAQEBAQEBAQEBAQEBAQEBARV8hSWBdYJWh?= =?us-ascii?q?z8rgisFmAsBhXaIFoFnToQAiFuGIYE/h0gBHgEBQoNnbAGIR34BAQE?= X-IronPort-AV: E=Sophos;i="5.24,485,1454976000"; d="scan'208";a="91473789" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2016 15:24:52 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u3EFOotS026806 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 14 Apr 2016 15:24:52 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 11:24:51 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Thu, 14 Apr 2016 11:24:50 -0400 From: "Stefano Previdi (sprevidi)" To: SPRING WG Thread-Topic: I-D Action: draft-ietf-spring-segment-routing-ldp-interop-01.txt Thread-Index: AQHRlmFw3dysD8GVtEK+5yEnSfwhcJ+J2dsA Date: Thu, 14 Apr 2016 15:24:50 +0000 Message-ID: <0F5DF910-DD3E-4AEF-8CC3-4F12739A02E3@cisco.com> References: <20160414152211.6872.11971.idtracker@ietfa.amsl.com> In-Reply-To: <20160414152211.6872.11971.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.70.63] Content-Type: text/plain; charset="utf-8" Content-ID: <8264D8BE8B042F4DACD4807D2EB237DE@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-ldp-interop-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 14 Apr 2016 15:24:55 -0000 dGhpcyBpcyB0aGUgbGF0ZXN0IHVwZGF0ZSBvZiB0aGUgbGRwLWludGVyb3AgZHJhZnQgYWZ0ZXIg dmFyaW91cyBjb21tZW50cyBhbW9uZyB3aGljaCB0aGUgb25lcyBmcm9tIEFsZXggKHNvcnJ5IGZy b20gYmVpbmcgc28gbGF0ZSkuDQoNCkkgaG9wZSBpdCBhZGRyZXNzIG1vc3Qgb2YgdGhlIGNvbW1l bnRzLCBrbm93aW5nIHRoYXQgdGhlIGF1dGhvcnMgYXJlIHN0aWxsIHdvcmtpbmcgb24gdGhlIG1h bmFnZWFiaWxpdHkgc2VjdGlvbiAoSSBqdXN0IGRpZG7igJl0IHdhbnQgdG8gbGV0IHRoZSBkcmFm dCBleHBpcmUpLg0KDQpUaGFua3MuDQpzLg0KDQoNCj4gT24gQXByIDE0LCAyMDE2LCBhdCA1OjIy IFBNLCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgd3JvdGU6DQo+IA0KPiANCj4gQSBOZXcgSW50 ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRz IGRpcmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBTb3VyY2Ug UGFja2V0IFJvdXRpbmcgaW4gTmV0d29ya2luZyBvZiB0aGUgSUVURi4NCj4gDQo+ICAgICAgICBU aXRsZSAgICAgICAgICAgOiBTZWdtZW50IFJvdXRpbmcgaW50ZXJ3b3JraW5nIHdpdGggTERQDQo+ ICAgICAgICBBdXRob3JzICAgICAgICAgOiBDbGFyZW5jZSBGaWxzZmlscw0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgU3RlZmFubyBQcmV2aWRpDQo+ICAgICAgICAgICAgICAgICAgICAgICAg ICBBaG1lZCBCYXNoYW5keQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgQnJ1bm8gRGVjcmFl bmUNCj4gICAgICAgICAgICAgICAgICAgICAgICAgIFN0ZXBoYW5lIExpdGtvd3NraQ0KPiAJRmls ZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLWxkcC1pbnRl cm9wLTAxLnR4dA0KPiAJUGFnZXMgICAgICAgICAgIDogMTYNCj4gCURhdGUgICAgICAgICAgICA6 IDIwMTYtMDQtMTQNCj4gDQo+IEFic3RyYWN0Og0KPiAgIEEgU2VnbWVudCBSb3V0aW5nIChTUikg bm9kZSBzdGVlcnMgYSBwYWNrZXQgdGhyb3VnaCBhIGNvbnRyb2xsZWQgc2V0DQo+ICAgb2YgaW5z dHJ1Y3Rpb25zLCBjYWxsZWQgc2VnbWVudHMsIGJ5IHByZXBlbmRpbmcgdGhlIHBhY2tldCB3aXRo IGFuIFNSDQo+ICAgaGVhZGVyLiAgQSBzZWdtZW50IGNhbiByZXByZXNlbnQgYW55IGluc3RydWN0 aW9uLCB0b3BvbG9naWNhbCBvcg0KPiAgIHNlcnZpY2UtYmFzZWQuICBTUiBhbGxvd3MgdG8gZW5m b3JjZSBhIGZsb3cgdGhyb3VnaCBhbnkgdG9wb2xvZ2ljYWwNCj4gICBwYXRoIGFuZCBzZXJ2aWNl IGNoYWluIHdoaWxlIG1haW50YWluaW5nIHBlci1mbG93IHN0YXRlIG9ubHkgYXQgdGhlDQo+ICAg aW5ncmVzcyBub2RlIHRvIHRoZSBTUiBkb21haW4uDQo+IA0KPiAgIFRoZSBTZWdtZW50IFJvdXRp bmcgYXJjaGl0ZWN0dXJlIGNhbiBiZSBkaXJlY3RseSBhcHBsaWVkIHRvIHRoZSBNUExTDQo+ICAg ZGF0YSBwbGFuZSB3aXRoIG5vIGNoYW5nZSBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZS4gIFRoaXMg ZHJhZnRzDQo+ICAgZGVzY3JpYmVzIGhvdyBTZWdtZW50IFJvdXRpbmcgb3BlcmF0ZXMgaW4gYSBu ZXR3b3JrIHdoZXJlIExEUCBpcw0KPiAgIGRlcGxveWVkIGFuZCBpbiB0aGUgY2FzZSB3aGVyZSBT Ui1jYXBhYmxlIGFuZCBub24tU1ItY2FwYWJsZSBub2Rlcw0KPiAgIGNvZXhpc3QuDQo+IA0KPiAN Cj4gDQo+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlz Og0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNwcmluZy1z ZWdtZW50LXJvdXRpbmctbGRwLWludGVyb3AvDQo+IA0KPiBUaGVyZSdzIGFsc28gYSBodG1saXpl ZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1sZHAtaW50ZXJvcC0wMQ0KPiANCj4gQSBk aWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0 aW5nLWxkcC1pbnRlcm9wLTAxDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9u eW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSS1E LUFubm91bmNlIG1haWxpbmcgbGlzdA0KPiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4gSW50ZXJuZXQt RHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCj4gb3Ig ZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCg0K From nobody Thu Apr 14 08:40:00 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEE712D5AB for ; Thu, 14 Apr 2016 08:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAVkfkPt2_Ie for ; Thu, 14 Apr 2016 08:39:57 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7176012D530 for ; Thu, 14 Apr 2016 08:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3282; q=dns/txt; s=iport; t=1460648397; x=1461857997; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=uShAtL7vfvuiaouGODbIVxOK0nyEk+3MYEQ+3IztF1M=; b=dWu+L7cS1n9OK4OoEU7m+JUuIYaeOWcqOs0kPIjiSn9o8I00nKVCrR2G c/RZ8QwYoeUFqrAgDltmKxvQud6XJlbtfDgFvFSSKbVtoPD8+uqcPlYUY 4XFm9rgJ8oVMfTihlgLRJ+52SMNH6XLjxmhRPItwx+Pts4aG0p/p+/YYD I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BpAgAzuQ9X/4kNJK1egzhTfQa6KQENg?= =?us-ascii?q?XEXC4UiSgKBOTgUAQEBAQEBAWUnhEEBAQEEAQEBNzQXBAIBCBEEAQEfCQcnCxQ?= =?us-ascii?q?JCAEBBAESCIghDsJfAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGIYRLhA8KBwGFd?= =?us-ascii?q?AWYCwGOBYFuhE6IW48oAR4BAUKDZ2yICQkXH34BAQE?= X-IronPort-AV: E=Sophos;i="5.24,485,1454976000"; d="scan'208";a="259963331" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Apr 2016 15:39:56 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u3EFduwf012531 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 15:39:56 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Apr 2016 10:39:55 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Thu, 14 Apr 2016 10:39:55 -0500 From: "Les Ginsberg (ginsberg)" To: "bruno.decraene@orange.com" , "spring@ietf.org" Thread-Topic: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call Thread-Index: AdGWIcRdLnRAPWN3Qn6eVontUw9C0AAAMhXQABBUb1A= Date: Thu, 14 Apr 2016 15:39:55 +0000 Message-ID: <94d2d9a233b04c888834de63ff186b26@XCH-ALN-001.cisco.com> References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10411_1460620508_570F4CDC_10411_96_23_53C29892C857584299CBF5D05346208A0F86E45F@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <10411_1460620508_570F4CDC_10411_96_23_53C29892C857584299CBF5D05346208A0F86E45F@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.79.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 14 Apr 2016 15:39:59 -0000 Support as co-author. Les > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of > bruno.decraene@orange.com > Sent: Thursday, April 14, 2016 12:55 AM > To: spring@ietf.org > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adop= tion > call >=20 > > From: bruno.decraene@orange.com > Sent: Thursday, April 14, 2016 9:51 > > AM > > > > Dear WG, > > > > As we discussed at our meeting last week, working group adoption has > > been requested for draft-ginsberg-spring-conflict-resolution. > > Please reply to the list with your comments, including although not > > limited to whether or not you support adoption. >=20 > We will end the call on April 29, 2016. >=20 >=20 > > Thanks, > > > > --John and Bruno > > > > > > > > > __________________________________________________________ > > > __________________________________________________________ > > _____ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > > que les pieces jointes. Les messages electroniques etant susceptibles > > d'alteration, Orange decline toute responsabilite si ce message a ete a= ltere, > deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not > > be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have > > been modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. L= es > messages electroniques etant susceptibles d'alteration, Orange decline to= ute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Thu Apr 14 09:09:32 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCD012D5D4 for ; Thu, 14 Apr 2016 09:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qF8AY0yKzQl for ; Thu, 14 Apr 2016 09:09:28 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FB2612B03A for ; Thu, 14 Apr 2016 09:09:28 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id p188so97968367oih.2 for ; Thu, 14 Apr 2016 09:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8QrpVn38WOW7WF8odZfLuDPWvwjfc/M5r3AC9miYb1I=; b=fdj4FOqvbigJ6n7AaFt540lTYHU1EBWf8QjydcThOF1m0o/B2RiBXr/rfQaqHn03n0 yuQQK7772UV3Jev0H9LsPMDkrJKFAWXwfhqZLmEzUKNLjL2sizSOsHP4g9H/CXY+xBhr vijmjvQRkA0ZiMeM9PPhIJNGfoho2/avcdaWtLT45+KNrA13Q654tIBqNuOra7wSQT/c NcOEQPcRAFkr4dTd3pFYk2jKyUxtbYJYYCqCK+a2kA0GreMqxS4I7j3haw9aSJYHA6F8 mOFY8knDCeDPwUWL9HXfUJPap4xpcYpP8IveW5QruJS/nU8sqo4CpdtpEsljpvBQIUgg 9aWA== 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:from:date :message-id:subject:to:cc; bh=8QrpVn38WOW7WF8odZfLuDPWvwjfc/M5r3AC9miYb1I=; b=AGeI9ImuwEsEg+eLZGSOdtkpRh/K4Sy1WaRuGGVS69mL9rJ0HfVN9rKaLetk9e8b3o 4WuJiZ+mglEvYMIsgr9hDXKWgKukyJDqf8xGJBrROQPpzY4ZBMtWYSTqxuplkhjR3CEm vGMdsmsNFC863LMa8Kgv1kmSl9dDAl3EEfmdWgEjPoze5JZwwPvR+/aB/xi6MiwamZtH DDfNIhyMyoO02vk8JZiZ9+B1pYcQe/XEKCm/pMXOYduIP5GHHBcJEclkBSj/ZPH1XfTK cnSOUxs0uZMQvsWcwPUjGfFsNwMXqNWaNUPlucW8UyvnF/EekO2fyytImlXHx5D2w5nq pRaQ== X-Gm-Message-State: AOPr4FVyiiAUoYLSdi05oa+RPsshocLvDn5jq7xTVnUKnHmyQl46b5/csI88E458KEXKQyAgdBQj1gXxbh240w== X-Received: by 10.202.80.205 with SMTP id e196mr8025028oib.126.1460650167695; Thu, 14 Apr 2016 09:09:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.242.35 with HTTP; Thu, 14 Apr 2016 09:09:08 -0700 (PDT) In-Reply-To: <0F5DF910-DD3E-4AEF-8CC3-4F12739A02E3@cisco.com> References: <20160414152211.6872.11971.idtracker@ietfa.amsl.com> <0F5DF910-DD3E-4AEF-8CC3-4F12739A02E3@cisco.com> From: "Andrew G. Malis" Date: Thu, 14 Apr 2016 12:09:08 -0400 Message-ID: To: "Stefano Previdi (sprevidi)" Content-Type: multipart/alternative; boundary=001a113d7a8c62fe5a0530741ead Archived-At: Cc: SPRING WG Subject: Re: [spring] I-D Action: draft-ietf-spring-segment-routing-ldp-interop-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 14 Apr 2016 16:09:31 -0000 --001a113d7a8c62fe5a0530741ead Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stefano, Before this draft concludes in the SPRING WG, you may wish to ask the MPLS and PALS WGs for a review, since LDP (inter)operation directly affects them, and they have considerable experience with LDP. Thanks, Andy On Thu, Apr 14, 2016 at 11:24 AM, Stefano Previdi (sprevidi) < sprevidi@cisco.com> wrote: > this is the latest update of the ldp-interop draft after various comments > among which the ones from Alex (sorry from being so late). > > I hope it address most of the comments, knowing that the authors are stil= l > working on the manageability section (I just didn=E2=80=99t want to let t= he draft > expire). > > Thanks. > s. > > > > On Apr 14, 2016, at 5:22 PM, internet-drafts@ietf.org wrote: > > > > > > 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 of > the IETF. > > > > Title : Segment Routing interworking with LDP > > Authors : Clarence Filsfils > > Stefano Previdi > > Ahmed Bashandy > > Bruno Decraene > > Stephane Litkowski > > Filename : > draft-ietf-spring-segment-routing-ldp-interop-01.txt > > Pages : 16 > > Date : 2016-04-14 > > > > Abstract: > > A Segment Routing (SR) node steers a packet through a controlled set > > of instructions, called segments, by prepending the packet with an SR > > header. A segment can represent any instruction, topological or > > service-based. SR allows to enforce a flow through any topological > > path and service chain while maintaining per-flow state only at the > > ingress node to the SR domain. > > > > The Segment Routing architecture can be directly applied to the MPLS > > data plane with no change in the forwarding plane. This drafts > > describes how Segment Routing operates in a network where LDP is > > deployed and in the case where SR-capable and non-SR-capable nodes > > coexist. > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-in= terop/ > > > > There's also a htmlized version available at: > > > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop= -01 > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-segment-routing-ldp= -interop-01 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --001a113d7a8c62fe5a0530741ead Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stefano,

Before this draft concludes in= the SPRING WG, you may wish to ask the MPLS and PALS WGs for a review, sin= ce LDP (inter)operation directly affects them, and they have considerable e= xperience with LDP.

Thanks,
Andy


On Thu, Apr 14, 2016 at 11:24 AM, Stefano Previdi (sprevidi) <sprevidi@= cisco.com> wrote:
this is = the latest update of the ldp-interop draft after various comments among whi= ch the ones from Alex (sorry from being so late).

I hope it address most of the comments, knowing that the authors are still = working on the manageability section (I just didn=E2=80=99t want to let the= draft expire).

Thanks.
s.


> On Apr 14, 2016, at 5:22 PM, internet-drafts@ietf.org wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Source Packet Routing in Networking o= f the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Segment Routing interworking with LDP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Clarence Filsfils
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Stefano Previdi
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Ahmed Bashandy
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Bruno Decraene
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Stephane Litkowski
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-spring-segment-routing-ldp-interop-01.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 16
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2016-04-14
>
> Abstract:
>=C2=A0 =C2=A0A Segment Routing (SR) node steers a packet through a cont= rolled set
>=C2=A0 =C2=A0of instructions, called segments, by prepending the packet= with an SR
>=C2=A0 =C2=A0header.=C2=A0 A segment can represent any instruction, top= ological or
>=C2=A0 =C2=A0service-based.=C2=A0 SR allows to enforce a flow through a= ny topological
>=C2=A0 =C2=A0path and service chain while maintaining per-flow state on= ly at the
>=C2=A0 =C2=A0ingress node to the SR domain.
>
>=C2=A0 =C2=A0The Segment Routing architecture can be directly applied t= o the MPLS
>=C2=A0 =C2=A0data plane with no change in the forwarding plane.=C2=A0 T= his drafts
>=C2=A0 =C2=A0describes how Segment Routing operates in a network where = LDP is
>=C2=A0 =C2=A0deployed and in the case where SR-capable and non-SR-capab= le nodes
>=C2=A0 =C2=A0coexist.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatrac= ker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/
>
> There's also a htmlized version available at:
> https://tools.ietf.= org/html/draft-ietf-spring-segment-routing-ldp-interop-01
>
> A diff from the previous version is available at:
> https://www= .ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-segment-routing-ldp-interop-01
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-ann= ounce
> Internet-Draft directories: http://www.ietf.org/shadow.html<= br> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

--001a113d7a8c62fe5a0530741ead-- From nobody Thu Apr 14 11:25:10 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06A312D19F for ; Thu, 14 Apr 2016 11:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QKSIyIDEM_K for ; Thu, 14 Apr 2016 11:25:07 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88FC112D92A for ; Thu, 14 Apr 2016 11:25:05 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id n1so48376437pfn.2 for ; Thu, 14 Apr 2016 11:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=ROJu/kmrzwUtvwIsdFjfQCuNpy26j435KIizIVF2jdQ=; b=IwloKp+SFQQL0Kp94CLe7tTEIB3vORQERIjN8LkggQeC2RyP9QymkjFigtTO5fwBP6 LseF4T/4XrW6mVkLJp9k3vvHq2NRq6kXPYHpBdmrdcGDlcvhWAR0Nvxz/VqT3HSNwJpR fh6VUD8b9falYwV64uKC00cBaGarz3sqAZdyzic7kb2Gislo8j5RGNXZWADwZAj4WodN PDtWEjNj/MMG+oYRmQ2NWlkaqckwTOTU7nAExfBkXxGP393CLfrO8jBQ4e1h/epBuIJp Z3ZsUSNDgEAP5f/cTK7lbuUO613UywSshE71Gvdqc54EhIsdc4WvbEREu/KbLVlC5ZTV GR3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=ROJu/kmrzwUtvwIsdFjfQCuNpy26j435KIizIVF2jdQ=; b=HoWtD0O6lRm/Hmw0X9nR7xyoYs4JArfBz2ZEy9sT6AGDD7IOe5ZTB2WLDwbZqgrmFa nQW/T0CV667gKT9hQZhd5R5oHcDuzx3+CB6EAPu3Q0vNgShKQeudc+v5CtUXyRkNEe6i 1Tb98Bzmvae6pe3BIKyYJJEGM3XdLwVZwVOJH1eMlmLuLYK4TahxaWAcI1Be5SUewHmv YgUhazx0Myj+pv2nc/pbxOv3O8cuYyFwJykMCVZP6fFaD56fRXE9LoCq8UwYeJvTLT8j FZrrpVT2P35VNVZNNj626yvX3W8w/rmroHTUbPlTXDjAiNI7Zi6svyc1upuqj1z+dZtd SFKg== X-Gm-Message-State: AOPr4FWrHrPxOAsrj97o775XmfmkrkuwEMOkMkCd7rBdUgxj66aPDa6qe9qlnlZ4u/wXoQ== X-Received: by 10.98.80.150 with SMTP id g22mr23204239pfj.132.1460658305086; Thu, 14 Apr 2016 11:25:05 -0700 (PDT) Received: from [192.168.1.21] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id p74sm59449255pfj.22.2016.04.14.11.25.04 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2016 11:25:04 -0700 (PDT) User-Agent: Microsoft-MacOutlook/0.0.0.160212 Date: Thu, 14 Apr 2016 11:25:03 -0700 From: Jeff Tantsura To: "bruno.decraene@orange.com" , "spring@ietf.org" Message-ID: Thread-Topic: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10411_1460620508_570F4CDC_10411_96_23_53C29892C857584299CBF5D05346208A0F86E45F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <94d2d9a233b04c888834de63ff186b26@XCH-ALN-001.cisco.com> In-Reply-To: <94d2d9a233b04c888834de63ff186b26@XCH-ALN-001.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 14 Apr 2016 18:25:08 -0000 Yes/support, very much needed guideline on conflict resolution! > >> -----Original Message----- >> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of >> bruno.decraene@orange.com >> Sent: Thursday, April 14, 2016 12:55 AM >> To: spring@ietf.org >> Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption >> call >> >> > From: bruno.decraene@orange.com > Sent: Thursday, April 14, 2016 9:51 >> > AM >> > >> > Dear WG, >> > >> > As we discussed at our meeting last week, working group adoption has >> > been requested for draft-ginsberg-spring-conflict-resolution. >> > Please reply to the list with your comments, including although not >> > limited to whether or not you support adoption. >> >> We will end the call on April 29, 2016. >> >> >> > Thanks, >> > >> > --John and Bruno >> > >> > >> > >> > >> __________________________________________________________ >> > >> __________________________________________________________ >> > _____ >> > >> > Ce message et ses pieces jointes peuvent contenir des informations >> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> > exploites ou copies sans autorisation. Si vous avez recu ce message >> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >> > que les pieces jointes. Les messages electroniques etant susceptibles >> > d'alteration, Orange decline toute responsabilite si ce message a ete altere, >> deforme ou falsifie. Merci. >> > >> > This message and its attachments may contain confidential or >> > privileged information that may be protected by law; they should not >> > be distributed, used or copied without authorisation. >> > If you have received this email in error, please notify the sender and >> > delete this message and its attachments. >> > As emails may be altered, Orange is not liable for messages that have >> > been modified, changed or falsified. >> > Thank you. >> > >> > _______________________________________________ >> > spring mailing list >> > spring@ietf.org >> > https://www.ietf.org/mailman/listinfo/spring >> >> __________________________________________________________ >> __________________________________________________________ >> _____ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites >> ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez >> le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les >> messages electroniques etant susceptibles d'alteration, Orange decline toute >> responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; they should not be distributed, >> used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete >> this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been >> modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring > >_______________________________________________ >spring mailing list >spring@ietf.org >https://www.ietf.org/mailman/listinfo/spring From nobody Fri Apr 15 00:08:44 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE9E12E038; Fri, 15 Apr 2016 00:08:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160415070840.15097.9355.idtracker@ietfa.amsl.com> Date: Fri, 15 Apr 2016 00:08:40 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-oam-usecase-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 07:08:40 -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 of the IETF. Title : A scalable and topology aware MPLS data plane monitoring system Authors : Ruediger Geib Clarence Filsfils Carlos Pignataro Nagendra Kumar Filename : draft-ietf-spring-oam-usecase-02.txt Pages : 12 Date : 2016-04-15 Abstract: This document describes features of a path monitoring system and a use case. Segment based routing enables a scalable and simple method to monitor data plane liveliness of the complete set of paths belonging to a single domain. The MPLS monitoring system adds to legacy MPLS ping and path trace, it doesn't result in a deprication them. MPLS topology awareness reduces management and control plane involvement of OAM measurements while enabling new OAM features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-oam-usecase-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-oam-usecase-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 15 05:37:23 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 991F012E1BE; Fri, 15 Apr 2016 05:37:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160415123721.15212.10943.idtracker@ietfa.amsl.com> Date: Fri, 15 Apr 2016 05:37:21 -0700 Archived-At: Subject: [spring] The SPRING WG has placed draft-ginsberg-spring-conflict-resolution in state "Call For Adoption By WG Issued" X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 12:37:21 -0000 The SPRING WG has placed draft-ginsberg-spring-conflict-resolution in state Call For Adoption By WG Issued (entered by Bruno Decraene) The document is available at https://datatracker.ietf.org/doc/draft-ginsberg-spring-conflict-resolution/ From nobody Fri Apr 15 11:14:08 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB2012DA4B; Fri, 15 Apr 2016 11:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lj0bs2bc4Rxl; Fri, 15 Apr 2016 11:14:05 -0700 (PDT) Received: from mail-pa0-x241.google.com (mail-pa0-x241.google.com [IPv6:2607:f8b0:400e:c03::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D37912DE43; Fri, 15 Apr 2016 11:14:05 -0700 (PDT) Received: by mail-pa0-x241.google.com with SMTP id k3so10262098pav.3; Fri, 15 Apr 2016 11:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=sq5viepXHZeUziphNIXurHwnbceEORo0FqPkCh5Hjjw=; b=yG+pgpkwxV8tI6RetDVtyk9CJn4zDyMGqZsp1QNsGwLbwityAKS0zD5JU9rvDCqiqc b/8G89MTZ6C8CY+S2t+5Xe85+uNCBUJQyEQgUXeAzOkqmoCp2Z/67ThhqAF+k2+SVRVe PHPmUIDbRXcc7KqiHgpMoQj1zIBdfnk88P6lNsV9bxdLLpIOYJju95QrAON1lmpDc9Mc atEWrnPLG8gtJLXmuyUhwZh8HAYj4SC/yU5EmpqtyZQ5GZ8+ALWet1YsWggkaKbkzEkv uMyZOR9L5wG83Y0WlsxzpoXDHcvGGQD7Dn0VSLNHJG+BowChUve1vKxW4Phr2uUCLJ/D 1czg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=sq5viepXHZeUziphNIXurHwnbceEORo0FqPkCh5Hjjw=; b=fEUSCUinTsIY00qiVfEgnYlVZwKA0WG++KX6VCg4yP4A/h1Jq5NpFVa6hndfaYSc8D rwfXFbO4PeOD7GutSNq/Dq7/M0BAw8p4Icl6BTdxsBGyTsldZVvjK9a/citWQxpmLYWv tfR+U5eOxlR1DNGKyX/NN0CmSZxTn96sqvWO1B0GCIDPC+RjFwd1bXsg5eOJWh+N/i9m x3lVA66qQZ8D+FRVWDpL3DApQXGOS2y9QQwmqEqTMgtnIG67rpKa9dfTWJbb3PLPLysV /VHRaMIcns1WQEIRiwmxBZiPg277JJ9rtcNuWtYJGMbveS3YkzRW1gsX3cw2IKVOKNze IlqA== X-Gm-Message-State: AOPr4FWljpkh791jG5n2ffmjcPiBemi0BOledHBy7BsXvtNv84nUW3vfa4rQ1/rYKZY6Dw== X-Received: by 10.66.148.232 with SMTP id tv8mr31150098pab.21.1460744045025; Fri, 15 Apr 2016 11:14:05 -0700 (PDT) Received: from [192.168.1.13] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id d12sm66162221pfj.85.2016.04.15.11.14.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Apr 2016 11:14:04 -0700 (PDT) User-Agent: Microsoft-MacOutlook/0.0.0.160212 Date: Fri, 15 Apr 2016 11:14:05 -0700 From: Jeff Tantsura To: "Henderickx, Wim (Nokia - BE)" , EXT Martin Pilka , "bruno.decraene@orange.com" , "spring@ietf.org" , "draft-ginsberg-spring-conflict-resolution@ietf.org" Message-ID: <40D37DC5-C1C7-4BE7-9042-7CE8CE353CB9@gmail.com> Thread-Topic: [spring] draft-ginsberg-spring-conflict-resolution - IPR Call References: <816B87CE-3999-49CF-8425-F1A1A2A4E783@alcatel-lucent.com> In-Reply-To: <816B87CE-3999-49CF-8425-F1A1A2A4E783@alcatel-lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - IPR Call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 15 Apr 2016 18:14:07 -0000 Same here On 4/14/16, 12:49 AM, "spring on behalf of Henderickx, Wim (Nokia - BE)" wrote: >As reviewer not aware on IPR related to this draft > > > > >On 13/04/16 20:32, "spring on behalf of EXT Martin Pilka" wrote: > >>Hello Bruno, >>I am also not aware of any IPR related to this draft. >>Thanks, >>Martin >> >> >>On 13/04/16 09:57, bruno.decraene@orange.com wrote: >>> Working Group, >>> >>> The authors of draft-ginsberg-spring-conflict-resolution believe that t= he document is ready to be considered for working adoption. >>> >>> This mail starts the IPR poll. >>> >>> Are you aware of any IPR that applies to draft-ginsberg-spring-conflict= -resolution? >>> >>> If so, has this IPR been disclosed in compliance with IETF IPR rules (s= ee RFCs 3979, 4879, 3669 and 5378 for more details)? >>> >>> If you are listed as a document author or contributor please respond to= this email regardless of whether or not you are aware of any relevant IPR. = The response needs to be sent to the SPRING wg mailing list. The document wi= ll not advance to the next stage until a response has been received from eac= h author and contributor. >>> >>> If you are on the SPRING WG email list but are not listed as an author = or contributor, then please explicitly respond only if you are aware of any = IPR that has not yet been disclosed in conformance with IETF rules. >>> >>> Thanks, >>> -- Bruno, John >>> >>> >>> _______________________________________________________________________= __________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or privileged= information that may be protected by law; >>> they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and = delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. >>> Thank you. >>> >>> >> >>MartinPilka >> >> >>Mlynsk=C3=A9 Nivy 56 / 821 05 Bratislava / Slovakia >>+421 908 767 009 / martin.pilka@pantheon.tech >>reception: +421 2 206 65 111 / www.pantheon.sk >>[logo] >>_______________________________________________ >>spring mailing list >>spring@ietf.org >>https://www.ietf.org/mailman/listinfo/spring >_______________________________________________ >spring mailing list >spring@ietf.org >https://www.ietf.org/mailman/listinfo/spring From nobody Tue Apr 19 01:54:06 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E9E12DF9F for ; Tue, 19 Apr 2016 01:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlT7CDDTkP1C for ; Tue, 19 Apr 2016 01:54:03 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E8D12EA45 for ; Tue, 19 Apr 2016 01:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3995; q=dns/txt; s=iport; t=1461056042; x=1462265642; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=AH5f7haF1Bg4CQct54JNGbJbWEQkSp1pz4aXGFm4o2A=; b=cKQMHfiU9NHvPiNjaUKegUSb3XOAKWiSbCwVHVFcWcQ1OHOkYvWHW6hW mAsjeRqYUxet+3qje6tftQMf62TRjyKuPwsWNxDE3VGKZIno6uJCCw3rE xjRv+/WkExch0ECnN4xMsx7lpyPdNcyiKrs3H/r+p9Gm+FCN637si32qH g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgBI8RVX/xbLJq1dhAsDeroYAQ2Bc?= =?us-ascii?q?RcLhSJKAoF3FAEBAQEBAQFlJ4RBAQEBBAEBATU2CQEBDAQLDgMBAwEBAQkWCAc?= =?us-ascii?q?JAwIBAgEVHwMGCAYBDAEFAgEBiCUOvSwBAQEBAQEBAQEBAQEBAQEBAQEBAQEVh?= =?us-ascii?q?iGES4oVAQSNU4o7hXiIF4FmToQAgwaEO4EbjyseAQFCggQagUw6MAGJOQEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,506,1454976000"; d="scan'208";a="676814387" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2016 08:54:00 +0000 Received: from [10.61.238.24] ([10.61.238.24]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3J8rx5X008836; Tue, 19 Apr 2016 08:54:00 GMT Message-ID: <5715F227.3050303@cisco.com> Date: Tue, 19 Apr 2016 10:53:59 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Madhukar Anand , "spring@ietf.org" References: <169f9c5d600e4ebcb44f775dd3451bcc@sv-ex13-prd2.infinera.com> In-Reply-To: <169f9c5d600e4ebcb44f775dd3451bcc@sv-ex13-prd2.infinera.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Sanjoy Bardhan Subject: Re: [spring] Fwd: New Version Notification for draft-anand-spring-poi-sr-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 08:54:06 -0000 Hi Madhukar, - you defined Opaque-Adj-SID sub-TLV is an optional sub-TLV of Extended Link TLV in case of OSPF and one of the IS-Neighbor TLVs in case of ISIS. The parent TLVs in all cases carry the neighbor identifier. Repeating the Remote POG Router-ID/System ID in Opaque-Adj-SID sub-TLV looks redundant. - Is the "paths through the optical transport domain" always between adjacent POGs? Would not you find it useful to advertise a "path" between non adjacent POG nodes? - Existing SR architecture includes the definition of Binding SID and there are extensions for IGPs to advertise it. The SID/Label Binding Sub-TLV is used to advertise a SID/Label mapping for a "path" to the prefix. It looks to me there is an overlap between the new Opaque-Adj-SID sub-TLV and existing SID/Label Binding Sub-TLV. Both of them advertise a "binding label" for a "path". Binding Sub-TLV talks about a path to a prefix, but given that the prefix can represent a "Router-ID" of the remote node, it can be used to advertise the path to a node. - Section 4 of the draft says: "The opaque adjacency segment can also optionally be announced with a set of attributes that characterizes the path". The Opaque-Adj-SID sub-TLV encoding does not provide for additional attributes. SID/Label Binding Sub-TLV supports nested sub-TLVs, which allows you to advertise path path attributes. I wonder whether existing Binding Sub-TLV with new sub-TLVs could be used for the Packet-Optical integration, rather then defining a new sub-TLV of a similar kind. thanks, Peter On 3/23/16 05:17 , Madhukar Anand wrote: > Hi all, > > The following draft talks about connecting packet and optical networks using segment routing as a common control plane. This is an attempt towards packet-optical integration. Please review and let us know of any comments. > https://www.ietf.org/internet-drafts/draft-anand-spring-poi-sr-00.txt > > Best regards, > Madhukar, Sanjoy and Ramesh > > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Sunday, March 20, 2016 6:32 PM > To: Madhukar Anand ; Sanjoy Bardhan > Subject: New Version Notification for draft-anand-spring-poi-sr-00.txt > > > A new version of I-D, draft-anand-spring-poi-sr-00.txt has been successfully submitted by Madhukar Anand and posted to the IETF repository. > > Name: draft-anand-spring-poi-sr > Revision: 00 > Title: Packet-Optical Integration in Segment Routing > Document date: 2016-03-20 > Group: Individual Submission > Pages: 15 > URL: https://www.ietf.org/internet-drafts/draft-anand-spring-poi-sr-00.txt > Status: https://datatracker.ietf.org/doc/draft-anand-spring-poi-sr/ > Htmlized: https://tools.ietf.org/html/draft-anand-spring-poi-sr-00 > > > Abstract: > This document illustrates a way to integrate a new class of nodes and > links in segment routing to represent networks in an opaque way for > further extensibility of the link-state protocols that help with > segment routing. An instance of the opaque definition would be > optical networks that are typically transport centric. In the IP > centric network, this will help in defining a common control protocol > for packet optical integration that will include optical paths as > opaque 'segments' or sub-paths as an augmentation to the defined > extensions of segment routing. This opaque option defines a general > mechanism to allow for future extensibility of segment routing. > > > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > . > From nobody Tue Apr 19 14:55:38 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9546E12DEF8 for ; Tue, 19 Apr 2016 14:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infinera.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbUqIz-HwFig for ; Tue, 19 Apr 2016 14:55:34 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0053.outbound.protection.outlook.com [65.55.169.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43B2F12DA4D for ; Tue, 19 Apr 2016 14:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infinera.onmicrosoft.com; s=selector1-infinera-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MNI/vEqujeR4yDxLHqpjI2DKlxV5ep65J6W0418LmSw=; b=IRVEhDVH+vq+18ph2BS4NqACAdnWa34BVmgWwGiwGIFr/8siCowo8Rhjq4Kdcj9F8Aljcl7ozoe4Ts7sh7XAqixuJRpkQRC2jTMInHv4pgolMRHRgl0E0XZNwsKPyoBe7IHeKy9quAgG4WlJFGO30nGs4Fnuv96L55AYayRxXk8= Received: from BY2PR1001CA0061.namprd10.prod.outlook.com (10.164.163.29) by BLUPR10MB0515.namprd10.prod.outlook.com (10.163.123.22) with Microsoft SMTP Server (TLS) id 15.1.466.19; Tue, 19 Apr 2016 21:55:31 +0000 Received: from BY2FFO11FD034.protection.gbl (2a01:111:f400:7c0c::158) by BY2PR1001CA0061.outlook.office365.com (2a01:111:e400:5a6b::29) with Microsoft SMTP Server (TLS) id 15.1.466.19 via Frontend Transport; Tue, 19 Apr 2016 21:55:31 +0000 Authentication-Results: spf=pass (sender IP is 204.128.141.23) smtp.mailfrom=infinera.com; cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=bestguesspass action=none header.from=infinera.com; Received-SPF: Pass (protection.outlook.com: domain of infinera.com designates 204.128.141.23 as permitted sender) receiver=protection.outlook.com; client-ip=204.128.141.23; helo=sv-ex13-prd1.infinera.com; Received: from sv-ex13-prd1.infinera.com (204.128.141.23) by BY2FFO11FD034.mail.protection.outlook.com (10.1.14.219) with Microsoft SMTP Server (TLS) id 15.1.472.8 via Frontend Transport; Tue, 19 Apr 2016 21:55:31 +0000 Received: from SV-EX13-PRD2.infinera.com (10.100.103.229) by sv-ex13-prd1.infinera.com (10.100.103.228) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 19 Apr 2016 14:55:24 -0700 Received: from SV-EX13-PRD2.infinera.com ([10.100.101.111]) by sv-ex13-prd2.infinera.com ([10.100.101.111]) with mapi id 15.00.1044.021; Tue, 19 Apr 2016 14:55:24 -0700 From: Madhukar Anand To: Peter Psenak , "spring@ietf.org" Thread-Topic: [spring] Fwd: New Version Notification for draft-anand-spring-poi-sr-00.txt Thread-Index: AdGEuseF6TBRnMfER4+fDkORo6lpmQVmOgeAAAyVhIA= Date: Tue, 19 Apr 2016 21:55:24 +0000 Message-ID: <65df9a7999b44eb695755fd4a676afdb@sv-ex13-prd2.infinera.com> References: <169f9c5d600e4ebcb44f775dd3451bcc@sv-ex13-prd2.infinera.com> <5715F227.3050303@cisco.com> In-Reply-To: <5715F227.3050303@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.100.99.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:204.128.141.23; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(2980300002)(438002)(53754006)(24454002)(13464003)(377454003)(199003)(377424004)(2473001)(189002)(50466002)(33646002)(54356999)(50986999)(76176999)(47776003)(230783001)(46406003)(16796002)(97756001)(108616004)(86362001)(2900100001)(80792005)(189998001)(53416004)(87936001)(106466001)(107886002)(586003)(5001970100001)(5001770100001)(77096005)(15975445007)(102836003)(1220700001)(1096002)(4001430100002)(3846002)(6116002)(23726003)(2950100001)(92566002)(2906002)(5008740100001)(11100500001)(10400500002)(6806005)(19580405001)(19580395003)(5003600100002)(15650500001)(4326007)(2501003)(24736003); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR10MB0515; H:sv-ex13-prd1.infinera.com; FPR:; SPF:Pass; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD034; 1:P0Arb2/ewuWKKM6bSzX3ASJM42HNSc0ZWNYXID1E0Sz+gqcHZ9VP0UqLnTXkgNhLVw0IxusAnhLnRGGtBI1w73frDVdJSD7fjfpwL2RswHz741lJQwlgIsbuJTe++dVBSSKwV9FkuxBMXzcvnvbc5VTf4mmU4skf7IDNGC2YpneTyUPaFFs+zOD5nkMPuVsHCEaYrrRdP/OZdm/NfDNgkxAM9D9X5626v97jBbABSKWROmx2HYe/L9vWmW5tC8RSBFCqPf4QRTrbMjqH2KKXnJzeupb8KiLwzE8Y2SQGvBgrcA/HjBpvxZAFMXDmXdT/KEiFuDbqZ7q1GRYE+GUAaiQQtVraQvWmPwuIvEwKOqhRbYYms5DeSSjFQW7h/T2f4bikJayIfTERZGvSIbIwcJI6hpORFLxxP8Bhu8CRTmXgzbAzSFLUpL5gLF72Ip8DOS3/MhAal9mQADGZEtHaTqil9mb7NiKewYhVBKZzUrnYSBkkW7dFI0pDLKGOXp9LPrPBb3FQntXDawQz2Ec3C5gFyzLgV2EGA5mlzOMhUGU= X-MS-Office365-Filtering-Correlation-Id: 4ab4e359-f914-4bd4-fdcd-08d3689d53a2 X-Microsoft-Exchange-Diagnostics: 1; BLUPR10MB0515; 2:fiCEcUZSzuXXZY6qWD+C+If5r4ur57SFsif0bY3x69PlGrX0DOHNG66tNECGMw3bb+xCr5qxnIoRTyd0hKxsVu9kz/AcQBzVXocMPmhuiCX+Wk7uYE79tbgyA1HBHve1xdxdTYydJL19D7xe1JL/YQr4Xpj6ABGt1MZ7+yCBL6FpfpaBdPfxsDur1eOiYgS6; 3:B7Mq/bHAcAAq/qKZIE6N9OC7iq0WeovhzG0r2tGy3B8TP+Kzng77yTvvpWc5EnlQ6bZZHGXACKBBowbC7kWCOwu1c9v3gk9AtauOofa5j6yQhaZRQAumC4cGL7ieaSi/Rmspz5Pj7sKPkOEiC5wtS0GGHUp4fQtPUuksk3LVNKaapC4kbSmdz1/DOdMzISJknZ6Vd66erBLbPmiLxeM0eEpqiFMB2syBO92d2O5Lm220hI+uFVEd+QlfIW2i8LPvRqCuvjlG8zI4ug/SXmGU7A==; 25:vpKsrV7w781MTx/xyOvndMU7SpGDK3QWu1MbSb5TfipAIM+7yC8dHoAeEz0FBIPPxDnaA/VYPHEQr7m8ZLYOyQl111G0K6qGlcHtVBI8Lt6pcexpPNUGFRa19Fbqmu3tyCL2brToL36Fd9Rs85uF6ss0OaWJYFN6IPjUTtjjmy/PFL/c/rPRp9vE0byLUcbi3bI3mnTzfFWqpNOeLEREsN5wzmJN/7npEgKlcFyF+Hss8auFN/L2qnZEN23anIr4EvtlkbR3T9JS8qAcCMVN/l1hTSvhsN83EVmqId+i+V7cWHxD97ATWoBPC923SIdDdiDpnmeUtFcPj+JWxJARCA== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BLUPR10MB0515; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(9101521026)(601004)(2401047)(13024025)(13017025)(13023025)(13018025)(13015025)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR10MB0515; BCL:0; PCL:0; RULEID:; SRVR:BLUPR10MB0515; X-Microsoft-Exchange-Diagnostics: 1; BLUPR10MB0515; 4:mDOOyOBeWvtfp6nI9HCT+eN8f+WxdAkPdl+q3hmv/6/jlCmlN9THnXvHqSJ6exbh85EqtRgQjPCU5RubTXsbtWG8GRQ2SrREG8pZ55vxhW0nZE3M4+PruVZm+vSKtL/BZyZcnI1alIzN+3gKLZG4zknRVrEO/iEmLyTGHHugvaY0OJg2CJm/EX5IbknvnuywCiuYH/R5kU7c2hrRGwglqu0e0Ax0AAtmbzEQqNdVVOMcSu3bF/DxNHOumTbvPor7ncwDPRHJXIE3HoqRNu2h6NrZq+cP5PPCkMTsdMvoydc90DEviBSKb8CW4nxZ9NRoWHhXJZOxZLPU+oEKjf/l6f/NRhXq8AtLY+/t4rD8UF8PCS7yiPq5CXdl00gY7mpeiBP/GXCNQmR74a9ygLSKMy+WWg7BRZ5e1ODLUM9la5To68OcTTnDPT9ZEpKvVhVjMIjbAw8OU1RrV2XiCfTD/N7GXM3Bf/OoV9mvmIvva7E0gU2IQGdeW9k/DIFO6bVhlkiQJpkhJUF2TR0BYmk9Yw== X-Forefront-PRVS: 0917DFAC67 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR10MB0515; 23:x2/Hj+MINB0ofL4BTF2O9LmFHytpH+d8vlo4oiJW9?= =?us-ascii?Q?QiVvHDesRN5bTfavnb6kAz87moRF3oQmTFagqAn21i+yMG8xGlkL1HLvHyjm?= =?us-ascii?Q?GLQN315Pkr1xGSSfor8vxe+JieCl0EXri30HEdkN7SFzUKj0AYWlJQAnh8+8?= =?us-ascii?Q?d28Kf2TPPg6g/ULMJvwBx+eJNI0YEU5F6qVzdwLxcR6nHYNA1IqiRL/gMbSG?= =?us-ascii?Q?FM5O5LpX60KhySpXeWpcQ7lIgN5OjGJvERb+kpibV4nDBtuA5TTQIPI4tG65?= =?us-ascii?Q?IT3A8eLLfdrn84hIPwVjVgv4yLThZzd5HnxknCZzDnzQZF7gi26BFNBNNFb+?= =?us-ascii?Q?H4kXLE9CLD/GPwvBiBjF/stmQdNq5l5MTervmKM0PNtn1dbJAvyzDTYvs6cg?= =?us-ascii?Q?dqzx9NusCGS/6jeC7M58qF+KU4utCxYUsuYh7jVc1g32R6fphOSqoRutXDq7?= =?us-ascii?Q?Ctd8PzaCKeBn2/la6S0NBvzms43Ay/viyvprtewjyDnmZCsL8JLumC+mQNvO?= =?us-ascii?Q?HB90RPK0BA/rJnV12TUyYfmdzDKaho3iu0i/YeC+oXzUCokqv2z5ZFcK/tPD?= =?us-ascii?Q?C0dysBBGgaBb33o8D66j1fEwdq2zy1x67G7+mJ973/hLb+Vc0VR11meGFbN4?= =?us-ascii?Q?Ptku3pKrfUppD85KhepeaHrrXRroGCmch0rFyXxbKmXICrrs3qq63aquiQJf?= =?us-ascii?Q?7JuoW03cjDoK0GILyB0EuBd04RTzFqW4fHWmbdF0R/5M/jtH6AM1PtlIjP4A?= =?us-ascii?Q?QHkZellFBpkPYhKTh5KK62LASFVzxc6rzyW5mrjsBdgJsxFmQvwa4ZeeJNGz?= =?us-ascii?Q?sDuLfR4J+rEYyGqCVz98ohsisqBonLFnNJACMIarIkb5I+nRjnrj9uyrkv23?= =?us-ascii?Q?RtWEeGAHZL75q0/IUpXK71YGq6bV/2YLNnEW1OnyKHmgQDzQ9hphSVu10pfO?= =?us-ascii?Q?4HBXBk0fWu3XnAlGIzeWYspUnFqt9pO06R8y6LtRzys8Sr3jUxmZVoxc5/uT?= =?us-ascii?Q?q3tGOskI2U7ouHm+IIL59EEgoDIG9a+xsliOYvQ7582gPuDFBSfaC9MwlAiO?= =?us-ascii?Q?GBaq+rerGFjoLugWrOLK4NSOSFck5dcDE/2txhU5cVWvMVMgf5ptwDbTanpc?= =?us-ascii?Q?v/ZWjZc03BLe2SVvA4ncKY2eI6mRle9B5zotv0FyEfx5zGJ8nGIObBnmbc5d?= =?us-ascii?Q?Wlbs8ri5dw27aap7oOmBjyBtZbf9jrDFhDOk5wJ5OK4NDBfVRXHPDi89K1i2?= =?us-ascii?Q?fpeTRwLt0xyl3wwfpq/J8KCWwIYrV2Ctmb5bOzjxxvy3AM4krKQzU67qPGY/?= =?us-ascii?Q?BCjh1gL+30GqmG19h3uN4ZPUdTWcm7r93MmADT6URlGKH8YOO6a7gLJwUlXu?= =?us-ascii?Q?izAPL5IsRN7dbA0uLbwJ8izVvKQ0W/OvktTPWkZOAVypXg7MyOXYHqu7/+sd?= =?us-ascii?Q?/tXnCCsVoWsgwOXfIPgb2KIGG45ViM=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR10MB0515; 5:0X5JPf4ADc6PPaNd42K5mNw5fDPTLzk14PXMNCVLRMaoe3i/u0NEr5Ce23Ak2qQVaD/Q/HZrJ8CvkLUIDgcEk+C6j/yF6m+YCno12FG35Q2dAac5klNZkL4ZTVf3K7Xo6kEYCLhjp3rtfYFbSyr00oJN/BJzRW8ENsZXnDbN1MekAaSmtrdyGTObKAqZk3UT; 24:uZQDCQrlAbKJ8DbLG7yZ9ahLB+20Gy8HEs1MD9Iy2fyptKR7hb69KPbHQn1mU9XuTvaABk2LH+gDosV2zhju47+B/s/0jJpc/z9k8ycz1as=; 7:jWd6YqU/BxR1HMMTIN7AQHLFQdQAj6etgnwxX6XzmePKY96Fz7n8KwQiqPInD0YBXAIGfSqEaw+lR7PE6HIHTVv1yQxG0C7lIpLKez9WLVMj1Ut5rbR4Y/nJvRVG1XKmFXhnu5X+Vc2RzAdaB29gdjk4SSDGAl0XOUacr1JIsZ3ARkISHXaxjB9M3eo5FRfBfeIAm1/FGiPflYTPLMogEG+Po3vHnLjvq+cegVPyYcU= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: infinera.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Apr 2016 21:55:31.1092 (UTC) X-MS-Exchange-CrossTenant-Id: 285643de-5f5b-4b03-a153-0ae2dc8aaf77 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=285643de-5f5b-4b03-a153-0ae2dc8aaf77; Ip=[204.128.141.23]; Helo=[sv-ex13-prd1.infinera.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR10MB0515 Archived-At: Cc: Sanjoy Bardhan Subject: Re: [spring] Fwd: New Version Notification for draft-anand-spring-poi-sr-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 19 Apr 2016 21:55:36 -0000 Hi Peter,=20 Thanks much for your comments. Please find some answers inline.=20 Thanks, Madhukar -----Original Message----- From: Peter Psenak [mailto:ppsenak@cisco.com] Sent: Tuesday, April 19, 2016 1:54 AM To: Madhukar Anand ; spring@ietf.org Cc: Ramesh Subrahmaniam ; Sanjoy Bardhan Subject: Re: [spring] Fwd: New Version Notification for draft-anand-spring-= poi-sr-00.txt Hi Madhukar, - you defined Opaque-Adj-SID sub-TLV is an optional sub-TLV of Extended Lin= k TLV in case of OSPF and one of the IS-Neighbor TLVs in case of ISIS. The = parent TLVs in all cases carry the neighbor identifier.=20 Repeating the Remote POG Router-ID/System ID in Opaque-Adj-SID sub-TLV look= s redundant. [MA] Sure, we will take care of this and remove the redundancy. - Is the "paths through the optical transport domain" always between adjace= nt POGs? Would not you find it useful to advertise a "path"=20 between non adjacent POG nodes? [MA] Yes, I think there may be scenarios where advertising a path may be us= eful. We will try to modify the TLV to accommodate this. - Existing SR architecture includes the definition of Binding SID and there= are extensions for IGPs to advertise it. The SID/Label Binding Sub-TLV is = used to advertise a SID/Label mapping for a "path" to the prefix. It looks = to me there is an overlap between the new Opaque-Adj-SID sub-TLV and existi= ng SID/Label Binding Sub-TLV. Both of them advertise a "binding label" for = a "path". Binding Sub-TLV talks about a path to a prefix, but given that t= he prefix can represent a "Router-ID" of the remote node, it can be used to= advertise the path to a node. - Section 4 of the draft says: "The opaque adjacency segment can also optio= nally be announced with a set of attributes that characterizes the path". T= he Opaque-Adj-SID sub-TLV encoding does not provide for additional attribut= es. SID/Label Binding Sub-TLV supports nested sub-TLVs, which allows you to= advertise path path attributes. I wonder whether existing Binding Sub-TLV with new sub-TLVs could be used f= or the Packet-Optical integration, rather than defining a new sub-TLV of a = similar kind. [MA] Yes, we are currently working with Jeff Tantsura on the possibility o= f using Binding SIDs for our extension. We will circle back to you once we= make progress on this. thanks, Peter On 3/23/16 05:17 , Madhukar Anand wrote: > Hi all, > > The following draft talks about connecting packet and optical networks us= ing segment routing as a common control plane. This is an attempt towards p= acket-optical integration. Please review and let us know of any comments. > https://www.ietf.org/internet-drafts/draft-anand-spring-poi-sr-00.txt > > Best regards, > Madhukar, Sanjoy and Ramesh > > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Sunday, March 20, 2016 6:32 PM > To: Madhukar Anand ; Sanjoy Bardhan=20 > > Subject: New Version Notification for draft-anand-spring-poi-sr-00.txt > > > A new version of I-D, draft-anand-spring-poi-sr-00.txt has been successfu= lly submitted by Madhukar Anand and posted to the IETF repository. > > Name: draft-anand-spring-poi-sr > Revision: 00 > Title: Packet-Optical Integration in Segment Routing > Document date: 2016-03-20 > Group: Individual Submission > Pages: 15 > URL: https://www.ietf.org/internet-drafts/draft-anand-spring-p= oi-sr-00.txt > Status: https://datatracker.ietf.org/doc/draft-anand-spring-poi-s= r/ > Htmlized: https://tools.ietf.org/html/draft-anand-spring-poi-sr-00 > > > Abstract: > This document illustrates a way to integrate a new class of nodes and > links in segment routing to represent networks in an opaque way for > further extensibility of the link-state protocols that help with > segment routing. An instance of the opaque definition would be > optical networks that are typically transport centric. In the IP > centric network, this will help in defining a common control protocol > for packet optical integration that will include optical paths as > opaque 'segments' or sub-paths as an augmentation to the defined > extensions of segment routing. This opaque option defines a general > mechanism to allow for future extensibility of segment routing. > > > > > > > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > . > From nobody Thu Apr 21 16:29:11 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFD212E798 for ; Thu, 21 Apr 2016 16:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdWpQCNBYtbV for ; Thu, 21 Apr 2016 16:29:08 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E5212E086 for ; Thu, 21 Apr 2016 16:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1575; q=dns/txt; s=iport; t=1461281348; x=1462490948; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=o6EYX1kmqP82byOcNn50iUzw4WeiMVUwe12aOaD1isw=; b=irkPK3H3omHVGZ9FaJ1ToqmWy3gtb+b5HuwlkHLn0Gy7AlnImbxi6/Bk xqfVfnVZLmZVZQrqt89bVx0aVITCdsAqCCUhHGnWaRFjoweG2aNBRfOxT fsIkNjIVRZE8xpsYNev/LHwR78MNiuKtYFqGNN3cEJRdhvAFvXogRLies E=; X-IronPort-AV: E=Sophos;i="5.24,515,1454976000"; d="scan'208";a="263715421" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2016 23:29:07 +0000 Received: from [10.154.57.130] ([10.154.57.130]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3LNT7Z6018433; Thu, 21 Apr 2016 23:29:07 GMT Message-ID: <57196243.9010600@cisco.com> Date: Thu, 21 Apr 2016 16:29:07 -0700 From: "Ahmed Bashandy (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: bruno.decraene@orange.com, "spring@ietf.org" References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 21 Apr 2016 23:29:09 -0000 Support. Very much needed Ahmed On 4/14/2016 12:50 AM, bruno.decraene@orange.com wrote: > Dear WG, > > As we discussed at our meeting last week, working group adoption has been requested for draft-ginsberg-spring-conflict-resolution. > Please reply to the list with your comments, including although not limited to whether or not you support adoption. > > Thanks, > > --John and Bruno > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Fri Apr 22 06:04:29 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277D412D5AA for ; Fri, 22 Apr 2016 06:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FMe94vV8QLR for ; Fri, 22 Apr 2016 06:04:26 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8B212D8EF for ; Fri, 22 Apr 2016 06:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1661; q=dns/txt; s=iport; t=1461330266; x=1462539866; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=dd4deOrS1XQ2jxUqKkVWtRJkKrQ0pJBsMk2Pg1QTKQ8=; b=ezjHowU1siC3UkYnND3K0EaDnrUHXe7wOd+J4oWKIDjUh7K31XsRTFer RyWGm9SdWnlMGKWUlhWPqCRia8kpMw0PU7Cd59gfLfRDXuS/dzEPAe+qK Pkr4a5nUSZtjHrIOcZXtDASCssz6XaJcKtAMcJuyfqY/CqFsxNvcUvi4i 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAgDYIBpX/5RdJa1egzhTfQa6AAENg?= =?us-ascii?q?XMXC4UiSgKBJDgUAQEBAQEBAWUnhEIBAQQBAQE3NBsCAQg2ECcLJQIEARKIKg6?= =?us-ascii?q?/GQEBAQEBAQEBAQEBAQEBAQEBAQETBIpshA8KBwGFdAWTHoRxAY4TgWaETYhdj?= =?us-ascii?q?y4BHgEBQoNrbIc5CRcffwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,517,1454976000"; d="scan'208";a="263960686" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Apr 2016 13:04:25 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3MD4Pqh009782 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Apr 2016 13:04:25 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 22 Apr 2016 08:04:24 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Fri, 22 Apr 2016 08:04:24 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: "bruno.decraene@orange.com" , "spring@ietf.org" Thread-Topic: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call Thread-Index: AQHRnJd+fFxfqTo/D0iGA9bGKLfkbQ== Date: Fri, 22 Apr 2016 13:04:24 +0000 Message-ID: References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.7.151005 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.224.19] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 22 Apr 2016 13:04:28 -0000 Support. Regards, Nagendra On 4/14/16, 3:50 AM, "spring on behalf of bruno.decraene@orange.com" wrote: >Dear WG, > >As we discussed at our meeting last week, working group adoption has been >requested for draft-ginsberg-spring-conflict-resolution. >Please reply to the list with your comments, including although not >limited to whether or not you support adoption. > >Thanks, > >--John and Bruno > > > >__________________________________________________________________________ >_______________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations >confidentielles ou privilegiees et ne doivent donc >pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >recu ce message par erreur, veuillez le signaler >a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >electroniques etant susceptibles d'alteration, >Orange decline toute responsabilite si ce message a ete altere, deforme >ou falsifie. Merci. > >This message and its attachments may contain confidential or privileged >information that may be protected by law; >they should not be distributed, used or copied without authorisation. >If you have received this email in error, please notify the sender and >delete this message and its attachments. >As emails may be altered, Orange is not liable for messages that have >been modified, changed or falsified. >Thank you. > >_______________________________________________ >spring mailing list >spring@ietf.org >https://www.ietf.org/mailman/listinfo/spring From nobody Mon Apr 25 01:47:33 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044DC12D523 for ; Mon, 25 Apr 2016 01:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSYa9AREjP-8 for ; Mon, 25 Apr 2016 01:47:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E88C412D52F for ; Mon, 25 Apr 2016 01:38:35 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 913AB18C2B0 for ; Mon, 25 Apr 2016 10:38:34 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.24]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 7136E27C078 for ; Mon, 25 Apr 2016 10:38:34 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0279.002; Mon, 25 Apr 2016 10:38:31 +0200 From: To: DECRAENE Bruno IMT/OLN , "spring@ietf.org" Thread-Topic: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call Thread-Index: AdGWIcRdLnRAPWN3Qn6eVontUw9C0AIrBGqw Date: Mon, 25 Apr 2016 08:38:29 +0000 Message-ID: <28303_1461573514_571DD78A_28303_7380_1_7e9b23c7-6ff5-4f48-a1de-79681937e551@OPEXCLILM7D.corporate.adroot.infra.ftgroup> References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.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.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.25.75717 Archived-At: Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 25 Apr 2016 08:47:32 -0000 +1 -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, April 14, 2016 09:51 To: spring@ietf.org Subject: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption c= all Dear WG, As we discussed at our meeting last week, working group adoption has been r= equested for draft-ginsberg-spring-conflict-resolution. Please reply to the list with your comments, including although not limited= to whether or not you support adoption. Thanks, --John and Bruno ___________________________________________________________________________= ______________________________________________ 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 Mon Apr 25 09:44:43 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E9212D0DA for ; Mon, 25 Apr 2016 09:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.503 X-Spam-Level: X-Spam-Status: No, score=0.503 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, MISSING_MIMEOLE=1.899, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apcDY9hXazxs for ; Mon, 25 Apr 2016 09:44:40 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 7463112B066 for ; Mon, 25 Apr 2016 09:44:40 -0700 (PDT) Received: from [IPv6:2620:15c:3:fd00:11d2:615e:30df:d649] (unknown [IPv6:2620:15c:3:fd00:11d2:615e:30df:d649]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 0E179540B08; Mon, 25 Apr 2016 12:44:37 -0400 (EDT) Date: Mon, 25 Apr 2016 12:44:34 -0400 Message-ID: <1ebf13ac-a979-49e4-974e-6431e4c062c7@email.android.com> X-Android-Message-ID: <1ebf13ac-a979-49e4-974e-6431e4c062c7@email.android.com> In-Reply-To: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> From: Jon Mitchell To: bruno.decraene@orange.com Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: spring@ietf.org Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 25 Apr 2016 16:44:41 -0000 PHAgZGlyPSJsdHIiPjxicj4KU3VwcG9ydCBhZG9wdGlvbi4uLjwvcD4KPHAgZGlyPSJsdHIiPi1K b248L3A+Cg== From nobody Mon Apr 25 11:00:06 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBFC12D628; Mon, 25 Apr 2016 11:00:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160425180004.30214.9754.idtracker@ietfa.amsl.com> Date: Mon, 25 Apr 2016 11:00:04 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-oam-usecase-03.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2016 18:00:04 -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 of the IETF. Title : A Scalable and Topology-Aware MPLS Dataplane Monitoring System Authors : Ruediger Geib Clarence Filsfils Carlos Pignataro Nagendra Kumar Filename : draft-ietf-spring-oam-usecase-03.txt Pages : 12 Date : 2016-04-25 Abstract: This document describes features of a path monitoring system and related use cases. Segment based routing enables a scalable and simple method to monitor data plane liveliness of the complete set of paths belonging to a single domain. The MPLS monitoring system adds features to the traditional MPLS ping and LSP trace, in a very complementary way. MPLS topology awareness reduces management and control plane involvement of OAM measurements while enabling new OAM features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-oam-usecase-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-oam-usecase-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 Mon Apr 25 21:21:28 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EFE12D0A8 for ; Mon, 25 Apr 2016 21:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkaURyxTSn7O for ; Mon, 25 Apr 2016 21:21:25 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8662C12B067 for ; Mon, 25 Apr 2016 21:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1997; q=dns/txt; s=iport; t=1461644485; x=1462854085; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=0s080gb7u2/Z/AkVj/T98KNs9fPdTG2gxrPKgV6KJks=; b=H8OFzsftGbsxITX6wyzQFAjEDxn8ZpTLIgGd/0RAiBkHSmN/NbmG8p5M M+YHLqwWNKLN2fT4aiPMkarvIvOVHtWPROBUoex0LiwW1XDsoCwjtvB+i 9FhA/njD7qJI0pKeCHXXzI7LTOZve/sDZMxtypJq1y/oGrxHWYn0HsUDy k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgBc6x5X/5tdJa1egzhTfQa5dQENg?= =?us-ascii?q?XQkhWoCgTk4FAEBAQEBAQFlJ4RBAQEBAwE6PQcLAgEZAwECHxAyGwIIAgQTiCI?= =?us-ascii?q?IDsMbAQEBAQEBAQMBAQEBAQEBAQEBARWGIYF1CIJOh2qCKwWNVIVLhHEBhXuCd?= =?us-ascii?q?4UkgWdOg3+IXY8vAR4BAUKCBRsWgTVsAYgAfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,535,1454976000"; d="scan'208";a="97719514" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2016 04:21:20 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u3Q4LKGh015248 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 26 Apr 2016 04:21:20 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 26 Apr 2016 00:21:19 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Tue, 26 Apr 2016 00:21:19 -0400 From: "Stefano Previdi (sprevidi)" To: SPRING WG Thread-Topic: New Version Notification for draft-filsfils-spring-sr-recursing-info-02.txt Thread-Index: AQHRn3K2bX1TGfzOFkKaNs/+V+t62A== Date: Tue, 26 Apr 2016 04:21:19 +0000 Message-ID: <07353123-9E9D-40E7-9CF3-517354F8ECF2@cisco.com> References: <20160426041835.30258.98412.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.250.128] Content-Type: text/plain; charset="us-ascii" Content-ID: <9754E1861715474A8B4E546840DA7447@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [spring] Fwd: New Version Notification for draft-filsfils-spring-sr-recursing-info-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 26 Apr 2016 04:21:27 -0000 just refreshed the draft. Comments are appreciated. Thanks. s. > Begin forwarded message: >=20 > From: > Subject: New Version Notification for draft-filsfils-spring-sr-recursing-= info-02.txt > Date: April 26, 2016 at 6:18:35 AM GMT+2 > To: Clarence Filsfils , Peter Psenak , Les Ginsberg , Stefano Previdi >=20 >=20 > A new version of I-D, draft-filsfils-spring-sr-recursing-info-02.txt > has been successfully submitted by Stefano Previdi and posted to the > IETF repository. >=20 > Name: draft-filsfils-spring-sr-recursing-info > Revision: 02 > Title: Segment Routing Recursive Information > Document date: 2016-04-25 > Group: Individual Submission > Pages: 8 > URL: https://www.ietf.org/internet-drafts/draft-filsfils-sprin= g-sr-recursing-info-02.txt > Status: https://datatracker.ietf.org/doc/draft-filsfils-spring-sr= -recursing-info/ > Htmlized: https://tools.ietf.org/html/draft-filsfils-spring-sr-recu= rsing-info-02 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-filsfils-spring= -sr-recursing-info-02 >=20 > Abstract: > Segment Routing (SR) allows for a flexible definition of end-to-end > paths within IGP topologies by encoding paths as sequences of > topological sub-paths, called "segments". These segments are > advertised by the link-state routing protocols (IS-IS and OSPF). >=20 > There are use cases where it is desirable to utilize a SID associated > with a given node in order to transport traffic destined to different > local services supported by such node. This document defines the > mechanism to do so and illustrates it. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Tue Apr 26 06:14:19 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4003F12B04F for ; Tue, 26 Apr 2016 06:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zk1iIs9Gqzqv for ; Tue, 26 Apr 2016 06:14:15 -0700 (PDT) Received: from owl2.lab.dtag.de (unknown [194.25.1.238]) by ietfa.amsl.com (Postfix) with ESMTP id 74D4512B01C for ; Tue, 26 Apr 2016 06:14:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by owl2.lab.dtag.de (Postfix) with ESMTP id E5B35C6DE9; Tue, 26 Apr 2016 15:14:13 +0200 (CEST) Received: from Martins-MacBook-Air.local (unknown [88.128.82.4]) by owl2.lab.dtag.de (Postfix) with ESMTPSA id BA5D3C684E; Tue, 26 Apr 2016 15:14:13 +0200 (CEST) To: bruno.decraene@orange.com, "spring@ietf.org" References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> From: Martin Horneffer Message-ID: <571F69A4.4070100@nic.dtag.de> Date: Tue, 26 Apr 2016 15:14:12 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 26 Apr 2016 13:14:17 -0000 Support. From an operator's point of view I see strong need for covering this topic. Best regards, Martin Am 14.04.16 um 09:50 schrieb bruno.decraene@orange.com: > Dear WG, > > As we discussed at our meeting last week, working group adoption has been requested for draft-ginsberg-spring-conflict-resolution. > Please reply to the list with your comments, including although not limited to whether or not you support adoption. > > Thanks, > > --John and Bruno > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > From nobody Tue Apr 26 11:10:09 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504A512D564 for ; Tue, 26 Apr 2016 11:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZcIp_CXpmE5 for ; Tue, 26 Apr 2016 11:10:05 -0700 (PDT) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7247712D563 for ; Tue, 26 Apr 2016 11:10:05 -0700 (PDT) Received: by mail-pf0-x241.google.com with SMTP id 145so2186699pfz.1 for ; Tue, 26 Apr 2016 11:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=8NmFH0IrP2lPEOP/n8hNCrnhz2QgfrNaDDw45fxrd9Q=; b=np9J9dmUFOnTBEzz7MJFQLXPBfWMzIqao4rfHVTDl8DaO11kjFPww6gwhKqeUYNaqh mTW+DhCKu4+J+uBRb9KQxwgEaAh09WqBbli+42NhNi9ztGVVoZe745F4yZIdTXpaI5WB oDYl12MsDJxcDLo4S8LEJnOzOSrsVQwaQropdNJSdPv4onOK8TBFGcFPbEa4SBHlGGGX GMWGmlYX1tGAeLm7F5SvY0xp5cJmKvlEDjIw6MxSFg4ORrPf17btRG/N6K31lFMPkzSu xLH9dJJiSaMgtIuLrLoVoweeqDoBcfJmOmqlnJ0hlEmEKvGJBjdhJdutY2wSMwRyjeqe DC0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=8NmFH0IrP2lPEOP/n8hNCrnhz2QgfrNaDDw45fxrd9Q=; b=nENETvbPObNW2LKEXmxL6TTkMv1y3Bwsy/cogUOo7v6Sq5S8oG/nEd7MTt8U0Hsrll LMSLaI4XKEcu+7A11/GRfQsupt4ipHBPydYFyqCXIfjJjI3y7N1paDc9cfQ+zrl5c9bD 17NRmlQ8R8D4PhCINawwBusZtgTMhRDxJz2+gCHTfuifSN16J7CdT2g0bAss7QfTYE7a t73a/wfk20OLqXUlEYXHhKT8OdFJWSn/O38fVdY1sU2sqXOVeTAImSPwclF3ddj2mFZv ooKVUfJJ4fwiDFxvcIYpZrD3NkrEkk3iTIA8o23befUSnDIBXh9pLF3AccAX7WXTcZ8m cHTQ== X-Gm-Message-State: AOPr4FX6OyQfKCTF47XODkJI00EH4Cqnzdfw1iCLrVKENLPfIABeRyg07NzyXie2UT7bew== X-Received: by 10.98.89.28 with SMTP id n28mr5597219pfb.41.1461694205060; Tue, 26 Apr 2016 11:10:05 -0700 (PDT) Received: from [192.168.1.13] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id fv10sm69119pad.40.2016.04.26.11.10.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Apr 2016 11:10:04 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.15.1.160411 Date: Tue, 26 Apr 2016 11:10:02 -0700 From: Jeff Tantsura To: Madhukar Anand , Peter Psenak , "spring@ietf.org" Message-ID: Thread-Topic: [spring] Fwd: New Version Notification for draft-anand-spring-poi-sr-00.txt References: <169f9c5d600e4ebcb44f775dd3451bcc@sv-ex13-prd2.infinera.com> <5715F227.3050303@cisco.com> <65df9a7999b44eb695755fd4a676afdb@sv-ex13-prd2.infinera.com> In-Reply-To: <65df9a7999b44eb695755fd4a676afdb@sv-ex13-prd2.infinera.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Cc: Sanjoy Bardhan Subject: Re: [spring] Fwd: New Version Notification for draft-anand-spring-poi-sr-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 26 Apr 2016 18:10:07 -0000 Hi Peter, Thanks for the comments, agree with all of them. We have been indeed looking o extend existing Binding Sub-TLV with new sub-TLVs to accommodate the Packet-Optical integration. Thanks, Jeff On 4/19/16, 2:55 PM, "spring on behalf of Madhukar Anand" wrote: >Hi Peter, > > Thanks much for your comments. Please find some answers inline. > >Thanks, >Madhukar > > >-----Original Message----- >From: Peter Psenak [mailto:ppsenak@cisco.com] >Sent: Tuesday, April 19, 2016 1:54 AM >To: Madhukar Anand ; spring@ietf.org >Cc: Ramesh Subrahmaniam ; Sanjoy Bardhan >Subject: Re: [spring] Fwd: New Version Notification for draft-anand-spring-poi-sr-00.txt > >Hi Madhukar, > >- you defined Opaque-Adj-SID sub-TLV is an optional sub-TLV of Extended Link TLV in case of OSPF and one of the IS-Neighbor TLVs in case of ISIS. The parent TLVs in all cases carry the neighbor identifier. >Repeating the Remote POG Router-ID/System ID in Opaque-Adj-SID sub-TLV looks redundant. > >[MA] Sure, we will take care of this and remove the redundancy. > > >- Is the "paths through the optical transport domain" always between adjacent POGs? Would not you find it useful to advertise a "path" >between non adjacent POG nodes? > >[MA] Yes, I think there may be scenarios where advertising a path may be useful. We will try to modify the TLV to accommodate this. > >- Existing SR architecture includes the definition of Binding SID and there are extensions for IGPs to advertise it. The SID/Label Binding Sub-TLV is used to advertise a SID/Label mapping for a "path" to the prefix. It looks to me there is an overlap between the new Opaque-Adj-SID sub-TLV and existing SID/Label Binding Sub-TLV. Both of them advertise a "binding label" for a "path". Binding Sub-TLV talks about a path to a prefix, but given that the prefix can represent a "Router-ID" of the remote node, it can be used to advertise the path to a node. > >- Section 4 of the draft says: "The opaque adjacency segment can also optionally be announced with a set of attributes that characterizes the path". The Opaque-Adj-SID sub-TLV encoding does not provide for additional attributes. SID/Label Binding Sub-TLV supports nested sub-TLVs, which allows you to advertise path path attributes. > >I wonder whether existing Binding Sub-TLV with new sub-TLVs could be used for the Packet-Optical integration, rather than defining a new sub-TLV of a similar kind. > > >[MA] Yes, we are currently working with Jeff Tantsura on the possibility of using Binding SIDs for our extension. We will circle back to you once we make progress on this. > > >thanks, >Peter > >On 3/23/16 05:17 , Madhukar Anand wrote: >> Hi all, >> >> The following draft talks about connecting packet and optical networks using segment routing as a common control plane. This is an attempt towards packet-optical integration. Please review and let us know of any comments. >> https://www.ietf.org/internet-drafts/draft-anand-spring-poi-sr-00.txt >> >> Best regards, >> Madhukar, Sanjoy and Ramesh >> >> >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Sunday, March 20, 2016 6:32 PM >> To: Madhukar Anand ; Sanjoy Bardhan >> >> Subject: New Version Notification for draft-anand-spring-poi-sr-00.txt >> >> >> A new version of I-D, draft-anand-spring-poi-sr-00.txt has been successfully submitted by Madhukar Anand and posted to the IETF repository. >> >> Name: draft-anand-spring-poi-sr >> Revision: 00 >> Title: Packet-Optical Integration in Segment Routing >> Document date: 2016-03-20 >> Group: Individual Submission >> Pages: 15 >> URL: https://www.ietf.org/internet-drafts/draft-anand-spring-poi-sr-00.txt >> Status: https://datatracker.ietf.org/doc/draft-anand-spring-poi-sr/ >> Htmlized: https://tools.ietf.org/html/draft-anand-spring-poi-sr-00 >> >> >> Abstract: >> This document illustrates a way to integrate a new class of nodes and >> links in segment routing to represent networks in an opaque way for >> further extensibility of the link-state protocols that help with >> segment routing. An instance of the opaque definition would be >> optical networks that are typically transport centric. In the IP >> centric network, this will help in defining a common control protocol >> for packet optical integration that will include optical paths as >> opaque 'segments' or sub-paths as an augmentation to the defined >> extensions of segment routing. This opaque option defines a general >> mechanism to allow for future extensibility of segment routing. >> >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> . >> > >_______________________________________________ >spring mailing list >spring@ietf.org >https://www.ietf.org/mailman/listinfo/spring From nobody Wed Apr 27 06:18:19 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9086F12D189; Wed, 27 Apr 2016 06:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVr-tv5jnRwG; Wed, 27 Apr 2016 06:18:02 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C98312D0F8; Wed, 27 Apr 2016 06:17:59 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 4F0BCA0351; Wed, 27 Apr 2016 15:17:58 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.75]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 2662F40066; Wed, 27 Apr 2016 15:17:58 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%19]) with mapi id 14.03.0279.002; Wed, 27 Apr 2016 15:17:57 +0200 From: To: "spring@ietf.org" , "ipv6@ietf.org" Thread-Topic: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Index: AdGghvaHsYiYrA0yQJaWWWPJYYsrcg== Date: Wed, 27 Apr 2016 13:17:57 +0000 Message-ID: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/related; boundary="_004_27B26A2868951342946169C453A0DF4B22EFA891OPEXCLILM23corp_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 27 Apr 2016 13:18:03 -0000 --_004_27B26A2868951342946169C453A0DF4B22EFA891OPEXCLILM23corp_ Content-Type: multipart/alternative; boundary="_000_27B26A2868951342946169C453A0DF4B22EFA891OPEXCLILM23corp_" --_000_27B26A2868951342946169C453A0DF4B22EFA891OPEXCLILM23corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I would like some clarification about the treatment of the SRH by an end p= oint (the node that its loopback matches the DA field), In section 3 : You say that the C-flag: Clean-up flag. Set when the SRH has to be removed from the packet when the packet reaches the last segment. Which mean that the last node inspects the SRH flags if the c-flag is set, = the node has to remove the SRH before sending the packet to its final desti= nation. But In section 4.3. You say that the node that decrements the Segments left pointer has to chec= k if the c-flag is set when the new value of the segments left point is equ= al to zero, If the c-flag is set and the segments left pointer =3D=3D 0 then remove the= SRH, What is confusing for me is that the node that decrements the pointer is no= t the last node in the SR path (behavior similar to PHP for MPLS) , which = I find in direct contradiction with section 3. Another question if a node receives a packet with the already segment left = =3D=3D 0, what should that node do with the packet(e.g., drops it?) Bests. [Orange logo] Rabah Guedrez Th=E9sard ORANGE/IMT/OLN/WTC/IEE/ITEQ Phone: +33 2 96 07 18 56 rabah.guedrez@orange.com ___________________________________________________________________________= ______________________________________________ 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_27B26A2868951342946169C453A0DF4B22EFA891OPEXCLILM23corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

I would like some clarification about the treatment = of the  SRH by an end point (the node that its loopback matches the DA= field),

 

In section 3 :

You say that the

C-flag: Clean-up flag.  Set when the SRH has to= be removed from

         the= packet when the packet reaches the last segment.

 

 

Which mean that the last node inspects the SRH flags= if the c-flag is set, the node has to remove the SRH before sending the pa= cket to its final destination.

 

But In section 4.3.

 

You say that the node that decrements the Segments l= eft pointer has to check if the c-flag is set when the new value of the seg= ments left point is equal to zero,

If the c-flag is set and the segments left pointer = =3D=3D 0 then remove the SRH,

 

What is confusing for me is that the node that decre= ments the pointer is not the last node in the SR path (behavior similar to =  PHP for MPLS) , which I find in direct contradiction with section 3.<= o:p>

 

Another question if a node receives a packet with th= e already segment left =3D=3D 0, what should that node do with the packet(e= .g., drops it?)

 

 

Bests.

 

 

3D"Ora=

 <= o:p>

Rabah Guedrez
Th=E9sard
ORANGE/IMT/OLN/WTC/IEE/ITEQ

 <= o:p>

Phone: +33 2 96 07 18 56
rabah.guedrez@orange.com

 <= o:p>

 

______________________________________________________________________=
___________________________________________________

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_27B26A2868951342946169C453A0DF4B22EFA891OPEXCLILM23corp_-- --_004_27B26A2868951342946169C453A0DF4B22EFA891OPEXCLILM23corp_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=406; creation-date="Wed, 27 Apr 2016 13:17:57 GMT"; modification-date="Wed, 27 Apr 2016 13:17:57 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODdhKAAyAIQQAP9mAP9wEP95IP+DMP+MQP+WUP+fYP+pcP+zgP+8j//Gn//Pr//Zv//iz//s 3//17////////////////////////////////////////////////////////////////ywAAAAA KAAyAAAF/iAkjmRpnmiqrmzrvnAsz3SdMkCu73zv/zoccEj8CYvI4jHJ9C2b0Nwz2pxSk9arUhvN coHer1PMDJN35rNUvWUP02r4WU6mi+1fPFev5V/9VIBdbm+EYIZGiDkIDA8KBIJFBAgPD5A5AwwQ DgcACQygBA2bBgAMCg4QCQADqaADmZsHArABQqkJo5CbCQgNBakAEA+5EAMNDwe6jQaaAkEAAhAK AAQQjBAB0agiwjgIENY4BeHDDKOlawOq1deaOZUGo94A4OIABuUOCPwE0ADxNDWDwArCggIPCEL4 Fi4VpXDICvh6tqZaQnbvTA0LtrBeuFYQdIE0qK0ippJNHBAsIKAg3KEv4ESEiZQjAAGUP2zo3Mmz p88WIQAAOw== --_004_27B26A2868951342946169C453A0DF4B22EFA891OPEXCLILM23corp_-- From nobody Wed Apr 27 06:50:37 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DEC12D1D3; Wed, 27 Apr 2016 06:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyGBFRP4pCj8; Wed, 27 Apr 2016 06:50:33 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBAC212D5B5; Wed, 27 Apr 2016 06:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3619; q=dns/txt; s=iport; t=1461765030; x=1462974630; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OMLw8acIb04LiGlXuK0IKK/BdxopezDvClSlc0yte0s=; b=i0forHs+sPaF6U8L0bPuxjbUFmFDQM0yCtQSSafEaHKQDu7APY1m9J7B WDwxYz9deKKXeMdUQMtBOauBi9/s+sk6eq/x4TvHtVpmEd8r1MEgpH+fZ s0GcR0ubye8gnevAR0b/Op6xWdumlEMsV+REPmaQL0h/L/iThwI7wxeG2 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQBYwyBX/5hdJa1egzhTfQa5ZgENg?= =?us-ascii?q?XUXC4VtAoErOBQBAQEBAQEBZRwLhEEBAQEDAQEBAWsLBQkCAgEIGC4bDAslAQE?= =?us-ascii?q?EDgWIIggOxCwBAQEBAQEBAQEBAQEBAQEBAQEBAQERBASGHYF1glaEDxEBHCyCf?= =?us-ascii?q?4IrAQSHdIsYhQQBjhaBZ4RNhCSEOY8vAR4BAUKDa2yHeTZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,541,1454976000"; d="scan'208";a="266615337" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2016 13:50:29 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u3RDoSOs003754 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Apr 2016 13:50:29 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 27 Apr 2016 09:50:28 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Wed, 27 Apr 2016 09:50:28 -0400 From: "Stefano Previdi (sprevidi)" To: "rabah.guedrez@orange.com" Thread-Topic: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Index: AdGghvaHsYiYrA0yQJaWWWPJYYsrcgAJlBiA Date: Wed, 27 Apr 2016 13:50:28 +0000 Message-ID: <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> References: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.74.154] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "ipv6@ietf.org" Subject: Re: [spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 27 Apr 2016 13:50:36 -0000 > On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote: >=20 > Hi,=20 > I would like some clarification about the treatment of the SRH by an end= point (the node that its loopback matches the DA field), > =20 > In section 3 : > You say that the=20 > C-flag: Clean-up flag. Set when the SRH has to be removed from > the packet when the packet reaches the last segment. the text is confusing but the semantic is correct ;-) the cleanup flag is processed so that the last segment receives a packet wi= thout any SRH. However, as you figured out, the processing of the C flag is done on the se= gment before last (penultimate segment). So, probably a more accurate text = would be: C-flag: Clean-up flag. =20 Set when the SRH has to be removed from the packet prior to forward the packet=20 towards the last segment. > Which mean that the last node inspects the SRH flags if the c-flag is set= , the node has to remove the SRH before sending the packet to its final des= tination. > =20 > But In section 4.3. > =20 > You say that the node that decrements the Segments left pointer has to ch= eck if the c-flag is set when the new value of the segments left point is e= qual to zero, > If the c-flag is set and the segments left pointer =3D=3D 0 then remove t= he SRH, > =20 > What is confusing for me is that the node that decrements the pointer is = not the last node in the SR path (behavior similar to PHP for MPLS) , whic= h I find in direct contradiction with section 3. you=92re right. The node that processes the cleanup flag is the penultimate= segment, not the last. > Another question if a node receives a packet with the already segment lef= t =3D=3D 0, what should that node do with the packet(e.g., drops it?) a node receiving a packet where: 1. DA =3D=3D itself 2. a routing header is present 3. segments_left =3D=3D 0 MUST ignore the routing header and process the packet normally. This is des= cribed in RFC2460 section 4.4 s. > =20 > =20 > Bests. > =20 > =20 > > =20 > Rabah Guedrez=20 > Th=E9sard=20 > ORANGE/IMT/OLN/WTC/IEE/ITEQ > =20 > Phone: +33 2 96 07 18 56=20 > rabah.guedrez@orange.com > =20 > =20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Wed Apr 27 07:09:27 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B3012B062; Wed, 27 Apr 2016 07:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ii6vXfbYvsK0; Wed, 27 Apr 2016 07:09:21 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2998512D129; Wed, 27 Apr 2016 07:09:21 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 034D11801DF; Wed, 27 Apr 2016 16:09:20 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id C35E11A0081; Wed, 27 Apr 2016 16:09:19 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0279.002; Wed, 27 Apr 2016 16:09:19 +0200 From: To: "Stefano Previdi (sprevidi)" Thread-Topic: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Index: AdGghvaHsYiYrA0yQJaWWWPJYYsrcgAJlBiAAAgqc4A= Date: Wed, 27 Apr 2016 14:09:19 +0000 Message-ID: <17898_1461766159_5720C80F_17898_697_1_27B26A2868951342946169C453A0DF4B22EFA8B9@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> In-Reply-To: <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "ipv6@ietf.org" Subject: Re: [spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 27 Apr 2016 14:09:23 -0000 =20 Yes, i think that a more accurate description is required. I have an additional question, In section 4.1 You say that the source node initializes the Segments left & first segment = pointers to n-1, and the DA =3D segment list[n-1], Do you consider that the first segment of the SR path (the last one in the = segment list field) is the ingress or the next node in the SR path=20 For example, for the following SR path PE1-P2-P3-PE4 does the segment list = =3D=3D [PE4,P3,P2,PE1] or [PE4,P3,P2] Bests =A0 Rabah Guedrez=20 Th=E9sard=20 ORANGE/IMT/OLN/WTC/IEE/ITEQ=20 =A0 Phone: +33 2 96 07 18 56=20 rabah.guedrez@orange.com=20 =A0 -----Message d'origine----- De=A0: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 Envoy=E9=A0: mercredi 27 avril 2016 15:50 =C0=A0: GUEDREZ Rabah IMT/OLN Cc=A0: spring@ietf.org; ipv6@ietf.org Objet=A0: Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt > On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote: >=20 > Hi,=20 > I would like some clarification about the treatment of the SRH by an end= point (the node that its loopback matches the DA field), >=20=20 > In section 3 : > You say that the=20 > C-flag: Clean-up flag. Set when the SRH has to be removed from > the packet when the packet reaches the last segment. the text is confusing but the semantic is correct ;-) the cleanup flag is processed so that the last segment receives a packet wi= thout any SRH. However, as you figured out, the processing of the C flag is done on the se= gment before last (penultimate segment). So, probably a more accurate text = would be: C-flag: Clean-up flag.=20=20 Set when the SRH has to be removed from the packet prior to forward the packet=20 towards the last segment. > Which mean that the last node inspects the SRH flags if the c-flag is set= , the node has to remove the SRH before sending the packet to its final des= tination. >=20=20 > But In section 4.3. >=20=20 > You say that the node that decrements the Segments left pointer has to ch= eck if the c-flag is set when the new value of the segments left point is e= qual to zero, > If the c-flag is set and the segments left pointer =3D=3D 0 then remove t= he SRH, >=20=20 > What is confusing for me is that the node that decrements the pointer is = not the last node in the SR path (behavior similar to PHP for MPLS) , whic= h I find in direct contradiction with section 3. you're right. The node that processes the cleanup flag is the penultimate s= egment, not the last. > Another question if a node receives a packet with the already segment lef= t =3D=3D 0, what should that node do with the packet(e.g., drops it?) a node receiving a packet where: 1. DA =3D=3D itself 2. a routing header is present 3. segments_left =3D=3D 0 MUST ignore the routing header and process the packet normally. This is des= cribed in RFC2460 section 4.4 s. >=20=20 >=20=20 > Bests. >=20=20 >=20=20 > >=20=20 > Rabah Guedrez=20 > Th=E9sard=20 > ORANGE/IMT/OLN/WTC/IEE/ITEQ >=20=20 > Phone: +33 2 96 07 18 56=20 > rabah.guedrez@orange.com >=20=20 >=20=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ___________________________________________________________________________= ______________________________________________ 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 Wed Apr 27 07:15:29 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B093112D1C2; Wed, 27 Apr 2016 07:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jXrJFZ1o1wM; Wed, 27 Apr 2016 07:15:23 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2553112D169; Wed, 27 Apr 2016 07:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6168; q=dns/txt; s=iport; t=1461766523; x=1462976123; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OS4PiNdFn4BzP4MkfJZ7n4CMcxrWE3nmGdmxC44DCpM=; b=hakoqd/xP/8zMwTIpHXPa7v2Bw+YX80QnTrvRGvpG7VIVl+a2pHKXNn1 El/e/phyEDS7VTZPoZAuRsRLN2xagjZu9jCJ+7S+6LuWA6tFGNVpqf5ks 7xVLblyvObcOiUpb/7FVxo/BngN/xB7NS01wyV+XZjacj/w5BRsqcBKxj o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQDkyCBX/5BdJa1egzhTfQa5ZgENg?= =?us-ascii?q?XUXC4VtAoEsOBQBAQEBAQEBZRwLhEEBAQEDAQEBAWsLBQkCAgEIGCcHGwwLFBE?= =?us-ascii?q?BAQQOBYgiCA7EMgEBAQEBAQEBAQEBAQEBAQEBAQEBAREEBIYdgXWCVoQPEQEcL?= =?us-ascii?q?IJ/gisFh3SGGIUAhQQBjhaBZ4RNhCSEOY8vAR4BAUKDa2yHeTZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,541,1454976000"; d="scan'208";a="265943055" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2016 14:15:22 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u3REFL7v006269 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Apr 2016 14:15:22 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 27 Apr 2016 10:15:21 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Wed, 27 Apr 2016 10:15:21 -0400 From: "Stefano Previdi (sprevidi)" To: "rabah.guedrez@orange.com" Thread-Topic: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Index: AdGghvaHsYiYrA0yQJaWWWPJYYsrcgAJlBiAAAgqc4D//8WgAA== Date: Wed, 27 Apr 2016 14:15:20 +0000 Message-ID: <066165DE-5C6E-4CB7-8E2D-5A6F18AC7A20@cisco.com> References: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> <17898_1461766159_5720C80F_17898_697_1_27B26A2868951342946169C453A0DF4B22EFA8B9@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <17898_1461766159_5720C80F_17898_697_1_27B26A2868951342946169C453A0DF4B22EFA8B9@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.74.154] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8F784D23B3B3214FA332151AFCDFBD1A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "ipv6@ietf.org" Subject: Re: [spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 27 Apr 2016 14:15:25 -0000 > On Apr 27, 2016, at 4:09 PM, rabah.guedrez@orange.com wrote: >=20 >=20 > Yes, i think that a more accurate description is required. >=20 > I have an additional question, >=20 > In section 4.1 > You say that the source node initializes the Segments left & first segmen= t pointers to n-1, and the DA =3D segment list[n-1], > Do you consider that the first segment of the SR path (the last one in th= e segment list field) is the ingress or the next node in the SR path=20 not the ingress. The ingress is the node that sets the segment list.=20 > For example, for the following SR path PE1-P2-P3-PE4 does the segment lis= t =3D=3D [PE4,P3,P2,PE1] or [PE4,P3,P2] if the segment list is created at the source of the packet then it will be: [PE4,P3,P2,PE1] if the segment list is created at the ingress (PE1) then it will be: [PE4,P3,P2] s. >=20 > Bests > =20 > Rabah Guedrez=20 > Th=E9sard=20 > ORANGE/IMT/OLN/WTC/IEE/ITEQ=20 > =20 > Phone: +33 2 96 07 18 56=20 > rabah.guedrez@orange.com=20 > =20 >=20 > -----Message d'origine----- > De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 > Envoy=E9 : mercredi 27 avril 2016 15:50 > =C0 : GUEDREZ Rabah IMT/OLN > Cc : spring@ietf.org; ipv6@ietf.org > Objet : Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt >=20 >=20 >> On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote: >>=20 >> Hi,=20 >> I would like some clarification about the treatment of the SRH by an en= d point (the node that its loopback matches the DA field), >>=20 >> In section 3 : >> You say that the=20 >> C-flag: Clean-up flag. Set when the SRH has to be removed from >> the packet when the packet reaches the last segment. >=20 >=20 > the text is confusing but the semantic is correct ;-) >=20 > the cleanup flag is processed so that the last segment receives a packet = without any SRH. >=20 > However, as you figured out, the processing of the C flag is done on the = segment before last (penultimate segment). So, probably a more accurate tex= t would be: >=20 > C-flag: Clean-up flag. =20 > Set when the SRH has to be removed from > the packet prior to forward the packet=20 > towards the last segment. >=20 >=20 >=20 >> Which mean that the last node inspects the SRH flags if the c-flag is se= t, the node has to remove the SRH before sending the packet to its final de= stination. >>=20 >> But In section 4.3. >>=20 >> You say that the node that decrements the Segments left pointer has to c= heck if the c-flag is set when the new value of the segments left point is = equal to zero, >> If the c-flag is set and the segments left pointer =3D=3D 0 then remove = the SRH, >>=20 >> What is confusing for me is that the node that decrements the pointer is= not the last node in the SR path (behavior similar to PHP for MPLS) , whi= ch I find in direct contradiction with section 3. >=20 >=20 > you're right. The node that processes the cleanup flag is the penultimate= segment, not the last. >=20 >=20 >> Another question if a node receives a packet with the already segment le= ft =3D=3D 0, what should that node do with the packet(e.g., drops it?) >=20 >=20 > a node receiving a packet where: > 1. DA =3D=3D itself > 2. a routing header is present > 3. segments_left =3D=3D 0 >=20 > MUST ignore the routing header and process the packet normally. This is d= escribed in RFC2460 section 4.4 >=20 > s. >=20 >=20 >>=20 >>=20 >> Bests. >>=20 >>=20 >> >>=20 >> Rabah Guedrez=20 >> Th=E9sard=20 >> ORANGE/IMT/OLN/WTC/IEE/ITEQ >>=20 >> Phone: +33 2 96 07 18 56=20 >> rabah.guedrez@orange.com >>=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages= electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged = information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 From nobody Wed Apr 27 16:31:29 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFA912D58A for ; Wed, 27 Apr 2016 16:31:28 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mo8EX-BJZnMQ for ; Wed, 27 Apr 2016 16:31:26 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FCE112D57A for ; Wed, 27 Apr 2016 16:31:26 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-be-57214ba1166e Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id CA.FE.03614.1AB41275; Thu, 28 Apr 2016 01:30:41 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Wed, 27 Apr 2016 19:31:25 -0400 From: Uma Chunduri To: "bruno.decraene@orange.com" , "spring@ietf.org" Thread-Topic: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call Thread-Index: AdGWIcRdLnRAPWN3Qn6eVontUw9C0AAAMhXQAqz8LVA= Date: Wed, 27 Apr 2016 23:31:23 +0000 Message-ID: <1B502206DFA0C544B7A6046915200863580C54E9@eusaamb105.ericsson.se> References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10411_1460620508_570F4CDC_10411_96_23_53C29892C857584299CBF5D05346208A0F86E45F@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <10411_1460620508_570F4CDC_10411_96_23_53C29892C857584299CBF5D05346208A0F86E45F@OPEXCLILM21.corporate.adroot.infra.ftgroup> 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_1B502206DFA0C544B7A6046915200863580C54E9eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZXLonSneht2K4wbeNMhY/dsxhtjh+4Tej A5PHkiU/mTxanp1kC2CK4rJJSc3JLEst0rdL4MqY17afseBCTsXuU+1sDYwtMV2MnBwSAiYS M/t3sUPYYhIX7q1n62Lk4hASOMoo8XLpL3YIZzmjxI/9s1hBqtgE9CQ+Tv0J1iEikCTROmEj E4gtLBAiMe3WAsYuRg6geKjEl6+iECVWEktXbgYrYRFQlTj98RY7SAmvgK/ErTVSEOPbmCTW LnvIBOJwCnQwSuzsPMsI0sAIdNH3U2vAmpkFxCVuPZnPBHGpgMSSPeeZIWxRiZeP/7FC2EoS k5aeY4Woz5eYOOcvWA2vgKDEyZlPWCYwisxCMmoWkrJZSMog4joSC3Z/YoOwtSWWLXzNDGOf OfCYCVl8ASP7KkaO0uKCnNx0I8NNjMD4OSbB5riDcW+v5yFGAQ5GJR5eBVmFcCHWxLLiytxD jBIczEoivAZuiuFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeb0j/4UJCaQnlqRmp6YWpBbBZJk4 OKUaGHk5jmbduemv2f/25D4tt1nHdjK4uq5MrFPKYLoyhyvpjrpI1DHGxIl8u6fL5nH+1t68 21tUdM3byg/uk9NOFumnvHAqUVG8Uvry3TL24251Hy9ObDllkvevz1Ve4c21yl+6j33SIw7d 6Mqd9p1j3mrmrrulCWw8baZXHaZZdod9WCRkeWfDMyWW4oxEQy3mouJEAL/cDW+bAgAA Archived-At: Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 27 Apr 2016 23:31:28 -0000 --_000_1B502206DFA0C544B7A6046915200863580C54E9eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, Have few comments on the draft: 1. As I indicated during meeting - I am not sure why we have to club = verification of SIDs advertised through regular protocol reachability prefixes and the ranges advertised through 'Mapping Server'= (SRMS). I didn't see any compelling reason to do this. SIDs advertised through reachability prefixes doesn't have= ranges unlike SRMS advertisements. As SRMS advertisements are primarily for nodes which are n= ot SR capable and I feel we should not mix this with nodes which are SR ca= pable. This isolation helps restricting the resolution work primarily for = multiple SRMS entries advertised through one node or multiple nodes. SRMS advertisements are indeed little bit unique in that yo= u are advertising "configuration" on behalf of node X from node Y with ranges (both prefix ranges and SID ranges). 2. Regarding the scope of conflict resolution: Section 1 " The problem to be addressed is protocol independent i.e., se= gment related advertisements may be originated by multiple nodes using different protocols and yet the conflict resolution MUST be the sam= e on all nodes regardless of the protocol used to transport the advertisements." Section 3.2.8 " o In cases where multiple routing protocols are in use mappi= ng entries advertised by all routing protocols MUST be included." This sounds like we are seeking to resolve conflicting entries outsid= e and across the protocols? Each IGP has separate mechanism for advertising mapping entry and I t= his is not clear with the current version of the draft how we can cross ver= ify SID/Prefix conflict across the protocol. Can you clarify this? -- Uma C. -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, April 14, 2016 12:55 AM To: spring@ietf.org Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adopti= on call > From: bruno.decraene@orange.com > Sent= : Thursday, April 14, 2016 9:51 > AM > > Dear WG, > > As we discussed at our meeting last week, working group adoption has > been requested for draft-ginsberg-spring-conflict-resolution. > Please reply to the list with your comments, including although not > limited to whether or not you support adoption. We will end the call on April 29, 2016. > Thanks, > > --John and Bruno > > > > __________________________________________________________ > __________________________________________________________ > _____ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > que les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, Orange decline toute responsabilite si ce message a ete alt= ere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. > > _______________________________________________ > 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. 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 --_000_1B502206DFA0C544B7A6046915200863580C54E9eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors,
 
Have few comments on the draft:
 
1. 
        As I indicated during meeti= ng - I am not sure why we have to club  verification of SIDs advertise= d through regular protocol reachability
           &nbs= p;    prefixes and the ranges advertised through 'Mapping Se= rver'  (SRMS). I didn't see any compelling reason to do this.
           &nbs= p;     SIDs advertised through reachability prefixes do= esn't have ranges unlike SRMS advertisements. 
           &nbs= p;     As SRMS advertisements are primarily for nodes w= hich are not SR capable and  I feel we should not mix this with nodes = which are SR capable.
 
        This isolation helps restri= cting the resolution work primarily for multiple SRMS entries advertised th= rough one node or multiple nodes.
           &nbs= p;    SRMS advertisements are indeed little bit unique in th= at you are advertising "configuration" on behalf of node X from n= ode Y
           &nbs= p;    with ranges (both prefix ranges and SID ranges).
 
 
2. 
           &nbs= p;    Regarding  the scope of conflict resolution:
 
 
       Section 1
 
           "=    The problem to be addressed is protocol independent i.e= ., segment
         related adv= ertisements may be originated by multiple nodes using
         different p= rotocols and yet the conflict resolution MUST be the same
         on all node= s regardless of the protocol used to transport the
         advertiseme= nts."
 
        Section 3.2.8
          "   o  In cases where multiple routing protocols are in use = mapping
      entries advertised by all routing pr= otocols MUST be included."
 
      This sounds like we are seeking to reso= lve conflicting entries outside and across the protocols?
      Each IGP has separate mechanism for adv= ertising mapping entry and I this is not clear with the current version of = the draft how we can cross verify SID/Prefix conflict across  the prot= ocol.
     Can you clarify this?
 
 
--
Uma C.
 
 
-----Original Message-----
From: spring [mailto:spring-boun= ces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Thursday, April 14, 2016 12:55 AM
To: spring@ietf.org
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adopti= on call
 
> From:  bruno.de= craene@orange.com > Sent: Thursday, April 14, 2016 9:51
> AM
>
> Dear WG,
>
> As we discussed at our meeting last week, working group adoption = has
> been requested for draft-ginsberg-spring-conflict-resolution.
> Please reply to the list with your comments, including although n= ot
> limited to whether or not you support adoption.
 
We will end the call on April 29, 2016.
 
 
> Thanks,
>
> --John and Bruno
>
>
>
> __________________________________________________________
> __________________________________________________________
> _____
>
> Ce message et ses pieces jointes peuvent contenir des information= s
> confidentielles ou privilegiees et ne doivent donc pas etre diffu= ses,
> exploites ou copies sans autorisation. Si vous avez recu ce messa= ge
> par erreur, veuillez le signaler a l'expediteur et le detruire ai= nsi
> que les pieces jointes. Les messages electroniques etant suscepti= bles
> d'alteration, Orange decline toute responsabilite si ce message a= ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should = not
> be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sende= r and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that = have
> been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> spring mailing list
 
______________________________________________________________________= ___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploite= s ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques eta= nt susceptibles d'alteration, Orange decline toute responsabilite si ce mes= sage a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege= d information that may be protected by law; they should not be distributed,= used or copied without authorisation.
If you have received this email in error, please notify the sender and= delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified.
Thank you.
 
_______________________________________________
spring mailing list
 
 --_000_1B502206DFA0C544B7A6046915200863580C54E9eusaamb105erics_-- From nobody Thu Apr 28 02:14:00 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D6512D5F6; Thu, 28 Apr 2016 02:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjhpDTMa3Kmd; Thu, 28 Apr 2016 02:13:54 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F233112D0B9; Thu, 28 Apr 2016 02:13:52 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 814B1C056C; Thu, 28 Apr 2016 11:13:51 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 4FF1E1A0082; Thu, 28 Apr 2016 11:13:51 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0279.002; Thu, 28 Apr 2016 11:13:51 +0200 From: To: "Stefano Previdi (sprevidi)" Thread-Topic: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Index: AdGghvaHsYiYrA0yQJaWWWPJYYsrcgAJlBiAACAEHnA= Date: Thu, 28 Apr 2016 09:13:50 +0000 Message-ID: <10381_1461834831_5721D44F_10381_307_1_27B26A2868951342946169C453A0DF4B22EFAEDC@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> In-Reply-To: <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "ipv6@ietf.org" Subject: Re: [spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 28 Apr 2016 09:13:56 -0000 =A0 Rabah Guedrez=20 Th=E9sard=20 ORANGE/IMT/OLN/WTC/IEE/ITEQ=20 =A0 Phone: +33 2 96 07 18 56=20 rabah.guedrez@orange.com=20 =A0 -----Message d'origine----- De=A0: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 Envoy=E9=A0: mercredi 27 avril 2016 15:50 =C0=A0: GUEDREZ Rabah IMT/OLN Cc=A0: spring@ietf.org; ipv6@ietf.org Objet=A0: Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt > On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote: >=20 > Hi,=20 > I would like some clarification about the treatment of the SRH by an end= point (the node that its loopback matches the DA field), >=20=20 > In section 3 : > You say that the=20 > C-flag: Clean-up flag. Set when the SRH has to be removed from > the packet when the packet reaches the last segment. the text is confusing but the semantic is correct ;-) the cleanup flag is processed so that the last segment receives a packet wi= thout any SRH. However, as you figured out, the processing of the C flag is done on the se= gment before last (penultimate segment). So, probably a more accurate text = would be: C-flag: Clean-up flag.=20=20 Set when the SRH has to be removed from the packet prior to forward the packet=20 towards the last segment. > Which mean that the last node inspects the SRH flags if the c-flag is set= , the node has to remove the SRH before sending the packet to its final des= tination. >=20=20 > But In section 4.3. >=20=20 > You say that the node that decrements the Segments left pointer has to ch= eck if the c-flag is set when the new value of the segments left point is e= qual to zero, > If the c-flag is set and the segments left pointer =3D=3D 0 then remove t= he SRH, >=20=20 > What is confusing for me is that the node that decrements the pointer is = not the last node in the SR path (behavior similar to PHP for MPLS) , whic= h I find in direct contradiction with section 3. you're right. The node that processes the cleanup flag is the penultimate s= egment, not the last. > Another question if a node receives a packet with the already segment lef= t =3D=3D 0, what should that node do with the packet(e.g., drops it?) a node receiving a packet where: 1. DA =3D=3D itself 2. a routing header is present 3. segments_left =3D=3D 0 MUST ignore the routing header and process the packet normally. This is des= cribed in RFC2460 section 4.4 Rabah : >>>>>> do you consider that the c-flag must be set for all the pack= ets. if we consider that setting the c-flag is not obligatory, then the egress= would receive an SRH with : 1. DA =3D=3D itself 2. a routing header is present 3. segments_left =3D=3D 0 The SRH has to be ignored based on RFC2460, is that corrects= ? which in my opinion is not the intended behavior . s. Rabah >=20=20 >=20=20 > Bests. >=20=20 >=20=20 > >=20=20 > Rabah Guedrez=20 > Th=E9sard=20 > ORANGE/IMT/OLN/WTC/IEE/ITEQ >=20=20 > Phone: +33 2 96 07 18 56=20 > rabah.guedrez@orange.com >=20=20 >=20=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- ___________________________________________________________________________= ______________________________________________ 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 Apr 28 03:30:53 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432D212D64C; Thu, 28 Apr 2016 03:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QQXcyrxAY-o; Thu, 28 Apr 2016 03:30:50 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D347912D647; Thu, 28 Apr 2016 03:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6366; q=dns/txt; s=iport; t=1461839449; x=1463049049; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=75tp9V5n8n42Pki6kHMWxC4tmiN/Al9F+aqPyGAVW6s=; b=DQMtAHwco5pAFyH4KT87k09ViS/NJGYj0wRerg13xm6agjAe2G7sn2Ei G9VvsQ9tNS2c2T1nxCoETq35a2AggpcZME0wVUC70IA/doVm6JghRgz2B HFi0jH4sePyyI5cN85DCLMXCk4nYfXtTblyhmCo8KbwYQTWbkxSei801U o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAgDD5SFX/4sNJK1egzhTfQa5bQENg?= =?us-ascii?q?XYXC4VtAoEjOBQBAQEBAQEBZRwLhEEBAQEDAQEBAWsLBQkCAgEIGCcHGwwLFBE?= =?us-ascii?q?BAQQOBYgiCA7DFgEBAQEBAQEBAQEBAQEBAQEBAQEBAREEBIYdgXWCVoQPEQEcL?= =?us-ascii?q?IJ/gisBBId0ixiFBAGOFoFnhE2EJIQ5jy8BHgEBQoNrbIgBNn8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,546,1454976000"; d="scan'208";a="265322724" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Apr 2016 10:30:48 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u3SAUmte000434 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 10:30:48 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Apr 2016 06:30:47 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Thu, 28 Apr 2016 06:30:47 -0400 From: "Stefano Previdi (sprevidi)" To: "rabah.guedrez@orange.com" Thread-Topic: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Index: AdGghvaHsYiYrA0yQJaWWWPJYYsrcgAJlBiAACAEHnAAC00uAA== Date: Thu, 28 Apr 2016 10:30:47 +0000 Message-ID: <8250BFA4-F21A-433A-899B-7E68C5219BC1@cisco.com> References: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> <10381_1461834831_5721D44F_10381_307_1_27B26A2868951342946169C453A0DF4B22EFAEDC@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <10381_1461834831_5721D44F_10381_307_1_27B26A2868951342946169C453A0DF4B22EFAEDC@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.238.46] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9B3DB3A1A6268F49867C1361A2A53A56@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "ipv6@ietf.org" Subject: Re: [spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 28 Apr 2016 10:30:52 -0000 On Apr 28, 2016, at 11:13 AM, rabah.guedrez@orange.com wrote: >=20 > Rabah Guedrez=20 > Th=E9sard=20 > ORANGE/IMT/OLN/WTC/IEE/ITEQ=20 > =20 > Phone: +33 2 96 07 18 56=20 > rabah.guedrez@orange.com=20 > =20 >=20 >=20 > -----Message d'origine----- > De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 > Envoy=E9 : mercredi 27 avril 2016 15:50 > =C0 : GUEDREZ Rabah IMT/OLN > Cc : spring@ietf.org; ipv6@ietf.org > Objet : Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt >=20 >=20 >> On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote: >>=20 >> Hi,=20 >> I would like some clarification about the treatment of the SRH by an en= d point (the node that its loopback matches the DA field), >>=20 >> In section 3 : >> You say that the=20 >> C-flag: Clean-up flag. Set when the SRH has to be removed from >> the packet when the packet reaches the last segment. >=20 >=20 > the text is confusing but the semantic is correct ;-) >=20 > the cleanup flag is processed so that the last segment receives a packet = without any SRH. >=20 > However, as you figured out, the processing of the C flag is done on the = segment before last (penultimate segment). So, probably a more accurate tex= t would be: >=20 > C-flag: Clean-up flag. =20 > Set when the SRH has to be removed from > the packet prior to forward the packet=20 > towards the last segment. >=20 >=20 >=20 >> Which mean that the last node inspects the SRH flags if the c-flag is se= t, the node has to remove the SRH before sending the packet to its final de= stination. >>=20 >> But In section 4.3. >>=20 >> You say that the node that decrements the Segments left pointer has to c= heck if the c-flag is set when the new value of the segments left point is = equal to zero, >> If the c-flag is set and the segments left pointer =3D=3D 0 then remove = the SRH, >>=20 >> What is confusing for me is that the node that decrements the pointer is= not the last node in the SR path (behavior similar to PHP for MPLS) , whi= ch I find in direct contradiction with section 3. >=20 >=20 > you're right. The node that processes the cleanup flag is the penultimate= segment, not the last. >=20 >=20 >> Another question if a node receives a packet with the already segment le= ft =3D=3D 0, what should that node do with the packet(e.g., drops it?) >=20 >=20 > a node receiving a packet where: > 1. DA =3D=3D itself > 2. a routing header is present > 3. segments_left =3D=3D 0 >=20 > MUST ignore the routing header and process the packet normally. This is d= escribed in RFC2460 section 4.4 >=20 > Rabah : >>>>>> do you consider that the c-flag must be set for all the pa= ckets. no. The c-flag is to be set when you insert an SRH into an existing packet. You set the c-flag so to be sure the SRH is removed before delivering the p= acket to its intended destination. > if we consider that setting the c-flag is not obligatory, then the egres= s would receive an SRH with : > 1. DA =3D=3D itself > 2. a routing header is present > 3. segments_left =3D=3D 0 when you use encapsulation and you don=92t set the c-flag, then the egress = receives the packet as you described above. > The SRH has to be ignored based on RFC2460, is that correct= s ? yes, the above is normal behavior when the path is completed (i.e.: all seg= ments have been processed and the DA is the intended destination of the pac= ket). > which in my opinion is not the intended behavior . can you explain what you mean by =93not the intended behavior=94 ? s. > s. > Rabah >=20 >>=20 >>=20 >> Bests. >>=20 >>=20 >> >>=20 >> Rabah Guedrez=20 >> Th=E9sard=20 >> ORANGE/IMT/OLN/WTC/IEE/ITEQ >>=20 >> Phone: +33 2 96 07 18 56=20 >> rabah.guedrez@orange.com >>=20 >>=20 >> ________________________________________________________________________= _________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages= electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged = information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 From nobody Thu Apr 28 03:58:21 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286A512D658; Thu, 28 Apr 2016 03:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K2iXzwFDGGA; Thu, 28 Apr 2016 03:58:15 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F7B12D114; Thu, 28 Apr 2016 03:58:14 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 383F72065D; Thu, 28 Apr 2016 12:58:13 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 1161F1A0075; Thu, 28 Apr 2016 12:58:13 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0279.002; Thu, 28 Apr 2016 12:58:13 +0200 From: To: "Stefano Previdi (sprevidi)" Thread-Topic: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Index: AdGghvaHsYiYrA0yQJaWWWPJYYsrcgAJlBiAACAEHnAAC00uAAAH55oQ Date: Thu, 28 Apr 2016 10:58:12 +0000 Message-ID: <8941_1461841093_5721ECC5_8941_18000_1_27B26A2868951342946169C453A0DF4B22EFAF03@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> <10381_1461834831_5721D44F_10381_307_1_27B26A2868951342946169C453A0DF4B22EFAEDC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <8250BFA4-F21A-433A-899B-7E68C5219BC1@cisco.com> In-Reply-To: <8250BFA4-F21A-433A-899B-7E68C5219BC1@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "ipv6@ietf.org" Subject: Re: [spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 28 Apr 2016 10:58:17 -0000 You have said in a previous response to a question that the draft only cons= ider the encapsulation of client packet into a new IPV6 header with SRH, an= d not adding only an SRH to an existing packet. Which make sense especially for service providers who would prefer to tunne= l client traffic (not modify the header of the client packets for security= reasons). If you only consider encapsulation, does keeping c-flag relevant? =A0 Rabah Guedrez=20 Th=E9sard=20 ORANGE/IMT/OLN/WTC/IEE/ITEQ=20 =A0 Phone: +33 2 96 07 18 56=20 rabah.guedrez@orange.com=20 =A0 -----Message d'origine----- De=A0: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 Envoy=E9=A0: jeudi 28 avril 2016 12:31 =C0=A0: GUEDREZ Rabah IMT/OLN Cc=A0: spring@ietf.org; ipv6@ietf.org Objet=A0: Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt On Apr 28, 2016, at 11:13 AM, rabah.guedrez@orange.com wrote: >=20 > Rabah Guedrez > Th=E9sard > ORANGE/IMT/OLN/WTC/IEE/ITEQ >=20=20 > Phone: +33 2 96 07 18 56 > rabah.guedrez@orange.com >=20=20 >=20 >=20 > -----Message d'origine----- > De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9 :=20 > mercredi 27 avril 2016 15:50 =C0 : GUEDREZ Rabah IMT/OLN Cc :=20 > spring@ietf.org; ipv6@ietf.org Objet : Re: I-D Action:=20 > draft-ietf-6man-segment-routing-header-01.txt >=20 >=20 >> On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote: >>=20 >> Hi, >> I would like some clarification about the treatment of the SRH by an=20 >> end point (the node that its loopback matches the DA field), >>=20 >> In section 3 : >> You say that the >> C-flag: Clean-up flag. Set when the SRH has to be removed from >> the packet when the packet reaches the last segment. >=20 >=20 > the text is confusing but the semantic is correct ;-) >=20 > the cleanup flag is processed so that the last segment receives a packet = without any SRH. >=20 > However, as you figured out, the processing of the C flag is done on the = segment before last (penultimate segment). So, probably a more accurate tex= t would be: >=20 > C-flag: Clean-up flag.=20=20 > Set when the SRH has to be removed from > the packet prior to forward the packet=20 > towards the last segment. >=20 >=20 >=20 >> Which mean that the last node inspects the SRH flags if the c-flag is se= t, the node has to remove the SRH before sending the packet to its final de= stination. >>=20 >> But In section 4.3. >>=20 >> You say that the node that decrements the Segments left pointer has=20 >> to check if the c-flag is set when the new value of the segments left=20 >> point is equal to zero, If the c-flag is set and the segments left=20 >> pointer =3D=3D 0 then remove the SRH, >>=20 >> What is confusing for me is that the node that decrements the pointer is= not the last node in the SR path (behavior similar to PHP for MPLS) , whi= ch I find in direct contradiction with section 3. >=20 >=20 > you're right. The node that processes the cleanup flag is the penultimate= segment, not the last. >=20 >=20 >> Another question if a node receives a packet with the already segment=20 >> left =3D=3D 0, what should that node do with the packet(e.g., drops it?) >=20 >=20 > a node receiving a packet where: > 1. DA =3D=3D itself > 2. a routing header is present > 3. segments_left =3D=3D 0 >=20 > MUST ignore the routing header and process the packet normally. This=20 > is described in RFC2460 section 4.4 >=20 > Rabah : >>>>>> do you consider that the c-flag must be set for all the pa= ckets. no. The c-flag is to be set when you insert an SRH into an existing packet. You set the c-flag so to be sure the SRH is removed before delivering the p= acket to its intended destination. > if we consider that setting the c-flag is not obligatory, then the egres= s would receive an SRH with : > 1. DA =3D=3D itself > 2. a routing header is present > 3. segments_left =3D=3D 0 when you use encapsulation and you don't set the c-flag, then the egress re= ceives the packet as you described above. > The SRH has to be ignored based on RFC2460, is that correct= s ? yes, the above is normal behavior when the path is completed (i.e.: all seg= ments have been processed and the DA is the intended destination of the pac= ket). > which in my opinion is not the intended behavior . can you explain what you mean by "not the intended behavior" ? s. > s. > Rabah >=20 >>=20 >>=20 >> Bests. >>=20 >>=20 >> >>=20 >> Rabah Guedrez >> Th=E9sard >> ORANGE/IMT/OLN/WTC/IEE/ITEQ >>=20 >> Phone: +33 2 96 07 18 56 >> rabah.guedrez@orange.com >>=20 >>=20 >> _____________________________________________________________________ >> ____________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 >=20 > ______________________________________________________________________ > ___________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 ___________________________________________________________________________= ______________________________________________ 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 Apr 28 04:46:08 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7362A12B022; Thu, 28 Apr 2016 04:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1scRvqhsqhu; Thu, 28 Apr 2016 04:46:04 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90B1912D12A; Thu, 28 Apr 2016 04:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20706; q=dns/txt; s=iport; t=1461843964; x=1463053564; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Slu7o+S9hamIvEQG78ht9YDX26/8U2qdTr8oFzA8/hA=; b=Mk7BGKOpl6SODtb5xVNh30IcFQ/QBQS9QPs70Cz3wEVZTCAZegdOgWHe 2Ri1EnY5lvkNJwsqIzsEiDSJMz1DPpew1pIjI7DyGwKKxqfPk0CHdBYfq Vbrd4CfQdmiiWqP/VXVROok43pbv+QcOJCrTxE+FE+P33G/pTV45FWmW7 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAgDg9iFX/5JdJa1egmxMU321AIRzA?= =?us-ascii?q?Q2BdhcBCoVtAoEkOBQBAQEBAQEBZRwLhEEBAQEDAQEBASpBCwUHAgICAQgVAgE?= =?us-ascii?q?nBxsMCxQJCAIEDgUIiBoIDsJ3AQEBAQEBAQEBAQEBAQEBAQEBAQEBEQQEhh2DS?= =?us-ascii?q?YEChA8RASImCoUgBYd0hhiFAIUEAY4PgW6ETYQkhDmPLwEeAQFCggUbgUtsiAG?= =?us-ascii?q?BNQEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,546,1454976000"; d="scan'208,217";a="101545491" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Apr 2016 11:46:02 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u3SBk2YJ024919 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 11:46:02 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Apr 2016 07:46:01 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Thu, 28 Apr 2016 07:46:01 -0400 From: "Stefano Previdi (sprevidi)" To: "rabah.guedrez@orange.com" Thread-Topic: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Index: AQHRoTzev8IxaMPY3kOJ15ohq3wgDJ+fRJn9 Date: Thu, 28 Apr 2016 11:46:01 +0000 Message-ID: <94e2e9c6597f454ba42a699b2a2ffed8@XCH-RTP-010.cisco.com> References: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> <10381_1461834831_5721D44F_10381_307_1_27B26A2868951342946169C453A0DF4B22EFAEDC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <8250BFA4-F21A-433A-899B-7E68C5219BC1@cisco.com>, <8941_1461841093_5721ECC5_8941_18000_1_27B26A2868951342946169C453A0DF4B22EFAF03@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <8941_1461841093_5721ECC5_8941_18000_1_27B26A2868951342946169C453A0DF4B22EFAF03@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_94e2e9c6597f454ba42a699b2a2ffed8XCHRTP010ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "ipv6@ietf.org" Subject: Re: [spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 28 Apr 2016 11:46:06 -0000 --_000_94e2e9c6597f454ba42a699b2a2ffed8XCHRTP010ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There are many operators and use cases where, instead of encapsulation, srh= insertion is a far better option. In fact all current implementations are doing srh insertion. Still, from a spec perspective, the srh processis the same. s. -----Original Message----- From: rabah.guedrez@orange.com [rabah.guedrez@orange.com] Received: Thursday, 28 Apr 2016, 12:58 To: Stefano Previdi (sprevidi) [sprevidi@cisco.com] CC: spring@ietf.org [spring@ietf.org]; ipv6@ietf.org [ipv6@ietf.org] Subject: RE: I-D Action: draft-ietf-6man-segment-routing-header-01.txt You have said in a previous response to a question that the draft only cons= ider the encapsulation of client packet into a new IPV6 header with SRH, an= d not adding only an SRH to an existing packet. Which make sense especially for service providers who would prefer to tunne= l client traffic (not modify the header of the client packets for security= reasons). If you only consider encapsulation, does keeping c-flag relevant? Rabah Guedrez Th=E9sard ORANGE/IMT/OLN/WTC/IEE/ITEQ Phone: +33 2 96 07 18 56 rabah.guedrez@orange.com -----Message d'origine----- De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9 : jeudi 28 avril 2016 12:31 =C0 : GUEDREZ Rabah IMT/OLN Cc : spring@ietf.org; ipv6@ietf.org Objet : Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt On Apr 28, 2016, at 11:13 AM, rabah.guedrez@orange.com wrote: > > Rabah Guedrez > Th=E9sard > ORANGE/IMT/OLN/WTC/IEE/ITEQ > > Phone: +33 2 96 07 18 56 > rabah.guedrez@orange.com > > > > -----Message d'origine----- > De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9 : > mercredi 27 avril 2016 15:50 =C0 : GUEDREZ Rabah IMT/OLN Cc : > spring@ietf.org; ipv6@ietf.org Objet : Re: I-D Action: > draft-ietf-6man-segment-routing-header-01.txt > > >> On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote: >> >> Hi, >> I would like some clarification about the treatment of the SRH by an >> end point (the node that its loopback matches the DA field), >> >> In section 3 : >> You say that the >> C-flag: Clean-up flag. Set when the SRH has to be removed from >> the packet when the packet reaches the last segment. > > > the text is confusing but the semantic is correct ;-) > > the cleanup flag is processed so that the last segment receives a packet = without any SRH. > > However, as you figured out, the processing of the C flag is done on the = segment before last (penultimate segment). So, probably a more accurate tex= t would be: > > C-flag: Clean-up flag. > Set when the SRH has to be removed from > the packet prior to forward the packet > towards the last segment. > > > >> Which mean that the last node inspects the SRH flags if the c-flag is se= t, the node has to remove the SRH before sending the packet to its final de= stination. >> >> But In section 4.3. >> >> You say that the node that decrements the Segments left pointer has >> to check if the c-flag is set when the new value of the segments left >> point is equal to zero, If the c-flag is set and the segments left >> pointer =3D=3D 0 then remove the SRH, >> >> What is confusing for me is that the node that decrements the pointer is= not the last node in the SR path (behavior similar to PHP for MPLS) , whi= ch I find in direct contradiction with section 3. > > > you're right. The node that processes the cleanup flag is the penultimate= segment, not the last. > > >> Another question if a node receives a packet with the already segment >> left =3D=3D 0, what should that node do with the packet(e.g., drops it?) > > > a node receiving a packet where: > 1. DA =3D=3D itself > 2. a routing header is present > 3. segments_left =3D=3D 0 > > MUST ignore the routing header and process the packet normally. This > is described in RFC2460 section 4.4 > > Rabah : >>>>>> do you consider that the c-flag must be set for all the pa= ckets. no. The c-flag is to be set when you insert an SRH into an existing packet. You set the c-flag so to be sure the SRH is removed before delivering the p= acket to its intended destination. > if we consider that setting the c-flag is not obligatory, then the egres= s would receive an SRH with : > 1. DA =3D=3D itself > 2. a routing header is present > 3. segments_left =3D=3D 0 when you use encapsulation and you don't set the c-flag, then the egress re= ceives the packet as you described above. > The SRH has to be ignored based on RFC2460, is that correct= s ? yes, the above is normal behavior when the path is completed (i.e.: all seg= ments have been processed and the DA is the intended destination of the pac= ket). > which in my opinion is not the intended behavior . can you explain what you mean by "not the intended behavior" ? s. > s. > Rabah > >> >> >> Bests. >> >> >> >> >> Rabah Guedrez >> Th=E9sard >> ORANGE/IMT/OLN/WTC/IEE/ITEQ >> >> Phone: +33 2 96 07 18 56 >> rabah.guedrez@orange.com >> >> >> _____________________________________________________________________ >> ____________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > ___________________________________________________________________________= ______________________________________________ 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_94e2e9c6597f454ba42a699b2a2ffed8XCHRTP010ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
There are many operators and use cases where, instead of e= ncapsulation, srh insertion is a far better option.

In fact all current implementations are doing srh insertion.

Still, from a spec perspective, the srh processis the same.

s.

-----Original Message-----
From: rabah.guedrez@orange.com [rabah.guedrez@orange.com]
Received: Thursday, 28 Apr 2016, 12:58
To: Stefano Previdi (sprevidi) [sprevidi@cisco.com]
CC: spring@ietf.org [spring@ietf.org]; ipv6@ietf.org [ipv6@ietf.org]=
Subject: RE: I-D Action: draft-ietf-6man-segment-routing-header-01.t= xt

You have said in a previous response to a question= that the draft only consider the encapsulation of client packet into a new= IPV6 header with SRH, and not adding only an SRH to an existing packet. Which make sense especially for service providers who would prefer to tunne= l client traffic  (not modify the header of the client packets for sec= urity reasons).

If you only consider encapsulation, does keeping  c-flag relevant?
 
Rabah Guedrez
Th=E9sard
ORANGE/IMT/OLN/WTC/IEE/ITEQ
 
Phone: +33 2 96 07 18 56
rabah.guedrez@orange.com
 


-----Message d'origine-----
De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
Envoy=E9 : jeudi 28 avril 2016 12:31
=C0 : GUEDREZ Rabah IMT/OLN
Cc : spring@ietf.org; ipv6@ietf.org
Objet : Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt<= br>
On Apr 28, 2016, at 11:13 AM, rabah.guedrez@orange.com wrote:
>
> Rabah Guedrez
> Th=E9sard
> ORANGE/IMT/OLN/WTC/IEE/ITEQ
> 
> Phone: +33 2 96 07 18 56
> rabah.guedrez@orange.com
> 
>
>
> -----Message d'origine-----
> De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9 :
> mercredi 27 avril 2016 15:50 =C0 : GUEDREZ Rabah IMT/OLN Cc :
> spring@ietf.org; ipv6@ietf.org Objet : Re: I-D Action:
> draft-ietf-6man-segment-routing-header-01.txt
>
>
>> On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote:
>>
>> Hi,
>> I would like some clarification about the treatment of the  S= RH by an
>> end point (the node that its loopback matches the DA field),
>>
>> In section 3 :
>> You say that the
>> C-flag: Clean-up flag.  Set when the SRH has to be removed fr= om
>>         the packet when th= e packet reaches the last segment.
>
>
> the text is confusing but the semantic is correct ;-)
>
> the cleanup flag is processed so that the last segment receives a pack= et without any SRH.
>
> However, as you figured out, the processing of the C flag is done on t= he segment before last (penultimate segment). So, probably a more accurate = text would be:
>
>  C-flag: Clean-up flag. 
>          Set when the SRH= has to be removed from
>          the packet prior= to forward the packet
>          towards the last= segment.
>
>
>
>> Which mean that the last node inspects the SRH flags if the c-flag= is set, the node has to remove the SRH before sending the packet to its fi= nal destination.
>>
>> But In section 4.3.
>>
>> You say that the node that decrements the Segments left pointer ha= s
>> to check if the c-flag is set when the new value of the segments l= eft
>> point is equal to zero, If the c-flag is set and the segments left=
>> pointer =3D=3D 0 then remove the SRH,
>>
>> What is confusing for me is that the node that decrements the poin= ter is not the last node in the SR path (behavior similar to  PHP for = MPLS) , which I find in direct contradiction with section 3.
>
>
> you're right. The node that processes the cleanup flag is the penultim= ate segment, not the last.
>
>
>> Another question if a node receives a packet with the already segm= ent
>> left =3D=3D 0, what should that node do with the packet(e.g., drop= s it?)
>
>
> a node receiving a packet where:
>        1. DA =3D=3D itself
>        2. a routing header is prese= nt
>        3. segments_left =3D=3D 0 >
> MUST ignore the routing header and process the packet normally. This <= br> > is described in RFC2460 section 4.4
>
> Rabah : >>>>>> do you consider that the c-flag must = be set for all the packets.


no.

The c-flag is to be set when you insert an SRH into an existing packet.

You set the c-flag so to be sure the SRH is removed before delivering the p= acket to its intended destination.


> if we consider that setting the c-flag is not obligatory, then the&nbs= p; egress would receive an SRH with :
>            = ;   1. DA =3D=3D itself
>        2. a routing header is prese= nt
>        3. segments_left =3D=3D 0

when you use encapsulation and you don't set the c-flag, then the egress re= ceives the packet as you described above.


>            = ;   The SRH has to be ignored based on RFC2460, is that corrects = ?


yes, the above is normal behavior when the path is completed (i.e.: all seg= ments have been processed and the DA is the intended destination of the pac= ket).


> which in my opinion is not the intended behavior .


can you explain what you mean by "not the intended behavior" ?
s.


> s.
> Rabah
>
>>
>>
>> Bests.
>>
>>
>> <image001.gif>
>>
>> Rabah Guedrez
>> Th=E9sard
>> ORANGE/IMT/OLN/WTC/IEE/ITEQ
>>
>> Phone: +33 2 96 07 18 56
>> rabah.guedrez@orange.com
>>
>>
>> __________________________________________________________________= ___
>> ____________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations=
>> confidentielles ou privilegiees et ne doivent donc pas etre diffus= es,
>> exploites ou copies sans autorisation. Si vous avez recu ce messag= e
>> par erreur, veuillez le signaler a l'expediteur et le detruire ain= si que les pieces jointes. Les messages electroniques etant susceptibles d'= alteration, Orange decline toute responsabilite si ce message a ete altere,= deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should n= ot be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender= and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that h= ave been modified, changed or falsified.
>> Thank you.
>>
>> ------------------------------------------------------------------= --
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> ------------------------------------------------------------------= --
>
>
> ______________________________________________________________________=
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, =
> exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi q= ue les pieces jointes. Les messages electroniques etant susceptibles d'alte= ration, Orange decline toute responsabilite si ce message a ete altere, def= orme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and= delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified.
> Thank you.
>


___________________________________________________________________________= ______________________________________________

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_94e2e9c6597f454ba42a699b2a2ffed8XCHRTP010ciscocom_-- From nobody Fri Apr 29 00:29:29 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F0512D0D9; Fri, 29 Apr 2016 00:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DjVN2XTjOCL; Fri, 29 Apr 2016 00:29:21 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4E68126FDC; Fri, 29 Apr 2016 00:29:20 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 25C8A180B73; Fri, 29 Apr 2016 09:29:19 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id E3D9A1A007D; Fri, 29 Apr 2016 09:29:18 +0200 (CEST) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0279.002; Fri, 29 Apr 2016 09:29:18 +0200 From: To: "Stefano Previdi (sprevidi)" Thread-Topic: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Index: AdGghvaHsYiYrA0yQJaWWWPJYYsrcgAJlBiAACAEHnAAC00uAAAH55oQ//9xNoD//pPp8A== Date: Fri, 29 Apr 2016 07:29:17 +0000 Message-ID: <7413_1461914959_57230D4E_7413_292_1_27B26A2868951342946169C453A0DF4B22EFB6EB@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> <10381_1461834831_5721D44F_10381_307_1_27B26A2868951342946169C453A0DF4B22EFAEDC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <8250BFA4-F21A-433A-899B-7E68C5219BC1@cisco.com>, <8941_1461841093_5721ECC5_8941_18000_1_27B26A2868951342946169C453A0DF4B22EFAF03@OPEXCLILM23.corporate.adroot.infra.ftgroup> <94e2e9c6597f454ba42a699b2a2ffed8@XCH-RTP-010.cisco.com> In-Reply-To: <94e2e9c6597f454ba42a699b2a2ffed8@XCH-RTP-010.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/related; boundary="_004_27B26A2868951342946169C453A0DF4B22EFB6EBOPEXCLILM23corp_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "ipv6@ietf.org" Subject: Re: [spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 29 Apr 2016 07:29:24 -0000 --_004_27B26A2868951342946169C453A0DF4B22EFB6EBOPEXCLILM23corp_ Content-Type: multipart/alternative; boundary="_000_27B26A2868951342946169C453A0DF4B22EFB6EBOPEXCLILM23corp_" --_000_27B26A2868951342946169C453A0DF4B22EFB6EBOPEXCLILM23corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If we consider SRH insertion with IPv6 PHP, the original destination addres= s would be lost when removing the SRH, The packet reaches the egress with a DA that matches egress address, but no= other information how to forward the packet to its final destination [Orange logo] Rabah Guedrez Th=E9sard ORANGE/IMT/OLN/WTC/IEE/ITEQ Phone: +33 2 96 07 18 56 rabah.guedrez@orange.com De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9 : jeudi 28 avril 2016 13:46 =C0 : GUEDREZ Rabah IMT/OLN Cc : spring@ietf.org; ipv6@ietf.org Objet : RE: I-D Action: draft-ietf-6man-segment-routing-header-01.txt There are many operators and use cases where, instead of encapsulation, srh= insertion is a far better option. In fact all current implementations are doing srh insertion. Still, from a spec perspective, the srh processis the same. s. -----Original Message----- From: rabah.guedrez@orange.com [rabah.gued= rez@orange.com] Received: Thursday, 28 Apr 2016, 12:58 To: Stefano Previdi (sprevidi) [sprevidi@cisco.com] CC: spring@ietf.org [spring@ietf.org]; ipv6@ietf.or= g [ipv6@ietf.org] Subject: RE: I-D Action: draft-ietf-6man-segment-routing-header-01.txt You have said in a previous response to a question that the draft only cons= ider the encapsulation of client packet into a new IPV6 header with SRH, an= d not adding only an SRH to an existing packet. Which make sense especially for service providers who would prefer to tunne= l client traffic (not modify the header of the client packets for security= reasons). If you only consider encapsulation, does keeping c-flag relevant? Rabah Guedrez Th=E9sard ORANGE/IMT/OLN/WTC/IEE/ITEQ Phone: +33 2 96 07 18 56 rabah.guedrez@orange.com -----Message d'origine----- De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9 : jeudi 28 avril 2016 12:31 =C0 : GUEDREZ Rabah IMT/OLN Cc : spring@ietf.org; ipv6@ietf.org Objet : Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt On Apr 28, 2016, at 11:13 AM, rabah.guedrez@orange.com wrote: > > Rabah Guedrez > Th=E9sard > ORANGE/IMT/OLN/WTC/IEE/ITEQ > > Phone: +33 2 96 07 18 56 > rabah.guedrez@orange.com > > > > -----Message d'origine----- > De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9 : > mercredi 27 avril 2016 15:50 =C0 : GUEDREZ Rabah IMT/OLN Cc : > spring@ietf.org; ipv6@ietf.org Objet : Re: I-D Action: > draft-ietf-6man-segment-routing-header-01.txt > > >> On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote: >> >> Hi, >> I would like some clarification about the treatment of the SRH by an >> end point (the node that its loopback matches the DA field), >> >> In section 3 : >> You say that the >> C-flag: Clean-up flag. Set when the SRH has to be removed from >> the packet when the packet reaches the last segment. > > > the text is confusing but the semantic is correct ;-) > > the cleanup flag is processed so that the last segment receives a packet = without any SRH. > > However, as you figured out, the processing of the C flag is done on the = segment before last (penultimate segment). So, probably a more accurate tex= t would be: > > C-flag: Clean-up flag. > Set when the SRH has to be removed from > the packet prior to forward the packet > towards the last segment. > > > >> Which mean that the last node inspects the SRH flags if the c-flag is se= t, the node has to remove the SRH before sending the packet to its final de= stination. >> >> But In section 4.3. >> >> You say that the node that decrements the Segments left pointer has >> to check if the c-flag is set when the new value of the segments left >> point is equal to zero, If the c-flag is set and the segments left >> pointer =3D=3D 0 then remove the SRH, >> >> What is confusing for me is that the node that decrements the pointer is= not the last node in the SR path (behavior similar to PHP for MPLS) , whi= ch I find in direct contradiction with section 3. > > > you're right. The node that processes the cleanup flag is the penultimate= segment, not the last. > > >> Another question if a node receives a packet with the already segment >> left =3D=3D 0, what should that node do with the packet(e.g., drops it?) > > > a node receiving a packet where: > 1. DA =3D=3D itself > 2. a routing header is present > 3. segments_left =3D=3D 0 > > MUST ignore the routing header and process the packet normally. This > is described in RFC2460 section 4.4 > > Rabah : >>>>>> do you consider that the c-flag must be set for all the pa= ckets. no. The c-flag is to be set when you insert an SRH into an existing packet. You set the c-flag so to be sure the SRH is removed before delivering the p= acket to its intended destination. > if we consider that setting the c-flag is not obligatory, then the egres= s would receive an SRH with : > 1. DA =3D=3D itself > 2. a routing header is present > 3. segments_left =3D=3D 0 when you use encapsulation and you don't set the c-flag, then the egress re= ceives the packet as you described above. > The SRH has to be ignored based on RFC2460, is that correct= s ? yes, the above is normal behavior when the path is completed (i.e.: all seg= ments have been processed and the DA is the intended destination of the pac= ket). > which in my opinion is not the intended behavior . can you explain what you mean by "not the intended behavior" ? s. > s. > Rabah > >> >> >> Bests. >> >> >> >> >> Rabah Guedrez >> Th=E9sard >> ORANGE/IMT/OLN/WTC/IEE/ITEQ >> >> Phone: +33 2 96 07 18 56 >> rabah.guedrez@orange.com >> >> >> _____________________________________________________________________ >> ____________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que= les pieces jointes. Les messages electroniques etant susceptibles d'altera= tion, Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not be = distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > ______________________________________________________________________ > ___________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que = les pieces jointes. Les messages electroniques etant susceptibles d'alterat= ion, Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not be d= istributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_27B26A2868951342946169C453A0DF4B22EFB6EBOPEXCLILM23corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

If we consider SRH insert= ion with IPv6 PHP, the original destination address would be lost when remo= ving the SRH,

The packet reaches the eg= ress with a DA that matches egress address, but no other information how to= forward the packet to its final destination

 <= /p>

 <= /p>

3D"Orange<= /span>

 

Rabah Guedrez
Th=E9sard
ORANGE/IMT/OLN/WTC/IEE/ITEQ

 

Phone: +33 2 96 07 18 56
rabah.guedrez@orange.com

 

 <= /p>

De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
Envoy=E9 : jeudi 28 avril 2016 13:46
=C0 : GUEDREZ Rabah IMT/OLN
Cc : spring@ietf.org; ipv6@ietf.org
Objet : RE: I-D Action: draft-ietf-6man-segment-routing-header-= 01.txt

 

There are many operators and use cases where, instead of encapsulation,= srh insertion is a far better option.

In fact all current implementations are doing srh insertion.

Still, from a spec perspective, the srh processis the same.

s.

-----Original Message-----
From: rabah.guedrez@oran= ge.com [rabah.guedrez@orange.com]
Received: Thursday, 28 Apr 2016, 12:58
To: Stefano Previdi (sprevidi) [sprevidi@cisco.com]
CC: spring@ietf.org [spring@i= etf.org]; ipv6@ietf.org [ipv6@ietf.org]
Subject: RE: I-D Action: draft-ietf-6man-segment-routing-header-01.t= xt

You have said in a previous response to a question that the dra= ft only consider the encapsulation of client packet into a new IPV6 header = with SRH, and not adding only an SRH to an existing packet.
Which make sense especially for service providers who would prefer to tunne= l client traffic  (not modify the header of the client packets for sec= urity reasons).

If you only consider encapsulation, does keeping  c-flag relevant?
 
Rabah Guedrez
Th=E9sard
ORANGE/IMT/OLN/WTC/IEE/ITEQ
 
Phone: +33 2 96 07 18 56
rabah.guedrez@orange.com  


-----Message d'origine-----
De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
Envoy=E9 : jeudi 28 avril 2016 12:31
=C0 : GUEDREZ Rabah IMT/OLN
Cc : spring@ietf.org; ipv6@ietf.org
Objet : Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt<= br>
On Apr 28, 2016, at 11:13 AM, r= abah.guedrez@orange.com wrote:
>
> Rabah Guedrez
> Th=E9sard
> ORANGE/IMT/OLN/WTC/IEE/ITEQ
> 
> Phone: +33 2 96 07 18 56
> rabah.guedrez@orange.com
> 
>
>
> -----Message d'origine-----
> De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9 :
> mercredi 27 avril 2016 15:50 =C0 : GUEDREZ Rabah IMT/OLN Cc :
> spring@ietf.org; ipv6@ietf.org Objet : Re: I-D Action:
> draft-ietf-6man-segment-routing-header-01.txt
>
>
>> On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote:
>>
>> Hi,
>> I would like some clarification about the treatment of the  S= RH by an
>> end point (the node that its loopback matches the DA field),
>>
>> In section 3 :
>> You say that the
>> C-flag: Clean-up flag.  Set when the SRH has to be removed fr= om
>>         the packet when th= e packet reaches the last segment.
>
>
> the text is confusing but the semantic is correct ;-)
>
> the cleanup flag is processed so that the last segment receives a pack= et without any SRH.
>
> However, as you figured out, the processing of the C flag is done on t= he segment before last (penultimate segment). So, probably a more accurate = text would be:
>
>  C-flag: Clean-up flag. 
>          Set when the SRH= has to be removed from
>          the packet prior= to forward the packet
>          towards the last= segment.
>
>
>
>> Which mean that the last node inspects the SRH flags if the c-flag= is set, the node has to remove the SRH before sending the packet to its fi= nal destination.
>>
>> But In section 4.3.
>>
>> You say that the node that decrements the Segments left pointer ha= s
>> to check if the c-flag is set when the new value of the segments l= eft
>> point is equal to zero, If the c-flag is set and the segments left=
>> pointer =3D=3D 0 then remove the SRH,
>>
>> What is confusing for me is that the node that decrements the poin= ter is not the last node in the SR path (behavior similar to  PHP for = MPLS) , which I find in direct contradiction with section 3.
>
>
> you're right. The node that processes the cleanup flag is the penultim= ate segment, not the last.
>
>
>> Another question if a node receives a packet with the already segm= ent
>> left =3D=3D 0, what should that node do with the packet(e.g., drop= s it?)
>
>
> a node receiving a packet where:
>        1. DA =3D=3D itself
>        2. a routing header is prese= nt
>        3. segments_left =3D=3D 0
>
> MUST ignore the routing header and process the packet normally. This <= br> > is described in RFC2460 section 4.4
>
> Rabah : >>>>>> do you consider that the c-flag must = be set for all the packets.


no.

The c-flag is to be set when you insert an SRH into an existing packet.

You set the c-flag so to be sure the SRH is removed before delivering the p= acket to its intended destination.


> if we consider that setting the c-flag is not obligatory, then the&nbs= p; egress would receive an SRH with :
>            = ;   1. DA =3D=3D itself
>        2. a routing header is prese= nt
>        3. segments_left =3D=3D 0


when you use encapsulation and you don't set the c-flag, then the egress re= ceives the packet as you described above.


>            = ;   The SRH has to be ignored based on RFC2460, is that corrects = ?


yes, the above is normal behavior when the path is completed (i.e.: all seg= ments have been processed and the DA is the intended destination of the pac= ket).


> which in my opinion is not the intended behavior .


can you explain what you mean by "not the intended behavior" ?

s.


> s.
> Rabah
>
>>
>>
>> Bests.
>>
>>
>> <image001.gif>
>>
>> Rabah Guedrez
>> Th=E9sard
>> ORANGE/IMT/OLN/WTC/IEE/ITEQ
>>
>> Phone: +33 2 96 07 18 56
>> rabah.guedrez@orange.c= om
>>
>>
>> __________________________________________________________________= ___
>> ____________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations=
>> confidentielles ou privilegiees et ne doivent donc pas etre diffus= es,
>> exploites ou copies sans autorisation. Si vous avez recu ce messag= e
>> par erreur, veuillez le signaler a l'expediteur et le detruire ain= si que les pieces jointes. Les messages electroniques etant susceptibles d'= alteration, Orange decline toute responsabilite si ce message a ete altere,= deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should n= ot be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender= and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that h= ave been modified, changed or falsified.
>> Thank you.
>>
>> ------------------------------------------------------------------= --
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> ------------------------------------------------------------------= --
>
>
> ______________________________________________________________________=
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, =
> exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi q= ue les pieces jointes. Les messages electroniques etant susceptibles d'alte= ration, Orange decline toute responsabilite si ce message a ete altere, def= orme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and= delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified.
> Thank you.
>


___________________________________________________________________________= ______________________________________________

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

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

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_27B26A2868951342946169C453A0DF4B22EFB6EBOPEXCLILM23corp_-- --_004_27B26A2868951342946169C453A0DF4B22EFB6EBOPEXCLILM23corp_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=406; creation-date="Fri, 29 Apr 2016 07:29:17 GMT"; modification-date="Fri, 29 Apr 2016 07:29:17 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODdhKAAyAIQQAP9mAP9wEP95IP+DMP+MQP+WUP+fYP+pcP+zgP+8j//Gn//Pr//Zv//iz//s 3//17////////////////////////////////////////////////////////////////ywAAAAA KAAyAAAF/iAkjmRpnmiqrmzrvnAsz3SdMkCu73zv/zoccEj8CYvI4jHJ9C2b0Nwz2pxSk9arUhvN coHer1PMDJN35rNUvWUP02r4WU6mi+1fPFev5V/9VIBdbm+EYIZGiDkIDA8KBIJFBAgPD5A5AwwQ DgcACQygBA2bBgAMCg4QCQADqaADmZsHArABQqkJo5CbCQgNBakAEA+5EAMNDwe6jQaaAkEAAhAK AAQQjBAB0agiwjgIENY4BeHDDKOlawOq1deaOZUGo94A4OIABuUOCPwE0ADxNDWDwArCggIPCEL4 Fi4VpXDICvh6tqZaQnbvTA0LtrBeuFYQdIE0qK0ippJNHBAsIKAg3KEv4ESEiZQjAAGUP2zo3Mmz p88WIQAAOw== --_004_27B26A2868951342946169C453A0DF4B22EFB6EBOPEXCLILM23corp_-- From nobody Fri Apr 29 01:40:49 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8FA12D5AD; Fri, 29 Apr 2016 01:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzmoQEhWDGdV; Fri, 29 Apr 2016 01:40:43 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BAF812D5A3; Fri, 29 Apr 2016 01:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11474; q=dns/txt; s=iport; t=1461919243; x=1463128843; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ffy6no1UmmrzXCl4caxrUJgvOUIjW4olkPH+Ngu35zU=; b=SXEvL+7plMV9xxcjUH5K4GrGYRe6ZAbWpnHzTKy2msbhrvls95uBqxph TW0zN1dfzDvEd+sw4FGgKbUkgsKVoOpXDM7plSKPa3Yjg06zpNfuVDe00 6s7b+gqtY7ioZGstKbToiI4nWUA0vZ2i/iLknu0+7JcrOD6FvINSHGYtt A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAgDMHCNX/4UNJK1egzhTfQa5ZQENg?= =?us-ascii?q?XYXC4VtAoErOBQBAQEBAQEBZRwLhEEBAQEDAQEBAWsLBQcCAgIBCBUCAScHGww?= =?us-ascii?q?LFAkIAgQOBYgiCA7DRQEBAQEBAQEBAQEBAQEBAQEBAQEBAREEBIYdgXWBVIECh?= =?us-ascii?q?A8RARwsgn+CKwEEh3SLGYUEAY4WgWeETYMpe4Q5jy8BHgEBQoIFG4FLbIYzNn8?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.24,551,1454976000"; d="scan'208";a="97283386" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Apr 2016 08:40:41 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3T8ef8f016449 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Apr 2016 08:40:41 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 29 Apr 2016 04:40:40 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Fri, 29 Apr 2016 04:40:40 -0400 From: "Stefano Previdi (sprevidi)" To: "rabah.guedrez@orange.com" Thread-Topic: I-D Action: draft-ietf-6man-segment-routing-header-01.txt Thread-Index: AQHRoTzev8IxaMPY3kOJ15ohq3wgDJ+fRJn9gAGNp4CAABPwAA== Date: Fri, 29 Apr 2016 08:40:40 +0000 Message-ID: <8FAD863D-B04B-4D12-BD29-380C34CF61BF@cisco.com> References: <18080_1461763078_5720BC06_18080_123_1_27B26A2868951342946169C453A0DF4B22EFA891@OPEXCLILM23.corporate.adroot.infra.ftgroup> <1F1BED9C-F702-48FC-9A25-6192B5338D02@cisco.com> <10381_1461834831_5721D44F_10381_307_1_27B26A2868951342946169C453A0DF4B22EFAEDC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <8250BFA4-F21A-433A-899B-7E68C5219BC1@cisco.com> <8941_1461841093_5721ECC5_8941_18000_1_27B26A2868951342946169C453A0DF4B22EFAF03@OPEXCLILM23.corporate.adroot.infra.ftgroup> <94e2e9c6597f454ba42a699b2a2ffed8@XCH-RTP-010.cisco.com> <7413_1461914959_57230D4E_7413_292_1_27B26A2868951342946169C453A0DF4B22EFB6EB@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <7413_1461914959_57230D4E_7413_292_1_27B26A2868951342946169C453A0DF4B22EFB6EB@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.111.237] Content-Type: text/plain; charset="Windows-1252" Content-ID: <321C2EFF5EEEA246A7BA5C96206E9281@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , "ipv6@ietf.org" Subject: Re: [spring] I-D Action: draft-ietf-6man-segment-routing-header-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 29 Apr 2016 08:40:45 -0000 well, I think you missed how routing headers are handled in ipv6. Please read rfc2460 section 4.4 and then draft-ietf-6man-segment-routing-he= ader section 4 and especially section 4.3. You=92ll see that the routing header is not an mpls label stack. s. > On Apr 29, 2016, at 9:29 AM, rabah.guedrez@orange.com wrote: >=20 > If we consider SRH insertion with IPv6 PHP, the original destination addr= ess would be lost when removing the SRH, > The packet reaches the egress with a DA that matches egress address, but = no other information how to forward the packet to its final destination > =20 > =20 > > =20 > Rabah Guedrez=20 > Th=E9sard=20 > ORANGE/IMT/OLN/WTC/IEE/ITEQ > =20 > Phone: +33 2 96 07 18 56=20 > rabah.guedrez@orange.com > =20 > =20 > De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 > Envoy=E9 : jeudi 28 avril 2016 13:46 > =C0 : GUEDREZ Rabah IMT/OLN > Cc : spring@ietf.org; ipv6@ietf.org > Objet : RE: I-D Action: draft-ietf-6man-segment-routing-header-01.txt > =20 > There are many operators and use cases where, instead of encapsulation, s= rh insertion is a far better option. >=20 > In fact all current implementations are doing srh insertion. >=20 > Still, from a spec perspective, the srh processis the same.=20 >=20 > s. >=20 > -----Original Message-----=20 > From: rabah.guedrez@orange.com [rabah.guedrez@orange.com] > Received: Thursday, 28 Apr 2016, 12:58 > To: Stefano Previdi (sprevidi) [sprevidi@cisco.com] > CC: spring@ietf.org [spring@ietf.org]; ipv6@ietf.org [ipv6@ietf.org] > Subject: RE: I-D Action: draft-ietf-6man-segment-routing-header-01.txt >=20 > You have said in a previous response to a question that the draft only co= nsider the encapsulation of client packet into a new IPV6 header with SRH, = and not adding only an SRH to an existing packet. > Which make sense especially for service providers who would prefer to tun= nel client traffic (not modify the header of the client packets for securi= ty reasons). >=20 > If you only consider encapsulation, does keeping c-flag relevant? > =20 > Rabah Guedrez=20 > Th=E9sard=20 > ORANGE/IMT/OLN/WTC/IEE/ITEQ=20 > =20 > Phone: +33 2 96 07 18 56=20 > rabah.guedrez@orange.com=20 > =20 >=20 >=20 > -----Message d'origine----- > De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 > Envoy=E9 : jeudi 28 avril 2016 12:31 > =C0 : GUEDREZ Rabah IMT/OLN > Cc : spring@ietf.org; ipv6@ietf.org > Objet : Re: I-D Action: draft-ietf-6man-segment-routing-header-01.txt >=20 > On Apr 28, 2016, at 11:13 AM, rabah.guedrez@orange.com wrote: > >=20 > > Rabah Guedrez > > Th=E9sard > > ORANGE/IMT/OLN/WTC/IEE/ITEQ > > =20 > > Phone: +33 2 96 07 18 56 > > rabah.guedrez@orange.com > > =20 > >=20 > >=20 > > -----Message d'origine----- > > De : Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] Envoy=E9 := =20 > > mercredi 27 avril 2016 15:50 =C0 : GUEDREZ Rabah IMT/OLN Cc :=20 > > spring@ietf.org; ipv6@ietf.org Objet : Re: I-D Action:=20 > > draft-ietf-6man-segment-routing-header-01.txt > >=20 > >=20 > >> On Apr 27, 2016, at 3:17 PM, rabah.guedrez@orange.com wrote: > >>=20 > >> Hi, > >> I would like some clarification about the treatment of the SRH by an= =20 > >> end point (the node that its loopback matches the DA field), > >>=20 > >> In section 3 : > >> You say that the > >> C-flag: Clean-up flag. Set when the SRH has to be removed from > >> the packet when the packet reaches the last segment. > >=20 > >=20 > > the text is confusing but the semantic is correct ;-) > >=20 > > the cleanup flag is processed so that the last segment receives a packe= t without any SRH. > >=20 > > However, as you figured out, the processing of the C flag is done on th= e segment before last (penultimate segment). So, probably a more accurate t= ext would be: > >=20 > > C-flag: Clean-up flag. =20 > > Set when the SRH has to be removed from > > the packet prior to forward the packet=20 > > towards the last segment. > >=20 > >=20 > >=20 > >> Which mean that the last node inspects the SRH flags if the c-flag is = set, the node has to remove the SRH before sending the packet to its final = destination. > >>=20 > >> But In section 4.3. > >>=20 > >> You say that the node that decrements the Segments left pointer has=20 > >> to check if the c-flag is set when the new value of the segments left= =20 > >> point is equal to zero, If the c-flag is set and the segments left=20 > >> pointer =3D=3D 0 then remove the SRH, > >>=20 > >> What is confusing for me is that the node that decrements the pointer = is not the last node in the SR path (behavior similar to PHP for MPLS) , w= hich I find in direct contradiction with section 3. > >=20 > >=20 > > you're right. The node that processes the cleanup flag is the penultima= te segment, not the last. > >=20 > >=20 > >> Another question if a node receives a packet with the already segment= =20 > >> left =3D=3D 0, what should that node do with the packet(e.g., drops it= ?) > >=20 > >=20 > > a node receiving a packet where: > > 1. DA =3D=3D itself > > 2. a routing header is present > > 3. segments_left =3D=3D 0 > >=20 > > MUST ignore the routing header and process the packet normally. This=20 > > is described in RFC2460 section 4.4 > >=20 > > Rabah : >>>>>> do you consider that the c-flag must be set for all the = packets. >=20 >=20 > no. >=20 > The c-flag is to be set when you insert an SRH into an existing packet. >=20 > You set the c-flag so to be sure the SRH is removed before delivering the= packet to its intended destination. >=20 >=20 > > if we consider that setting the c-flag is not obligatory, then the egr= ess would receive an SRH with : > > 1. DA =3D=3D itself > > 2. a routing header is present > > 3. segments_left =3D=3D 0 >=20 >=20 > when you use encapsulation and you don't set the c-flag, then the egress = receives the packet as you described above. >=20 >=20 > > The SRH has to be ignored based on RFC2460, is that corre= cts ? >=20 >=20 > yes, the above is normal behavior when the path is completed (i.e.: all s= egments have been processed and the DA is the intended destination of the p= acket). >=20 >=20 > > which in my opinion is not the intended behavior . >=20 >=20 > can you explain what you mean by "not the intended behavior" ? >=20 > s. >=20 >=20 > > s. > > Rabah > >=20 > >>=20 > >>=20 > >> Bests. > >>=20 > >>=20 > >> > >>=20 > >> Rabah Guedrez > >> Th=E9sard > >> ORANGE/IMT/OLN/WTC/IEE/ITEQ > >>=20 > >> Phone: +33 2 96 07 18 56 > >> rabah.guedrez@orange.com > >>=20 > >>=20 > >> _____________________________________________________________________ > >> ____________________________________________________ > >>=20 > >> Ce message et ses pieces jointes peuvent contenir des informations=20 > >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,= =20 > >> exploites ou copies sans autorisation. Si vous avez recu ce message=20 > >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi q= ue les pieces jointes. Les messages electroniques etant susceptibles d'alte= ration, Orange decline toute responsabilite si ce message a ete altere, def= orme ou falsifie. Merci. > >>=20 > >> This message and its attachments may contain confidential or=20 > >> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation. > >> If you have received this email in error, please notify the sender and= delete this message and its attachments. > >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > >> Thank you. > >>=20 > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > >=20 > >=20 > > ______________________________________________________________________ > > ___________________________________________________ > >=20 > > Ce message et ses pieces jointes peuvent contenir des informations=20 > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu= e les pieces jointes. Les messages electroniques etant susceptibles d'alter= ation, Orange decline toute responsabilite si ce message a ete altere, defo= rme ou falsifie. Merci. > >=20 > > This message and its attachments may contain confidential or=20 > > privileged information that may be protected by law; they should not be= distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and = delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. > > Thank you. > >=20 >=20 >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 From nobody Sat Apr 30 22:10:40 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49C112B016 for ; Sat, 30 Apr 2016 22:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5p1Q_OoiHAq for ; Sat, 30 Apr 2016 22:10:36 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD3D12B00D for ; Sat, 30 Apr 2016 22:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34249; q=dns/txt; s=iport; t=1462079435; x=1463289035; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=6sWeu3gRWfXIbLdIVajS8OzUmJ539on4OniE5wFtKUU=; b=FGvzPEqFyeO9lh32f8YWvCQj5U3Qq/ErKEEEFlr+pI4qLPDKdVPitQM3 A8sJPFEiiuFFhqQ6l7e1Msc7uKzR4TgWQN+2ZTvhAlH6ppZZw3yy6G24Y jRCdANSM6T0DgvVCzQZheoVwSEgDcZBvSMZXhQVa2d7etYe9elOq58eHF M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAgCLjiVX/5RdJa1egmxMU30GuXABD?= =?us-ascii?q?YFyBBcBCoUkSgKBHTgUAQEBAQEBAWUnhEEBAQEDAQEBASpBEAcEAgEIEQQBASE?= =?us-ascii?q?BBgcnCxQJCAEBBAESCIgaCA7DMgEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhiGET?= =?us-ascii?q?IQPCgcBBkyFIAWTI4RxAY4QgW6ETYhdjzABHgEBQoIFG4FLbIYnCRcffwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,560,1454976000"; d="scan'208,217";a="267384169" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 May 2016 05:10:34 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u415AYde022763 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 1 May 2016 05:10:34 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 1 May 2016 00:10:33 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Sun, 1 May 2016 00:10:33 -0500 From: "Les Ginsberg (ginsberg)" To: Uma Chunduri , "bruno.decraene@orange.com" , "spring@ietf.org" Thread-Topic: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call Thread-Index: AdGWIcRdLnRAPWN3Qn6eVontUw9C0AAAMhXQAqz8LVAApDM0UA== Date: Sun, 1 May 2016 05:10:33 +0000 Message-ID: <0468fb2fe35841668bc35606e988074c@XCH-ALN-001.cisco.com> References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10411_1460620508_570F4CDC_10411_96_23_53C29892C857584299CBF5D05346208A0F86E45F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1B502206DFA0C544B7A6046915200863580C54E9@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A6046915200863580C54E9@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.87.208] Content-Type: multipart/alternative; boundary="_000_0468fb2fe35841668bc35606e988074cXCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 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, 01 May 2016 05:10:38 -0000 --_000_0468fb2fe35841668bc35606e988074cXCHALN001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Uma - We are indeed defining conflict resolution across all the SID advertisement= s regardless of source (protocol or SRMS) - as the sections you have quoted= clearly state. Why? Because we need consistent use of SIDs in the forwarding plane. From f= orwarding perspective it matters not whether the SID was advertised by prot= ocol instance #1 or #2 or by an SRMS. What matters is that the SID I use to= determine what label I install in my forwarding plane is the same SID that= my neighbors will use. Otherwise forwarding will be broken. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Uma Chunduri Sent: Wednesday, April 27, 2016 4:31 PM To: bruno.decraene@orange.com; spring@ietf.org Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adopti= on call Dear Authors, Have few comments on the draft: 1. As I indicated during meeting - I am not sure why we have to club = verification of SIDs advertised through regular protocol reachability prefixes and the ranges advertised through 'Mapping Server'= (SRMS). I didn't see any compelling reason to do this. SIDs advertised through reachability prefixes doesn't have= ranges unlike SRMS advertisements. As SRMS advertisements are primarily for nodes which are n= ot SR capable and I feel we should not mix this with nodes which are SR ca= pable. This isolation helps restricting the resolution work primarily for = multiple SRMS entries advertised through one node or multiple nodes. SRMS advertisements are indeed little bit unique in that yo= u are advertising "configuration" on behalf of node X from node Y with ranges (both prefix ranges and SID ranges). 2. Regarding the scope of conflict resolution: Section 1 " The problem to be addressed is protocol independent i.e., se= gment related advertisements may be originated by multiple nodes using different protocols and yet the conflict resolution MUST be the sa= me on all nodes regardless of the protocol used to transport the advertisements." Section 3.2.8 " o In cases where multiple routing protocols are in use mappi= ng entries advertised by all routing protocols MUST be included." This sounds like we are seeking to resolve conflicting entries outsid= e and across the protocols? Each IGP has separate mechanism for advertising mapping entry and I t= his is not clear with the current version of the draft how we can cross ver= ify SID/Prefix conflict across the protocol. Can you clarify this? -- Uma C. -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, April 14, 2016 12:55 AM To: spring@ietf.org Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adopti= on call > From: bruno.decraene@orange.com > Sent= : Thursday, April 14, 2016 9:51 > AM > > Dear WG, > > As we discussed at our meeting last week, working group adoption has > been requested for draft-ginsberg-spring-conflict-resolution. > Please reply to the list with your comments, including although not > limited to whether or not you support adoption. We will end the call on April 29, 2016. > Thanks, > > --John and Bruno > > > > __________________________________________________________ > __________________________________________________________ > _____ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > que les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, Orange decline toute responsabilite si ce message a ete alt= ere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. > > _______________________________________________ > 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. 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 --_000_0468fb2fe35841668bc35606e988074cXCHALN001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Uma –

 <= /p>

We are indeed defining co= nflict resolution across all the SID advertisements regardless of source (p= rotocol or SRMS) – as the sections you have quoted clearly state.

 <= /p>

Why? Because we need cons= istent use of SIDs in the forwarding plane. From forwarding perspective it = matters not whether the SID was advertised by protocol instance #1 or #2 or by an SRMS. What matters is that the SID I use to determine wh= at label I install in my forwarding plane is the same SID that my neighbors= will use. Otherwise forwarding will be broken.

 <= /p>

   Les

 <= /p>

 <= /p>

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Uma Chunduri
Sent: Wednesday, April 27, 2016 4:31 PM
To: bruno.decraene@orange.com; spring@ietf.org
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG= adoption call

 

Dear Authors,

 

Have few comments on the draft:

 

1. 

      &nb= sp; As I indicated during meeting - I am not sure why we have to club = verification of SIDs advertised through regular protocol reachability

      &nb= sp;         prefixes and the ranges= advertised through 'Mapping Server'  (SRMS). I didn't see any compell= ing reason to do this.

      &nb= sp;          SIDs advertised t= hrough reachability prefixes doesn't have ranges unlike SRMS advertisements= . 

      &nb= sp;          As SRMS advertise= ments are primarily for nodes which are not SR capable and  I feel we = should not mix this with nodes which are SR capable.

 

      &nb= sp; This isolation helps restricting the resolution work primarily for mult= iple SRMS entries advertised through one node or multiple nodes.

      &nb= sp;         SRMS advertisements are= indeed little bit unique in that you are advertising "configuration&q= uot; on behalf of node X from node Y

      &nb= sp;         with ranges (both prefi= x ranges and SID ranges).

 

 

2. 

      &nb= sp;         Regarding  the sco= pe of conflict resolution:

 

 

       Se= ction 1

 

      &nb= sp;    "   The problem to be addressed is protocol independent i= .e., segment

      =    related advertisements may be originated by multiple nodes usi= ng

      =    different protocols and yet the conflict resolution MUST be th= e same

      =    on all nodes regardless of the protocol used to transport the<= /span>

      =    advertisements."

 

      =   Section 3.2.8

      =     "   o  In cases where multiple routi= ng protocols are in use mapping

      entri= es advertised by all routing protocols MUST be included."

 

      This sou= nds like we are seeking to resolve conflicting entries outside and across t= he protocols?

      Each IGP= has separate mechanism for advertising mapping entry and I this is not cle= ar with the current version of the draft how we can cross verify SID/Prefix= conflict across  the protocol.

     Can you clarif= y this?

 

 

--

Uma C.

 

 

-----Original Message-----
From: spring [mailto:spring-boun= ces@ietf.org] On Behalf Of bruno.decraene@orange.com<= br> Sent: Thursday, April 14, 2016 12:55 AM
To: spring@ietf.org
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adopti= on call

 

> From:  bruno.decraene@orange.com = > Sent: Thursday, April 14, 2016 9:51

> AM

>

> Dear WG,

>

> As we discussed at our meeting las= t week, working group adoption has

> been requested for draft-ginsberg-= spring-conflict-resolution.

> Please reply to the list with your= comments, including although not

> limited to whether or not you supp= ort adoption.

 

We will end the call on April 29, 2016.=

 

 

> Thanks,

>

> --John and Bruno=

>

>

>

> __________________________________= ________________________

> __________________________________= ________________________

> _____

>

> Ce message et ses pieces jointes p= euvent contenir des informations

> confidentielles ou privilegiees et= ne doivent donc pas etre diffuses,

> exploites ou copies sans autorisat= ion. Si vous avez recu ce message

> par erreur, veuillez le signaler a= l'expediteur et le detruire ainsi

> que les pieces jointes. Les messag= es electroniques etant susceptibles

> d'alteration, Orange decline toute= responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

>

> This message and its attachments m= ay contain confidential or

> privileged information that may be= protected by law; they should not

> be distributed, used or copied wit= hout authorisation.

> If you have received this email in= error, please notify the sender and

> delete this message and its attach= ments.

> As emails may be altered, Orange i= s not liable for messages that have

> been modified, changed or falsifie= d.

> Thank you.

>

> __________________________________= _____________

> spring mailing list

 

_______________________________________= ___________________________________________________________________________= _______

 

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

 

This message and its attachments may co= ntain confidential or privileged information that may be protected by law; = they should not be distributed, used or copied without authorisation.<= /o:p>

If you have received this email in erro= r, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not= liable for messages that have been modified, changed or falsified.

Thank you.

 

_______________________________________= ________

spring mailing list

 

--_000_0468fb2fe35841668bc35606e988074cXCHALN001ciscocom_--