(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 protected]] Sent: Wednesday, May 03, 2017 9:58 AM To: [email protected] Cc: [email protected] 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
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
