Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 1 Jan 2017 17:15:18 +0000

Mustapha -

Some responses inline, but I emphasize again that the most important issue being discussed at the moment is what to do when conflicts are detected. There are two proposals:

1)Do not use the SIDs which are in conflict ("Ignore")
2)Use some conflict resolution algorithm to choose how to use the conflicting SIDs ("Ignore overlap only")

I would encourage you and everyone else to comment on that.

If we choose #2 above then the specific preference rule (currently defined in Section 3.3.4 of the draft) can be reviewed - but not much point in doing so until we decide whether we are going to use a preference rule at all.

From: Aissaoui, Mustapha (Nokia - CA) [mailto:[email-masked]]
Sent: Friday, December 23, 2016 6:59 AM
To: Les Ginsberg (ginsberg); [email-masked]
Subject: RE: SID Conflict Resolution: A Simpler Proposal

Hi Les,
I made some follow-up inline.

Regards,
Mustapha.

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Thursday, December 22, 2016 2:37 PM
To: Aissaoui, Mustapha (Nokia - CA) <[email-masked]>; [email-masked]
Subject: RE: SID Conflict Resolution: A Simpler Proposal

Mustapha -

From: spring [mailto:[email-masked]] On Behalf Of Aissaoui, Mustapha (Nokia - CA)
Sent: Thursday, December 22, 2016 8:10 AM
To: Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal

Hi Les,
I read slides 17-21 of the document you referenced below and I have the following comments:

1.     Page 17, "Order Matters - Prefix vs SID Conflict".

When you perform resolution on  a per prefix basis, prefix conflicts are naturally processed first followed by SID conflicts across different prefixes. So the ordering issue described is only specific if you decided to resolve conflicting SID entries outside of the natural prefix resolution by a router.

[Les:] What may seem "natural" to you might not to someone else. I don't care to debate that point. What is being illustrated here is that in order to provide a normative specification that - if followed - guarantees interoperability we have to specify the order in which conflicts are processed otherwise different results may be obtained.

MA> I agree on the intent of specifying a procedure which achieves interoperability. However, it seems to me this draft is ignoring the fact that routers do per-prefix resolution and is trying to perform the SID resolution outside of it.
[Les2:] Section 3.2 of the draft details the types of conflicts which may occur. These include:

  1)Prefix conflicts - different SIDs assigned to the same prefix
2)SID conflicts - multiple prefixes associated with the same SID

The term "pre-prefix resolution" suggests to me that you think all we have to do is find all the SID advertisements associated with a given prefix in order to determine whether we have a conflict or not. But that only finds "prefix conflicts" - it does not find SID conflicts - and both have to be dealt with.
If you mean something else please clarify.

2.     Page 18, "Order Matters: Derived vs non-derived- prefix conflict".

It seems to me this issue is an artifact of the specific algorithm used to resolve conflicts. Because the algorithm uses parameters such as "Range (start w smallest)" then obviously derived SRMS entries will lend a different result than original SRMS entries.

With the pre-prefix resolution, the only information kept from the original SRMS entry is the preference and the advertising or owner router. Anything else is not used. It seems to me a simple algorithm based on preference first then followed by some rule on selecting the advertising router if conflicts exist within the same preference would work.

[Les:] You have implemented things in a certain way. Someone else might choose to implement in a different way. A normative specification does not (and should not) constrain an implementation. What is being illustrated here is that if the implementation does not retain the underived entry (in whatever internal form it chooses) different results will be obtained because the preference algorithm depends on comparing the underived ranges.

MA> I do not believe this is about implementation. It is about what routers do and that is resolution per prefix. It does not matter how the prefix SID information is advertised, individually or part of an SRMS entry, at the end it is associated with a prefix.

3.     Finally, there is something which has not been addressed in the slides. There is still a possibility of conflicting entries among SIDs advertised using the prefix SID sub-TLV within a Prefix TLV (IS-IS IP Reach TLV or OSPF Extended Prefix TLV). A simple rule selecting the advertising router should also work fine here.

[Les:] No - source of an advertisement has been quite deliberately excluded from the preference algorithm. With redistribution/route leaking the source of an advertisement may appear to be different on different routers- this would result in different results on different routers.

MA> The following RFC is specifying an optional attribute (the IPv4/IPv6 Source Router ID TLV) to encode the original advertising router of a prefix. This can be used to perform a simple selection algorithm:
https://tools.ietf.org/html/rfc7794#section-2.2

Otherwise, what is your proposal for this point (3)? I could not find it addressed in the current version of the draft.

[Les2:] The proposal is NOT to use the source of an advertisement as an input to conflict resolution.
RFC 7794 only addresses the issue for IS-IS and even then only for SIDs learned via prefix reachability advertisements. Use of source still has consistency issues for SRMS advertisements, OSPF, and cases which involve multiple protocol instances.
This choice has been consciously made and is in part based on our experience with existing implementations.

That said, this issue is only relevant if you believe it is necessary/desirable to use a preference rule to make a choice when a conflict exists.
The proponents of "Ignore" don't want to do this - we want to NOT use SIDs which are in conflict. We believe this is less likely to lead to interoperability problems and is less likely to have undesirable side effects. It also prioritizes detection and reporting of conflicts.

   Les

Regards,
Mustapha.

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Friday, December 09, 2016 1:49 PM
To: Aissaoui, Mustapha (Nokia - CA) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: SID Conflict Resolution: A Simpler Proposal

Mustapha -

From: Aissaoui, Mustapha (Nokia - CA) [mailto:[email-masked]]
Sent: Friday, December 09, 2016 7:44 AM
To: Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>
Subject: RE: SID Conflict Resolution: A Simpler Proposal

I have a couple of comments on the below proposal.

1.     Regarding the SRMS Preference Sub-TLV in section 3.1 of the draft. In many cases, a configuration on the resolving router can assign a preference to each SRMS in case there is no advertisement of this sub-TLV or to override an advertised value. I propose that this option be allowed. Here is a proposed update to the relevant paragraph:

"
           Advertisement of a preference value is optional.  Nodes which do not
          advertise a preference value are assigned a preference value of 128.
           A resolving router can override the default or the advertised value by local policy.

"

[Les:] In order to get consistent conflict resolution on all nodes in the network, it is necessary that they all have the same database - which includes the preference value. If you allow local policy to modify the preference you no longer have consistent databases on all nodes and we can no longer guarantee consistent conflict resolution. So your proposal is not viable IMO.

2.     I am trying to understand the concept of sorting SRMS entries which have different prefixes and different range sizes.

