Re: [spring] SID Conflict Resolution: A Simpler Proposal
John E Drake <jdrake@juniper.net> Mon, 05 December 2016 16:48 UTC
Return-Path: <jdrake@juniper.net>
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 74F0B129BC8 for <spring@ietfa.amsl.com>; Mon, 5 Dec 2016 08:48:06 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 8TTsECLvYmG4 for <spring@ietfa.amsl.com>; Mon, 5 Dec 2016 08:48:03 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0095.outbound.protection.outlook.com [104.47.34.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EC3B129B63 for <spring@ietf.org>; Mon, 5 Dec 2016 08:46:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rsWsgzSUJAE0Jus3UmRGg3uGf/sbB7+YTk6DyjTW27k=; b=WwkCM/zLgQs2HXeRaAjedK5GRLRQImQsxOOaGMCw4mcS2kkPk+Gq1YzZfQWhsq44XRWT7fgIXzOU7QEJy1io66JyCDP+TptVpv27bQju7cnf2LfPG8tQgQS3gyI15wodwOx5rKKJDEaa58fW3Op+FK+UtHgvMybh3/MxGOSAB6E=
Received: from BN6PR05MB2995.namprd05.prod.outlook.com (10.173.19.13) by BN6PR05MB2993.namprd05.prod.outlook.com (10.173.19.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4; Mon, 5 Dec 2016 16:46:55 +0000
Received: from BN6PR05MB2995.namprd05.prod.outlook.com ([10.173.19.13]) by BN6PR05MB2995.namprd05.prod.outlook.com ([10.173.19.13]) with mapi id 15.01.0771.006; Mon, 5 Dec 2016 16:46:55 +0000
From: John E Drake <jdrake@juniper.net>
To: "Acee Lindem (acee)" <acee@cisco.com>
Thread-Topic: [spring] SID Conflict Resolution: A Simpler Proposal
Thread-Index: AQHSTxSjpdbpy2EEiUGYnIhp/Ij4b6D5kDYq
Date: Mon, 05 Dec 2016 16:46:55 +0000
Message-ID: <4DC300D3-C9F5-47EB-9AB2-7BAE2FF304BF@juniper.net>
References: <D46AFE2D.8E978%acee@cisco.com>
In-Reply-To: <D46AFE2D.8E978%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrake@juniper.net;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [107.19.189.2]
x-ms-office365-filtering-correlation-id: 7a9ac305-da13-44cc-2149-08d41d2e526f
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR05MB2993;
x-microsoft-exchange-diagnostics: 1; BN6PR05MB2993; 7:5xPisFPc1bRA+gum3+yJ/bI1wiGyQWMeAD1jhQfq+i/Vd22IhTxpN9OWAhnrz9OGADWpjAeRTUvSD7wtNLO4xXwPj/dvyjeU9WWrUFs60d69IqmGnDROmVqggeqCnHNGIHbPtj5s+RUcv17NfUSrSCrqDtyR6Yytcwu/Nzel/hfm5SWcXi4JIgrCPY9kxy4spKjSS9m80rsr5YlsSk8V1NtRoss4kdNkl5LRp2jKA60/GfdK2/K9brLs+Sbh603pRFXVAkvN6ygrV5vfVLuhzp9nlFf+HuFLZKvY/nluB6phOFzo6h2/5u8/6MlMR/JgRGbFbsAfqvuUHzcwAQjbUK4KbXhXin7MAXk6LBAxAKy6Al+W/r2Bka6aOTopZSLmSU6UQR5Tek4HCs+dKEIWcY6neEINoFzepU/IS8120O8A742ED4IFqzdjmcsHkz4WzebfYzsWoH8dDHCpEKbfow==
x-microsoft-antispam-prvs: <BN6PR05MB29933ADEDB64B63247F774D7C7830@BN6PR05MB2993.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(95692535739014)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:BN6PR05MB2993; BCL:0; PCL:0; RULEID:; SRVR:BN6PR05MB2993;
x-forefront-prvs: 0147E151B5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(189002)(377454003)(199003)(122556002)(38730400001)(39410400001)(4326007)(101416001)(7736002)(5003630100001)(7906003)(76176999)(54356999)(606004)(50986999)(189998001)(229853002)(6486002)(3846002)(36756003)(77096006)(102836003)(33656002)(6116002)(790700001)(97736004)(7846002)(561944003)(106356001)(39450400002)(39850400001)(3280700002)(68736007)(110136003)(2950100002)(106116001)(81156014)(3660700001)(105586002)(8676002)(66066001)(92566002)(5660300001)(81166006)(6512006)(39840400001)(6916009)(82746002)(2900100001)(2906002)(8936002)(83716003)(9886003)(6506006)(86362001)(99286002)(39860400001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR05MB2993; H:BN6PR05MB2995.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_4DC300D3C9F547EB9AB27BAE2FF304BFjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2016 16:46:55.3257 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB2993
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/BVvFOn-xDf3kOxk87ZIa3AyMkTc>
Cc: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "spring@ietf.org" <spring@ietf.org>
Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Dec 2016 16:48:06 -0000
I agree with Acee Sent from my iPhone On Dec 5, 2016, at 11:28 AM, Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>> wrote: I like the proposal below much better than keeping track of the overlapping and non-overlapping ranges and dynamically resolving conflicts as the routing state changes. While providing a generalized solution to provide such resolution is an interesting problem, I don’t believe that the complexity justifies the benefit for what are configuration errors. Thanks, Acee From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> on behalf of "Les Ginsberg (ginsberg)" <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> Date: Sunday, December 4, 2016 at 7:04 PM To: "spring@ietf.org<mailto:spring@ietf.org>" <spring@ietf.org<mailto:spring@ietf.org>> Subject: [spring] SID Conflict Resolution: A Simpler Proposal When the problem addressed by draft-ietf-spring-conflict-resolution was first presented at IETF 94, the authors defined the following priorities: 1)Detect the problem 2)Report the problem This alerts the network operator to the existence of a conflict so that the configuration error can be corrected. 3)Define consistent behavior This avoids mis-forwarding while the conflict exists. 4)Don’t overengineer the solution Given that it is impossible to know which of the conflicting entries is the correct one, we should apply a simple algorithm to resolve the conflict. 5)Agree on the resolution behavior The resolution behavior was deliberately the last point because it was considered the least important. Input was received over the past year which emphasized the importance of trying to "maximize forwarding" in the presence of conflicts. Subsequent revisions of the draft have tried to address this concern. However the authors have repeatedly stressed that the solution being proposed ("ignore overlap only") was more complex than other offered alternatives and would be more difficult to guarantee interoperability because subtle differences in an implementation could produce different results. At IETF97 significant feedback was received preferring a simpler solution to the problem. The authors are very sympathetic to this feedback and therefore are proposing a solution based on what the draft defines as the "Ignore" policy - where all entries which are in conflict are ignored. We believe this is far more desirable and aligns with the priorities listed above. We outline the proposed solution below and would like to receive feedback from the WG before publishing the next revision of the draft. Les (on behalf of the authors) New Proposal In the latest revision of the draft "SRMS Preference" was introduced. This provides a way for a numerical preference to be explicitly associated with an SRMS advertisement. Using this an operator can indicate which advertisement is to be preferred when a conflict is present. The authors think this is a useful addition and we therefore want to include this in the new solution. The new preference rule used to resolve conflicts is defined as follows: A given mapping entry is compared against all mapping entries in the database with a preference greater than or equal to its own. If there is a conflict, the mapping entry with lower preference is ignored. If two mapping entries are in conflict and have equal preference then both entries are ignored. Implementation of this policy is defined as follows: Step 1: Within a single address-family/algorithm/topology sort entries based on preference Step 2: Starting with the lowest preference entries, resolve prefix conflicts using the above preference rule. The output is an active policy per topology. Step 3: Take the outputs from Step 2 and again sort them by preference Step 4: Starting with the lowest preference entries, resolve SID conflicts using the above preference rule The output from Step 4 is then the current Active Policy. Here are a few examples. Each mapping entry is represented by the tuple: (Preference, Prefix/mask Index range <#>) Example 1: 1. (150, 1.1.1.1/32 100 range 100) 2. (149, 1.1.1.10/32 200 range 200) 3. (148, 1.1.1.101/32 500 range 10) Entry 3 conflicts with entry 2, it is ignored. Entry 2 conflicts with entry 1, it is ignored. Active policy: (150, 1.1.1.1/32 100 range 100) Example 2: 1. (150, 1.1.1.1/32 100 range 100) 2. (150, 1.1.1.10/32 200 range 200) 3. (150, 1.1.1.101/32 500 range 10) 4. (150, 2.2.2.1/32 1000 range 1) Entry 1 conflicts with entry 2, both are marked as ignore. Entry 3 conflicts with entry 2. It is marked as ignore. Entry 4 has no conflicts with any entries Active policy: (150, 2.2.2.1/32 1000 range 1) Example 3: 1. (150, 1.1.1.1/32 100 range 500) 2. (150, 1.1.1.10/32 200 range 200) 3. (150, 1.1.1.101/32 500 range 10) 4. (150, 2.2.2.1/32 1000 range 1) Entry 1 conflicts with entries 2, 3, and 4. All entries are marked ignore. Active policy: Empty Example 4: 1. (150, 1.1.1.1/32 100 range 10) 2. (149, 1.1.1.10/32 200 range 300) 3. (149, 1.1.1.101/32 500 range 10) 4. (148, 2.2.2.1/32 1000 range 1) Entry 4 conflicts with entry 2. It is marked ignore. Entry 2 conflicts with entry 3. Entries 2 and 3 are marked ignore. Active policy: (150, 1.1.1.1/32 100 range 10) _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring
- [spring] SID Conflict Resolution: A Simpler Propo… Les Ginsberg (ginsberg)
- Re: [spring] SID Conflict Resolution: A Simpler P… Acee Lindem (acee)
- Re: [spring] SID Conflict Resolution: A Simpler P… John E Drake
- Re: [spring] SID Conflict Resolution: A Simpler P… Jeff Tantsura
- Re: [spring] SID Conflict Resolution: A Simpler P… Shraddha Hegde
- Re: [spring] SID Conflict Resolution: A Simpler P… Les Ginsberg (ginsberg)
- Re: [spring] SID Conflict Resolution: A Simpler P… bruno.decraene
- Re: [spring] SID Conflict Resolution: A Simpler P… Aissaoui, Mustapha (Nokia - CA)
- Re: [spring] SID Conflict Resolution: A Simpler P… Les Ginsberg (ginsberg)
- Re: [spring] SID Conflict Resolution: A Simpler P… Les Ginsberg (ginsberg)
- Re: [spring] SID Conflict Resolution: A Simpler P… Van De Velde, Gunter (Nokia - BE)
- Re: [spring] SID Conflict Resolution: A Simpler P… Les Ginsberg (ginsberg)
- Re: [spring] SID Conflict Resolution: A Simpler P… Robert Raszuk
- Re: [spring] SID Conflict Resolution: A Simpler P… Les Ginsberg (ginsberg)
- Re: [spring] SID Conflict Resolution: A Simpler P… Van De Velde, Gunter (Nokia - BE)
- Re: [spring] SID Conflict Resolution: A Simpler P… Henderickx, Wim (Nokia - BE)
- Re: [spring] SID Conflict Resolution: A Simpler P… bruno.decraene
- Re: [spring] SID Conflict Resolution: A Simpler P… Les Ginsberg (ginsberg)
- Re: [spring] SID Conflict Resolution: A Simpler P… bruno.decraene
- Re: [spring] SID Conflict Resolution: A Simpler P… bruno.decraene
- Re: [spring] SID Conflict Resolution: A Simpler P… Les Ginsberg (ginsberg)
- Re: [spring] SID Conflict Resolution: A Simpler P… Les Ginsberg (ginsberg)
- Re: [spring] SID Conflict Resolution: A Simpler P… Aissaoui, Mustapha (Nokia - CA)
- Re: [spring] SID Conflict Resolution: A Simpler P… Les Ginsberg (ginsberg)
- Re: [spring] SID Conflict Resolution: A Simpler P… Robert Raszuk
- Re: [spring] SID Conflict Resolution: A Simpler P… Les Ginsberg (ginsberg)
- Re: [spring] SID Conflict Resolution: A Simpler P… Robert Raszuk
- Re: [spring] SID Conflict Resolution: A Simpler P… Les Ginsberg (ginsberg)
- Re: [spring] SID Conflict Resolution: A Simpler P… Robert Raszuk
- Re: [spring] SID Conflict Resolution: A Simpler P… Les Ginsberg (ginsberg)
- Re: [spring] SID Conflict Resolution: A Simpler P… Aissaoui, Mustapha (Nokia - CA)
- Re: [spring] SID Conflict Resolution: A Simpler P… Aissaoui, Mustapha (Nokia - CA)
- Re: [spring] SID Conflict Resolution: A Simpler P… Marc Binderberger
- Re: [spring] SID Conflict Resolution: A Simpler P… Les Ginsberg (ginsberg)
- Re: [spring] SID Conflict Resolution: A Simpler P… Les Ginsberg (ginsberg)
- Re: [spring] SID Conflict Resolution: A Simpler P… Marc Binderberger
- Re: [spring] SID Conflict Resolution: A Simpler P… bruno.decraene
- Re: [spring] SID Conflict Resolution: A Simpler P… bruno.decraene
- Re: [spring] SID Conflict Resolution: A Simpler P… bruno.decraene
- Re: [spring] SID Conflict Resolution: A Simpler P… Aissaoui, Mustapha (Nokia - CA)