Petr Lapukhov | 27 Jul 19:30 2014

WG review for draft-lapukhov-bgp-routing-large-dc


Authors of draft-lapukhov-bgp-routing-large-dc would like to submit it for WG review and possible
adoption as a workgroup document. In this draft we summarize our experience of using BGP as the only
protocol for routing in large-scale data-center networks (100K+ bare metal servers, multiple
thousands of routers). 

Document location:

Thank you!

Adrian Farrel | 25 Jul 19:57 2014

Call for review draft-farrkingel-pce-abno-architecture


The authors of draft-farrkingel-pce-abno-architecture are in the process of
requesting AD-sponsored publication of draft-farrkingel-pce-abno-architecture

This I-D is a bit of an architecture and a bit an applicability statement. It
spans quite a lot of IETF technology.

The last call will obviously pop out sometime, but it would be nice to have
review comments before then.

Antoni Przygienda | 24 Jul 23:05 2014

MINIMIZE BACKOFF SPF two technical points

As first, I’m supportive for the work & I think it’s of solid applicable value albeit it’s strictly not IETF territory (it’s not necessary for interop strictly speaking).


First is very blunt:  if you manage to really make all the routers in the area compute <at> precisely the same time, you may not be doing yourself the favor you seek ;-)  What I mean is that generating perfectly synchronized peaks in a network tends to generate strange attractors, a good example was the synchronization of the HELLOs on all links over time that had to be jittered. Peaks can stress infra unexpectedly & lead to e.g. synchronized re-advertisement of LSAs  (or anything that SPF can trigger now and in the future).  Given on top that an SPF in the future is not necessarily the 2-3 msec SPF seen today (rLFA & such runs seem to become the new flavor of SPF) I suggest to include a small configurable jitter before the first SPF is triggered (couple msecs should do the trick but I’m willing to hear the argument that flooding de-sync’s the SPF runs enough already).


The other issue is far more subtle but may merit a section in the draft.  This work is pushing the protocol in a very specific direction along the CAP paradigm, i.e. a link-state routing protocol is roughly


1.      Always 100% P (partitioned)

2.      Basically 100% available  A  (tad hard to define given FIBs)

3.      _eventually_ consistent C


Now, it is fairly well understood that having all 3 is not possible across very wide set of CS problems and we are not exempt of that.  We cannot move P  so pushing on the C will cause A to move to the negative. Now, what do I mean by that.  Triggering the SPFs more aggressively will give you better consistent&available in the scenario of a single link failure if things go well. Now, compared to e.g. a batching algorithm that computes every 500 msecs without backing off and will show linear consistent&available even in case of fast-link flapping, many links failing consecutively and so on, exponential backoff will cause massively lower consistency after several link failure and this network-wide so certain people may loose big time when using that. Beside that, the quick SPFs can block lots of other things in the protocol that are not parallelized or block other protocols waiting for SPFs to finish or next SPF (2nd failure) stuck on FIB download running (all hypothetical, but availability in widest sense will go down if you see more consistency). Again, the work is good but the section will show people that it’s not an ‘universal’ improvement but something triggered to ideally a seldom occurring 1 or 2 links failure.




--- tony




That period of time in which our affairs prosper, our friends are true and our happiness is assured.”
Ambrose Bierce, The Unabridged Devil's Dictionary


rtgwg mailing list
rtgwg <at>
Hannes Gredler | 24 Jul 14:35 2014

On minimizing SPF backoff induced blackouts


some old presentation from Dave Katz on backoff and timing.
    [courtesy Chris Bowers for digging it up ...]

slide 15 is of particular interest - says that if
an implementation and the system around it is properly
designed then no backoff should be required.

Yasuhiro Ohara | 23 Jul 22:33 2014

a MRT algorithm


Regarding Maximally Redundant Trees algorithms, please take a look
at my IEEE INFOCOM paper in 2009, which is titled "MARA: Maximum
Alternative Routing Algorithm".

It is a extended version of Dijkstra, and we've succeeded to extend the
Dijkstra's shortest path tree. This means that the calculated DAG is
compatible to the current SPF Tree, so you might not need multi-topology
in the first place.

liu.bin21 | 23 Jul 04:00 2014

Re: Reply to comments -- Comparison between FAR and OSPF - FRR

Hello Curtis,

Thank you for your comments.
But from what did you get conclusion of 'research projects'? We not only have a deployment experience but also strict large-scale system data analysis.

Following is my reply:

'No SPF is required for FRR to provide protection, restoring traffic flow though sometimes on a suboptimal path.'
--Is FRR only used within domain? If so, it can be counted as a drawback. And LDP FRR cannot guarantee that the calculated path is the optimal path, leading to the emergence of new link congestion. But FAT TREE architecture network is a non-blocking network.

'One commercial CSPF measured about a decade ago completed in 30-40msec on a test topology of 450.  That was on a 300 MHz or less PPC or Pentium-2.
Todays processors are an order of magnitude faster, so we could expect (with order NlogN scaling of SPF) to get about the same SPF time on a topology of 4K or more nodes with no improvements in software.'
--As seen from the above CSPF business application data, there is a linear correlation between the convergence time and the number of topologies, while it is not sensitive to the FAR.
To compare the FRR and FRR, the working process of the LDP FRR technology is described as follows:
1) Running LDP protocol in the network, it works as DU (downstream independent) label distribution + orderly label control + free label retention. (Disadvantage :additional protocol overhead)

In the above case, there are two paths from R1 to R5, R5 initiates multi-label mapping message to the upstream. Eventually, R2 and R3 respectively assign labels to R1 for reaching R5, among which, the label distributed by R2 is the primary label, the label distributed by R3 can be used as a backup. (Disadvantage: the irregular topology leads to complex routing and prone to cause more serious link block)

2) Specify one equipment port of the LSR as the backup of another equipment port.

3) Equipment maintenance label forwarding table: As the port backup has not been implemented, one label forwarding table has only one next hop and label, and the label is distributed for FEC by the LDP peer connected to the next hop of the routing of FEC. After the port backup is implemented, if the next hop of a label forwarding table is the protected port, add a next hop and label for the entry, and the label is distributed for FEC by the LDP peer connected to the backup next hop. (Disadvantage: large protocol database overhead and processing overhead)

4) Equipment maintenance of the working status of each port (normal/failure).

5) Packets reach the next hop, and are forwarded to the destination according to the corresponding label forwarding table.

It can be seen from the above FRR processing that FRR has the following disadvantages compared to FAR:

1) Additional protocol overhead: For the protection of links, nodes and paths, it is necessary to set up a backup LSP respectively, which causes unnecessary overhead and complex protocol processing; (there is no such protocol overhead for FAR, and because FAR is based on regular topology, path protection and switching process are simple.)

2) Backup LSP failures may exist. As there is no protection mechanism, it cannot fast reroute when it fails; (FatTree network architecture has multiple natural selection.)

3) There is a linear correlation between the convergence time and the number of topologies, while it is not sensitive to the FAR.

4) LDP FRR cannot guarantee that the calculated path is the optimal path, leading to the emergence of new link congestion. But FAT TREE architecture network is a non-blocking network.


rtgwg mailing list
rtgwg <at>
Jeff Tantsura | 9 Jul 19:11 2014

IETF 90 RTGWG Agenda


The agenda for IETF 90 RTGWG has been posted:

Looking forward to seeing you in Toronto!

internet-drafts | 4 Jul 19:36 2014

I-D Action: draft-ietf-rtgwg-mrt-frr-architecture-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Routing Area Working Group Working Group of the IETF.

        Title           : An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees
        Authors         : Alia Atlas
                          Robert Kebler
                          Chris Bowers
                          Gabor Sandor Enyedi
                          Andras Csaszar
                          Jeff Tantsura
                          Maciek Konstantynowicz
                          Russ White
	Filename        : draft-ietf-rtgwg-mrt-frr-architecture-04.txt
	Pages           : 41
	Date            : 2014-07-04

   With increasing deployment of Loop-Free Alternates (LFA) [RFC5286],
   it is clear that a complete solution for IP and LDP Fast-Reroute is
   required.  This specification provides that solution.  IP/LDP Fast-
   Reroute with Maximally Redundant Trees (MRT-FRR) is a technology that
   gives link-protection and node-protection with 100% coverage in any
   network topology that is still connected after the failure.

   MRT removes all need to engineer for coverage.  MRT is also extremely
   computationally efficient.  For any router in the network, the MRT
   computation is less than the LFA computation for a node with three or
   more neighbors.

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

Internet-Drafts are also available by anonymous FTP at:
liu.bin21 | 2 Jul 11:20 2014

Requests time slot for FAR <at> IETF 90 rtgwg

Greeting all,

We wish to present our new version draft(draft-sl-rtgwg-far-dcn-01) during this  
meeting, consequently, we would like to ask for a time slot for the draft presentation.

-topic: Generic Fault-avoidance Routing Protocol for Data Center Networks
- brief statement of problem & updateing for comments.
- requested duration: 15min
- speaker name: Bhumip Khasnabish

I'll appreciate the opportunity of time slot. We hope to receive guidance and agreement from the chairs and the experts.

Many thanks for guidance, and best wishes.


Yours Sincerely,

Richard bin liu
rtgwg mailing list
rtgwg <at>
Alvaro Retana (aretana | 27 Jun 22:48 2014

IETF 90 Agenda Items (rtgwg)


We have a 90-minute slot in Toronto on Wednesday afternoon:
WEDNESDAY, July 23, 2014 1520-1650 Afternoon Session II Ballroom RTG rtgwg Routing Area Working Group WG
Send any requests for time to Jeff and I.  We will prioritize the items already listed in the charter as milestones. Other items may be considered if we have time.

Please note that we will be requiring two conditions to be part of the final agenda: (1) your draft MUST have been published already, and (2) you MUST provide the chairs with your slides by EOD on Monday, July 21, 2014.  We will also appreciate starting a discussion on the list so everyone is aware of your draft and/or any updates.

Keep the following dates in mind:

rtgwg mailing list
rtgwg <at>
stephane.litkowski | 27 Jun 14:26 2014

FW: New Version Notification for draft-litkowski-rtgwg-spf-uloop-pb-statement-00.txt

Hi RTGWGers, 

Here is a problem statement draft showing the impact of using different SPF strategies in link state IGP protocols.

Comments are welcome.


-----Original Message-----
From: internet-drafts <at> [mailto:internet-drafts <at>] 
Sent: Friday, June 27, 2014 14:09
Subject: New Version Notification for draft-litkowski-rtgwg-spf-uloop-pb-statement-00.txt

A new version of I-D, draft-litkowski-rtgwg-spf-uloop-pb-statement-00.txt
has been successfully submitted by Stephane Litkowski and posted to the IETF repository.

Name:		draft-litkowski-rtgwg-spf-uloop-pb-statement
Revision:	00
Title:		Link State protocols SPF trigger and delay algorithm impact on IGP microloops
Document date:	2014-06-27
Group:		Individual Submission
Pages:		12

   A micro-loop is a packet forwarding loop that may occur transiently
   among two or more routers in a hop-by-hop packet forwarding paradigm.

   In this document, we are trying to analyze the impact of using
   different Link State IGP implementations in a single network in
   regards of microloops.  The analysis is focused on the SPF triggers
   and SPF delay algorithm in a first step.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and
diff are available at

The IETF Secretariat


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.