Since a SID advertised in a prefix SID sub-TLV within a Prefix TLV (IS-IS IP Reach TLV or OSPF Extended Prefix TLV) has higher priority over a SID for the same prefix advertised from a SRMS, then you have to add to the below sorting an entry for each individual prefix which advertised a prefix SID sub-TLV within a prefix TLV.

At this point, the concept of an entry with multiple prefixes is moot and you may as well just sort on a per prefix basis which is the most natural thing to do given that the prefix resolution and then the SID resolution are performed on a per prefix basis. SID conflicts can be resolved on a per prefix basis using the below proposed preference algorithm without having to ignore SID values for unrelated prefixes just because it happens that they were advertised in the same SRMS entry.

[Les:] The simpler proposal does not require sorting on anything other than preference. After that, you can process entries in any order you want and you will get the same answer.

With "Ignore Overlap Only" one of the issues with trying to use the non-conflicting portions of a mapping entry which has a range > 1 is that the order in which you process entries influences the result. Please see slides 17 - 20 from the IETF97 presentation: https://www.ietf.org/proceedings/97/slides/slides-97-spring-1_ietf97_draft-ietf-spring-conflict-resolution-02-00.pptx for some simple examples of this.

   Les

Regards,
Mustapha.

From: spring [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Sunday, December 04, 2016 7:04 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [spring] SID Conflict Resolution: A Simpler Proposal

When the problem addressed by draft-ietf-spring-conflict-resolution was first

presented at IETF 94, the authors defined the following priorities:

1)Detect the problem

2)Report the problem

This alerts the network operator to the existence of a conflict so that

the configuration error can be corrected.

3)Define consistent behavior

This avoids mis-forwarding while the conflict exists.

4)Don't overengineer the solution

Given that it is impossible to know which of the conflicting entries

is the correct one, we should apply a simple algorithm to resolve the conflict.

5)Agree on the resolution behavior

The resolution behavior was deliberately the last point because it was

considered the least important.

Input was received over the past year which emphasized the importance of

trying to "maximize forwarding" in the presence of conflicts. Subsequent

revisions of the draft have tried to address this concern. However the authors

have repeatedly stressed that the solution being proposed

("ignore overlap only") was more complex than other offered alternatives and

would be more difficult to guarantee interoperability because subtle

differences in an implementation could produce different results.

At IETF97 significant feedback was received preferring a simpler solution to

the problem. The authors are very sympathetic to this feedback and therefore

are proposing a solution based on what the draft defines as the "Ignore"

policy - where all entries which are in conflict are ignored. We believe this

is far more desirable and aligns with the priorities listed above.

We outline the proposed solution below and would like to receive feedback from

the WG before publishing the next revision of the draft.

   Les (on behalf of the authors)

New Proposal

In the latest revision of the draft "SRMS Preference" was introduced. This

provides a way for a numerical preference to be explicitly associated with an

SRMS advertisement. Using this an operator can indicate which advertisement is

to be preferred when a conflict is present. The authors think this is a useful

addition and we therefore want to include this in the new solution.

The new preference rule used to resolve conflicts is defined as follows:

A given mapping entry is compared against all mapping entries in the database

with a preference greater than or equal to its own. If there is a conflict,

the mapping entry with lower preference is ignored. If two mapping entries are

in conflict and have equal preference then both entries are ignored.

Implementation of this policy is defined as follows:

Step 1: Within a single address-family/algorithm/topology sort entries

based on preference

Step 2: Starting with the lowest preference entries, resolve prefix conflicts

using the above preference rule. The output is an active policy per topology.

Step 3: Take the outputs from Step 2 and again sort them by preference

Step 4: Starting with the lowest preference entries, resolve SID conflicts

using the above preference rule

The output from Step 4 is then the current Active Policy.

Here are a few examples. Each mapping entry is represented by the tuple:

(Preference, Prefix/mask Index range <#>)

Example 1:

1. (150, 1.1.1.1/32 100 range 100)

2. (149, 1.1.1.10/32 200 range 200)

3. (148, 1.1.1.101/32 500 range 10)

Entry 3 conflicts with entry 2, it is ignored.

Entry 2 conflicts with entry 1, it is ignored.

Active policy:

(150, 1.1.1.1/32 100 range 100)

Example 2:

1. (150, 1.1.1.1/32 100 range 100)

2. (150, 1.1.1.10/32 200 range 200)

3. (150, 1.1.1.101/32 500 range 10)

4. (150, 2.2.2.1/32 1000 range 1)

Entry 1 conflicts with entry 2, both are marked as ignore.

Entry 3 conflicts with entry 2. It is marked as ignore.

Entry 4 has no conflicts with any entries

Active policy:

(150, 2.2.2.1/32 1000 range 1)

Example 3:

1. (150, 1.1.1.1/32 100 range 500)

2. (150, 1.1.1.10/32 200 range 200)

3. (150, 1.1.1.101/32 500 range 10)

4. (150, 2.2.2.1/32 1000 range 1)

Entry 1 conflicts with entries 2, 3, and  4. All entries are marked ignore.

Active policy:

Empty

Example 4:

1. (150, 1.1.1.1/32 100 range 10)

2. (149, 1.1.1.10/32 200 range 300)

3. (149, 1.1.1.101/32 500 range 10)

4. (148, 2.2.2.1/32 1000 range 1)

Entry 4 conflicts with entry 2. It is marked ignore.

Entry 2 conflicts with entry 3. Entries 2 and 3 are marked ignore.

Active policy:

(150, 1.1.1.1/32 100 range 10)

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 1 Jan 2017 17:25:06 +0000

Marc

> -----Original Message-----
> From: Marc Binderberger [mailto:[email-masked]]
> Sent: Friday, December 30, 2016 11:53 PM
> To: Aissaoui, Mustapha (Nokia - CA); Robert Raszuk; Les Ginsberg (ginsberg)
> Cc: [email-masked]
> mind-boggling discussion :-)
> 
> Hello SR experts.
> 
> 
> Mustapha wrote
> 
> > I have the impression the authors are trying to address SID conflict
> > resolution outside of the natural per prefix resolution on the router.
> 
> that was my thought too. From the routing protocol I deal with a prefix. Then
> I need to find the SID for the prefix to program my ingress/egress labels. If
> the mapping prefix -> SID has conflicting results _then_ I have a problem.
> 
> 
> Or in other words:
> 
> 2. (150, 1.1.1.1/32 500 range 2)
> 
> would result in no mapping, following the new proposal. All due to a typo of
> 1.1.1.1 instead of 1.1.2.1 in the 2nd mapping?  While I understand the
> algorithm I don't want to be the poor operator having my OSS screen full with
> alarms for 1.1.1.3..100 .
> 
> 
> Btw, the "preference" field, what purpose does is serve?  Has this been
> introduced solely to tie-break conflicts?  So we have one more parameter
> that can be typo-d :-) Or is there actually an application for it?

