Re: [trill] TRILL Resilient Distribution Trees, who have read it?

[Mingui Zhang <[e-mail]>]

Hi Thomas,


>    They are seeing 34-100ms convergence times and think this can be
>    further reduced by an order of magnitude (recommendation 7)

When you say convergence time can be as short as 34 ms, it certainly does not include the failure detection time. Since failures are detected in ISIS by non-receipt of Hellos within three holding timers, which are "commonly set to a value of tens of seconds and, in any case, has a minimum expressible value of one second [rbBFD]". When the presenter mentioned the convergence time, I believe he meant "the time elapsed from a failure event realized by the control protocol until the forwarding has been recovered [CONVERGE]". However, the service disruption does include the failure detection time, during which the forwarding paths via the failure spot are already cut off. So, the service disruption time at least includes the following two parts: 1) Failure detection time; 2) Service resuming time (a.k.a. convergence time).

>Won't TRILL have similar convergence times? Are we talking about using
>failover to shave off a few tens of milliseconds? Or is there some
>sort of expectation that this will shave seconds or more off the
>recovery time?

We expect that "TRILL Resilient Distribution Trees" reduce the whole recovery time.

>Which applications are those? Are there particular deployment
>scenarios that are being targetted, or is this just a general
>argument?

Video distribution (e.g., IPTV) is such kind of application [RDT].

>And just how long does this period of "inconsistency" last? And just
>how quickly will a node know that a path that it is using has failed
>and that it needs to fallback to using the precomputed backup path?
>Won't it also take time for news of a failure to propagate through the
>network? In other words, won't the network already be reconfiguring
>itself even before a node realizes that a path has failed and it
>should switch to a backup?

The figure on page 4 of [CONVERGE] also tells us that inconsistence introduces a sky-high deal of looping traffic. This period can last seconds. RDT not only reduces the service disruption time but also decreases the looping traffic.

There are three kinds of protection described in the draft. Only the global 1:1 protection relies on the "news of a failure" to determine to switch to a backup.

We catch the issue in Section 5.4 of the draft. You will find there is no problem that network reconfiguration and the use of backup take place in parallel.

>So again, I'm really trying to understand just how much of an
>improvement the proposed approach is expected to produce.

Let me quantify the improvement we expected to produce:
"Service disruption time should be magnitude shorter than one second [RFC5714]". 
Exactly, we expect [RDT] meets "Realistic availability requirements (sub-second to sub-200msec)... [MOFRR]". 

References
[rbBFD] http://www.ietf.org/id/draft-ietf-trill-rbridge-bfd-07.txt
[CONVERGE] http://www.ieee802.org/1/files/public/docs2010/new-farkas-convergence-1110.pdf
[RDT] http://datatracker.ietf.org/doc/draft-zhang-trill-resilient-trees/?include_text=1
[RFC5714] http://tools.ietf.org/html/rfc5714
[MOFRR] http://tools.ietf.org/html/draft-karan-mofrr-02

Thanks,
Mingui






>-----Original Message-----
>From: Thomas Narten [mailto:[e-mail]]
>Sent: Tuesday, December 18, 2012 11:36 PM
>To: Mingui Zhang
>Cc: [e-mail]
>Subject: Re: [trill] TRILL Resilient Distribution Trees, who have read it?
>
>Hi.
>
>I understand at a high level what the reational is. What I'm really
>trying to get at is: does the cost/complexity justify the benefit? For
>this, some quantifiable metrics would help - not just generalities
>like "convergence will be faster", etc.
>
>Mingui Zhang <[e-mail]> writes:
>
>> Hi Thomas,
>
>> TRILL provides multicast service using ISIS link state routing. When
>>  there is a failure, RBridges are notified through the propagation
>>  of LSPs, which will trigger a campus-wide convergence on
>>  distribution trees. The convergence includes the following major
>>  processes: 1) the propagation of LSPs around the whole campus; 2)
>>  the recalculation of trees on affected RBridges; 3) the update of
>>  forwarding information on those RBridges. These processes make the
>>  convergence time-consuming.
>
>I take issue with this. The whole point of link-state flooding
>approaches is that they are fast - much faster than alternatives.
>
>And as a data point, back in Paris, Paul Unbehagen gave a presentation
>in the IS-IS WG on SPB deployment where (according to my notes):
>
>    They are seeing 34-100ms convergence times and think this can be
>    further reduced by an order of magnitude (recommendation 7)
>
>Won't TRILL have similar convergence times? Are we talking about using
>failover to shave off a few tens of milliseconds? Or is there some
>sort of expectation that this will shave seconds or more off the
>recovery time?
>
>That is, do we have any evidence (or targets) for TRILL convergence
>times (after a topology change) that are "too long"? Just "how fast"
>reconvergence is considered fast enough, and what is considered
>problematical?
>
>> As we know, most multicast traffic is
>>  generated by applications which are sensitive to interrupt
>>  latency. Therefore, the convergence will lead to the disruption of
>>  multicast service.
>
>Which applications are those? Are there particular deployment
>scenarios that are being targetted, or is this just a general
>argument?
>
>> Due to the propagation delay of LSPs, the distribution trees are
>>  calculated and installed on RBridges at different time, which
>>  brings _inconsistence_ of forwarding states among RBridges. Before
>>  the convergence finishes, multicast frames may be trapped by
>>  forwarding loops and finally dropped. This increases the volume of
>>  broadcast/multicast traffic.
>
>And just how long does this period of "inconsistency" last? And just
>how quickly will a node know that a path that it is using has failed
>and that it needs to fallback to using the precomputed backup path?
>Won't it also take time for news of a failure to propagate through the
>network? In other words, won't the network already be reconfiguring
>itself even before a node realizes that a path has failed and it
>should switch to a backup?
>
>So again, I'm really trying to understand just how much of an
>improvement the proposed approach is expected to produce.
>
>To be clear, I'm not necessarily opposed to this work. But I would
>like a better understanding of exactly how much benefit we can really
>expect, so I can understand how to weigh the tradeoffs between
>increased complexity vs. actual benefit.
>
>Thomas