![Page 1: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/1.jpg)
On Improving the Efficiency and Manageability of NotVia
Ang Li†, Pierre Francois‡, and Xiaowei Yang†
† UCIrvine‡ Université catholique de Louvain
CoNext 2007 12/13/07 New York
![Page 2: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/2.jpg)
Outline
• Introduction• Background on IP Fast Reroute• Problem statement
• Our solutions• Evaluation• Conclusion
![Page 3: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/3.jpg)
2095
1176
902
1295 639
856
1893
587
233260
846
700
548
366
Routing Convergence Causes Packet Losses
XConvergence!(sub-second)
![Page 4: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/4.jpg)
2095
1176
902
1295 639
856
1893
587
233260
846
700
548
366
IP Fast Reroute Reduces Packet Losses
XFailure detected!
(≈10ms)
SV NY
SV NY
SV NV
![Page 5: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/5.jpg)
Considered IPFRR Techniques
• Loop-Free Alternates (LFA)• Lightweight• Problem: no full protection coverage
• NotVia address (NotVia)• Used when LFA does not apply• Full coverage• Overhead
![Page 6: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/6.jpg)
IPFRR with NotVia Address
2095
1176
902
1295 639
856
1893
587
233260
846
700
548
366
NVDV->KA
X
1. Announce the NotVia address2. Each router computes a nexthop for the address3. When failure happens, encapsulate
packets with the address
DV NVDV->KA
SV NY
![Page 7: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/7.jpg)
Problem Statement
• NotVia’s overhead• Memory overhead• Computational overhead
• Not management-friendly• Operators do not know the protection
paths• Details in the paper
![Page 8: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/8.jpg)
Memory Overhead
• Extra FIB entries
dst nexthop
Kansas C. Denver
New York Denver
… …
2095
1176
902
1295 639
856
1893
587
233260
846
700
548
366
NVD->K Los Angeles
… …
# of extra entries = # of unidirectional links unprotected by LFA
![Page 9: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/9.jpg)
Computational Overhead• Computational overhead
• Extra SPT computations• Each router needs to compute one SPT for each NotVia entry• Up to 20ms for one SPT in a Tier-1 ISP• Up to 20s in a topology with 1000+ links
• NotVia entries updated to the linecards
• It may result in…• Protection restoration time t2 can be long• Resources are consumed when needed by other more urgent processes
![Page 10: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/10.jpg)
Outline
• Introduction• Our solutions• Evaluation• Conclusion
![Page 11: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/11.jpg)
Contributions
• We make NotVia more practical• NotVia aggregation to reduce memory overhead• Prioritized computation to reduce computational
overhead• rNotVia algorithm to obtain protection path
information (in the paper)
• Simple & local techniques
![Page 12: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/12.jpg)
1. NotVia Aggregation
2095
1176
902
1295 639
856
1893
587
233260
846
700
548
366
NVDV->KAObservation:
very often, nexthop(NV)=normal nexthop(NV’s originator)
![Page 13: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/13.jpg)
How can we Reduce Overhead?
• NotVia aggregation1. Assign the NotVia addresses from the originator’s prefix2. Do nothing when the nexthops are the same3. Install more specific entries only when nexthops are
different For instance, 10.0.0.0/8 for Kansas City 10.0.0.1 for NVDV->KA
• Aggregation saves• FIB memory on linecards• Processing: less entries to be managed by the RIB and
FIB processes
![Page 14: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/14.jpg)
2. Prioritized NotVia Computation
2095
1176
902
1295 639
856
1893
587
233260
846
700
548
366
NVDV->KAProblem: how can a routerfirst compute the
necessary NotVia entries?
![Page 15: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/15.jpg)
Prioritize NotVia Computations
• Compute closer NotVia addresses first• Observation: protection paths are close to the
not-via link
• Prioritization reduces the time to restore NotVia protection• Because the protection is restored after all
necessary NotVia entries are generated
![Page 16: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/16.jpg)
Outline
• Introduction• Our solutions• Evaluation• Conclusion
![Page 17: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/17.jpg)
Data sets and Methodology
• Topologies• 5 real ISP topologies
• Real configured metrics• From small ones to a Tier-1 ISP (with over
400 nodes)• Synthesized topologies from BRITE
• Customized simulator• Most results not related with simulator
implementation
![Page 18: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/18.jpg)
Effectiveness of Aggregation
140+ nodes, 400+ links
![Page 19: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/19.jpg)
Effectiveness of Prioritization
![Page 20: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/20.jpg)
Outline
• Introduction• Our solutions• Evaluation• Conclusion
![Page 21: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/21.jpg)
Conclusion
• NotVia provides full coverage, but…• Introduces memory and computational overhead• Not management-friendly
• We optimized it with simple techniques• NotVia aggregation• Prioritization• rNotVia
• Evaluation on real topologies suggests they are effective
![Page 22: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/22.jpg)
Thank you!
Questions?
![Page 23: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/23.jpg)
rNotVia Efficiency
![Page 24: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/24.jpg)
IPFRR with Loop-Free Alternate
Two modes of LFA Destination based: router R is S’ LFA w.r.t. destination D
S can reroute packets destined to D through R when link S→T fails R will not forward the packets back to S
Link based: router R is S’ LFA w.r.t. link S→T S can reroute any packet through R when link S→T fails R will not forward the packets back to S
Similar scheme for node protection LFA serves as the baseline solution of IPFRR
Easy for a router to find its LFAs No encapsulation / packet header modification
However, LFAs may not always be available
S T D
R1
5
1 1
1
S DS D
![Page 25: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/25.jpg)
rNotVia’s Applicability
rNotVia might be used to compute NotVia entries Can further reduce # of NotVia entries! In reality: rNotVia is heavier than current optimized SPT
computation One rNotVia(rSPT) == one normal SPT SPT could be significantly optimized by only computing the
incremental part (iSPT) For rNotVia the optimization gain is marginal
rNotVia is only used for management Running in low priority When the network is stable For reporting purposes
![Page 26: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/26.jpg)
How the Distance is Measured?
IGP distance v.s. Hop distance
Hop distance is better High link cost within PoP Close in terms of hop count
One SPT to get hop distance Pre-computed in low priority
![Page 27: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/27.jpg)
How does rNotVia work?
2095
1176
902
1295 639
856
1893
587
233260
846
700
548
366
X
X
X XX
XXX: no black color
![Page 28: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/28.jpg)
How Long does it take to restore NotVia protection?
• Results after a link failure• Restoration time defined as the time when the last necessary entry is computed
![Page 29: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/29.jpg)
Partial NotVia Aggregation
• ““I don’t want the NotVia addresses to mess up I don’t want the NotVia addresses to mess up with my normal addresses!”with my normal addresses!”
• Solution: announce a new dedicated prefix – “NotVia prefix”1. Assign NotVia addresses from the NotVia prefix2. Do nothing when the nexthops are the same3. Always install an entry for each NotVia prefix4. Assign nexthop(NotVia prefix) to be nexthop(originator)
No extra computation
• Partial aggregation saves:• Memory: # of L > # of N• Computation gain is same
![Page 30: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/30.jpg)
IPFRR with NotVia address
2095
1176
902
1295 639
856
1893
587
233260
846
700
548
366
NVD->K
1. Announce the NotVia address2. Each router computes a nexthop for the address3. When failure happens, encapsulate
packets with the address
src NVD->K src dst X
![Page 31: On Improving the Efficiency and Manageability of NotVia Ang Li †, Pierre Francois ‡, and Xiaowei Yang † † UCIrvine ‡ Université catholique de Louvain CoNext](https://reader035.vdocuments.site/reader035/viewer/2022081513/5697c0241a28abf838cd4e48/html5/thumbnails/31.jpg)
Effectiveness of Prioritization
Node 38’s 92nd round of computation generates a necessary NotVia entry withoutprioritization
(92, 38)
Green – with prioritization Red – without prioritization
Round Number of NotVia Computation
dot: the round at which a necessary entry is computed