[Les:] Preference has been introduced primarily to support introduction of a new mapping servers in a safer manner. It also can support non-disruptive  migration from an LDP enabled network to an SR enabled network.

Consider the simple example of wanting to bring up a new mapping server in a live network. One can introduce the new SRMS advertisements with a preference of "0" - so they won't be used but will be advertised. Advertisements can then be validated by all nodes (e.g. implementations could provide informational report of conflicts even when the conflicting advertisements are not actually being used to determine what to install in the forwarding plane) before they are put into use.

HTH

    Les

> 
> 
> Robert wrote
> 
> > After mental reset I conclude that perhaps even the introduction of
> > the draft is questionable
> 
> That goes much further than what I had in mind ;-) but I wonder if we go too
> far. I still think it is useful to describe what is a conflict - and this way also
> saying what should not be mistaken for a conflict. The discussion about
> conflict-with-range vs. conflict-with-prefix seems useful to me.
> 
> My problem with the earlier drafts was more about the conflict
> resolution/reaction, I found it complex and too specific to generally agree on.
> My personal opinion is when you have a conflict then _drop_ the prefix
> traffic. But quite frankly "dropping", "not programming", "strip to IP" or
> whatever else, they are all simple operations. Or simple code path, as
> Stewart put it, as long as we stick to _one_ of them. The draft should
> demand one particular operation to be a MUST for interoperability.
> 
> 
> 
> Regards, Marc
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Fri, 23 Dec 2016 15:24:55 +0000, Aissaoui, Mustapha (Nokia - CA) wrote:
> > Hi Robert,
> > In fact you are touching on the point I am trying to make in my
> > comment (1) on the slides. Reading this draft, I have the impression
> > the authors are trying to address SID conflict resolution outside of
> > the natural per prefix resolution on the router. While in theory this
> > can be done but it makes the algorithm much more complex trying to
> > compare overlapping SRMS SID entries with different range sizes.
> >
> > There are two sources of advertisement of the SID information:
> > a.     Per-prefix SID entries received in the  prefix SID sub-TLV within a
> > Prefix TLV (IS-IS IP Reach TLV or OSPF Extended Prefix TLV).
> > b.     SRMS entries which advertise SID information for a range of prefixes.
> >
> > The range size of the SRMS entry entirely depends on how the user
> > wants to advertise the information and has no meaning for the
> > resolution. From a router's perspective, the SID information is
> > associated with a prefix regardless how it is advertised.
> >
> > The per-prefix SID information is preferred to the SRMS SID information.
> > And thus a simple algorithm which at the top level selects the SID
> > among set (a) based on the source advertising router and if empty
> > selects the SID among set (b) based on the SRMS preference and then
> > based on the SRMS router-id if same preference will work.
> >
> > Regards,
> > Mustapha.
> >
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert
> > Raszuk
> > Sent: Thursday, December 22, 2016 5:29 PM
> > To: Les Ginsberg (ginsberg) <[email-masked]>
> > Cc: Aissaoui, Mustapha (Nokia - CA) <[email-masked]>;
> > [email-masked]
> > Les,
> > After mental reset I conclude that perhaps even the introduction of
> > the draft is questionable as in real life it applies to be quite an
> > unrealistic scenario to have a situation where more then one protocol
> > is used *in the same time* as active in forwarding for an exact same IP
> prefix.
> >
> > Last time I checked SIDs are meaningless without a prefix they are
> > attached to and it is a prefix they accompany to indicate which SID
> > should be used on a given node.
> >
> > Therefor if you consider that today most implementations pretty well
> > can handle overlapping prefixes from multiple sources what real
> > problem is this draft solving ?
> >
> > Are you trying to create a forwarding graph by SIDs only detaching
> > them from IP prefixes all together ?
> >
> > Cheers,
> > R.
> >
> >
> > On Thu, Dec 22, 2016 at 10:32 PM, Les Ginsberg (ginsberg)
> > <[email-masked]> wrote:
> >> Robert -
> >>
> >> You have a complete misunderstanding of roles here.
> >>
> >> How the owner of a route may be represented in the RIB isn't impacted
> >> by SRMS or conflict resolution. Nor is the determination of which
> >> route is the best route. We are only determining whether to use or
> >> not use a SID which was associated with the prefix by some
> advertisement.
> >>
> >> The Introduction to the draft states:
> >>
> >> "The problem to be addressed is protocol independent i.e., segment
> >>    related advertisements may be originated by multiple nodes using
> >>    different protocols and yet the conflict resolution MUST be the same
> >>    on all nodes regardless of the protocol used to transport the
> >>    advertisements."
> >>
> >> Please do a mental reset. J
> >>
> >>    Les
> >>
> >>
> >> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> >> Robert Raszuk
> >> Sent: Thursday, December 22, 2016 11:52 AM
> >> To: Les Ginsberg (ginsberg)
> >> Cc: Aissaoui, Mustapha (Nokia - CA); [email-masked]
> >>
> >> On #1 I am also with Mustapha here. For clarity of this discussion
> >> can you enumerate when from RIB to FIB/LFIB you are installing the
> >> exact same active prefix from more then one producer ? Is SRMS sort
> >> of zombie here and not treated as real route producer hence we have
> >> an issue ? And the issue is only with conflicts of SRMS + real route
> producer ?
> >>
> >> On #3 you said that "with redistribution/route leaking the source of
> >> an advertisement may appear to be different on different routers"
> >> that is very true. In fact with simple static route or static label
> >> configured on a router the RIB and FIB on that router will be
> >> different then RIB and FIB on the other routers without such static
> >> route. And the point is that such static route or label is there for
> >> a reason you may not know about. So struggling for data plane
> >> consistency deliberately excluding source when operational needs
> >> require otherwise is not really that much helpful I am afraid.
> >>
> >> Greetings,
> >> Robert.
> >>
> >>
> >> On Thu, Dec 22, 2016 at 8:37 PM, Les Ginsberg (ginsberg)
> >> <[email-masked]> wrote:
> >> Mustapha -
> >>
> >> When you perform resolution on  a per prefix basis, prefix conflicts
> >> are naturally processed first followed by SID conflicts across
> >> different prefixes. So the ordering issue described is only specific
> >> if you decided to resolve conflicting SID entries outside of the
> >> natural prefix resolution by a router.
> >>
> >> [Les:] What may seem "natural" to you might not to someone else. I don'
> >> t care to debate that point. What is being illustrated here is that
> >> in order to provide a normative specification that - if followed -
> >> guarantees interoperability we have to specify the order in which
> >> conflicts are processed otherwise different results may be obtained.
> >>
> >> It seems to me this issue is an artifact of the specific algorithm
> >> used to resolve conflicts. Because the algorithm uses parameters such
> >> as "Range (start w smallest)" then obviously derived SRMS entries
> >> will lend a different result than original SRMS entries.
> >> With the pre-prefix resolution, the only information kept from the
> >> original SRMS entry is the preference and the advertising or owner router.
> >> Anything else is not used. It seems to me a simple algorithm based on
> >> preference first then followed by some rule on selecting the
> >> advertising router if conflicts exist within the same preference would
> work.
> >>
> >> [Les:] You have implemented things in a certain way. Someone else
> >> might choose to implement in a different way. A normative
> >> specification does not (and should not) constrain an implementation.
> >> What is being illustrated here is that if the implementation does not
> >> retain the underived entry (in whatever internal form it chooses)
> >> different results will be obtained because the preference algorithm
> depends on comparing the underived ranges.
> >>
> >> 3.     Finally, there is something which has not been addressed in the
> >> slides. There is still a possibility of conflicting entries among
> >> SIDs advertised using the prefix SID sub-TLV within a Prefix TLV
> >> (IS-IS IP Reach TLV or OSPF Extended Prefix TLV). A simple rule
> >> selecting the advertising router should also work fine here.
> >>
> >> [Les:] No - source of an advertisement has been quite
> >>
> >> deliberately excluded from the preference algorithm. With
> >> redistribution/route leaking the source of an advertisement may
> >> appear to be different on different routers- this would result in
> >> different results on different routers.
> >>
> >>    Les
> >>
> >> Regards,
> >> Mustapha.
> >>
> >> 1.     Regarding the SRMS Preference Sub-TLV in section 3.1 of the draft.
> >> In many cases, a configuration on the resolving router can assign a
> >> preference to each SRMS in case there is no advertisement of this
> >> sub-TLV or to override an advertised value. I propose that this option be
> allowed.
> >> Here is a proposed update to the relevant paragraph:
> >> "
> >> [Les:] In order to get consistent conflict resolution on all nodes in
> >> the network, it is necessary that they all have the same database -
> >> which includes the preference value. If you allow local policy to
> >> modify the preference you no longer have consistent databases on all
> >> nodes and we can no longer guarantee consistent conflict resolution.
> >> So your proposal is not viable IMO.
> >>
> >> 2.     I am trying to understand the concept of sorting SRMS entries which
> >> have different prefixes and different range sizes.
> >> Since a SID advertised in a prefix SID sub-TLV within a Prefix TLV
> >> (IS-IS IP Reach TLV or OSPF Extended Prefix TLV) has higher priority
> >> over a SID for the same prefix advertised from a SRMS, then you have
> >> to add to the below sorting an entry for each individual prefix which
> >> advertised a prefix SID sub-TLV within a prefix TLV.
> >> At this point, the concept of an entry with multiple prefixes is moot
> >> and you may as well just sort on a per prefix basis which is the most
> >> natural thing to do given that the prefix resolution and then the SID
> >> resolution are performed on a per prefix basis. SID conflicts can be
> >> resolved on a per prefix basis using the below proposed preference
> >> algorithm without having to ignore SID values for unrelated prefixes
> >> just because it happens that they were advertised in the same SRMS
> entry.
> >>
> >> [Les:] The simpler proposal does not require sorting on anything
> >> other than preference. After that, you can process entries in any
> >> order you want and you will get the same answer.
> >> With "Ignore Overlap Only" one of the issues with trying to use the
> >> non-conflicting portions of a mapping entry which has a range > 1 is
> >> that the order in which you process entries influences the result.
> >> Please see slides 17 - 20 from the IETF97 presentation:
> >>
> https://www.ietf.org/proceedings/97/slides/slides-97-spring-1_ietf97_draft-
> ietf-spring-conflict-resolution-02-00.pptx
> >> for some simple examples of this.
> >>
> >>    Les
> >>
> >>
> >> Regards,
> >> Mustapha.
> >>
> >> From: spring [mailto:[email-masked]] On Behalf Of Les
> >> Ginsberg
> >> (ginsberg)
> >> To: [email-masked]
> >> When the problem addressed by draft-ietf-spring-conflict-resolution
> >> was first presented at IETF 94, the authors defined the following
> >> priorities:
> >>
> >> 1)Detect the problem
> >> 2)Report the problem
> >> This alerts the network operator to the existence of a conflict so
> >> that the configuration error can be corrected.
> >> The resolution behavior was deliberately the last point because it
> >> was considered the least important.
> >>
> >> Input was received over the past year which emphasized the importance
> >> of trying to "maximize forwarding" in the presence of conflicts.
> >> Subsequent revisions of the draft have tried to address this concern.
> >> However the authors have repeatedly stressed that the solution being
> >> proposed ("ignore overlap only") was more complex than other offered
> >> alternatives and would be more difficult to guarantee
> >> interoperability because subtle differences in an implementation
> >> could produce different results.
> >>
> >> At IETF97 significant feedback was received preferring a simpler
> >> solution to the problem. The authors are very sympathetic to this
> >> feedback and therefore are proposing a solution based on what the
> >> draft defines as the "Ignore"
> >> policy - where all entries which are in conflict are ignored. We
> >> believe this is far more desirable and aligns with the priorities
> >> listed above.
> >>
> >> We outline the proposed solution below and would like to receive
> >> feedback from the WG before publishing the next revision of the
> >> draft.
> >>
> >> In the latest revision of the draft "SRMS Preference" was introduced.
> >> This provides a way for a numerical preference to be explicitly
> >> associated with an SRMS advertisement. Using this an operator can
> >> indicate which advertisement is to be preferred when a conflict is
> >> present. The authors think this is a useful addition and we therefore
> >> want to include this in the new solution.
> >>
> >> A given mapping entry is compared against all mapping entries in the
> >> database with a preference greater than or equal to its own. If there
> >> is a conflict, the mapping entry with lower preference is ignored. If
> >> two mapping entries are in conflict and have equal preference then
> >> both entries are ignored.
> >>
> >> Step 1: Within a single address-family/algorithm/topology sort
> >> entries based on preference Step 2: Starting with the lowest
> >> preference entries, resolve prefix conflicts using the above
> >> preference rule. The output is an active policy per topology.
> >> Step 3: Take the outputs from Step 2 and again sort them by
> >> preference Step 4: Starting with the lowest preference entries,
> >> resolve SID conflicts using the above preference rule
> >>
> >> _______________________________________________
> >> spring mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/spring
> >>
> >
> >
> >
> > _______________________________________________
> > spring mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/spring

