Subject: Re: Mail regarding draft-litkowski-rtgwg-spf-uloop-pb-statement

From: Mike Shand <[email-masked]>
Date: Thu, 07 May 2015 11:14:49 +0100

I have been assigned as Routing Directorate QA reviewer for this document.

The following web page contains a briefing on the QA process.

​https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa

The document provides a useful summary of the issues leading to 
micro-loop formation, especially in mixed vendor networks and provides 
examples of the possibilities to adversely affect the the micro-loop 
behaviour by inconsistent choices of parameters and algorithms among the 
routers in the network.

I confess that I find the timing diagrams quite hard to follow. One of 
the penalties of being constrained by the need to use ASCII art. But I 
wonder if something could be done to make them a little easier to follow 
without losing the essential information?

There are some very simple mitigation techniques, such as delaying the 
locally triggered  SPF/FIB installation more than a remotely triggered 
one, which it may be helpful to mention.

The document goes on to propose future work to standardise some behaviours.

Clearly this work is at an early stage and the trade-offs between 
standardisation and allowing vendors freedom to innovate for the benefit 
of their customers must be carefully considered.

The document seems like a good starting point for this work.

In reading the document I spotted a few items which it would be as well 
to address.

General:

1. micro-loop or microloop. The terminology is used inconsistently. RFC 
5715 uses micro-loop
2. There are numerous instances of awkward usage of english. It would be 
helpful to address these at some stage.

Nits:

3. "   We will call SPF delay, the delay timer that exists in most
    implementations that makes codes to wait before running SPF
    computation after a SPF trigger is received."

The phrase "makes codes to wait" is somewhat contrived. How about "that 
specifies the required delay"?

4. "   Routers have more and more powerful controlplane and dataplane that
    reduce the Control plane to Forwarding plane overhead during the
    convergence process.  Even if FIB update is still reasonably the
    highest contributor in the convergence time for large network, its
    duration is reducing more and more and may become comparable to
    protocol timers.  This is particular true in small and medium
    networks."

I don't understand what is meant by "may become comparable to protocol 
timers"? Are you suggesting that the FIB update latency WAS greater than 
the protocol timers, but has now been reduced to a comparable value?

The reference to small and medium networks is also confusing, since in 
my experience it is actually the small and medium networks which are 
subject to the LARGEST FIB update times as a result of the deployment of 
under powered hardware.

5. "   In multi vendor networks, using different implementations of a link
    state protocol may favor micro-loops creation during convergence time
    due to deprecancies of timers."

deprecancies? Do you mean discrepancies?

6. "4.2 Exponential Backoff"

"   o  First delay : amount of time to wait before running SPF. This
       delay is used on when SPF is in fast mode."

I assume "is used only when SPF" is what you mean.

and similarly in the next bullet

Mike

---

From: <[email-masked]>
Date: Mon, 11 May 2015 13:22:06 +0000

Hi Mike,

Thanks for this first review. I will for sure address your comments.
Some inline answers.

From: rtgwg [mailto:[email-masked]] On Behalf Of Mike Shand
Sent: Thursday, May 07, 2015 12:15
To: [email-masked]
Cc: [email-masked]
Subject: Re: Mail regarding draft-litkowski-rtgwg-spf-uloop-pb-statement

The document provides a useful summary of the issues leading to micro-loop formation, especially in mixed vendor networks and provides examples of the possibilities to adversely affect the the micro-loop behaviour by inconsistent choices of parameters and algorithms among the routers in the network.
I confess that I find the timing diagrams quite hard to follow. One of the penalties of being constrained by the need to use ASCII art. But I wonder if something could be done to make them a little easier to follow without losing the essential information?
There are some very simple mitigation techniques, such as delaying the locally triggered  SPF/FIB installation more than a remotely triggered one, which it may be helpful to mention.

Clearly this work is at an early stage and the trade-offs between standardisation and allowing vendors freedom to innovate for the benefit of their customers must be carefully considered.

In reading the document I spotted a few items which it would be as well to address.

General:

1. micro-loop or microloop. The terminology is used inconsistently. RFC 5715 uses micro-loop
[SLI] Will be fixed

2. There are numerous instances of awkward usage of english. It would be helpful to address these at some stage.

Nits:

