Subject: [spring] Anycast and SID Conflict Resolution

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 13 May 2017 00:28:23 +0000

(Changing subject - was "Mail regarding draft-ietf-spring-conflict-resolution")

Shraddha/Eric -

Although the conflict resolution draft is not yet in its final form, there are some basic principles which have not changed across the various versions:

1)Who advertised a SID plays no role in conflict resolution
2)All nodes agree on which mapping entries are Active(MAY be used in forwarding) and which are Inactive (MUST NOT be used in forwarding)
3)Whether the Active entry is consistent w local configuration is not relevant

The scenario you describe below:

Node X advertises address A with SID S
Node Y advertises address A with no SID

This is not a conflict.
It may represent a misconfiguration - but this does not matter to conflict resolution.

How could this legitimately happen?
The operator may be introducing (or withdrawing) use of an SRMS. Addition or removal of local SID configuration may simply be in transition.

How could this be a misconfiguration?
Address A was not intended to be an anycast address and was incorrectly configured on Node Y.

(Other possibilities exist)

The conflict resolution procedures make no attempt to determine which entries are "right" and which entries are "wrong". A database is built of all advertised mapping entries, the conflict resolution policy is applied, and a set of Active/Inactive entries result. All SR capable nodes MUST use that output when programming forwarding entries. All that conflict resolution is trying to achieve is consistent behavior in the forwarding plane.

   Les

From: Shraddha Hegde [mailto:[email-masked]]
Sent: Wednesday, May 03, 2017 9:58 AM
To: [email-masked]
Cc: [email-masked]
Subject: Mail regarding draft-ietf-spring-conflict-resolution

Hi Authors,

When there are multiple anycast IP addresses assigned to different nodes and one or more nodes
do not advertise a Prefix SID for that anycast address but other nodes advertise a prefix-sid, there is a possibility
of different implementations behaving differently with respect to programming the labelled routes.

This scenario should be considered as a prefix conflict and the behavior should be addressed in the draft.
I suggest to update section 3.2.1 with the relevant text to describe the behavior.

Rgds
Shraddha