---

From: Marc Binderberger <[email-masked]>
Date: Sun, 1 Jan 2017 14:43:10 -0800

Hello Les,

I cannot help but thinking we get carried away with the SRMS ranges. For me 
the actual meaning of a range lays in it's expanded form; with this I mean

(<pref>, 10.1.1.1/32, 100, range 3) is expanded

    10.1.1.1/32 -> SID 100
    10.1.1.2/32 -> SID 101
    10.1.1.3/32 -> SID 102

If you take it from the expanded form then we have the "Ignore overlap only". 
That is how I understand the phrase "per-prefix". I would prefer to discuss 
the prefix or SID conflict on this expanded, per-prefix basis. E.g. for the 
example

with the typo/mistake of 1.1.1.1 instead of 1.1.2.1 in the 2nd range I don't 
see why prefixes 1.1.1.3/32 - 1.1.1.100/32 should not be mapped to SIDs 102 - 
199. The conflict is for 1.1.1.1/32 and 1.1.1.2/32 alone and the question of 
conflict resolution is for these two prefixes alone.

Saying this, having a warning that these two ranges create a conflict would 
be a useful debugging information.

For the action, once a conflict based on the expanded form is detected: I 
would prefer to drop the traffic, i.e. in the example above

    1.1.1.1/32 -> drop
    1.1.1.2/32 -> drop

