Re: [OSPF] draft-ietf-spring-conflict-resolution/draft-ietf-ospf-segment-routing-extensions: If you please provide your inputs on the issue.

Mahendra Singh Negi <mahendrasingh@huawei.com> Fri, 23 February 2018 04:49 UTC

Return-Path: <mahendrasingh@huawei.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3628F12008A; Thu, 22 Feb 2018 20:49:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.229
X-Spam-Level:
X-Spam-Status: No, score=-4.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, 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 4VS5hYLVQ0Cz; Thu, 22 Feb 2018 20:49:11 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 2EE84120727; Thu, 22 Feb 2018 20:49:04 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id CB66058F457D8; Fri, 23 Feb 2018 04:49:00 +0000 (GMT)
Received: from DGGEMI406-HUB.china.huawei.com (10.3.17.144) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 23 Feb 2018 04:49:01 +0000
Received: from DGGEMI512-MBX.china.huawei.com ([169.254.4.157]) by dggemi406-hub.china.huawei.com ([10.3.17.144]) with mapi id 14.03.0361.001; Fri, 23 Feb 2018 12:48:48 +0800
From: Mahendra Singh Negi <mahendrasingh@huawei.com>
To: "draft-ietf-spring-conflict-resolution@ietf.org" <draft-ietf-spring-conflict-resolution@ietf.org>, "draft-ietf-ospf-segment-routing-extensions@ietf.org" <draft-ietf-ospf-segment-routing-extensions@ietf.org>
CC: "ospf@ietf.org" <ospf@ietf.org>
Thread-Topic: draft-ietf-spring-conflict-resolution/draft-ietf-ospf-segment-routing-extensions: If you please provide your inputs on the issue.
Thread-Index: AdOrmDoKtvH811w7SQ6U3oTJ9e/oJwAxyePA
Date: Fri, 23 Feb 2018 04:48:47 +0000
Message-ID: <B495DF531F7B5943B1816E2031125EF8A846E542@DGGEMI512-MBX.china.huawei.com>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.153.41]
Content-Type: multipart/related; boundary="_004_B495DF531F7B5943B1816E2031125EF8A846E542DGGEMI512MBXchi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/2UVR-wEIEmcdSiYUMbvs_peVec4>
Subject: Re: [OSPF] draft-ietf-spring-conflict-resolution/draft-ietf-ospf-segment-routing-extensions: If you please provide your inputs on the issue.
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Feb 2018 04:49:13 -0000

Dear Authors,

Amidst implementing conflict resolution for OSPF SR ( https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-05) we came across this issue.


Topology:
[cid:image001.png@01D3AC8E.01F60430]

Issue:



1.       Prefix conflict occurs at RT1 and RT2.

2.       Both RT1 and RT2 resolve the conflict and download corresponding Label for SID:1 (SID:1 wins conflict resolution).

3.       Both RT1 and RT2 advertise inter-area Extended Prefix Opaque LSA for prefix 10.10.10.10 in area a1 with SID:1.

Reference: https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-24#section-7.2

&

https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-24#section-5

  (If an OSPF router advertises multiple Prefix-SIDs for the same prefix, topology and algorithm, all of them MUST be ignored.)



4.       Now at RT1, user changes the  SID configuration value to 4, and still SID 1 wins the conflict resolution as in area a1 RT2 has not flushed or updated SID:1, and SID:1 is forever in LSDB.

How to fix the issue?

a)      think ABRs should advertise all the SIDs to leaking areas and MUST condition mentioned highlighted in yellow above be relaxed (i.e. update inter-area segment routing section accordingly) and let each node run conflict-resolution.

b)       On SID configuration change, RT1 Flushes the SID:1 and waits for SID:1 flushing out from the LSDB and then originates with new SID:4.(How long to wait is decided locally).


I prefer (a), if you please provide your opinion on this. We are under development, highly appreciate prompt  responses.



Regards,
Mahendra