Transcript 04-draft-xu-mpls-spring-islands-connection-over-ip-00-02

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
www.huawei.com
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-MPLSSR 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.
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 IPbased 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-segmentrouting-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.
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).
Connecting MPLS SPRING over IP
Node Segment : Label Z

X
Y
Z
SR
Non-SR
SR
Packet
Packet
Packet
Label Z
Label Z
Label Z
IP (X->Z)
IP (X->Z)
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.
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 3.22. Lack of Outgoing Label).
Node Segment : Label Z
Packet
Label Z
X
Y
Z
SR
Non-SR
SR
Discussion: do we need this draft? (con’t)
www.huawei.com
Next Steps

Any comments and suggestions?