nor should there be any ingress label programmed for SIDs 100, 101, 500, 501.
But as I said in another email, as long as we can agree on a simple action - 
drop, strip all labels, do not program the prefix - and make it mandatory 
that all implementations support this one action then fine with me.

Regards, Marc

On Sun, 1 Jan 2017 17:15:18 +0000, Les Ginsberg (ginsberg) wrote:
> Mustapha –
>  
> Some responses inline, but I emphasize again that the most important issue 
> being discussed at the moment is what to do when conflicts are detected. 
> There are two proposals:
>  
> 1)Do not use the SIDs which are in conflict (“Ignore”)
> 2)Use some conflict resolution algorithm to choose how to use the 
> conflicting SIDs (“Ignore overlap only”)
>  
> If we choose #2 above then the specific preference rule (currently defined 
> in Section 3.3.4 of the draft) can be reviewed – but not much point in 
> doing so until we decide whether we are going to use a preference rule at 
> all.
>  
> 1.     Page 17, “Order Matters - Prefix vs SID Conflict”.
> When you perform resolution on  a per prefix basis, prefix conflicts are 
> naturally processed first followed by SID conflicts across different 
> prefixes. So the ordering issue described is only specific if you decided 
> to resolve conflicting SID entries outside of the natural prefix resolution 
> by a router. 
>  
> [Les:] What may seem “natural” to you might not to someone else. I don’t 
> care to debate that point. What is being illustrated here is that in order 
> to provide a normative specification that – if followed – guarantees 
> interoperability we have to specify the order in which conflicts are 
> processed otherwise different results may be obtained.
>  
> MA> I agree on the intent of specifying a procedure which achieves 
> interoperability. However, it seems to me this draft is ignoring the fact 
> that routers do per-prefix resolution and is trying to perform the SID 
> resolution outside of it.
>   1)Prefix conflicts – different SIDs assigned to the same prefix
> 2)SID conflicts – multiple prefixes associated with the same SID
>  
> The term “pre-prefix resolution” suggests to me that you think all we 
> have to do is find all the SID advertisements associated with a given 
> prefix in order to determine whether we have a conflict or not. But that 
> only finds “prefix conflicts” – it does not find SID conflicts – and 
> both have to be dealt with.
> 2.     Page 18, “Order Matters: Derived vs non-derived– prefix conflict”.
> It seems to me this issue is an artifact of the specific algorithm used to 
> resolve conflicts. Because the algorithm uses parameters such as “Range 
> (start w smallest)” then obviously derived SRMS entries will lend a 
> different result than original SRMS entries. 
> With the pre-prefix resolution, the only information kept from the original 
> SRMS entry is the preference and the advertising or owner router. Anything 
> else is not used. It seems to me a simple algorithm based on preference 
> first then followed by some rule on selecting the advertising router if 
> conflicts exist within the same preference would work.
>  
> [Les:] You have implemented things in a certain way. Someone else might 
> choose to implement in a different way. A normative specification does not 
> (and should not) constrain an implementation. What is being illustrated 
> here is that if the implementation does not retain the underived entry (in 
> whatever internal form it chooses) different results will be obtained 
> because the preference algorithm depends on comparing the underived ranges.
>  
> MA> I do not believe this is about implementation. It is about what routers 
> do and that is resolution per prefix. It does not matter how the prefix SID 
> information is advertised, individually or part of an SRMS entry, at the 
> end it is associated with a prefix.
>  
> slides. There is still a possibility of conflicting entries among SIDs 
> advertised using the prefix SID sub-TLV within a Prefix TLV (IS-IS IP Reach 
> TLV or OSPF Extended Prefix TLV). A simple rule selecting the advertising 
> router should also work fine here.
>  
> [Les:] No – source of an advertisement has been quite deliberately 
> excluded from the preference algorithm. With redistribution/route leaking 
> the source of an advertisement may appear to be different on different 
> routers- this would result in different results on different routers.
>  
> MA> The following RFC is specifying an optional attribute (the IPv4/IPv6 
> Source Router ID TLV) to encode the original advertising router of a 
> prefix. This can be used to perform a simple selection algorithm:
> Otherwise, what is your proposal for this point (3)? I could not find it 
> addressed in the current version of the draft.
>  
> RFC 7794 only addresses the issue for IS-IS and even then only for SIDs 
> learned via prefix reachability advertisements. Use of source still has 
> consistency issues for SRMS advertisements, OSPF, and cases which involve 
> multiple protocol instances.
> This choice has been consciously made and is in part based on our 
> experience with existing implementations.
>  
> That said, this issue is only relevant if you believe it is 
> necessary/desirable to use a preference rule to make a choice when a 
> conflict exists. 
> The proponents of “Ignore” don’t want to do this – we want to NOT use 
> SIDs which are in conflict. We believe this is less likely to lead to 
> interoperability problems and is less likely to have undesirable side 
> effects. It also prioritizes detection and reporting of conflicts.
>  
>    Les
>  
> Regards,
> Mustapha.
>  
> preference to each SRMS in case there is no advertisement of this sub-TLV 
> or to override an advertised value. I propose that this option be allowed. 
> “
> “
> [Les:] In order to get consistent conflict resolution on all nodes in the 
> network, it is necessary that they all have the same database – which 
> includes the preference value. If you allow local policy to modify the 
> preference you no longer have consistent databases on all nodes and we can 
> no longer guarantee consistent conflict resolution. So your proposal is not 
> viable IMO.
>  
> Since a SID advertised in a prefix SID sub-TLV within a Prefix TLV (IS-IS 
> IP Reach TLV or OSPF Extended Prefix TLV) has higher priority over a SID 
> for the same prefix advertised from a SRMS, then you have to add to the 
> below sorting an entry for each individual prefix which advertised a prefix 
> SID sub-TLV within a prefix TLV. 
> At this point, the concept of an entry with multiple prefixes is moot and 
> you may as well just sort on a per prefix basis which is the most natural 
> thing to do given that the prefix resolution and then the SID resolution 
> are performed on a per prefix basis. SID conflicts can be resolved on a per 
> prefix basis using the below proposed preference algorithm without having 
> to ignore SID values for unrelated prefixes just because it happens that 
> they were advertised in the same SRMS entry.
>  
> [Les:] The simpler proposal does not require sorting on anything other than 
> preference. After that, you can process entries in any order you want and 
> you will get the same answer.
> With “Ignore Overlap Only” one of the issues with trying to use the 
> non-conflicting portions of a mapping entry which has a range > 1 is that 
> the order in which you process entries influences the result. Please see 
> slides 17 – 20 from the IETF97 presentation: 
> 
https://www.ietf.org/proceedings/97/slides/slides-97-spring-1_ietf97_draft-ietf-spring-conflict-resolution-02-00.pptx 
> 4)Don’t overengineer the solution
> database