The phrase "makes codes to wait" is somewhat contrived. How about "that specifies the required delay"?
[SLI] your proposal is fine, will be fixed

I don't understand what is meant by "may become comparable to protocol timers"? Are you suggesting that the FIB update latency WAS greater than the protocol timers, but has now been reduced to a comparable value?
[SLI] Right, even if it may be not true for all the networks, this tends to be the case

The reference to small and medium networks is also confusing, since in my experience it is actually the small and medium networks which are subject to the LARGEST FIB update times as a result of the deployment of under powered hardware.
[SLI] Yes and no …
I may say that small/medium networks have less powerful hardware, but also less routes (except badly designed networks ☺ ). Large network have more powerful hardware but more routes to handle.

deprecancies? Do you mean discrepancies?
[SLI] Yep, I meant “discrepancies” , will be fixed.

I assume "is used only when SPF" is what you mean.
[SLI] Right, will be fixed

Mike

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Martin Horneffer <[email-masked]>
Date: Mon, 11 May 2015 17:06:08 +0300

Hello Stephane, Mike, and group,

just one comment (see below) since I get to see more and more different 
networks from the operator's point of view.

Am 11.05.15 um 16:22 schrieb [email-masked]:
> timers"? Are you suggesting that the FIB update latency WAS greater 
> than the protocol timers, but has now been reduced to a comparable value?
> subject to the LARGEST FIB update times as a result of the deployment 
> of under powered hardware.
> [SLI] Yes and no …
>
> I may say that small/medium networks have less powerful hardware, but 
> also less routes (except badly designed networks J). Large network 
> have more powerful hardware but more routes to handle.
>
This really depends on many corner conditions such as exact choice and 
age of hardware, network design in term of topology and routing 
architecture and, of course, size of the network.

While it might be possible for a small or medium sized network with a 
very clean design, a small number of internal routes, and modern 
hardware to have a very fast FIB update, there are numerous reasons why 
this could fail: old hardware or software, network design which includes 
many parts of the aggregation, access and service generation area in the 
IGP, and/or routing architectures which for one reason or the other 
include some service routes in the IGP.
For very large networks on the other hand it will definitely not be 
possible to keep FIB updates very fast.

IMHO it would be a good idea to remove  the reference to the size of the 
network. And don't even try to specify which kind of network has shorter 
or longer FIB update times. Just indicate that depending on size and 
exact design of a network it MAY have short FIB updates times, but make 
clear that by no means this is always the case.

Best regards, Martin

---

From: <[email-masked]>
Date: Mon, 11 May 2015 15:13:33 +0000

Hi Martin,

That makes sense to me. I will remove the reference.

Thanks,

Stephane

From: Martin Horneffer [mailto:[email-masked]]
Sent: Monday, May 11, 2015 16:06
To: LITKOWSKI Stephane SCE/IBNF; Mike Shand; [email-masked]
Cc: [email-masked]
Subject: Re: Mail regarding draft-litkowski-rtgwg-spf-uloop-pb-statement

just one comment (see below) since I get to see more and more different networks from the operator's point of view.

Am 11.05.15 um 16:22 schrieb [email-masked]<mailto:[email-masked]>:

The reference to small and medium networks is also confusing, since in my experience it is actually the small and medium networks which are subject to the LARGEST FIB update times as a result of the deployment of under powered hardware.
[SLI] Yes and no ...
I may say that small/medium networks have less powerful hardware, but also less routes (except badly designed networks :) ). Large network have more powerful hardware but more routes to handle.
This really depends on many corner conditions such as exact choice and age of hardware, network design in term of topology and routing architecture and, of course, size of the network.

While it might be possible for a small or medium sized network with a very clean design, a small number of internal routes, and modern hardware to have a very fast FIB update, there are numerous reasons why this could fail: old hardware or software, network design which includes many parts of the aggregation, access and service generation area in the IGP, and/or routing architectures which for one reason or the other include some service routes in the IGP.
For very large networks on the other hand it will definitely not be possible to keep FIB updates very fast.

IMHO it would be a good idea to remove  the reference to the size of the network. And don't even try to specify which kind of network has shorter or longer FIB update times. Just indicate that depending on size and exact design of a network it MAY have short FIB updates times, but make clear that by no means this is always the case.

Best regards, Martin