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

From: Mahendra Singh Negi <[email-masked]>
Date: Fri, 23 Feb 2018 04:48:47 +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:

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

---

From: Peter Psenak <[email-masked]>
Date: Fri, 23 Feb 2018 09:28:39 +0100

Mahendra,

On 23/02/18 05:48 , Mahendra Singh Negi wrote:
> 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:*
>
> *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
>
>
> &
>
>    (If an OSPF router advertises multiple Prefix-SIDs for the same
> prefix, topology and algorithm, all of them MUST be ignored.)

which router advertises multiple Prefix-SIDs for the same prefix in your 
example?
>
> 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.

I don't understand the above. Why would that happen?

Peter

>
> *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
>

---

From: Mahendra Singh Negi <[email-masked]>
Date: Fri, 23 Feb 2018 09:02:57 +0000

which router advertises multiple Prefix-SIDs for the same prefix in your example?
->
ABRs (RT1 and RT2) advertise resolved SID(i.e. SID:1) in area a1 for same prefix 10.10.10.10.

Now on configuration change at RT1 (i.e. SID:4), RT1 assumes SID:1 be originated by RT2 and runs conflict resolution
->

Regards,
Mahendra

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: 23 February 2018 13:59
To: Mahendra Singh Negi; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: draft-ietf-spring-conflict-resolution/draft-ietf-ospf-segment-routing-extensions: If you please provide your inputs on the issue.

Mahendra,

On 23/02/18 05:48 , Mahendra Singh Negi wrote:
> https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-05) 
> we came across this issue.
>
> **
>
> **
>
> *Topology:*
>
> *Issue:*
>
> 2.Both RT1 and RT2 resolve the conflict and download corresponding 
> Label for SID:1 (SID:1 wins conflict resolution).
>

which router advertises multiple Prefix-SIDs for the same prefix in your example?

Peter

> SID:1 flushing out from the LSDB and then originates with new 
> SID:4.(How long to wait is decided locally).
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 23 Feb 2018 17:37:57 +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:[email-masked]]
Sent: Thursday, February 22, 2018 8:49 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: draft-ietf-spring-conflict-resolution/draft-ietf-ospf-segment-routing-extensions: If you please provide your inputs on the issue.

Dear Authors,

Topology:

Issue:

&

How to fix the issue?

Regards,
Mahendra

---

From: Mahendra Singh Negi <[email-masked]>
Date: Fri, 23 Feb 2018 21:03:15 +0000

Dear Les,

Abrs RT1 and RT2 advertise SID 1 in area a1 10.10.10.10 SID:1 inter-area.

Now in RT1 change the configuration to SID:4.

RT1 assumes that SID:1 being originated by RT2 as SID:1 (inter-area is not yet deleted), hence Prefix conflict resolution is triggerred and SID:1 wins.

RT1 advertise 10.10.10.10 SID:1 in area a1 and 10.10.10.10 SID:4 in area a0.
In general I understand it like this : each node resolves the conflict, downloads wining SID for forwarding but advertises locally configured SID. I think advertisement should not depend on conflict-resolution, If you please clarify on this basic point.
Agreed, issue will not persist, its a transient one.

Regards,
Mahendra
From:Les Ginsberg (ginsberg)
To:Mahendra Singh Negi,[email-masked],[email-masked]
Cc:[email-masked]
Date:2018-02-23 23:08:17
Subject:RE: draft-ietf-spring-conflict-resolution/draft-ietf-ospf-segment-routing-extensions: If you please provide your inputs on the issue.

Mahendra –

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

You claim:

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

   Les

Dear Authors,

Topology:

Issue:

&

How to fix the issue?

Regards,
Mahendra

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 23 Feb 2018 21:08:06 +0000

Mahendra -

What is advertised depends on what is configured (right or wrong). We do not "overwrite" config based on detected conflicts - the misconfiguration has to be addressed by the network operator.

   Les

From: Mahendra Singh Negi [mailto:[email-masked]]
Sent: Friday, February 23, 2018 1:03 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: draft-ietf-spring-conflict-resolution <[email-masked]>; draft-ietf-ospf-segment-routing-extensions <[email-masked]>; ospf <[email-masked]>
Subject: Re: RE: draft-ietf-spring-conflict-resolution/draft-ietf-ospf-segment-routing-extensions: If you please provide your inputs on the issue.

Dear Les,

Regards,
Mahendra

Mahendra -

You claim:

   Les

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

Dear Authors,

Topology:

Issue:

&

How to fix the issue?

Regards,
Mahendra

---

From: Mahendra Singh Negi <[email-masked]>
Date: Fri, 23 Feb 2018 21:22:23 +0000

Thanks for the clarification.

Regards,
Mahendra
From:Les Ginsberg (ginsberg)
To:Mahendra Singh Negi
Cc:draft-ietf-spring-conflict-resolution,draft-ietf-ospf-segment-routing-extensions,ospf
Date:2018-02-24 02:38:19
Subject:RE: RE: draft-ietf-spring-conflict-resolution/draft-ietf-ospf-segment-routing-extensions: If you please provide your inputs on the issue.

Mahendra –

What is advertised depends on what is configured (right or wrong). We do not “overwrite” config based on detected conflicts – the misconfiguration has to be addressed by the network operator.

   Les

Dear Les,

Regards,
Mahendra

Mahendra –

You claim:

   Les

Dear Authors,

Topology:

Issue:

&

How to fix the issue?

Regards,
Mahendra