---

From: <[email-masked]>
Date: Thu, 5 Jan 2017 16:42:43 +0000

Les,

Thanks for the answer.
Please see inline [Bruno]

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Thursday, December 22, 2016 2:50 AM
To: DECRAENE Bruno IMT/OLN
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: SID Conflict Resolution: A Simpler Proposal

Bruno -

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, December 21, 2016 6:40 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: SID Conflict Resolution: A Simpler Proposal

Les,

Still as an individual contributor, SID conflict resolution is about a trade-off between implementation complexity and network availability. Hence evaluating the consequences on network availability is at least as important as evaluating the implementation complexity; especially as the former is easier to quantify while the latter may be implementation specific. So on this FEC/network availability standpoint, please find below three comments.

1) The slides presented might IMHO slightly mislead a reader:
- the discussion on network availability compares "Quarantine" vs "Ignore Overlap"
- the conclusion discuss "Ignore Overlap" vs "Ignore"

So they are comparing different things, while a quick reader may assume that apples were compared to apples.
Note that I'm not saying (and not thinking) that this is misleading on purpose. I'm expressing the way I read it.

[Les:] Please remember the history here. Prior to Seoul the input we had was:
"Ignore" is least desirable - evaluate between "Quarantine" and "Ignore Overlap".
The discussion over the previous few months therefore was comparing the latter two. Slides for both Berlin and Seoul were therefore prepared with that in mind.

Significant feedback at Seoul and since has made "Ignore" a candidate again - so the email thread has now focused on "Ignore" vs "Ignore Overlap Only".
If I had received this feedback before Seoul I would have prepared different slides.

My apologies for not being clairvoyant. :)

[Bruno] My comment was related to the one set of slides presented in Seoul. Therefore:
- this set could have been self-consistent without a need for clairvoyance.
- I'm not sure how much feedback received _after_ presenting those slides are supposed to explain why the body and the conclusion of this presentation compare different things, without even a warning for the reader.
But it's too late to change those slides.

2) Regarding the new proposal, post Seoul, it is vocal on the complexity side, but not on the network availability side which is not evaluated. This does not helps the WG understanding of the trade-off involved and the making of an informed decision.
I'm even wondering if the network availability has been considered since by default, this proposal seems to kill, by design, the SRMS and SR-LDP inter-working.
SRMS has been designed in order to allow for the inter-working with LDP, in a brown-field scenario where SR is introduced in a LDP MPLS network.
e.g. a typical set of advertisements would be
1. PrefixSID: (192, 1.1.1.1/32 100 range 1)
2. MS:        (128, 1.1.1.1/32 100 range 255)

With this simple example, not even having a configuration error but using a nominal configuration, the MS advertisement would be ignored with the ignore policy, hence the LDP interwork would not work, and all LDP/non-SR nodes would loose SID hence loose SR connectivity.
Eventually, you may change the algorithm, to look beyond the most preferred entry, and check whether the SIDs are really different or not. And if not, change the algo to pick the largest range rather than the highest preference. But this is adding complexity to cover a specific case, while keeping the solution weak in term of network availability, in the general case. e.g. if we do have a different SID, many  prefix (99%) would lose their SID.

[Les:] Your interpretation is incorrect. There is no conflict in the example you provide - therefore no entries will be ignored (this is true no matter what conflict resolution strategy is chosen).
The definition of conflicts can be found in Section 3.2 of the draft. Nothing in this discussion proposes changes to that- and the definition of a conflict has never been under debate.
[Bruno] Good for this specific example. Thanks for spelling this detail out.
This however does not answer the general comment regarding the evaluation of the network availability, for this new proposal.

What we have discussed over the last 6 months or more has been what to do when conflicts exist- this is Section 3.3 of the draft.

3) Finally, when discussing "Ignore Overlap", a typical quote from the authors is "maximize forwarding" or "operate optimally", as if we were trying to optimize for the last bit. But note that "Ignore Overlap" is _not_ maximizing forwarding.  Maximizing forwarding would be much more complex, and nobody on the list has even tried for this, including draft-ietf-spring-conflict-resolution.
e.g. with following advertisements with a misconfiguration
1. PrefixSID: (192, 1.1.1.1/32 101 range 1)
2. MS:        (128, 1.1.1.1/32 100 range 255)

