Presentation is loading. Please wait.

Presentation is loading. Please wait.

Connecting MPLS-SPRING Islands over IP Networks

Similar presentations


Presentation on theme: "Connecting MPLS-SPRING Islands over IP Networks"— Presentation transcript:

1 Connecting MPLS-SPRING Islands over IP Networks
draft-xu-mpls-spring-islands-connection-over-ip-00 Xiaohu Xu (Huawei) Robert Raszuk (Bloomberg LP) Uma Chunduri Luis M. Contreras (Telefonica I+D) Luay Jalil (Verizon) IETF97, Seoul

2 Motivations “The SPRING architecture MUST allow incremental and selective deployment without any requirement of flag day or massive upgrade of all network elements.” (see draft-ietf-spring-problem-statement-07) To support incremental deployment of MPLS Segment Routing (SR), non-MPLS-SR nodes is required to enable LDP (see draft-ietf-spring-segment-routing-ldp-interop ). This is absolutely fine for brownfield networks where MPLS LDP has already been enabled before. However, it seems a bit unreasonable for greenfield networks as it destroys the beauty of MPLS SR (i.e., simplify network provisioning by running a single protocol that is IGP). The incremental deployment capability of IPv6 SR is better than MPLS SR since non-SR nodes in the IPv6 SR case just need to support IPv6 forwarding. Unfortunately, the encapsulation overhead is a significant concern at least in some networks since the explicit path information is encoded as a list of 128-bit long IPv6 addresses. This incremental deployment capability doesn’t exist for IPv4 underlay networks.

3 Motivations To facilitate the incremental deployment of MPLS-SR technology, this document describes a mechanism which allows the outermost LSP to be replaced by an IP-based tunnel when the next-hop along the LSP is not MPLS-SR-enabled. No need to run any other label distribution protocol (e.g., LDP, see draft-ietf-spring-segment-routing-ldp-interop ). Therefore, keep the incremental deployment capability as perfect as IPv6-SR (i.e., non-SR nodes just need to support IP forwarding capability). More importantly, it’s a universal source routing method which integrates existing IP and MPLS specifications. The MPLS label stack contained within an IP packet (either IPv4 or IPv6) is used to indicate the explicit path information. If the IP packet is an IPv6 packet, it can be looked as a compact IPv6 SR variant where the explicit path is encoded as a list of short IDs instead of IPv6 addresses. As a hardware convenience those short IDs are formatted as MPLS labels.

4 Use Cases MPLS-SR-based Service Function Chaining (SFC) (see draft-xu-sfc-mpls-service-chaining) Only partial SFC-related nodes (e.g., Service Function Forwarders (SFF) and classifiers) are required to be MPLS-SR-capable while the intermediate routers just need to support IP forwarding (either IPv4 or IPv6). Traffic Engineering in the dual-plane network scenarios Only a few routers (e.g., the entry and exit nodes of each plane) are required to be MPLS-SR-capable while the intermediate routers just need to support IP forwarding (either IPv4 or IPv6).

5 Connecting MPLS SPRING over IP
X Z Node Segment : Label Z Label Z Packet IP (X->Z) Y Non-SR SR Upon receiving an MPLS packet with the top label indicating a next node segment (i.e., Z), if the IGP next-hop router (i.e., Y) towards that node segment is a non-SR router, X would forward the MPLS packet to the next node segment (i.e., Z) through an IP-based tunnel (e.g., MPLS-over-UDP tunnel [RFC7510]). If the top label is not a PHP label, X SHOULD swap the top label to the corresponding label significant to Z and then encapsulate the MPLS packet into an IP-based tunnel. If the top label is a PHP label and not at the bottom of the label stack, X SHOULD pop that top label before performing the above encapsulation.

6 Discussion: do we need this draft?
When an MPLS-SR-enabled router X receives an MPLS packet with the top label indicating a given node segment Z, if the next-hop of the best path to Z is a non-MPLS router, X couldn't map the packet's top label into an Next Hop Label Forwarding Entry (NHLFE) , even though the top label itself is a valid incoming label. As a result, X would have to drop that packet according to RFC3031 (see Section Lack of Outgoing Label). Node Segment : Label Z X Y Z SR Non-SR SR Packet Label Z

7 Discussion: do we need this draft? (con’t)

8 Next Steps Any comments and suggestions?


Download ppt "Connecting MPLS-SPRING Islands over IP Networks"

Similar presentations


Ads by Google