Les,

>From what you describe in section 3.3.8, all the SIDs attached to prefixes are 
>fed into the database.
The example I am talking about,

1.prefix 1.1.1.1 advertised from node A with no SID
2.Prefix 1.1.1.1 advertised from node B with SID 10
3. Prefix 1.1.1.1 advertised from node C with SID 10

The advertisements 2 and 3 are fed into the mapping database and 1 isn't.

The conflict resolution does not detect any conflict with the above 
advertisements and
For prefix 1.1.1.1 /SID 10 is chosen.
All this is fine but the problem is in programming the forwarding plane.

Lets say for a certain node E in the network node A is the nexthop for 1.1.1.1.
How would node E program its forwarding plane?

Node E should recognize the conflict between node A, Node B and C and program 
the
SID 10 with a pop and forward instead of looking into the P and E flags of the 
SID 10?

This is good enough detail, that should be explained in the draft instead of 
leaving it to the
Imagination of implementers.

Rgds
Shraddha




From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Wednesday, May 3, 2017 11:47 PM
To: Shraddha Hegde <shrad...@juniper.net>; 
draft-ietf-spring-conflict-resolut...@ietf.org
Cc: spring@ietf.org
Subject: RE: Mail regarding draft-ietf-spring-conflict-resolution

Shraddha -

There is a misunderstanding on your part. It would be good if you read Section 
3.3.8.  Guaranteeing Database Consistency again.

In short, it does not matter whether you do or do not advertise a prefix SID 
for a prefix which you own. What matters is that all routers populate the 
mapping entry database consistent w Section 3.3.8 and that each router applies 
the conflict resolution rules in a consistent manner. Then all routers will be 
using the same prefix/SID pair in forwarding.

   Les


From: Shraddha Hegde [mailto:shrad...@juniper.net]
Sent: Wednesday, May 03, 2017 9:58 AM
To: 
draft-ietf-spring-conflict-resolut...@ietf.org<mailto:draft-ietf-spring-conflict-resolut...@ietf.org>
Cc: spring@ietf.org<mailto:spring@ietf.org>
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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Reply via email to