During prefix conflict, for 1.1.1.1/32 Ignore Overlap selects the SID from prefixSID entry, which will latter have a SID conflict with the MS entry (SID 101, prefixes 1.1.1.1 vs 1.1.1.2). As a result, 1.1.1.2 won't get a SID.
In this specific case, a solution "maximizing the forwarding" would have ignored the PrefixSID. But in the general case, "maximizing the forwarding" may require evaluating all options, and then pick the best one based on all results.

So please let's keep evaluating the impact on the network availability. Berlin presentation was a good example on this.
[Les:] Well, the Berlin slides (see Slide 25) use the term "Maximize SR Forwarding".
https://www.ietf.org/proceedings/96/slides/slides-96-spring-4.pdf

One of the problems with making a choice when conflicts exist is that there is no way of knowing what prefixes are the most important in a particular network deployment.
[Bruno] Relative importance of prefix is completely orthogonal. So far, all evaluations have been made by counting the number of prefixes disregarded. Let's continue this way. I'm not sure why you want to make the evaluation more complex.

 "Ignore overlap only" aimed to maximize the number of prefixes which had SIDs
[Bruno] I'd say "improve" rather than "maximize" the number of SIDs. Otherwise, that goal is missed, as highlighted in my examepl.

in the hope that we would have a greater chance of including the more important prefixes
[Bruno] again, relative importance of prefixes have not been consider nor discuss.
- but since all of our tie-breakers are simply arbitrary choices there is no guarantee. From Section 3.3.4 of the draft:

2 Smaller range wins
3.  IPv6 entry wins over IPv4 entry
4.  Longer prefix length wins
5.  Smaller algorithm wins
6.  Smaller starting address (considered as an unsigned integer
       value) wins
   7.  Smaller starting SID wins

If you were to seriously try to focus on "network availability" we would need to incorporate additional information which might include:

·         Is a prefix reachable?

·         How much traffic depends on each prefix

·         What class of traffic depends on each prefix

[Bruno] I guess it depends on how we define "network availability". We can rephrase as PE/FEC availability if you want.
And yes, network operator are serious about network availability. I'd assume that box vendor are serious about box availability.

This can only increase the complexity of the implementation - and I have no doubt the debate about the best heuristics could go on without end.
[Bruno] I'm not asking for maximizing the PE/FEC availability. I'm asking for not using the term "maximizing", since this is not what we are looking for (nor doing).

I return again to the priorities which the authors stated from the beginning:

1)Detect the problem
2)Report the problem

For some of us, the resolution behavior is the least important. For you it seems it is the most important.
[Bruno] We all agree on points 1 to 3 so there is no need to discuss them.
What is important is the end result for the users of the network. And that's not even in the authors list of priority, even after two years of discussion and statements from multiple network operators that this point it important.

--Bruno

That is what  the debate is really about.

   Les

--Bruno

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Friday, December 09, 2016 7:31 PM
To: DECRAENE Bruno IMT/OLN
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: SID Conflict Resolution: A Simpler Proposal

Bruno -

Welcome back to the discussion. :)
Inline.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, December 09, 2016 2:07 AM
To: Les Ginsberg (ginsberg)
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: SID Conflict Resolution: A Simpler Proposal

Hi Les,

As a individual contributor, please find below some clarification questions [Bruno]

From: spring [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, December 05, 2016 1:04 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [spring] SID Conflict Resolution: A Simpler Proposal

1)Detect the problem

2)Report the problem

[Bruno] In the draft, the "Ignore" policy (§3.3.1) ignores all conflicting entries.

In your below proposition, the policy seems to pick the most preferred entry. This looks like more similar to the "Quarantine" policy proposed in the draft (§3.3.2)

Am I missing something?

[Les:] At the time "Ignore" was introduced (over a year ago) the notion of "SRMS preference" did not exist - that was only added in the most recent version of the draft.

We (the authors) feel that this is a useful construct because:

1)It provides an explicit basis on which to choose between conflicting entries.

2)It is particularly useful when bringing up a new SRMS as it allows the advertised values to be verified before they are used.

So, your comment is correct in that there is now a preference algorithm in use - whereas with the original definition of "Ignore" there was no preference algorithm. But the sole criteria of the preference rule is the explicitly configured preference - none of the other criteria proposed for Quarantine are used - and in particular we do not make partial use of a mapping entry as is the case with "Ignore Overlap Only".

I am happy to modify the nomenclature - but the point of this thread is not to replace a new draft revision - it is to get the sense of the WG before we publish a new revision as to whether we should continue down the "Ignore Overlap only" path or move to a simpler strategy - so let's not be too picky about the naming.

New Proposal

based on preference

[Bruno] I'm not sure what you are refering to by "preference". Is this the IGP "SRMS Preference sub-TLV" or is this the preference defined in the draft (§3.3.4)?

[Les:] It is the former.

Assuming you meant the SRMS preference, why limiting to this field, rather than including all fields defined in the draft preference algo?

Using the latter would reduce the risk of ignoring all entries (i.e. having no entry in output of this algo). Also a priori,  a sort would not be required as a single pass could select the most preferred entry.

[Les:] The point of the alternative proposal is a simplification. The presentation in Seoul (check out the slides) highlighted complexities in the implementation of "ignore-overlap-only" - in particular subtleties in the order in which an implementation looks at entries which could produce interoperability issues even though implementations are using the same preference rule. The alternative reduces the chances of these interoperability issues occurring because the algorithm used is simpler and less subject to subtle implementation differences.

If you want to argue that these are solvable problems I won't disagree with you - it is a question of where we want to put our time and effort. A number of folks are commenting that they prefer to focus on fixing the configuration and not invest  time in validating that conflict resolution is implemented in an interoperable way. As we (the authors) have stated from the beginning, we believe the emphasis should be on detecting and reporting the conflicts - not spending cycles implementing the most robust means of trying to operate optimally while the misconfiguration exists. I know you disagree on this point - but that is exactly what the WG is debating - not whether it is possible to make "ignore overlap only" work.

   Les

Thanks

-- Bruno

Example 1:

Active policy:

Example 2:

Active policy:

Example 3:

Active policy:

Empty

Example 4:

Active policy:

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Thu, 5 Jan 2017 16:47:41 +0000

Les,

