< draft-anand-spring-poi-sr-06.txt   draft-anand-spring-poi-sr-07.txt >
SPRING Working Group Madhukar Anand SPRING Working Group Madhukar Anand
Internet-Draft Sanjoy Bardhan Internet-Draft Ciena Corporation
Intended Status: Standard Track Infinera Corporation Intended Status: Standard Track
Sanjoy Bardhan
Infinera Corporation
Ramesh Subrahmaniam Ramesh Subrahmaniam
Individual Individual
Jeff Tantsura Jeff Tantsura
Nuage Networks Apstra
Utpal Mukhopadhyaya Utpal Mukhopadhyaya
Equinix Inc Equinix Inc
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Expires: January 31, 2019 July 30, 2018 Expires: August 1, 2019 January 28, 2019
Packet-Optical Integration in Segment Routing Packet-Optical Integration in Segment Routing
draft-anand-spring-poi-sr-06 draft-anand-spring-poi-sr-07
Abstract Abstract
This document illustrates a way to integrate a new class of nodes and This document illustrates a way to integrate a new class of nodes and
links in segment routing to represent transport networks in an opaque links in segment routing to represent transport/optical networks in
way into the segment routing domain. An instance of this class would an opaque way into the segment routing domain. An instance of this
be optical networks that are typically transport centric. In the IP class would be optical networks that are typically transport centric
centric network, this will help in defining a common control protocol by having very few devices with the capability to process packets.
for packet optical integration that will include optical paths as In the IP centric network, this will help in defining a common
'transport segments' or sub-paths as an augmentation to packet paths. control protocol for packet optical integration that will include
The transport segment option also defines a general mechanism to optical paths as 'transport segments' or sub-paths as an augmentation
allow for future extensibility of segment routing into non-packet to packet paths. The transport segment option also defines a general
domains. mechanism to allow for future extensibility of segment routing into
non-packet domains.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 23 skipping to change at page 2, line 25
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 45 skipping to change at page 2, line 47
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Reference Taxonomy . . . . . . . . . . . . . . . . . . . . . . 4 2. Reference Taxonomy . . . . . . . . . . . . . . . . . . . . . . 4
3. Use case - Packet Optical Integration . . . . . . . . . . . . . 5 3. Use case - Packet Optical Integration . . . . . . . . . . . . . 5
4. Mechanism overview . . . . . . . . . . . . . . . . . . . . . . 8 4. Mechanism overview . . . . . . . . . . . . . . . . . . . . . . 8
5. Transport Segments as SR Policy . . . . . . . . . . . . . . . 9 5. Transport Segments as SR Policy . . . . . . . . . . . . . . . 9
6. PCEP extensions for supporting the transport segment . . . . . 10 6. PCEP extensions for supporting the transport segment . . . . . 10
7. BGP-LS extensions for supporting the transport segment . . . . 11 7. BGP-LS extensions for supporting the transport segment . . . . 11
7.1 Node Attribuites TLV . . . . . . . . . . . . . . . . . . . . 11 7.1 Node Attributes TLV . . . . . . . . . . . . . . . . . . . . 11
7.2 SR-Optical-Node-Capability TLV . . . . . . . . . . . . . . . 11 7.2 SR-Optical-Node-Capability Sub-TLV . . . . . . . . . . . . . 11
7.3 Prefix Attribute TLVs . . . . . . . . . . . . . . . . . . . 12 7.3 Prefix Attribute TLVs . . . . . . . . . . . . . . . . . . . 12
7.3.1 Transport Segment SID Sub-TLV . . . . . . . . . . . . . 12 7.3.1 Transport Segment SID Sub-TLV . . . . . . . . . . . . . 12
8. Note about Transport Segments and Scalability . . . . . . . . . 13 8. Note about Transport Segments and Scalability . . . . . . . . . 13
9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11.1 PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1 PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.2 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.2 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 12 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1 Normative References . . . . . . . . . . . . . . . . . . . 15 13.1 Normative References . . . . . . . . . . . . . . . . . . . 15
13.2 Informative References . . . . . . . . . . . . . . . . . . 16 13.2 Informative References . . . . . . . . . . . . . . . . . . 16
skipping to change at page 4, line 21 skipping to change at page 4, line 21
engineering or failure response has proved challenging. To address engineering or failure response has proved challenging. To address
this challenge, a unified control and management paradigm that this challenge, a unified control and management paradigm that
provides an incremental path to complete packet-optical integration provides an incremental path to complete packet-optical integration
while leveraging existing signaling and routing protocols in either while leveraging existing signaling and routing protocols in either
domains is needed. This document introduces such a paradigm based on domains is needed. This document introduces such a paradigm based on
Segment Routing (SR) [RFC8402]. Segment Routing (SR) [RFC8402].
This document introduces a new type of segment, Transport segment, as This document introduces a new type of segment, Transport segment, as
a special case of SR traffic engineering (SR-TE) policy (Type 1, Sec a special case of SR traffic engineering (SR-TE) policy (Type 1, Sec
5. [I-D.draft-ietf-spring-segment-routing-policy]). Specifically, the 5. [I-D.draft-ietf-spring-segment-routing-policy]). Specifically, the
structure of SR-TE policy and constraints associated in the transport structure of SR-TE policy and constraints associated in the
network are different from those outlined for the packet networks. transport/optical network are different from those outlined for the
Transport segment can be used to model abstracted paths through the packet networks. Transport segment can be used to model abstracted
optical transport domain and integrate it with the packet network for paths through the transport/optical domain and integrate it with the
delivering end-to-end services. In addition, this also introduces a packet network for delivering end-to-end services. In addition, this
notion of a Packet optical gateway (POG). These are nodes in the also introduces a notion of a Packet optical gateway (POG). These are
network that map packet services to the optical domain that originate nodes in the network that map packet services to the optical domain
and terminate these transport segments. Given a transport segment, a that originate and terminate these transport segments. Given a
POG will expand it to a path in the optical transport network. A POG transport segment, a POG will expand it to a path in the optical
can be viewed as SR traffic engineering policy headend. transport network. A POG can be viewed as SR traffic engineering
policy headend.
The concept of POG introduced here allows for multiple instantiations The concept of POG introduced here allows for multiple instantiations
of the concept. In one case, the packet device is distinct from the 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 transport/optical device, and the POG is a logical entity that spans
these two devices. In this case, the POG functionality is achieved these two devices. In this case, the POG functionality is achieved
with the help of external coordination between the packet and optical with the help of external coordination between the packet and optical
devices. In another case, the packet and optical components are devices. In another case, the packet and optical components are
integrated into one physical device, and the co-ordination required integrated into one physical device, and the co-ordination required
for functioning of the POG is performed by this integrated device. 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 It must be noted that in either case, it is the packet/optical data
plane that is either disaggregated or integrated. Control of the plane that is either disaggregated or integrated. Control of the
devices can be logically centralized or distributed in either devices can be logically centralized or distributed in either
scenario. The focus of this document is to define the logical scenario. The focus of this document is to define the logical
functions of a POG without going into the exact instantiations of the functions of a POG without going into the exact instantiations of the
skipping to change at page 5, line 29 skipping to change at page 5, line 29
used in the Packet Optical Gateways (POG). The path is usually used in the Packet Optical Gateways (POG). The path is usually
constructed for each domain that may be manually derived or through a constructed for each domain that may be manually derived or through a
stateful PCE which is run specifically in that domain. stateful PCE which is run specifically in that domain.
P5 P5
P1 _ .-'-._ ,'P4 P1 _ .-'-._ ,'P4
`._ .-' `-. ,' `._ .-' `-. ,'
`. _.-' `-._ ,' `. _.-' `-._ ,'
`-. .-' `-. ,' `-. .-' `-. ,'
P2`.-'--------------------------`-.- P3 P2`.-'--------------------------`-.- P3
|\ /| |\ /|
| \ / | Packet | \ / | Packet
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
| \ / | | \ / |
| \ / | Transport | \ / | Optical
| \ / | | \ / |
| ................./ | | ................/ |
| ,'O2 O3`. | | ,'O2 O3`. |
| ,' `. | | ,' `. |
|,' `.| |,' `.|
O1\ | O4 O1\ | O4
\ ,' \ ,'
\ ,' \ ,'
.......................- .......................-
O6 O5 O6 O5
Figure 1: Representation of a packet-optical path Figure 1: Representation of a packet-optical path
In Figure 1 above, the nodes represent a packet optical network. In Figure 1 above, the nodes represent a packet optical network.
P1,...,P5 are packet devices. Nodes P2 and P3 are connected via optical 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 network (e.g., DWDM) comprising of nodes O1,...,O6. Nodes P2 and P3 are
communicate with other packet devices and also with the devices in the POGs that communicate with other packet devices and also with the
optical transport domain. In defining a path between nodes P2 and P3, we devices in the transport/optical domain. POGs P2 and P3 are connected to
will need to specify the nodes and the links in both the packet and optical nodes O2/O3 and O3/O4 respectively via multiple links that are
optical transport domains. visible to the packet network. In defining a path between nodes P2 and
P3, we will need to specify the nodes and the links in both the packet
and transport/optical domains.
To leverage segment routing to define a service between P1 and P4, the 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 ingress node P1 would append all outgoing packets in a SR header
consisting of the SIDs that constitute the path. In the packet domain 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 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 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 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 the paths between the two POGs P2 and P3. For instance, if the packet is
announce the active optical path as a transport segment - for example, forwarded on the link from P2 towards O1 with the expectation that it
the optical path {O1, O2, O3} could be represented as a label Om and the would come out on the link O4-P3, it could be routed in the optical
optical path {O2, O3} could be represented as a transport label On. Both network using either path {O1, O2, O3, O4} or {O1, O6, O5, O4}.
Om and On will be advertised by Packet node P2. These paths are not Currently, this decision is made in the optical domain, and there are no
known to the packet SR domain and is only relevant to the optical domain mechanisms in the packet network to influence that. The transport
D between P2 and P3. A PCE that is run in Domain D would be segment mechanism proposed in this draft has been designed with an
responsible for calculating paths corresponding to label Om and On. The explicit goal of providing better control of optical path selection to
expanded segment list would read as {P2, Om, P3, P4} or {P2, On, P3, the packet network and applications running on them.
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. Under the proposed scheme, each POG would announce active optical paths
There may be multiple optical paths between P2 and P3 corresponding to to the other POG as a transport segment - for example, the optical path
multiple SR policies. For example, some optical paths can be low-cost, from P2 to P3 comprising {O1, O2, O3, O4} could be represented as a
some are low-latency, and some others can be high-bandwidth paths. transport segment label Om and the optical path from P2 to P3 comprising
Transport segments for all these candidate viable alternative paths may devices {O1, O5, O6, O4} could be represented as a transport segment
be generated statically or dynamically.They may be pre-computed or may label On. Both Om and On will be advertised by POG P2 as two optical
be generated on the fly when a customer at node P1 requests a service paths between P2 and P3 with specific properties. The specifics of the
towards node P4. A discussion on transport segments and scalability can optical paths, including specific intermediate devices, need not be
be found in Section 8. exposed to the packet SR domain and are only relevant to the optical
domain between P2 and P3. A PCE that is run in the optical domain
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}. Multiple optical paths between P2 and P3 corresponding to
different properties can be exposed as transport segments in the packet
domain. For example, some optical paths can be low operational cost
paths, some could be 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. Use-case examples of transport segments.
1. Consider the scenario where there are multiple fibers between two 1. Consider the scenario where there are multiple fibers between two
packet end points. The network operator may choose to route packet packet end points. The network operator may choose to route packet
traffic on the first fiber, and reserve the second fiber only for traffic on the first fiber, and reserve the second fiber only for
maintenance or low priority traffic. maintenance or low priority traffic.
2. As a second use-case, consider the case where the packet end points 2. As a second use-case, consider the case where the packet end points
are connected by optical transport provided by two different service are connected by transport/optical network provided by two different
providers. The packet operator wants to preferentially route traffic service providers. The packet operator wants to preferentially route
over one of the providers and use the second provider as a backup. traffic over one of the providers and use the second provider as a
backup.
3. Finally, let the packet end points be connected by optical paths that 3. Finally, let the packet end points be connected by optical paths that
may span multiple optical domains i.e. different administrative control. may span multiple optical domains i.e. different administrative control.
For instance, one optical transport path may lie completely in one For instance, one transport/optical path may lie completely in one
country while the other optical transport path transits another country. country while the other transport/optical path transits another country.
Weather, tariffs, security considerations and other factors may Weather, tariffs, security considerations and other factors may
determine how the packet operator wants to route different types of determine how the packet operator wants to route different types of
traffic on this network. traffic on this network.
All of the above use-cases can be supported by first mapping distinct All of the above use-cases can be supported by first mapping distinct
optical transport paths to different transport segments and then, transport/optical paths to different transport segments and then,
depending on the need, affixing appropriate transport segment identifier depending on the need, affixing appropriate transport segment identifier
to the specific packet to route it appropriately through the transport to the specific packet to route it appropriately through the transport
domain. domain.
+------------------------+ +------------------------+
| | | |
+--------------+----' PCE or Controller |----+---------------+ +--------------+----' PCE or Controller |----+---------------+
| | | | | | | | | | | |
| | +------------------------+ | | | | +------------------------+ | |
| | | | | | | |
| | .-----. | | | | .-----. | |
| | ( ) | | | | ( ) | |
+-------+ +-------+ .--( )--. +-------+ +-------+ +-------+ +-------+ .--( )--. +-------+ +-------+
| SR | |Packet | ( ) |Packet | | SR | | SR | |Packet | ( ) |Packet | | SR |
| Edge | |Optical|-( Optical Transport )_ |Optical| | Edge | | Edge | |Optical|-( Transport/optical )_ |Optical| | Edge |
|Router | ... |Gateway| ( Domain ) |Gateway| ... |Router | |Router | ... |Gateway| ( Domain ) |Gateway| ... |Router |
+---+.--+ +-------+ ( ) +-------+ +---+.--+ +---+.--+ +-------+ ( ) +-------+ +---+.--+
| '--( )--' | | '--( )--' |
,--+. ( ) ,-+-. ,--+. ( ) ,-+-.
( CE ) '-----' ( CE ) ( CE ) '-----' ( CE )
`---' `---' `---' `---'
Figure 3. Reference Topology for Transport Segment Mechanism Figure 3. Reference Topology for Transport Segment Mechanism
4. Mechanism overview 4. Mechanism overview
The current proposal assumes that the SR domains run standard The current proposal assumes that the SR domains run standard
protocols without any modification to discover the topology and protocols without any modification to discover the topology and
distribute labels. There are also no modifications necessary in the distribute labels. There are also no modifications necessary in the
control plane mechanisms in the optical transport domains. The only control plane mechanisms in the transport/optical domains. The only
requirement of a transport segment is that the optical path be setup requirement of a transport segment is that the optical path be setup
before they are announced to the packet network. For example, the before they are announced to the packet network. For example, the
optical paths may be setup using a domain-specific controller or a optical paths may be setup using a domain-specific controller or a
PCE based on requirements from the packet domain (such as bandwidth, PCE based on requirements from the packet domain (such as bandwidth,
QoS, latency and cost) taking into consideration the constraints in QoS, latency and cost) taking into consideration the constraints in
the optical network. the optical network.
The mechanism for supporting the transport segment is as follows. The mechanism for supporting the transport segment is as follows.
1. Firstly, the Packet Optical Gateway (POG) devices are announced 1. Firstly, the Packet Optical Gateway (POG) devices are announced
in the packet domain. This is indicated by advertising a new SR node in the packet domain. This is indicated by advertising a new SR node
capability flag. The exact extensions to support this capability are capability flag. The exact extensions to support this capability are
described in the subsequent sections of this document. described in the subsequent sections of this document.
2. Then, the POG devices announce candidate optical transport 2. Then, the POG devices announce candidate transport/optical
paths between that POG (Source POG) and other POGs (Destination POG) paths between that POG (Source POG) and other POGs (Destination POG)
via appropriate mechanisms in the packet domain. The paths are via appropriate mechanisms in the packet domain. The paths are
announced with an appropriate optical transport domain ID and a announced with an appropriate transport/optical domain ID and a
Binding SID representing the transport segment from a source POG to a Binding SID representing the transport segment from a source POG to a
destination POG. The appropriate protocol-specific extensions to destination POG. The appropriate protocol-specific extensions to
carry path characteristics and Binding SID corresponding to a optical carry path characteristics and Binding SID corresponding to a optical
path are described in the subsequent sections of this document. path are described in the subsequent sections of this document.
3.The transport SR policy can also optionally be announced with a 3.The transport SR policy can also optionally be announced with a
set of attributes that characterizes the path in the optical set of attributes that characterizes the path in the
transport domain between the two POG devices. For instance, those transport/optical domain between the two POG devices. For instance,
could define the path attributes such as path identifier, latency, those could define the path attributes such as path identifier,
bandwidth, quality, directionality, or optical path protection latency, bandwidth, quality, directionality, or optical path
schemes. These attributes can be used to determine the "color" of the protection schemes. These attributes can be used to determine the
SR-TE policy in the tuple <Source POG, Destination POG, color> used "color" of the SR-TE policy in the tuple <Source POG, Destination
to prioritize different candidate paths between the POGs. POG, color> used to prioritize different candidate paths between the
POGs.
4. The POG device is also responsible for programming its 4. The POG device is also responsible for programming its
forwarding table to map every transport segment Binding SID entry forwarding table to map every transport segment Binding SID entry
into an appropriate forwarding action relevant in the optical domain, into an appropriate forwarding action relevant in the optical domain,
such as mapping it to a optical label-switched path. such as mapping it to a optical label-switched path.
5. The transport SR policy is communicated to the PCE or 5. The transport SR policy is communicated to the PCE or
Controller using extensions to BGP-LS or PCEP as described in Controller using extensions to BGP-LS or PCEP as described in
subsequent sections of this document. subsequent sections of this document.
skipping to change at page 10, line 13 skipping to change at page 10, line 21
subsequent section. subsequent section.
6. PCEP extensions for supporting the transport segment 6. PCEP extensions for supporting the transport segment
To communicate the Packet-Optical Gateway capability of the device, we To communicate the Packet-Optical Gateway capability of the device, we
introduce a new PCEP capabilities TLV is defined as follows(extensions introduce a new PCEP capabilities TLV is defined as follows(extensions
to [I-D.ietf-pce-segment-routing]): to [I-D.ietf-pce-segment-routing]):
Value Meaning Reference Value Meaning Reference
-------- ------------------------------------ ----------------- -------- ------------------------------------ -----------------
27 TRANSPORT-SR-PCE-CAPABILITY This document TBD1 TRANSPORT-SR-PCE-CAPABILITY This document
A new type of TLV to accommodate a transport segment is defined A new type of TLV to accommodate a transport segment is defined
by extending Binding SIDs [I-D.sivabalan-pce-binding-label-sid] by extending Binding SIDs [I-D.sivabalan-pce-binding-label-sid]
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Type (BT) | Domain ID | | Binding Type (BT) | Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Value | | Binding Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Transport Segment Sub TLVs (variable length) ~ ~ Transport Segment Sub TLVs (variable length) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Type: TBD, suggested value 32 Type: TBD
Length: variable. Length: variable.
Binding Type: 0 or 1 as defined in Binding Type: 0 or 1 as defined in
[I-D.sivabalan-pce-binding-label-sid] [I-D.sivabalan-pce-binding-label-sid]
Domain ID: An identifier for the transport domain Domain ID: An identifier for the transport domain
Binding Value: is the transport segment label Binding Value: is the transport segment label
Transport Segment Sub TLVs: TBD Transport Segment Sub TLVs: TBD
IANA will be requested to allocate a new TLV type (recommended value IANA will be requested to allocate a new TLV type for
is 32) for TRANSPORT-SEGMENT-BINDING-TLV as specified in this document: TRANSPORT-SEGMENT-BINDING-TLV as specified in this document:
1 Transport Segment Label (This document) TBD Transport Segment Label (This document)
7. BGP-LS extensions for supporting the transport segment 7. BGP-LS extensions for supporting the transport segment
7.1 Node Attribuites TLV 7.1 Node Attributes TLV
To communicate the Packet-Optical Gateway capability of the To communicate the Packet-Optical Gateway capability of the
device, we introduce an new optical informational capability device, we introduce an new optical informational capability
the following new Node Attribute TLV is defined: the following new Node Attribute TLV is defined:
+-----------+----------------------------+----------+---------------+ +-----------+----------------------------+----------+---------------+
| TLV Code | Description | Length | Section | | TLV Code | Description | Length | Section |
| Point | | | | | Point | | | |
+-----------+----------------------------+----------+---------------+ +-----------+----------------------------+----------+---------------+
| 1172 | SR-Optical-Node-Capability | variable | | | TBD | SR-Optical-Node-Capability | variable | |
| | TLV | | | | | TLV | | |
+-----------+----------------------------+----------+---------------+ +-----------+----------------------------+----------+---------------+
Table 1: Node Attribute TLVs Table 1: Node Attribute TLVs
These TLVs can ONLY be added to the Node Attribute associated with These TLVs can ONLY be added to the Node Attribute associated with
the node NLRI that originates the corresponding SR TLV. the node NLRI that originates the corresponding SR TLV.
7.2 SR-Optical-Node-Capability TLV 7.2 SR-Optical-Node-Capability Sub-TLV
The SR Capabilities sub-TLV has following format: The SR Capabilities sub-TLV has following format:
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | RESERVED | | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 4 skipping to change at page 12, line 9
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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | RESERVED | | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Type : TBD, Suggested Value 1157 Type : TBD, Suggested Value 1157
Length: variable. Length: variable.
Flags: The Flags field currently has only one bit defined. If the bit Flags: The Flags field currently has only one bit defined. If the bit
is set it has the capability of an Packet Optical Gateway. is set it has the capability of an Packet Optical Gateway.
7.3 Prefix Attribute TLVs 7.3 Prefix Attribute TLVs
The following Prefix Attribute Binding SID Sub-TLVs have been added: The following Prefix Attribute Binding SID Sub-TLVs have been added:
+------------+-------------------------+----------+-----------------+ +------------+-------------------------+----------+-----------------+
| TLV Code | Description | Length | Section | | TLV Code | Description | Length | Section |
| Point | | | | | Point | | | |
+------------+-------------------------+----------+-----------------+ +------------+-------------------------+----------+-----------------+
| 1173 | TRANSPORT-SEGMENT-SID | 12 | | | TBD | TRANSPORT-SEGMENT-SID | 12 | |
| | | | | | | | | |
+------------+-------------------------+----------+-----------------+ +------------+-------------------------+----------+-----------------+
Table 4: Prefix Attribute - Binding SID Sub-TLVs Table 4: Prefix Attribute - Binding SID Sub-TLVs
The Transport segment TLV allows a node to advertise an transport The Transport segment TLV allows a node to advertise an transport
segment within a single IGP domain. The transport segment SID TLV segment within a single IGP domain. The transport segment SID TLV
TRANSPORT-SEGMENT-TLV has the following format: TRANSPORT-SEGMENT-TLV has the following format:
7.3.1 Transport Segment SID Sub-TLV 7.3.1 Transport Segment SID Sub-TLV
skipping to change at page 14, line 14 skipping to change at page 14, line 20
to handle a large number of transport segments (and identifiers). This to handle a large number of transport segments (and identifiers). This
framework does leave open the possibility of handling a large number framework does leave open the possibility of handling a large number
of transport segments in future. For instance, a hierarchical of transport segments in future. For instance, a hierarchical
partitioning of the optical domain along with stacking of multiple partitioning of the optical domain along with stacking of multiple
transport segment identifiers could be explored towards reducing transport segment identifiers could be explored towards reducing
the overall number of transport segment identifiers. the overall number of transport segment identifiers.
9. Summary 9. Summary
The motivation for introducing a new type of segment - transport The motivation for introducing a new type of segment - transport
segment - is to integrate transport networks with the segment segment - is to integrate transport/optical networks with the segment
routing domain and expose characteristics of the transport domain into routing domain and expose characteristics of the transport/optical
the packet domain. An end-to-end path across packet and transport domain into the packet domain. An end-to-end path across packet and
domains can then be specified by attaching appropriate SIDs to the transport/optical domains can then be specified by attaching
packet. An instance of transport segments has been defined here for appropriate SIDs to the packet. An instance of transport segments has
optical networks, where paths between packet-optical gateway devices been defined here for optical networks, where paths between
have been abstracted using binding SIDs. Extensions to various packet-optical gateway devices have been abstracted using
protocols to announce the transport segment have been proposed binding SIDs. Extensions to various protocols to announce the
in this document. transport segment have been proposed in this document.
10. Security Considerations 10. Security Considerations
This document does not introduce any new security considerations. This document does not introduce any new security considerations.
11 IANA Considerations 11 IANA Considerations
This documents request allocation for the following TLVs and subTLVs. This documents request allocation for the following TLVs and subTLVs.
11.1 PCEP 11.1 PCEP
Packet-Optical Gateway capability of the device Packet-Optical Gateway capability of the device
Value Meaning Reference Value Meaning Reference
-------- ------------------------------------ ----------------- -------- ------------------------------------ -----------------
27 TRANSPORT-SR-PCE-CAPABILITY This document TBD1 TRANSPORT-SR-PCE-CAPABILITY This document
A new type of TLV to accommodate a transport segment is defined A new type of TLV to accommodate a transport segment is defined
by extending Binding SIDs [I-D.sivabalan-pce-binding-label-sid] by extending Binding SIDs [I-D.sivabalan-pce-binding-label-sid]
Value Description Reference Value Description Reference
TBD2 TRANSPORT-SR-PCEP-TLV This document
32 TRANSPORT-SR-PCEP-TLV This document
This document requests that a registry is created to manage the value This document requests that a registry is created to manage the value
of the Binding Type field in the TRANSPORT-SR-PCEP TLV. of the Binding Type field in the TRANSPORT-SR-PCEP TLV.
Value Description Reference Value Description Reference
1 Transport Segment Label This document TBD3 Transport Segment Label This document
11.2 BGP-LS 11.2 BGP-LS
Node Attributes TLV: Node Attributes TLV:
Value Description Reference Value Description Reference
1172 TRANSPORT-SR-BGPLS-CAPABILITY This document TBD4 TRANSPORT-SR-BGPLS-CAPABILITY This document
Prefix Attribute Binding SID SubTLV: Prefix Attribute Binding SID SubTLV:
Value Description Reference Value Description Reference
1173 TRANSPORT-SR-BGPLS-TLV This document TBD5 TRANSPORT-SR-BGPLS-TLV This document
12 Acknowledgements 12 Acknowledgements
We would like to thank Peter Psenak, and Radhakrishna We would like to thank Peter Psenak, Bruno Decraene Ketan
Valiveti for their comments and review of this document. Talaulikar and Radhakrishna Valiveti for their comments and
review of this document.
13 References 13 References
13.1 Normative References 13.1 Normative References
[RFC8402] [RFC8402]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing Architecture", Litkowski, S., and R. Shakir, "Segment Routing Architecture",
RFC 8402, July 2018. RFC 8402, July 2018.
skipping to change at page 16, line 11 skipping to change at page 16, line 16
June 2018. June 2018.
[I-D.draft-ietf-spring-segment-routing-policy] [I-D.draft-ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A.,
and Mattes, P., "Segment Routing Policy Architecture", and Mattes, P., "Segment Routing Policy Architecture",
draft-ietf-spring-segment-routing-policy-01.txt draft-ietf-spring-segment-routing-policy-01.txt
(work in progress), June 2018. (work in progress), June 2018.
13.2 Informative References 13.2 Informative References
[RFC5513] Farrel, A., "IANA Considerations for Three Letter
Acronyms", RFC 5513, DOI 10.17487/RFC5513, April 1 2009,
<http://www.rfc-editor.org/info/rfc5513>.
[RFC5514] Vyncke, E., "IPv6 over Social Networks",
RFC 5514, DOI 10.17487/RFC5514, April 1 2009,
<http://www.rfc-editor.org/info/rfc5514>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
Authors' Addresses Authors' Addresses
Madhukar Anand Madhukar Anand
Infinera Corporation Ciena Corporation
169 W Java Dr, Sunnyvale, CA 94089 3939, N 1st Street, San Jose, CA, 95134
Email: madanand@ciena.com
Email: manand@infinera.com
Sanjoy Bardhan Sanjoy Bardhan
Infinera Corporation Infinera Corporation
169 W Java Dr, Sunnyvale, CA 94089 169 W Java Dr, Sunnyvale, CA 94089
Email: sbardhan@infinera.com Email: sbardhan@infinera.com
Ramesh Subrahmaniam Ramesh Subrahmaniam
Email: svr_fremont@yahoo.com Email: svr_fremont@yahoo.com
Jeff Tantsura Jeff Tantsura
Nuage Networks Apstra
755 Ravendale Drive 333 Middlefield Road Suite 200
Mountain View CA 94043 Menlo Park, CA 94025
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
Utpal Mukhopadhyaya Utpal Mukhopadhyaya
Equinix Inc Equinix Inc
1188 E. Arques, Sunnyvale, CA 94085 1188 E. Arques, Sunnyvale, CA 94085
Email: umukhopadhyaya@equinix.com Email: umukhopadhyaya@equinix.com
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
BE BE
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
 End of changes. 46 change blocks. 
117 lines changed or deleted 143 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/