IETF Logo Mail Archive

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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Fri, 23 February 2018 17:38 UTC

Return-Path: <ginsberg@cisco.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 6C9791241F8; Fri, 23 Feb 2018 09:38:01 -0800 (PST)
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 czaX7FRXVrUC; Fri, 23 Feb 2018 09:37:59 -0800 (PST)
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 4DCEC12008A; Fri, 23 Feb 2018 09:37:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28358; q=dns/txt; s=iport; t=1519407479; x=1520617079; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AF/eC05ObT3pakYb84EHEgf02kOuh+UgdJKb5bFXAzU=; b=FPBIu5M1D5mNnXwF66thqaZmS85ZHDWZaWxmKG4s2dk0Qdy7B9ebLLyL l24lPAgwhBh9qafOwEgp1fW02UN4/g1oeeHe6kvqJy3x2tiaJYvzxQJu/ fr0tZ9hD8l6f4VFsTfdOHpwyPX4u63JGbdaLQ6w2hstGjRgEcoJpJcK3g A=;
X-Files: image001.png : 7156
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AxAQArUJBa/4UNJK1dGQEBAQEBAQEBAQEBAQcBAQEBAYJadWZwKAqOA417ggKBFpZRFIICBwECJYUOAoI4VBgBAgEBAQEBAQJrKIUjAQEBBAUgCAFLEAIBCBEEAQEGAQEBGwQHAgUQAQ4MFAkIAQEEAQ0EAQYCBooVEKo7EYNOiHiCHgEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4KBYUYgieBV4Fmgy2DLgEBAgGBNm6FRgWkQgkChyEBgQWNXoIohimLfYscgnGJcQIRGQGBOwEfOYFRcBWCfYJUHBmBbXgBjACBGQEBAQ
X-IronPort-AV: E=Sophos;i="5.47,383,1515456000"; d="png'150?scan'150,208,217,150";a="357941178"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2018 17:37:58 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w1NHbwi0000387 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 23 Feb 2018 17:37:58 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.1320.4; Fri, 23 Feb 2018 11:37:57 -0600
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.1320.000; Fri, 23 Feb 2018 11:37:57 -0600
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Mahendra Singh Negi <mahendrasingh@huawei.com>, "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/oJwAxyePAABseD4A=
Date: Fri, 23 Feb 2018 17:37:57 +0000
Message-ID: <85b56959d3e74ffd9ca6edbadc4d0f3c@XCH-ALN-001.cisco.com>
References: <B495DF531F7B5943B1816E2031125EF8A846E542@DGGEMI512-MBX.china.huawei.com>
In-Reply-To: <B495DF531F7B5943B1816E2031125EF8A846E542@DGGEMI512-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.98.188]
Content-Type: multipart/related; boundary="_004_85b56959d3e74ffd9ca6edbadc4d0f3cXCHALN001ciscocom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/bFq8Tr6jr8ZcGaPzQxrrYqQ1m_w>
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 17:38:01 -0000

Mahendra -

Similar to Peter, I don't fully understand your scenario.

You claim:

10.10.10.10/SID 1 is originated by RT1
10.10.10.10/SID 3 os originated by RT3

Now you change SID config on RT1 so it advertises:
10.10.10.10/SID 4

In a short period of time RT2 should also reflect this update.

So the statement "SID:1 is forever in LSDB" makes no sense to me.

Certainly there is a transient period during which databases may have different combinations of (1,3) or (4,3) or even (1,3,4) but this will not persist.

   Les


From: Mahendra Singh Negi [mailto:mahendrasingh@huawei.com]
Sent: Thursday, February 22, 2018 8:49 PM
To: draft-ietf-spring-conflict-resolution@ietf.org; draft-ietf-ospf-segment-routing-extensions@ietf.org
Cc: ospf@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution/draft-ietf-ospf-segment-routing-extensions: If you please provide your inputs on the issue.

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@01D3AC89.CC75DE10]

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

v2.23.0 | Report a Bug | By Email