I'm not sure that the problem is exactly the same for routers and for controllers:
- Routers do transit, hence we MUST achieve consistency to avoid mis-routing (e.g SID 1 used for 1.0.0.1 by some nodes and for 1.0.0.2 by some other nodes) or black-holing (e.g. SID 1 used for 1.0.0.1 by some (source) nodes but dropped by some other (transit) nodes).
- In SR, the "Controler" would typically control the ingress/"source routing node" behavior. It can choose, independently, to not use a SID/prefix in case of conflict. (a la "ignore all")

So the problem looks different and it seems that the solution selected may also be different.

> I am not optimistic that all controllers will implement conflict resolution.

Well,  I think that open source can help: it's enough if a single "one" implements the right conflict resolution behavior. And we have running code showing that a per FEC behavior can be implemented by "one".

--Bruno

Sent: Thursday, December 22, 2016 8:42 AM

And one more thought for everyone to mull over while enjoying the holidays...

Consistency is a requirement of any solution i.e. all routers in the network MUST use the same algorithm operating on the same database.
However, this requirement goes beyond routers - it is also required of any entity - specifically controllers - which might specify an engineered path consisting of prefix SIDs.

I think no one questions that all routers will implement the standardized solution - but will all controllers?

Consider the consequences if a controller does not implement the solution.

We have the following conflict:

(192, 1.1.1.1/32 100 range 1)
(192, 2.2.2.2/32 100 range 1)

If we use a policy which chooses a winning entry in such a case (such as "Ignore Overlap Only") the winner will be (192, 1.1.1.1/32 100 range 1) (based on current preference rules defined in the draft).
Labels associated with SID 100 will be installed in router forwarding plans and direct traffic towards 1.1.1.1.

If we use a policy which does not use either of the conflicting entries routers will NOT install labels associated with SID 100 in the forwarding plane and traffic arriving with such a label will be dropped.

If a controller which does NOT do conflict resolution builds an engineered path which traverses 2.2.2.2, it will send a label stack including SID 100.

Using "Ignore Overlap Only", routers will forward a packet with SID 100 towards 1.1.1.1 rather than 2.2.2.2.

Using "Ignore", packets using SID 100 will be dropped.

I am not optimistic that all controllers will implement conflict resolution. If I am right, the consequences of the combination of the Conflict Resolution policy chosen and a Controller which does not implement conflict resolution should be considered.

  Les

From: spring [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, December 21, 2016 5:50 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal

Bruno -

Les,

One of the problems with making a choice when conflicts exist is that there is no way of knowing what prefixes are the most important in a particular network deployment.  "Ignore overlap only" aimed to maximize the number of prefixes which had SIDs in the hope that we would have a greater chance of including the more important prefixes - but since all of our tie-breakers are simply arbitrary choices there is no guarantee. From Section 3.3.4 of the draft:

2 Smaller range wins

·         Is a prefix reachable?

1)Detect the problem
2)Report the problem

   Les

--Bruno

Bruno -

Hi Les,

1)Detect the problem

2)Report the problem

Am I missing something?

New Proposal

based on preference

[Les:] It is the former.

   Les

Thanks

-- Bruno

Example 1:

Active policy:

Example 2:

Active policy:

Example 3:

Active policy:

Empty

Example 4:

Active policy:

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 5 Jan 2017 16:50:08 +0000

An even simpler proposal for the prefix conflict:

- if a SID is attached to the prefix (Prefix-SID Sub-TLV) use it.
- IOW, prefix-SID have precedence over Mapping Server advertisements. (note that this was the original text, a few years back in the IGP drafts)
                - This looks pretty simple as this is about disregarding (in fact not even looking at) MS entries.

- otherwise looks for MS entries
                - there should be few since they are compressed using the "range" field, so there should not be "scalability issues"
                - if this is still too complex to look for MS entries and pick one, I suppose that the Quarantine algo could be used on the MS entries (at least SR capable nodes would not suffer from the conflict, and their proportion should increase over time).

This would clearly simplify the draft, which is what you are calling for: no need to introduce the following complexities: "Generalized Mapping entry", "derived mapping entries" and their associated complexity. As a consequence, this would also simplify the discussion in the WG.

Additional advantages are:
- implementations would not be mandated to support the Mapping Server at all (neither server nor client side). This is interesting for vendors not having deployment case mandating LDP interworking. (e.g. greenfield deployment, possibly DC environment, mono-vendor networks)
- advertisement from SR nodes are always used and do not conflict. As time goes, we should expect that the proportion of SR compatible nodes increase, which in the long run favor the simple rule (don't even consider SRMS) and the absence of conflict (while with SRMS, we have, by design, multiple advertisements covering the same prefix: 2 SRMS advertisements for redundancy, plus Prefix SID for SR nodes. Hence chance to have conflict in case not all configurations are equals)
- in the long run, we could deprecate MS entries and SR-LDP interworking, with no impact on the selection rules/selected entries.

Regards,
--Bruno

1)Detect the problem

2)Report the problem

New Proposal

based on preference

Example 1:

Active policy:

Example 2:

Active policy:

Example 3:

Active policy:

Empty

Example 4:

Active policy:

---

From: "Aissaoui, Mustapha (Nokia - CA)" <[email-masked]>
Date: Mon, 9 Jan 2017 23:53:03 +0000

Hi Les,
I am supporting the "ignore overlap only" policy. The reason I am bringing the "per-prefix resolution" in this discussion is because the SID conflict resolution happens naturally in 2 steps as part of the prefix resolution:

1.     First resolve SID conflicts of the same prefix.

2.     Then, resolve SID conflicts across prefixes.

This way, all the SIDs associated with a given prefix are first evaluated and a value is chosen.

Then if multiple prefixes from step (1) have conflicting SIDs then install a single SID only in step (2).

We just need simple rules to make the selection within each step.

I agree that the "ignore" policy is simpler as it does not have to worry about a selection algorithm but it seems to me it will lead to unnecessary loss of SR forwarding capability.

Regards,
Mustapha.

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Sunday, January 01, 2017 12:15 PM
To: Aissaoui, Mustapha (Nokia - CA) <[email-masked]>; [email-masked]
Subject: RE: SID Conflict Resolution: A Simpler Proposal

Mustapha -

Hi Les,

Regards,
Mustapha.

Mustapha -

Hi Les,

   Les

Regards,
Mustapha.

Mustapha -

"

"

   Les

Regards,
Mustapha.

1)Detect the problem

2)Report the problem

New Proposal

based on preference

Example 1:

Active policy:

Example 2:

Active policy:

Example 3:

Active policy:

Empty

Example 4:

Active policy: