TEAS Working Group Zafar Ali, Ed.
Internet Draft George Swallow, Ed.
Intended status: Standard Track Cisco Systems
Updates RFC4874 F. Zhang, Ed.
Expires: September 03, 2018 Huawei
D. Beller, Ed.
Nokia
March 02, 2018
Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path
Diversity using Exclude Route
draft-ietf-teas-lsp-diversity-10.txt
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 03, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Ali, Swallow, Zhang, Beller, et al. Expires September 2018 [Page 1]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
Abstract
Resource ReSerVation Protocol-Traffic Engineering provides support
for the communication of exclusion information during label switched
path (LSP) setup. A typical LSP diversity use case is for
protection, where two LSPs should follow different paths through the
network in order to avoid single points of failure, thus greatly
improving service availability. This document specifies an approach
which can be used for network scenarios where full knowledge of the
path(s) is not necessarily known by use of an abstract identifier
for the path. Three types of abstract identifiers are specified:
client-based, Path Computation Engine (PCE)-based, network-based.
This document specifies two new diversity subobjects for the RSVP
eXclude Route Object (XRO) and the Explicit Exclusion Route
Subobject (EXRS).
For the protection use case, LSPs are typically created at a slow
rate and exist for a long time, so that it is reasonable to assume
that a given (reference) path currently existing, with a well-known
identifier, will continue to exist and can be used as a reference
when creating the new diverse path. Re-routing of the existing
(reference)LSP, before the new path is established, is not
considered.
Conventions used in this document
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].
Table of Contents
Terms and Abbreviations..........................................3
1. Introduction..................................................3
1.1. Client-Initiated Identifier..............................6
1.2. PCE-allocated Identifier.................................7
1.3. Network-Assigned Identifier..............................8
2. RSVP-TE signaling extensions.................................10
2.1. Diversity XRO Subobject.................................10
2.2. Diversity EXRS Subobject................................17
2.3. Processing rules for the Diversity XRO and EXRS
subobjects..............................................17
3. Security Considerations......................................21
4. IANA Considerations..........................................22
4.1. New XRO subobject types.................................22
4.2. New EXRS subobject types................................22
4.3. New RSVP error sub-codes................................22
Expires September 2018 [Page 2]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
5. Acknowledgements.............................................23
6. References...................................................23
6.1. Normative References....................................23
6.2. Informative References..................................24
Terms and Abbreviations
Diverse LSP: a diverse Label-Switched Path (LSP) is an LSP that
has a path that does not have any link or SRLG in common with the
path of a given LSP. Diverse LSPs are meaningful in the context
of protection or restoration.
ERO: Explicit Route Object as defined in [RFC3209]
EXRS: Explicit eXclusion Route Subobject as defined in [RFC4874]
SRLG: Shared Risk Link Group as defined in [RFC4202]
Reference Path: the reference path is the path of an existing
LSP, to which the path of a diverse LSP shall be diverse.
XRO: eXclude Route Object as defined in [RFC4874]
1. Introduction
Path diversity for multiple connections is a well-known
operational requirement. Diversity constraints ensure that Label-
Switched Paths (LSPs) can be established without sharing network
resources, thus greatly reducing the probability of simultaneous
connection failures.
The source node can compute diverse paths for LSPs when it has
full knowledge of the network topology and is permitted to signal
an Explicit Route Object (ERO). However, there are scenarios where
different nodes perform path computations, and therefore there is
a need for relevant diversity constraints to be signaled to those
nodes. These include (but are not limited to):
. LSPs with loose hops in the Explicit Route Object, e.g. inter-
domain LSPs.
. Generalized Multi-Protocol Label Switching (GMPLS) User-
Network Interface (UNI), where the core node may perform path
computation [RFC4208].
Expires September 2018 [Page 3]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
[RFC4874] introduced a means of specifying nodes and resources to
be excluded from a route, using the eXclude Route Object (XRO) and
Explicit Exclusion Route Subobject (EXRS). It facilitates the
calculation of diverse paths for LSPs based on known properties of
those paths including addresses of links and nodes traversed, and
Shared Risk Link Groups (SRLGs) of traversed links. Employing
these mechanisms requires that the source node that initiates
signaling knows the relevant properties of the path(s) from which
diversity is desired. However, there are circumstances under which
this may not be possible or desirable, including (but not limited
to):
. Exclusion of a path which does not originate, terminate or
traverse the source node of the diverse LSP, in which case the
addresses of links and SRLGs of the path from which diversity
is required are unknown to the source node.
. Exclusion of a path which is known to the source node of the
diverse LSP for which the node has incomplete or no path
information, e.g. due to operator policy. In this case, the
source node is aware of the existence of the reference path but
the information required to construct an XRO object to
guarantee diversity from the reference path is not fully known.
Inter-domain and GMPLS overlay networks can impose such
restrictions.
This is illustrated in the Figure 1, where the overlay reference
model from [RFC4208] is shown.
Expires September 2018 [Page 4]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
Overlay Overlay
Network +----------------------------------+ Network
+---------+ | | +---------+
| +----+ | | +-----+ +-----+ +-----+ | | +----+ |
| | | | UNI | | | | | | | | UNI | | | |
| -+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+- |
| | | | +--+--+ | | | | | | +---+-| | |
| +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ |
+---------+ | | | | | | | +---------+
| | | | | | |
+---------+ | | +--+--+ | +--+--+ | | +---------+
| +----+ | | | | | +-------+ +-----+ | +----+ |
| | +-+--+ | | CN4 +---------------+ CN5 | | | | | |
| -+ EN2+-+-----+--+ | | +---+-----+-+ EN4+- |
| | | | UNI | +-----+ +-----+ | UNI | | | |
| +----+ | | | | +----+ |
+---------+ +----------------------------------+ +---------+
Overlay Core Network Overlay
Network Network
Legend: EN - Edge Node
CN - Core Node
Figure 1: Overlay Reference Model [RFC4208]
Figure 1 depicts two types of UNI connectivity: single-homed and
dual-homed ENs (which also applies to higher order multi-homed
connectivity). Single-homed EN devices are connected to a single
CN device via a single UNI link. This single UNI link may
constitute a single point of failure. UNI connection between EN1
and CN1 is an example of singled-homed UNI connectivity.
Such a single point of failure can be avoided when the EN device
is connected to two different CN devices, as depicted for EN2 in
Figure 1. For the dual-homing case, it is possible to establish
two different UNI connections from the same source EN device to
the same destination EN device. For example, two connections from
EN2 to EN3 may use the two UNI links EN2-CN1 and EN2-CN4. To
avoid single points of failure within the provider network, it is
necessary to also ensure path (LSP) diversity within the core
network.
Expires September 2018 [Page 5]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
In a network providing a set of UNI interfaces between ENs and
CNs such as that shown in Figure 1, the CNs typically perform
path computation. Information sharing across the UNI boundary is
restricted based on the policy rules imposed by the core network.
Typically, the core network topology information as well as LSP
path information is not exposed to the ENs. In the network shown
in Figure 1, consider a use case where an LSP from EN2 to EN4
needs to be SRLG diverse from an LSP from EN1 to EN3. In this
case, EN2 may not know SRLG attributes of the EN1- EN3 LSP and
hence cannot construct an XRO to exclude these SRLGs. In this
example EN2 cannot use the procedures described in [RFC4874].
Similarly, an LSP from EN2 to EN3 traversing CN1 needs to be
diverse from an LSP from EN2 to EN3 going via CN4. Again, in this
case, exclusions based on [RFC4874] cannot be used.
This document addresses these diversity requirements by
introducing an approach of excluding the path taken by these
particular LSP(s). The reference LSP(s) or route(s) from which
diversity is required is/are identified by an abstract
"identifier". The type of identifier to use is highly dependent
on the core network operator's networking deployment scenario; it
could be client-initiated (provided by the EN), provided by a PCE
or allocated by the (core) network. This document defines three
different types of identifiers corresponding to these three
cases: a client-initiated identifier, a PCE allocated identifier
and CN ingress node (UNI-N) allocated identifier (= network-
assigned identifier).
1.1. Client-Initiated Identifier
The following fields MUST be used to represent the client-
initiated identifier: IPv4/IPv6 tunnel sender address,
IPv4/IPv6 tunnel endpoint address, Tunnel ID, and Extended
Tunnel ID. Based on local policy, the client MAY also include
the LSP ID to identify a specific LSP within the tunnel. These
fields are defined in [RFC3209], sections 4.6.1.1 and 4.6.2.1.
The usage of the client-initiated identifier is illustrated by
Figure 1. Suppose a LSP from EN2 to EN4 needs to be diverse with
respect to a LSP from EN1 to EN3. The LSP identifier of the EN1-
EN3 LSP is LSP-IDENTIFIER1, where LSP-IDENTIFIER1 is defined by
the tuple (tunnel-id = T1, LSP ID = L1, source address = EN1.RID
(ROUTE Identifier), destination address = EN3.RID, extended
tunnel-id = EN1.RID). Similarly, LSP identifier of the EN2-EN4
LSP is LSP-IDENTIFIER2, where LSP-IDENTIFIER2 is defined by the
tuple (tunnel-id = T2, LSP ID = L2, source address = EN2.RID,
destination address = EN4.RID, extended tunnel-id = EN2.RID). The
Expires September 2018 [Page 6]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
EN1-EN3 LSP is signaled with an exclusion requirement from LSP-
IDENTIFIER2, and the EN2-EN4 LSP is signaled with an exclusion
requirement from LSP-IDENTIFIER1. In order to maintain diversity
between these two connections within the core network, the core
network SHOULD implement Crankback Signaling Extensions as
defined in [RFC4920]. Note that crankback signaling is known to
lead to slower setup times and sub-optimal paths under some
circumstances as described by [RFC4920].
1.2. PCE-allocated Identifier
In scenarios where a PCE is deployed and used to perform path
computation, the core edge node (e.g., node CN1 in Figure 1)
could consult a PCE to allocate identifiers, which are used to
signal path diversity constraints. In other deployment scenarios,
a PCE is deployed at a network node(s) or a PCE is part of a
Network Management System (NMS). In all these cases, the PCE is
consulted and the Path-Key as defined in [RFC5520] can be used in
RSVP signaling as the identifier to ensure diversity.
An example of specifying LSP diversity using a Path-Key is shown
in Figure 2, where a simple network with two domains is shown. It
is desired to set up a pair of path-disjoint LSPs from the source
in Domain 1 to the destination in Domain 2, but the domains keep
strict confidentiality about all path and topology information.
The first LSP is signaled by the source with ERO {A, B, loose Dst}
and is set up with the path {Src, A, B, U, V, W, Dst}. However,
when sending the Record Route Object (RRO) out of Domain 2, node
U would normally strip the path and replace it with a loose hop
to the destination. With this limited information, the source is
unable to include enough detail in the ERO of the second LSP to
avoid it taking, for example, the path {Src, C, D, X, V, W, Dst}
for path-disjointness.
Expires September 2018 [Page 7]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
--------------------- -----------------------------
| Domain 1 | | Domain 2 |
| | | |
| --- --- | | --- --- --- |
| | A |--| B |--+--+--| U |--| V |---| W | |
| / --- --- | | --- --- --- \ |
| ---/ | | / / \--- |
| |Src| | | / / |Dst| |
| ---\ | | / / /--- |
| \ --- --- | | --- / --- / --- / |
| | C |--| D |--+--+--| X |---| Y |--| Z | |
| --- --- | | --- --- --- |
| | | |
--------------------- -----------------------------
Figure 2: A Simple Multi-Domain Network
In order to support LSP diversity, node U consults the PCE and
replaces the path segment {U, V, W} in the RRO with a Path Key
subobject. The PCE function assigns an "identifier" and puts it
into the Path Key field of the Path Key subobject. The PCE ID in
the message indicates that this replacement operation was
performed by node U.
With this additional information, the source node is able to
signal the subsequent LSPs with the ERO set to {C, D, exclude
Path Key(EXRS), loose Dst}. When the signaling message reaches
node X, it can consult the PCE function associated with node U to
expand the Path Key in order to calculate a path that is diverse
with respect to the first LSP. Alternatively, the source node
could use an ERO of {C, D, loose Dst} and include an XRO
containing the Path Key.
This mechanism can work with all the Path Key resolution
mechanisms, as detailed in [RFC5553] section 3.1. A PCE, co-
located or not, may be used to resolve the Path Key, but the node
(i.e., a Label Switching Router (LSR)) can also use the Path Key
information to index a Path Segment previously supplied to it by
the entity that originated the Path Key, for example the LSR that
inserted the Path Key in the RRO or a management system.
1.3. Network-Assigned Identifier
There are scenarios in which the network provides diversity-
related information for a service that allows the client device
to include this information in the signaling message. If the
Expires September 2018 [Page 8]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
Shared Resource Link Group (SRLG) identifier information is both
available and shareable (by policy) with the ENs, the procedure
defined in [RFC8001] can be used to collect SRLG identifiers
associated with an LSP (LSP1). When a second LSP (LSP2) needs to
be diverse with respect to LSP1, the EN constructing the RSVP
signaling message for setting up LSP2 can insert the SRLG
identifiers associated with LSP1 as diversity constraints into
the XRO using the procedure described in [RFC4874]. However, if
the core network SRLG identifiers are either not available or not
shareable with the ENs based on policies enforced by core
network, existing mechanisms cannot be used.
In this draft, a signaling mechanism is defined where information
signaled to the CN via the UNI does not require shared knowledge
of core network SRLG information. For this purpose, the concept
of a Path Affinity Set (PAS) is defined for abstracting SRLG
information. The motive behind the introduction of the PAS is to
minimize the exchange of diversity information between the core
network (CNs) and the client devices (ENs). The PAS contains an
abstract SRLG identifier associated with a given path rather than
a detailed SRLG list. The PAS is a single identifier that can be
used to request diversity and associate diversity. The means by
which the processing node determines the path corresponding to
the PAS is beyond the scope of this document.
A CN on the core network boundary interprets the specific PAS
identifier (e.g. "123") as meaning to exclude the core network
SRLG information (or equivalent) that has been allocated by LSPs
associated with this PAS identifier value. For example, if a Path
exists for the LSP with the PAS identifier "123", the CN would
use local knowledge of the core network SRLGs associated with the
LSPs tagged with PAS attribute "123" and use those SRLGs as
constraints for path computation. If a PAS identifier is used as
an exclusion identifier in the connection request, the CN (UNI-N)
in the core network is assumed to be able to determine the
existing core network SRLG information and calculate a path that
meets the determined diversity constraints.
When a CN satisfies a connection setup for a (SRLG) diverse
signaled path, the CN may optionally record the core network SRLG
information for that connection in terms of CN based parameters
and associates that with the EN addresses in the Path message.
Specifically, for Layer 1 Virtual Private Networks (L1VPNs), Port
Information Tables (PIT) [RFC5251] can be leveraged to translate
between client (EN) addresses and core network addresses.
Expires September 2018 [Page 9]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
The means to distribute the PAS information within the core
network is beyond the scope of this document. For example, the
PAS and the associated SRLG information can be distributed within
the core network by an Interior Gateway Protocol (IGP) or by
other means such as configuration. Regardless of means used to
distribute the PAS information, the information is kept inside
the core network and is not shared with the overlay network (see
Figure 1).
2. RSVP-TE signaling extensions
This section describes the signaling extensions required to
address the aforementioned requirements and use cases.
2.1. Diversity XRO Subobject
New Diversity XRO subobjects are defined below for the IPv4 and
IPv6 address families. Most of the fields in the IPv4 and IPv6
Diversity XRO subobjects are common and are described following
the definition of the two subobjects.
IPv4 Diversity XRO subobject is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Diversity Identifier Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Expires September 2018 [Page 10]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
Similarly, the IPv6 Diversity XRO subobject is defined as
follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| XRO Type | Length |DI Type|A-Flags|E-Flags| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Diversity Identifier source address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diversity Identifier Value |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L:
The L-flag is used in the same way as for the XRO
subobjects defined in [RFC4874], i.e.,
0 indicates that the diversity constraints MUST be
satisfied.
1 indicates that the diversity constraints SHOULD be
satisfied.
XRO Type
The value is set to TBA1 for the IPv4 Diversity XRO
subobject (value to be assigned by IANA). The value is set
to TBA2 for the IPv6 Diversity XRO subobject (value to be
assigned by IANA).
Length
Expires September 2018 [Page 11]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
Per [RFC4874], the Length contains the total length of the
IPv4/IPv6 subobject in bytes, including the XRO Type and
Length fields. The Length is variable, depending on the
diversity identifier value.
Diversity Identifier Type (DI Type)
Diversity Identifier Type (DI Type) indicates the way the
reference LSP(s) or route(s) with which diversity is
required is identified in the IPv4/IPv6 Diversity
subobjects. The following three DI type values are defined
in this document:
DI Type value Definition
------------- --------------------------------
1 Client Initiated Identifier
2 PCE Allocated Identifier
3 Network Assigned Identifier
Attribute Flags (A-Flags):
The Attribute Flags (A-Flags) are used to communicate
desirable attributes of the LSP being signaled in the IPv4/
IPv6 Diversity subobjects. Each flag acts independently.
Any combination of flags is permitted.
0x01 = Destination node exception
Indicates that the exclusion does not apply to the
destination node of the LSP being signaled.
0x02 = Processing node exception
Indicates that the exclusion does not apply to the
node(s) performing ERO expansion for the LSP being
signaled. An ingress UNI-N node is an example of such a
node.
0x04 = Penultimate node exception
Indicates that the penultimate node of the LSP being
signaled MAY be shared with the excluded path even when
this violates the exclusion flags. This flag is useful,
for example, when an EN is not dual-homed (like EN4 in
Figure 1 where all LSPs have to go through CN5).
Expires September 2018 [Page 12]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
The penultimate node exception flag is typically set
when the destination node is single homed (e.g. EN1 or
EN4 in Figure 1). In such a case, LSP diversity can only
be accomplished inside the core network up to the egress
node and the penultimate hop must be the same for the
LSPs.
0x08 = LSP ID to be ignored
This flag is used to indicate tunnel level exclusion.
Specifically, this flag is used to indicate that if
diversity identifier contains LSP ID field, the LSP ID
is to be ignored and the exclusion applies to any LSP
matching the rest of the diversity identifier.
Exclusion Flags (E-Flags):
The Exclusion Flags are used to communicate the desired
type(s) of exclusion requested in the IPv4/IPv6 diversity
subobjects. The following flags are defined. Any
combination of these flags is permitted. Please note that
the exclusion specified by these flags may be modified by
the value of the Attribute-flags. For example, node
exclusion flag is ignored for the "Penultimate node" if
the "Penultimate node exception" flag of the Attribute-
flags is set.
0x01 = SRLG exclusion
Indicates that the path of the LSP being signaled is
requested to be SRLG disjoint with respect to the
excluded path specified by the IPv4/IPv6 Diversity
XRO subobject.
0x02 = Node exclusion
Indicates that the path of the LSP being signaled is
requested to be node-diverse from the excluded path
specified by the IPv4/IPv6 Diversity XRO subobject.
0x04 = Link exclusion
Expires September 2018 [Page 13]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
Indicates that the path of the LSP being signaled is
requested to be link-diverse from the path specified
by the IPv4/IPv6 Diversity XRO subobject.
0x08 = reserved
This flag is reserved. It MUST be set to zero on
transmission, and MUST be ignored on receipt for both
IPv4/IPv6 Diversity XRO subobjects.
Resvd
This field is reserved. It MUST be set to zero on
transmission, and MUST be ignored on receipt for both
IPv4/IPv6 Diversity XRO subobjects.
IPv4 / IPv6 Diversity Identifier source address:
This field MUST be set to the IPv4/IPv6 address of the node
that assigns the diversity identifier. Depending on the
diversity identifier type, the diversity identifier source
may be a client node, PCE entity or network node.
Specifically:
o When the diversity identifier type is set to "IPv4/IPv6
Client Initiated Identifier", the value MUST be set to
IPv4/IPv6 tunnel sender address of the reference LSP
against which diversity is desired. IPv4/IPv6 tunnel
sender address is as defined in [RFC3209].
o When the diversity identifier type is set to "IPv4/IPv6
PCE Allocated Identifier", the value MUST be set to the
IPv4/IPv6 address of the node that assigned the Path Key
identifier and that can return an expansion of the Path
Key or use the Path Key as exclusion in a path
computation. The Path Key is defined in [RFC5553]. The
PCE-ID is carried in the Diversity Identifier Source
Address field of the subobject.
o When the diversity identifier type is set to "IPv4/IPv6
Network Assigned Identifier", the value MUST be set to the
Expires September 2018 [Page 14]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
IPv4/IPv6 address of the node allocating the Path Affinity
Set (PAS).
Diversity Identifier Value:
Encoding for this field depends on the diversity identifier
type, as defined in the following.
When the diversity identifier type is set to "Client
Initiated Identifier" in the IPv4 Diversity XRO subobject,
the diversity identifier value MUST be encoded as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv4 tunnel end point address, Tunnel ID, Extended
Tunnel ID and LSP ID are as defined in [RFC3209].
When the diversity identifier type is set to "Client
Initiated Identifier" in the IPv6 Diversity XRO subobject,
the diversity identifier value MUST be encoded as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID |
Expires September 2018 [Page 15]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 tunnel end point address, Tunnel ID, IPv6 Extended
Tunnel ID and LSP ID are as defined in [RFC3209].
When the diversity identifier type is set to "PCE Allocated
Identifier" in IPv4 or IPv6 Diversity XRO subobject, the
diversity identifier value MUST be encoded as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Path Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path Key is defined in [RFC5553].
When the diversity identifier type is set to "Network
Assigned Identifier" in IPv4 or IPv6 Diversity XRO
subobject, the diversity identifier value MUST be encoded
as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Affinity Set (PAS) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path Affinity Set (PAS) identifier field is a 32-bit
value that is scoped by, i.e., is only meaningful when
used in combination with, the Diversity Identifier source
address field. There are no restrictions on how a node
Expires September 2018 [Page 16]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
selects a PAS identifier value. Section 1.3 defines the
PAS term and provides context on how values may be
selected.
2.2. Diversity EXRS Subobject
[RFC4874] defines the EXRS ERO subobject. An EXRS is used to
identify abstract nodes or resources that must not or should not
be used on the path between two inclusive abstract nodes or
resources in the explicit route. An EXRS contains one or more
subobjects of its own, called EXRS subobjects [RFC4874].
An EXRS MAY include a Diversity subobject as specified in this
document. The same type values TBA1 and TBA2 MUST be used.
2.3. Processing rules for the Diversity XRO and EXRS subobjects
The procedure defined in [RFC4874] for processing the XRO and
EXRS is not changed by this document. The processing rules for
the Diversity XRO and EXRS subobjects are similar unless the
differences are explicitly described. Similarly, IPv4 and IPv6
Diversity XRO subobjects and IPv4 and IPv6 Diversity EXRS
subobjects follow the same processing rules.
If the processing node cannot recognize the Diversity XRO/EXRS
subobject, the node is expected to follow the procedure defined
in [RFC4874].
An XRO/EXRS object MAY contain multiple Diversity subobjects of
the same DI Type. E.g., in order to exclude multiple Path Keys, a
node MAY include multiple Diversity XRO subobjects each with a
different Path Key. Similarly, in order to exclude the routes
taken by multiple LSPs, a node MAY include multiple Diversity
XRO/EXRS subobjects each with a different LSP identifier.
Likewise, to exclude multiple PAS identifiers, a node MAY include
multiple Diversity XRO/EXRS subobjects each with a different PAS
identifier. However, all Diversity subobjects in an XRO/EXRS MUST
contain the same Diversity Identifier Type. If a Path message
contains an XRO/EXRS with multiple Diversity subobjects of
different DI Types, the processing node MUST return a PathErr
with the error code "Routing Problem" (24) and error sub-code
"XRO/EXRS Too Complex" (68/69).
If the processing node recognizes the Diversity XRO/EXRS
subobject but does not support the DI type, it MUST return a
Expires September 2018 [Page 17]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
PathErr with the error code "Routing Problem" (24) and error sub-
code "Unsupported Diversity Identifier Type" (TBA3).
In case of DI type "Client Initiated Identifier", all nodes along
the path SHOULD process the diversity information signaled in the
XRO/EXRS Diversity subobjects to verify that the signaled
diversity constraint is satisfied. If a diversity violation is
detected, crankback signaling MAY be initiated.
In case of DI type "PCE Allocated Identifier" and "Network
Assigned Identifier", the nodes in the domain that perform path
computation SHOULD process the diversity information signaled in
the XRO/EXRS Diversity subobjects as follows. In the PCE case,
the ingress node of a domain sends a path computation request for
a path from ingress node to egress node including diversity
constraints to a PCE. Or,in the PAS case, the ingress node is
capable to calculate the path for the new LSP from ingress node
to the egress node taking the diversity constraints into account.
The calculated path is then carried in the explicit route object
(ERO). Hence, the transit nodes in a domain and the domain egress
node SHOULD NOT process the signaled diversity information unless
path computation is performed.
While processing EXRS object, if a loose hop expansion results in
the creation of another loose hop in the outgoing ERO, the
processing node MAY include the EXRS in the newly created loose
hop for further processing by downstream nodes.
The Attribute-flags affect the processing of the Diversity
XRO/EXRS subobject as follows:
o When the "Processing node exception" flag is set, the
exclusion MUST be ignored for the node processing the XRO
or EXRS subobject.
o When the "Destination node exception" flag is set, the
exclusion MUST be ignored for the destination node in
processing the XRO subobject. The destination node
exception for the EXRS subobject applies to the explicit
node identified by the ERO subobject that identifies the
next abstract node. When the "destination node exception"
flag is set in the EXRS subobject, exclusion MUST be
ignored for the said node (i.e., the next abstract node).
o When the "Penultimate node exception" flag is set in the
XRO subobject, the exclusion MUST be ignored for the
penultimate node on the path of the LSP being established.
Expires September 2018 [Page 18]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
The penultimate node exception for the EXRS subobject
applies to the node before the explicit node identified by
the ERO subobject that identifies the next abstract node.
When the "penultimate node exception" flag is set in the
EXRS subobject, the exclusion MUST be ignored for the said
node (i.e., the node before the next abstract node).
If the L-flag of the Diversity XRO subobject or Diversity EXRS
subobject is not set, the processing node proceeds as follows.
- If the Diversity Identifier Type is set to "Client Initiated
Identifier", the processing node MUST ensure that the path
calculated/expanded for the signaled LSP is diverse from the
route taken by the LSP identified in the Diversity Identifier
Value field.
- If the Diversity Identifier Type is set to "PCE Allocated
Identifier", the processing node MUST ensure that any path
calculated for the signaled LSP is diverse from the route
identified by the Path Key. The processing node MAY use the PCE
identified by the Diversity Identifier Source Address in the
subobject for route computation. The processing node MAY use
the Path Key resolution mechanisms described in [RFC5553].
- If the Diversity Identifier Type is set to "Network Assigned
Identifier", the processing node MUST ensure that the path
calculated for the signaled LSP is diverse with respect to the
values associated with the PAS identifier and Diversity
Identifier source address fields.
- Regardless of whether the path computation is performed
locally or at a remote node (e.g., PCE), the processing node
MUST ensure that any path calculated for the signaled LSP is
diverse from the requested Exclusion Flags.
- If the excluded path referenced in the XRO subobject is
unknown to the processing node, the processing node SHOULD
ignore the Diversity XRO subobject and SHOULD proceed with the
signaling request. After sending the Resv for the signaled LSP,
the processing node MUST return a PathErr with the error code
"Notify Error" (25) and error sub-code TBA4 "Route of XRO LSP
identifier unknown" (value to be assigned by IANA) for the
signaled LSP.
- If the processing node fails to find a path that meets the
requested constraint, the processing node MUST return a PathErr
Expires September 2018 [Page 19]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
with the error code "Routing Problem" (24) and error sub-code
"Route blocked by Exclude Route" (67).
If the L-flag of the Diversity XRO subobject or Diversity EXRS
subobject is set, the processing node proceeds as follows:
- If the Diversity Identifier Type is set to " Client Initiated
Identifiers", the processing node SHOULD ensure that the path
calculated/ expended for the signaled LSP is diverse from the
route taken by the LSP identified in the Diversity Identifier
Value field.
- If the Diversity Identifier Type is set to " PCE Allocated
Identifiers", the processing node SHOULD ensure that the path
calculated for the signaled LSP is diverse from the route
identified by the Path Key.
- If the Diversity Identifier Type is set to "IPv4/IPv6 Network
Assigned Identifiers", the processing node SHOULD ensure that
the path calculated for the signaled LSP is diverse with
respect to the values associated with the PAS identifier and
Diversity Identifier source address fields.
- If the processing node fails to find a path that meets the
requested constraint, it SHOULD proceed with signaling using a
suitable path that meets the constraint as far as possible.
After sending the Resv for the signaled LSP, it MUST return a
PathErr message with error code "Notify Error" (25) and error
sub-code TBA5 "Failed to satisfy Exclude Route" (value: to be
assigned by IANA) to the source node.
If, subsequent to the initial signaling of a diverse LSP, an
excluded path referenced in the XRO subobject becomes known to
the processing node, or a change in the excluded path becomes
known to the processing node, the processing node MUST re-
evaluate the exclusion and diversity constraints requested by the
diverse LSP to determine whether they are still satisfied.
- In case the L-flag was not set in the initial setup message,
the exclusion and diversity constraints were satisfied at the
time of the initial setup. If the processing node re-evaluating
the exclusion and diversity constraints for a diverse LSP
detects that the exclusion and diversity constraints are no
longer met, it MUST send a PathErr message for the diverse LSP
with the error code "Routing Problem" (24) and error sub-code
"Route blocked by Exclude Route" (67). The Path_State_Removed
flag (PSR) [RFC3473] MUST NOT be set. A source node receiving a
Expires September 2018 [Page 20]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
PathErr message with this error code and sub-code combination
SHOULD take appropriate actions and move the diverse LSP to a
new path that meets the original constraints.
- In case the L-flag was set in the initial setup message, the
exclusion and diversity constraints may or may not be satisfied
at any given time. If the exclusion constraints for a diverse
LSP were satisfied before and if the processing node re-
evaluating the exclusion and diversity constraints for a
diverse LSP detects that exclusion and diversity constraints
are no longer met, it MUST send a PathErr message for the
diverse LSP with the error code error code "Notify Error" (25)
and error sub-code TBA5 "Failed to satisfy Exclude Route"
(value: to be assigned by IANA). The PSR flag MUST NOT be set.
The source node MAY take no consequent action and keep the LSP
along the path that does not meet the original constraints.
Similarly, if the exclusion constraints for a diverse LSP were
not satisfied before and if the processing node re-evaluating
the exclusion and diversity constraints for a diverse LSP
detects that the exclusion constraints are met, it MUST send a
PathErr message for the diverse LSP with the error code "Notify
Error" (25) and a new error sub- code TBA6 "Compliant path
exists" (value: to be assigned by IANA). The PSR flag MUST NOT
be set. A source node receiving a PathErr message with this
error code and sub-code combination MAY move the diverse LSP to
a new path that meets the original constraints.
3. Security Considerations
This document does not introduce any additional security issues
in addition to those identified in [RFC5920], [RFC2205],
[RFC3209], [RFC3473], [RFC2747], [RFC4874], [RFC5520], and
[RFC5553].
The diversity mechanisms defined in this document, rely on the
new diversity subobject that is carried in the XRO or EXRS,
respectively. In section 7 of [RFC4874], it is noted some
administrative boundaries may remove the XRO due to security
concerns on explicit route information exchange. However, when
the diversity subobjects specified in this document are used,
removing at the administrative boundary an XRO containing these
diversity subobjects would result in the request for diversity
being dropped at the boundary, and path computation would be
unlikely to produce the requested diverse path. As such,
diversity subobjects MUST be retained in an XRO crossing an
Expires September 2018 [Page 21]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
administrative boundary, even if other subobjects are removed.
This retention would be based on operator policy. The use of
diversity subobjects are based on mutual agreement. This avoids
the need to share the identity of network resources when
supporting diversity.
4. IANA Considerations
IANA is requested to administer the assignment of new values
defined in this document and summarized in this section.
4.1. New XRO subobject types
IANA registry: RSVP PARAMETERS
Subsection: Class Names, Class Numbers, and Class Types
This document defines two new subobjects for the EXCLUDE_ROUTE
object [RFC4874], C-Type 1. (see:
http://www.iana.org/assignments/rsvp-parameters/rsvp-
parameters.xhtml#rsvp-parameters-94)
+--------------------------+----------------+
| Subobject Description | Subobject Type |
+--------------------------+----------------+
| IPv4 Diversity subobject | TBA1 |
| IPv6 Diversity subobject | TBA2 |
+--------------------------+----------------+
4.2. New EXRS subobject types
The Diversity XRO subobjects are also defined as new EXRS
subobjects. (EXPLICIT_ROUTE see:
http://www.iana.org/assignments/rsvp-parameters/rsvp-
parameters.xhtml#rsvp-parameters-24). The same numeric subobject
type values TBA1 and TBA2 are being requested for the two new
EXRS subobjects.
4.3. New RSVP error sub-codes
IANA registry: RSVP PARAMETERS
Subsection: Error Codes and Globally Defined Error Value Sub-
Codes.
Expires September 2018 [Page 22]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
For Error Code "Routing Problem" (24) (see [RFC3209]) the
following sub-codes are defined. (see:
http://www.iana.org/assignments/rsvp-parameters/rsvp-
parameters.xhtml#rsvp-parameters-105)
+-------------+----------------------------+---------------+
| Error Value | Description | Reference |
| Sub-codes | | |
+-------------+----------------------------+---------------+
| TBA3 | Unsupported Diversity | This document |
| | Identifier Type | |
+-------------+----------------------------+---------------+
For Error Code "Notify Error" (25) (see [RFC3209]) the following
sub-codes are defined. (see:
http://www.iana.org/assignments/rsvp-parameters/rsvp-
parameters.xhtml#rsvp-parameters-105)
+-------------+----------------------------+---------------+
| Error Value | Description | Reference |
| Sub-codes | | |
+-------------+----------------------------+---------------+
| TBA4 | Route of XRO LSP | This document |
| | identifier unknown | |
| TBA5 | Failed to satisfy | This document |
| | Exclude Route | |
| TBA6 | Compliant path exists | This document |
+-------------+----------------------------+---------------+
5. Acknowledgements
The authors would like to thank Xihua Fu for his contributions.
The authors also would like to thank Luyuan Fang and Walid Wakim
for their review comments.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Expires September 2018 [Page 23]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
[RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and
S. Jamin, "Resource ReserVation Protocol -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2747] Baker, F., Lindell, B. and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747, January 2000.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January
2003.
[RFC4202] Kompella, Ed., K, Rekhter, Y, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4202, October 2005.
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude
Routes - Extension to Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita,
N., and G. Ash, "Crankback Signaling Extensions for
MPLS and GMPLS RSVP-TE", RFC 4920, July 2007.
[RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur,
"Resource Reservation Protocol (RSVP) Extensions for
Path Key Support", RFC 5553, May 2009.
6.2. Informative References
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS)
User-Network Interface (UNI): Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Support for the
Overlay Model", RFC 4208, October 2005.
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
"Preserving Topology Confidentiality in Inter-Domain
Path Computation Using a Path-Key-Based Mechanism", RFC
5520, April 2009.
Expires September 2018 [Page 24]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
[RFC8001] F. Zhang, D. Li, O. Gonzalez de Dios, C. Margaria,
"RSVP-TE Extensions for Collecting SRLG Information",
RFC 8001, January 2017.
[RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and
S. Jamin, "Resource ReserVation Protocol -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC5251] Fedyk, D. (Ed.), Rekhter, Y. (Ed.), Papadimitriou, D.,
Rabbat, R., and Berger, L., "Layer 1 VPN Basic Mode",
RFC 5251, July 2008.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
Contributors' Addresses
Igor Bryskin
Huawei Technologies
Email: Igor.Bryskin@huawei.com
Daniele Ceccarelli
Ericsson
Email: Daniele.Ceccarelli@ericsson.com
Dhruv Dhody
Huawei Technologies
Email: dhruv.ietf@gmail.com
Oscar Gonzalez de Dios
Telefonica I+D
Email: ogondio@tid.es
Don Fedyk
Hewlett-Packard Enterprise
Email: don.fedyk@hpe.com
Clarence Filsfils
Cisco Systems, Inc.
Email: cfilsfil@cisco.com
Expires September 2018 [Page 25]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
Gabriele Maria Galimberti
Cisco Systems
Email: ggalimbe@cisco.com
Ori Gerstel
SDN Solutions Ltd.
Email: origerstel@gmail.com
Matt Hartley
Cisco Systems
Email: mhartley@cisco.com
Kenji Kumaki
KDDI Corporation
Email: ke-kumaki@kddi.com
Ruediger Kunze
Deutsche Telekom AG
Email: Ruediger.Kunze@telekom.de
Lieven Levrau
Nokia
Email: Lieven.Levrau@nokia.com
Cyril Margaria
cyril.margaria@gmail.com
Julien Meuric
France Telecom Orange
Email: julien.meuric@orange.com
Yuji Tochio
Fujitsu
Email: tochio@jp.fujitsu.com
Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com
Authors' Addresses
Zafar Ali
Cisco Systems.
Email: zali@cisco.com
Dieter Beller
Expires September 2018 [Page 26]
Internet Draft draft-ietf-teas-lsp-diversity-10.txt
Nokia
Email: Dieter.Beller@nokia.com
George Swallow
Cisco Systems
Email: swallow@cisco.com
Fatai Zhang
Huawei Technologies
Email: zhangfatai@huawei.com
Expires September 2018 [Page 27]
