Robert –
You are making progress – but still a ways to go. ☺
Consider the following simple case:
OSPF on Router #1 advertises 1.1.1.1/32 w SID 100
OSPF on Router #2 advertises 2.2.2.2/32 w SID 100
Both routes will get installed in the RIB/FIB on all routers – but we cannot
install the same label in the forwarding for both destinations – so we have to
decide what to do.
1)We could simply not install a label for either prefix – that is the
“simple/Ignore” approach that is being discussed. IP forwarding will then be
used.
2)We could use a preference rule to determine which entry is the winner as far
as use of the label is concerned – that is the “Ignore Overlap Only” approach
is one way of doing this. The winner would have labels installed – the loser
would not.
Regardless of conflict resolution strategy both routes will still exist in
forwarding.
The debate we are having is whether to use #1 or #2.
But none of this relates to “overlapping prefixes” or same route from multiple
sources or any other problem which routing already handles.
HTH
Les
From: [email protected] [mailto:[email protected]] On Behalf Of Robert Raszuk
Sent: Thursday, December 22, 2016 2:29 PM
To: Les Ginsberg (ginsberg)
Cc: Aissaoui, Mustapha (Nokia - CA); [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]<mailto:[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. ☺
Les
From: [email protected]<mailto:[email protected]>
[mailto:[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]<mailto:[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]<mailto:[email protected]>> wrote:
Mustapha -
From: spring [mailto:[email protected]<mailto:[email protected]>]
On Behalf Of Aissaoui, Mustapha (Nokia - CA)
Sent: Thursday, December 22, 2016 8:10 AM
To: Les Ginsberg (ginsberg); [email protected]<mailto:[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]<mailto:[email protected]>>;
[email protected]<mailto:[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]<mailto:[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]<mailto:[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<http://1.1.1.1/32> 100 range 100)
2. (149, 1.1.1.10/32<http://1.1.1.10/32> 200 range 200)
3. (148, 1.1.1.101/32<http://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<http://1.1.1.1/32> 100 range 100)
Example 2:
1. (150, 1.1.1.1/32<http://1.1.1.1/32> 100 range 100)
2. (150, 1.1.1.10/32<http://1.1.1.10/32> 200 range 200)
3. (150, 1.1.1.101/32<http://1.1.1.101/32> 500 range 10)
4. (150, 2.2.2.1/32<http://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<http://2.2.2.1/32> 1000 range 1)
Example 3:
1. (150, 1.1.1.1/32<http://1.1.1.1/32> 100 range 500)
2. (150, 1.1.1.10/32<http://1.1.1.10/32> 200 range 200)
3. (150, 1.1.1.101/32<http://1.1.1.101/32> 500 range 10)
4. (150, 2.2.2.1/32<http://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<http://1.1.1.1/32> 100 range 10)
2. (149, 1.1.1.10/32<http://1.1.1.10/32> 200 range 300)
3. (149, 1.1.1.101/32<http://1.1.1.101/32> 500 range 10)
4. (148, 2.2.2.1/32<http://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<http://1.1.1.1/32> 100 range 10)
_______________________________________________
spring mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
