Marc
> -----Original Message-----
> From: Marc Binderberger [mailto:[email protected]]
> Sent: Friday, December 30, 2016 11:53 PM
> To: Aissaoui, Mustapha (Nokia - CA); Robert Raszuk; Les Ginsberg (ginsberg)
> Cc: [email protected]
> Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal
>
>
> 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:
>
> 1. (150, 1.1.1.1/32 100 range 100)
> 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 protected] [mailto:[email protected]] On Behalf Of Robert
> > Raszuk
> > Sent: Thursday, December 22, 2016 5:29 PM
> > To: Les Ginsberg (ginsberg) <[email protected]>
> > Cc: Aissaoui, Mustapha (Nokia - CA) <[email protected]>;
> > [email protected]
> > Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal
> >
> > 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 protected]> 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 protected] [mailto:[email protected]] On Behalf Of
> >> Robert Raszuk
> >> Sent: Thursday, December 22, 2016 11:52 AM
> >> To: Les Ginsberg (ginsberg)
> >> Cc: Aissaoui, Mustapha (Nokia - CA); [email protected]
> >>
> >> Subject: Re: [spring] SID Conflict Resolution: A Simpler Proposal
> >>
> >> Hi Les,
> >>
> >> 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 protected]> wrote:
> >> 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.
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> 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
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
