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
1. (150, 1.1.1.1/32 100 range 100)
2. (150, 1.1.1.1/32 500 range 2)
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”)
>
> 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 protected]]
> Sent: Friday, December 23, 2016 6:59 AM
> To: Les Ginsberg (ginsberg); [email protected]
> Subject: RE: SID Conflict Resolution: A Simpler Proposal
>
> Hi Les,
> I made some follow-up inline.
>
> Regards,
> Mustapha.
>
> From: Les Ginsberg (ginsberg) [mailto:[email protected]]
> Sent: Thursday, December 22, 2016 2:37 PM
> To: Aissaoui, Mustapha (Nokia - CA) <[email protected]>;
> [email protected]
> Subject: RE: SID Conflict Resolution: A Simpler Proposal
>
> Mustapha -
>
> From: spring [mailto:[email protected]] On Behalf Of Aissaoui,
> Mustapha (Nokia - CA)
> Sent: Thursday, December 22, 2016 8:10 AM
> To: Les Ginsberg (ginsberg); [email protected]
> 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 protected]]
> Sent: Friday, December 09, 2016 1:49 PM
> To: Aissaoui, Mustapha (Nokia - CA) <[email protected]>;
> [email protected]
> Subject: RE: SID Conflict Resolution: A Simpler Proposal
>
> Mustapha -
>
> From: Aissaoui, Mustapha (Nokia - CA) [mailto:[email protected]]
> Sent: Friday, December 09, 2016 7:44 AM
> To: Les Ginsberg (ginsberg); [email protected]
> 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 protected]] On Behalf Of Les Ginsberg
> (ginsberg)
> Sent: Sunday, December 04, 2016 7:04 PM
> To: [email protected]
> 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)
>
>
>
>
>
> _______________________________________________
> spring mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
