Hi Les,
> OSNC is trying to mitigate the consequences of a distributed network by
> trying to guarantee that no node in the network triggers an SPF until it has
> received all of the LSPs in a single "batch" as defined by the originator.
I think guarantee is too high a bar. I consider it simply useful information
to do the right thing.
> But you still can't guarantee that the batch will arrive at every node at the
> "same time".
Of course.
> And what is the definition of a “batch”.
That is up to the transmitter, of course. I would consider it to be a set of
fragments that have an inter-dependency that suggests that they be processed
together.
> You cannot limit a batch simply to cases where you move a single TLV.
True, but that is the simplest case to consider. Obviously, you could have
mass movement which would increase the scope of a batch if several TLVs all
shifted at once.
> To do so would require you to delay any other updates until you were
> “certain” that the TLV move had been processed network-wide – which you have
> no way to determine.
That is not the goal.
> Consider Node A which has generated 10 LSPs - and updates two of them
> (quickly) in the following order:
> A.00-2 includes an update to a prefix admin tag (minimal impact on
> convergence)
> A.00-4 includes a new adjacency (significant impact on convergence)
In this particular instance, there is no dependency. Thus, there’s no reason
to batch the updates in the first place. This would seem to me to be a
misapplication of the proposal. These should not be batched in the first place.
Could we please discuss an example that’s relevant?
Let’s please consider the example where an adjacency has moved from A.00-2 to
A.00-4.
> NOTE: Does not matter whether you treat this as two different batches
> (different OSNC in each LSP) or as one batch (same OSNC in both LSPs).
I don’t understand this comment.
> Nodes B and C are multiple hops away from Node A - potentially on different
> flooding paths.
>
> We have the following possible combinations:
> B supports OSNC - C does not. [B(OSNC) C]
> B and C support OSNC [B(OSNC) C(OSNC)]
> Neither B nor C supports OSNC [B C] (AKA legacy)
>
> Case 0: A.00-2 and A.00-4 arrive at B and C at the "same time".
> All combinations behave the same
Agreed.
> Case 1: A.00-4 arrives at B and C at the "same time" but A.00-2 is delayed in
> arriving at both nodes.
> [B(OSNC) C] Node C Converges faster than Node B
> [B(OSNC) C(OSNC)] Both nodes delay convergence
> [B C] Both nodes converge quickly
In the revised example:
[B (OSNC) C] C SPFs first, but has duplicate
adjacencies to deal with. If it chooses the wrong one, it generates an
incorrect transient.
[B (OSNC) C (OSNC) ]. Both nodes delay convergence
[B C] Both nodes have duplicate
adjancies to deal with. They may do so inconsistently. Both can generate
incorrect transients.
The partial deployment case does not seem any worse than the legacy case.
> Conclusion: OSNC has not helped. Partial deployment makes things worse
Disagree. This seems like it is no worse. For all intents and purposes, it is
the same as the legacy case.
> Case 2: A.00-2 arrives at B and C at the "same time" but A.00-4 is delayed in
> arriving at node B only.
> {B(OSNC) C] Node C Converges faster than Node B
> [B(OSNC) C(OSNC)] Both nodes delay convergence
> {B C] Both nodes converge quickly
In the revised example:
[B (OSNC) C] C converges correctly as it has both
fragments. B delays, but does not create additional inconsistency.
This is already the best that
can be done anyway.
[B (OSNC) C(OSNC) ] C converges correctly as it has both fragments.
B delays, but does not create additonal inconsistency.
[B C] C converges correctly as it has
both fragments. B does not delay, but creates an incorrect transient.
> Conclusion: OSNC has not helped. Partial deployment makes things worse
Disagree. Quite the opposite. OSNC has prevented an unnecessary transient.
When the fragment does arrive at B, it hasn’t triggered SPF, so it can promptly
SPF and correct the overall discrepancy.
> No doubt there are other examples – some of which may be more favorable to
> OSNC - but the point here is that there are cases where partial deployment
> can make things worse.
> Adding complexity and not being able to guarantee improved results is not a
> winning combination.
Your analysis was significantly flawed. The correct analysis clearly shows the
exact case where OSNC improves things. It’s not perfect. It’s not magic, but
it is somewhat better.
I concur that it is additional complexity. Whether the benefit is worth the
complexity should be the focus of this discussion.
Regards,
Tony
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
