SPRING Working Group Madhukar Anand
Internet-Draft Sanjoy Bardhan
Intended Status: Standard Track Infinera Corporation
Ramesh Subrahmaniam
Individual
Jeff Tantsura
Nuage Networks
Utpal Mukhopadhyaya
Equinix Inc
Clarence Filsfils
Cisco Systems, Inc.
Expires: January 31, 2019 July 30, 2018
Packet-Optical Integration in Segment Routing
draft-anand-spring-poi-sr-06
Abstract
This document illustrates a way to integrate a new class of nodes and
links in segment routing to represent transport networks in an opaque
way into the segment routing domain. An instance of this class would
be optical networks that are typically transport centric. In the IP
centric network, this will help in defining a common control protocol
for packet optical integration that will include optical paths as
'transport segments' or sub-paths as an augmentation to packet paths.
The transport segment option also defines a general mechanism to
allow for future extensibility of segment routing into non-packet
domains.
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 to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Anand et al., Expires January 31, 2019 [Page 1]
Internet-Draft draft-anand-spring-poi-sr-06 July 30, 2018
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License 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.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Reference Taxonomy . . . . . . . . . . . . . . . . . . . . . . 4
3. Use case - Packet Optical Integration . . . . . . . . . . . . . 5
4. Mechanism overview . . . . . . . . . . . . . . . . . . . . . . 8
5. Transport Segments as SR Policy . . . . . . . . . . . . . . . 9
6. PCEP extensions for supporting the transport segment . . . . . 10
7. BGP-LS extensions for supporting the transport segment . . . . 11
7.1 Node Attribuites TLV . . . . . . . . . . . . . . . . . . . . 11
7.2 SR-Optical-Node-Capability TLV . . . . . . . . . . . . . . . 11
7.3 Prefix Attribute TLVs . . . . . . . . . . . . . . . . . . . 12
7.3.1 Transport Segment SID Sub-TLV . . . . . . . . . . . . . 12
8. Note about Transport Segments and Scalability . . . . . . . . . 13
9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
Anand et al., Expires January 31, 2019 [Page 2]
Internet-Draft draft-anand-spring-poi-sr-06 July 30, 2018
11 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11.1 PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.2 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1 Normative References . . . . . . . . . . . . . . . . . . . 15
13.2 Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Anand et al., Expires January 31, 2019 [Page 3]
Internet-Draft draft-anand-spring-poi-sr-06 July 30, 2018
1 Introduction
Packet and optical transport networks have evolved independently with
different control plane mechanisms that have to be provisioned and
maintained separately. Consequently, coordinating packet and optical
networks for delivering services such as end-to-end traffic
engineering or failure response has proved challenging. To address
this challenge, a unified control and management paradigm that
provides an incremental path to complete packet-optical integration
while leveraging existing signaling and routing protocols in either
domains is needed. This document introduces such a paradigm based on
Segment Routing (SR) [RFC8402].
This document introduces a new type of segment, Transport segment, as
a special case of SR traffic engineering (SR-TE) policy (Type 1, Sec
5. [I-D.draft-ietf-spring-segment-routing-policy]). Specifically, the
structure of SR-TE policy and constraints associated in the transport
network are different from those outlined for the packet networks.
Transport segment can be used to model abstracted paths through the
optical transport domain and integrate it with the packet network for
delivering end-to-end services. In addition, this also introduces a
notion of a Packet optical gateway (POG). These are nodes in the
network that map packet services to the optical domain that originate
and terminate these transport segments. Given a transport segment, a
POG will expand it to a path in the optical transport network. A POG
can be viewed as SR traffic engineering policy headend.
The concept of POG introduced here allows for multiple instantiations
of the concept. In one case, the packet device is distinct from the
optical transport device, and the POG is a logical entity that spans
these two devices. In this case, the POG functionality is achieved
with the help of external coordination between the packet and optical
devices. In another case, the packet and optical components are
integrated into one physical device, and the co-ordination required
for functioning of the POG is performed by this integrated device.
It must be noted that in either case, it is the packet/optical data
plane that is either disaggregated or integrated. Control of the
devices can be logically centralized or distributed in either
scenario. The focus of this document is to define the logical
functions of a POG without going into the exact instantiations of the
concept.
2. Reference Taxonomy
POG - Packet optical gateway Device
SR Edge Router - The Edge Router which is the ingress device
Anand et al., Expires January 31, 2019 [Page 4]
Internet-Draft draft-anand-spring-poi-sr-06 July 30, 2018
CE - Customer Edge Device that is outside of the SR domain
PCE - Path Computation Engine
Controller - A network controller
3. Use case - Packet Optical Integration
Many operators build and operate their networks that are both multi-
layer and multi-domain. Services are built around these layers and
domains to provide end-to-end services. Due to the nature of the
different domains, such as packet and optical, the management and
service creation has always been problematic and time consuming. With
segment routing, enabling a head-end node to select a path and embed
the information in the packet is a powerful construct that would be
used in the Packet Optical Gateways (POG). The path is usually
constructed for each domain that may be manually derived or through a
stateful PCE which is run specifically in that domain.
P5
P1 _ .-'-._ ,'P4
`._ .-' `-. ,'
`. _.-' `-._ ,'
`-. .-' `-. ,'
P2`.-'--------------------------`-.- P3
|\ /|
| \ / | Packet
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
| \ / |
| \ / | Transport
| \ / |
| ................./ |
| ,'O2 O3`. |
| ,' `. |
|,' `.|
O1\ | O4
\ ,'
\ ,'
.......................-
O6 O5
Figure 1: Representation of a packet-optical path
Anand et al., Expires January 31, 2019 [Page 5]
Internet-Draft draft-anand-spring-poi-sr-06 July 30, 2018
In Figure 1 above, the nodes represent a packet optical network.
P1,...,P5 are packet devices. Nodes P2 and P3 are connected via optical
network comprising of nodes O1,...,O6. Nodes P2 and P3 are POGs that
communicate with other packet devices and also with the devices in the
optical transport domain. In defining a path between nodes P2 and P3, we
will need to specify the nodes and the links in both the packet and
optical transport domains.
To leverage segment routing to define a service between P1 and P4, the
ingress node P1 would append all outgoing packets in a SR header
consisting of the SIDs that constitute the path. In the packet domain
this would mean P1 would send its packets towards P4 using a segment
list {P2, P3, P4} or {P2, P5, P3, P4} as the case may be. The operator
would need to use a different mechanism in the optical domain to set up
the optical paths comprising the nodes O1, O2 and O3. Each POG would
announce the active optical path as a transport segment - for example,
the optical path {O1, O2, O3} could be represented as a label Om and the
optical path {O2, O3} could be represented as a transport label On. Both
Om and On will be advertised by Packet node P2. These paths are not
known to the packet SR domain and is only relevant to the optical domain
D between P2 and P3. A PCE that is run in Domain D would be
responsible for calculating paths corresponding to label Om and On. The
expanded segment list would read as {P2, Om, P3, P4} or {P2, On, P3,
P4}. It is to be noted that there are other possible paths between P2
and P3 in the optical domain involving optical nodes O5, O6, and O4.
There may be multiple optical paths between P2 and P3 corresponding to
multiple SR policies. For example, some optical paths can be low-cost,
some are low-latency, and some others can be high-bandwidth paths.
Transport segments for all these candidate viable alternative paths may
be generated statically or dynamically.They may be pre-computed or may
be generated on the fly when a customer at node P1 requests a service
towards node P4. A discussion on transport segments and scalability can
be found in Section 8.
Use-case examples of transport segments.
1. Consider the scenario where there are multiple fibers between two
packet end points. The network operator may choose to route packet
traffic on the first fiber, and reserve the second fiber only for
maintenance or low priority traffic.
2. As a second use-case, consider the case where the packet end points
are connected by optical transport provided by two different service
providers. The packet operator wants to preferentially route traffic
over one of the providers and use the second provider as a backup.
Anand et al., Expires January 31, 2019 [Page 6]
Internet-Draft draft-anand-spring-poi-sr-06 July 30, 2018
3. Finally, let the packet end points be connected by optical paths that
may span multiple optical domains i.e. different administrative control.
For instance, one optical transport path may lie completely in one
country while the other optical transport path transits another country.
Weather, tariffs, security considerations and other factors may
determine how the packet operator wants to route different types of
traffic on this network.
All of the above use-cases can be supported by first mapping distinct
optical transport paths to different transport segments and then,
depending on the need, affixing appropriate transport segment identifier
to the specific packet to route it appropriately through the transport
domain.
+------------------------+
| |
+--------------+----' PCE or Controller |----+---------------+
| | | | | |
| | +------------------------+ | |
| | | |
| | .-----. | |
| | ( ) | |
+-------+ +-------+ .--( )--. +-------+ +-------+
| SR | |Packet | ( ) |Packet | | SR |
| Edge | |Optical|-( Optical Transport )_ |Optical| | Edge |
|Router | ... |Gateway| ( Domain ) |Gateway| ... |Router |
+---+.--+ +-------+ ( ) +-------+ +---+.--+
| '--( )--' |
,--+. ( ) ,-+-.
( CE ) '-----' ( CE )
`---' `---'
Figure 3. Reference Topology for Transport Segment Mechanism
Anand et al., Expires January 31, 2019 [Page 7]
Internet-Draft draft-anand-spring-poi-sr-06 July 30, 2018
4. Mechanism overview
The current proposal assumes that the SR domains run standard
protocols without any modification to discover the topology and
distribute labels. There are also no modifications necessary in the
control plane mechanisms in the optical transport domains. The only
requirement of a transport segment is that the optical path be setup
before they are announced to the packet network. For example, the
optical paths may be setup using a domain-specific controller or a
PCE based on requirements from the packet domain (such as bandwidth,
QoS, latency and cost) taking into consideration the constraints in
the optical network.
The mechanism for supporting the transport segment is as follows.
1. Firstly, the Packet Optical Gateway (POG) devices are announced
in the packet domain. This is indicated by advertising a new SR node
capability flag. The exact extensions to support this capability are
described in the subsequent sections of this document.
2. Then, the POG devices announce candidate optical transport
paths between that POG (Source POG) and other POGs (Destination POG)
via appropriate mechanisms in the packet domain. The paths are
announced with an appropriate optical transport domain ID and a
Binding SID representing the transport segment from a source POG to a
destination POG. The appropriate protocol-specific extensions to
carry path characteristics and Binding SID corresponding to a optical
path are described in the subsequent sections of this document.
3.The transport SR policy can also optionally be announced with a
set of attributes that characterizes the path in the optical
transport domain between the two POG devices. For instance, those
could define the path attributes such as path identifier, latency,
bandwidth, quality, directionality, or optical path protection
schemes. These attributes can be used to determine the "color" of the
SR-TE policy in the tuple <Source POG, Destination POG, color> used
to prioritize different candidate paths between the POGs.
4. The POG device is also responsible for programming its
forwarding table to map every transport segment Binding SID entry
into an appropriate forwarding action relevant in the optical domain,
such as mapping it to a optical label-switched path.
5. The transport SR policy is communicated to the PCE or
Controller using extensions to BGP-LS or PCEP as described in
subsequent sections of this document.
6. Finally, the PCE or Controller in the packet domain then uses
Anand et al., Expires January 31, 2019 [Page 8]
Internet-Draft draft-anand-spring-poi-sr-06 July 30, 2018
the transport segment binding SID in the overall SR policy to
influence the path traversed by the packet in the optical domain,
thereby defining the end-to-end path for a given service.
In the next few sections, we outline a few representative protocol
specific extensions to carry the transport segment.
5. Transport Segments as SR Policy
The Segment Routing Traffic Engineering (SRTE) [ietf-spring-segment-
routing-policy] process installs the transport segment SR policy in
the forwarding plane of the POG. The Transport SR policy is
identified by using a transport segment Binding SID. Corresponding to
each transport segment Binding SID, the SRTE process MAY learn about
multiple candidate paths. The SRTE-DB includes information about the
candidate paths including optical domain, topology and path
characteristics. All of the information can be learned from different
sources including but not limited to: Netconf/Restconf, PCEP and BGP-
LS.
The information model for Transport SR policy is as follows:
Transport SR Policy FO1
Candidate-paths
path preference 200 (selected)
BSID1
path preference 100
BSID2
path preference 100
BSID3
path preference 50
BSID4
A transport SR policy is identified through the tuple <Source POG,
Destination POG, color>. Each TSR policy is associated with one or more
candidate paths, each of them associated with a (locally) unique Binding
SID and a path preference. For each transport SR policy, the candidate
path with the highest path preference (at most one) is selected and used
for forwarding traffic that is being steered onto that policy. When
candidate paths change (or a new candidate path is set up), the path
selection process can be re-executed. The validity of each path is to be
verified by the POG before announcement in the packet domain. If there
are no valid paths, then the transport SR policy is deemed invalid.
The allocation of BSID to a path can include dynamic, explicit or
generic allocation strategies as discussed in [ietf-spring-segment-
routing-policy]. We discuss PCEP and BGP-LS specific extensions in the
subsequent section.
Anand et al., Expires January 31, 2019 [Page 9]
Internet-Draft draft-anand-spring-poi-sr-06 July 30, 2018
6. PCEP extensions for supporting the transport segment
To communicate the Packet-Optical Gateway capability of the device, we
introduce a new PCEP capabilities TLV is defined as follows(extensions
to [I-D.ietf-pce-segment-routing]):
Value Meaning Reference
-------- ------------------------------------ -----------------
27 TRANSPORT-SR-PCE-CAPABILITY This document
A new type of TLV to accommodate a transport segment is defined
by extending Binding SIDs [I-D.sivabalan-pce-binding-label-sid]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Type (BT) | Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Transport Segment Sub TLVs (variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type: TBD, suggested value 32
Length: variable.
Binding Type: 0 or 1 as defined in
[I-D.sivabalan-pce-binding-label-sid]
Domain ID: An identifier for the transport domain
Binding Value: is the transport segment label
Anand et al., Expires January 31, 2019 [Page 10]
Internet-Draft draft-anand-spring-poi-sr-06 July 30, 2018
Transport Segment Sub TLVs: TBD
IANA will be requested to allocate a new TLV type (recommended value
is 32) for TRANSPORT-SEGMENT-BINDING-TLV as specified in this document:
1 Transport Segment Label (This document)
7. BGP-LS extensions for supporting the transport segment
7.1 Node Attribuites TLV
To communicate the Packet-Optical Gateway capability of the
device, we introduce an new optical informational capability
the following new Node Attribute TLV is defined:
+-----------+----------------------------+----------+---------------+
| TLV Code | Description | Length | Section |
| Point | | | |
+-----------+----------------------------+----------+---------------+
| 1172 | SR-Optical-Node-Capability | variable | |
| | TLV | | |
+-----------+----------------------------+----------+---------------+
Table 1: Node Attribute TLVs
These TLVs can ONLY be added to the Node Attribute associated with
the node NLRI that originates the corresponding SR TLV.
7.2 SR-Optical-Node-Capability TLV
The SR Capabilities sub-TLV has following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type : TBD, Suggested Value 1157
Anand et al., Expires January 31, 2019 [Page 11]
Internet-Draft draft-anand-spring-poi-sr-06 July 30, 2018
Length: variable.
Flags: The Flags field currently has only one bit defined. If the bit
is set it has the capability of an Packet Optical Gateway.
7.3 Prefix Attribute TLVs
The following Prefix Attribute Binding SID Sub-TLVs have been added:
+------------+-------------------------+----------+-----------------+
| TLV Code | Description | Length | Section |
| Point | | | |
+------------+-------------------------+----------+-----------------+
| 1173 | TRANSPORT-SEGMENT-SID | 12 | |
| | | | |
+------------+-------------------------+----------+-----------------+
Table 4: Prefix Attribute - Binding SID Sub-TLVs
The Transport segment TLV allows a node to advertise an transport
segment within a single IGP domain. The transport segment SID TLV
TRANSPORT-SEGMENT-TLV has the following format:
7.3.1 Transport Segment SID Sub-TLV
Further, a new sub-TLV (similar to the IPV4 ERO SubTLV) of
Binding SID Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the
transport segment label is defined as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain ID | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet-Optical Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Transport Segment Sub TLVs (variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type : TBD
Length: variable.
Domain ID: An identifier for the transport domain
Anand et al., Expires January 31, 2019 [Page 12]
Internet-Draft draft-anand-spring-poi-sr-06 July 30, 2018
Flags: 1 octet field of following flags:
V - Value flag. If set, then the optical label carries a value.
By default the flag is SET.
L - Local. Local Flag. If set, then the value/index carried by
the Adj-SID has local significance. By default the flag is SET.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V|L|
+-+-+-+-+-+-+-+-+
Packet-Optical Label : according to the V and L flags, it contains
either:
* A 3 octet local label where the 20 rightmost bits are
used for encoding the label value. In this case the V and
L flags MUST be set.
* A 4 octet index defining the offset in the label space
advertised by this router. In this case V and L flags MUST
be unset.
Transport Segment Sub TLVs: TBD
Multiple TRANSPORT-SEGMENT-TLV MAY be associated with a pair
of POG devices to represent multiple paths within the optical domain
8. Note about Transport Segments and Scalability
In most operational scenarios, there would be multiple, distinct paths
between the POGs. There is no requirement that every distinct path in
the optical domain be advertised as a separate transport segment.
Transport segments are designed to be consumed in the packet domain,
and the correspondence between transport segments and exact paths in
the optical domain are determined by their utility to the packet world.
Therefore, the number of transport segments is to be determined by the
individual packet-optical use-case. The number of actual paths in the
optical domain between the POG is expected to be large (counting the
number of active and passive devices in the optical network), it is
likely that multiple actual paths are to be advertised as one transport
segment. Of course, in the degenerate case, it is possible that there
is a one-to-one correspondence between an optical path and a transport
segment. Given this view of network operation, the POG is not expected
Anand et al., Expires January 31, 2019 [Page 13]
Internet-Draft draft-anand-spring-poi-sr-06 July 30, 2018
to handle a large number of transport segments (and identifiers). This
framework does leave open the possibility of handling a large number
of transport segments in future. For instance, a hierarchical
partitioning of the optical domain along with stacking of multiple
transport segment identifiers could be explored towards reducing
the overall number of transport segment identifiers.
9. Summary
The motivation for introducing a new type of segment - transport
segment - is to integrate transport networks with the segment
routing domain and expose characteristics of the transport domain into
the packet domain. An end-to-end path across packet and transport
domains can then be specified by attaching appropriate SIDs to the
packet. An instance of transport segments has been defined here for
optical networks, where paths between packet-optical gateway devices
have been abstracted using binding SIDs. Extensions to various
protocols to announce the transport segment have been proposed
in this document.
10. Security Considerations
This document does not introduce any new security considerations.
11 IANA Considerations
This documents request allocation for the following TLVs and subTLVs.
11.1 PCEP
Packet-Optical Gateway capability of the device
Value Meaning Reference
-------- ------------------------------------ -----------------
27 TRANSPORT-SR-PCE-CAPABILITY This document
A new type of TLV to accommodate a transport segment is defined
by extending Binding SIDs [I-D.sivabalan-pce-binding-label-sid]
Value Description Reference
32 TRANSPORT-SR-PCEP-TLV This document
This document requests that a registry is created to manage the value
of the Binding Type field in the TRANSPORT-SR-PCEP TLV.
Anand et al., Expires January 31, 2019 [Page 14]
Internet-Draft draft-anand-spring-poi-sr-06 July 30, 2018
Value Description Reference
1 Transport Segment Label This document
11.2 BGP-LS
Node Attributes TLV:
Value Description Reference
1172 TRANSPORT-SR-BGPLS-CAPABILITY This document
Prefix Attribute Binding SID SubTLV:
Value Description Reference
1173 TRANSPORT-SR-BGPLS-TLV This document
12 Acknowledgements
We would like to thank Peter Psenak, and Radhakrishna
Valiveti for their comments and review of this document.
13 References
13.1 Normative References
[RFC8402]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing Architecture",
RFC 8402, July 2018.
[I-D.sivabalan-pce-binding-label-sid]
Sivabalan, S., Tantsura, J., Filsfils, C., Previdi, S.,
Hardwick, J., and Dhody, D., "Carrying Binding Label/
Segment-ID in PCE-based Networks.", draft-sivabalan-pce-
binding-label-sid-04 (work in progress), Mar 2018.
[I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-12 (work in progress),
June 2018.
[I-D.draft-ietf-spring-segment-routing-policy]
Anand et al., Expires January 31, 2019 [Page 15]
Internet-Draft draft-anand-spring-poi-sr-06 July 30, 2018
Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A.,
and Mattes, P., "Segment Routing Policy Architecture",
draft-ietf-spring-segment-routing-policy-01.txt
(work in progress), June 2018.
13.2 Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Authors' Addresses
Madhukar Anand
Infinera Corporation
169 W Java Dr, Sunnyvale, CA 94089
Email: manand@infinera.com
Sanjoy Bardhan
Infinera Corporation
169 W Java Dr, Sunnyvale, CA 94089
Email: sbardhan@infinera.com
Ramesh Subrahmaniam
Email: svr_fremont@yahoo.com
Jeff Tantsura
Nuage Networks
755 Ravendale Drive
Mountain View CA 94043
Email: jefftant.ietf@gmail.com
Anand et al., Expires January 31, 2019 [Page 16]
Internet-Draft draft-anand-spring-poi-sr-06 July 30, 2018
Utpal Mukhopadhyaya
Equinix Inc
1188 E. Arques, Sunnyvale, CA 94085
Email: umukhopadhyaya@equinix.com
Clarence Filsfils
Cisco Systems, Inc.
Brussels
BE
Email: cfilsfil@cisco.com
Anand et al., Expires January 31, 2019 [Page 17]