Internet DRAFT - draft-li-spring-multi-topology-segment
draft-li-spring-multi-topology-segment
Network Working Group Z. Li
Internet-Draft N. Wu
Intended status: Standards Track Huawei
Expires: September 10, 2015 March 9, 2015
Multi-Topology (MT) Segment in Segment Routing
draft-li-spring-multi-topology-segment-00
Abstract
Multi-Topologies (MTs) can be used for computing different paths for
unicast traffic, multicast traffic, different classes of service
based on flexible criteria, or an in-band network management
topology. This document proposes the multi-topology segment for
segment routing. MRT FRR using multi-topology segment is described
as the use case to explains the procedures of the forwarding plane
and the control plane for multi-topology segment..
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li & Wu Expires September 10, 2015 [Page 1]
Internet-Draft MT Segment in SR March 2015
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. MRT FRR Using Multi-Topology Segment . . . . . . . . . . . . 3
4. Forwarding Mechanisms . . . . . . . . . . . . . . . . . . . . 4
4.1. MRT-FRR in SR . . . . . . . . . . . . . . . . . . . . . . 4
5. Procedures of Control Plane . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 4
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
Segment Routing (SR), introduced by
[I-D.ietf-spring-segment-routing], leverages the source routing
paradigm. A packet can be steered through an ordered list of
instructions, which are also called segments. The node segment,
adjacency segment, etc. have been proposed for different usecases.
This document proposes the multi-topology segment for the segment
routing. As stated, Multi-Topologies (MTs) can be used for computing
different paths for unicast traffic, multicast traffic, different
classes of service based on flexible criteria, or an in-band network
management topology. The multi-topology segment is used to identify
the multi-topology with the segment ID. MRT FRR using multi-topology
segment is described as the use case to explains the procedures of
the forwarding plane and the control plane for multi-topology
segment.
2. Terminology
o Segment: a segment identifies an instruction.
Li & Wu Expires September 10, 2015 [Page 2]
Internet-Draft MT Segment in SR March 2015
o Multi-Topology Segment, Multi-Topology-SID: a Topology Segment is
an IGP segment attached to a IGP multi-topology. A Multi Topology
Segment is always global within the SR/IGP domain and identifies
an instruction to indicate one specified topology. The Multi-
Topology -SID is the SID of the Multi-Topology Segment.
o Maximally Redundant Trees (MRT): A pair of trees where the path
from any node X to the root R along the first tree and the path
from the same node X to the root along the second tree share the
minimum number of nodes and the minimum number of links. Each
such shared node is a cut-vertex. Any shared links are cut-links.
Any RT is an MRT but many MRTs are not RTs.
o GADAG: Generalized ADAG - a graph that is the combination of the
ADAGs of all blocks.
o GADAG root: The root node of GADAG.
o MRT-Red: MRT-Red is used to describe one of the two MRTs; it is
used to described the associated forwarding topology and MT-ID.
Specifically, MRT-Red is the decreasing MRT where links in the
GADAG are taken in the direction from a higher topologically
ordered node to a lower one.
o MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is
used to described the associated forwarding topology and MT-ID.
Specifically, MRT-Blue is the increasing MRT where links in the
GADAG are taken in the direction from a lower topologically
ordered node to a higher one.
3. MRT FRR Using Multi-Topology Segment
As described in [I-D.ietf-rtgwg-mrt-frr-architecture], MRT-FRR
leverages multi-topologies mechanism to support a pair of Maximally
Redundant Trees (MRT) and provides disjoint alternates for a common
destination. Unfortunately, IP header could not provides extra bits
to indicate its topology. So for the IP network MRT-FRR has to
depend on IP tunnels, which will consume more IP addresses.
This dilemma can be solved through allocating segments for the MRT-
Red topology and the MRT-Blue topology respectively. These Multi-
Topology Segments (Multi-Topology SID) SHOULD have global semantics
in the SR domain. Thus multi-topology forwarding can be easily
achieved with global segments indicating corresponding topologies.
With the help of Segment Routing mechanism, for MRT FRR in the IP
network no extra IP address will be introduced and LDP protocol is
not necessary to be introduced.
Li & Wu Expires September 10, 2015 [Page 3]
Internet-Draft MT Segment in SR March 2015
4. Forwarding Mechanisms
4.1. MRT-FRR in SR
As stated before, MRT-FRR in segment routing domain can depend on
topology indicating segment to do multi-topology forwarding. There
are three types of routers involved into MRT-FRR forwarding.
At the MRT ingress router, the IP packet enters segment routing
network for MRT then follows the MRT path to the destination with a
Topology Segment inserted into the packet header. In the MRT-FRR
scenario, a Multi-Topology Segment indicating MRT-Red or MRT-Blue is
used to steer the packet along the alternate path.
At the transit router, a packet is received with one segment
indicating the corresponding topology it belongs to. The router will
pop the segment, look up the route in the corresponding FIB. When
forwarding the packet to the next hop, the multi-topology segment
will be pushed again.
At the egress router, the packet will pop the Multi-Topology Segment
and continue to forward the packet to the destination.
When MPLS forwarding is applied for the segment routing, the multi-
topology segment can map to the MPLS label to indicate the multi-
topology.
5. Procedures of Control Plane
IGP extensions should be introduced to carries the topology-id and
its corresponding index that determines the actual SID/label value
inside the set of all advertised SID/label ranges of a given router.
A receiving router uses the index to determine the actual SID/label
value in order to identify corresponding topology. The Multi-
Topology SID MUST be unique within a given IGP domain. The
initiation of advertisement of the Multi-Topology SID binding SHOULD
be advertised by a specific node in the SR domain. The node can be
specified manually or chosen automatically.
6. IANA Considerations
This document makes no request of IANA.
7. Security Considerations
This document does not introduce new security threat.
Li & Wu Expires September 10, 2015 [Page 4]
Internet-Draft MT Segment in SR March 2015
8. References
8.1. Normative References
[I-D.ietf-rtgwg-mrt-frr-architecture]
Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar,
A., Tantsura, J., and R. White, "An Architecture for IP/
LDP Fast-Reroute Using Maximally Redundant Trees", draft-
ietf-rtgwg-mrt-frr-architecture-05 (work in progress),
January 2015.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,
and E. Crabbe, "Segment Routing Architecture", draft-ietf-
spring-segment-routing-01 (work in progress), February
2015.
8.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Zhenbin Li
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Nan Wu
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: eric.wu@huawei.com
Li & Wu Expires September 10, 2015 [Page 5]
