The optimization for BGP-VPN routes is based on the idea to move the label infomation from MPLS LDIs to the separate structure of LSP array. Once the MPLS-LDIs are label-free, they could be shared, the same way as recursive IP-LDI.
To improve the IGP/LDP convergence mainly by the shareing IGP/LDP pathlists and their LDIs. Before these structures are not shared because of need to support the in-place modification for IGP/LDP LDIs. To achieve both sharing and in-place modifications, will introduce the LW-LDI, which is a simple data structure containing the pointer to the actual LDP/IGP LDI, and the hardware LDI. With LW-LDI the forwarding chain will looks like
Leaf --> LW-LDI --> Shared-PL-LDI --> NextHop
Here LW-LDI is populated per leaf, therefore it supports in-place modification; At the same time, the heavy structures such as pathlist and LDIs are shared.
GPL - generic path-list. currently GPL supports only IP dependencies and IP LDI, it will be extended to support MPLS dependencies and MPLS LDI
LW-LDI - structure that pointing to the actual software and platform LDI. LW-LDI is used to support Pathlist sharing for IGP, when the HW LDIs are not shared
LSP (label switching path) - output data structure corresponding to RIB/LSD labeled path (output label)
LSPA - array of LSPs for one RIB/LSD route
MPLS-PL (MPLS pathlist) - data structure containing label and the forwarding information for one route, included LSPA, LDI, and dependent leafs. In 3.5, MPLS-PL will be converted to LSPA
Pathlist - data structure containing the forwarding info for IP routes.
Sharing MPLS forwarding data-structure
==============================
1) Sharing MPLS LDI by moving labels out of MPLS-LDI into LSP-Array
2) Sharing disposition LSP-Arrays where all paths are either Unlabeled or IMPL-NULL. This is relevant for the disposition on the egress-PE
3) Sharing MPLS-LDI of the different type (IMP, EOS0, EOS1)
Criteria for sharing GPL sharing
in SW, share all GPL and their respective LDIs
in HW, will share
recursive IP-GPLs
recursive MPLS-GPLs in the context of VRF tables
recursive MPLS-GPLs for the label cross-connects (inter-AS)
Data Path Type
Path_type_IP - should point to an IP next-hop of IP leaf
Path_type_labeled - should point to MPLS next-hop or EOS 0 or EOS 1 leaf
Path_type_unlabeled - the path is also an IP path for resolution purpose. However we differentiate between unlabeled an pure IP because unlabeled paths may exist in unlabeled path-list. Unlabeled path-list may be used by MPLS leaves and some platform populate MPLS and IP load-infos in different HW structures
Path_type_IMP_NULL - depends on the matching leaf, the path may be used to send out pure IP packets or MPLS packets. This path depends on both IP and MPLS next-hops
Path_type_tunnel - biscuit path
FIB MPLS extension
登录后才可评论.
