< draft-anand-spring-poi-sr-04.txt   draft-anand-spring-poi-sr-05.txt >
SPRING Working Group Madhukar Anand SPRING Working Group Madhukar Anand
Internet-Draft Sanjoy Bardhan Internet-Draft Sanjoy Bardhan
Intended Status: Informational Infinera Corporation Intended Status: Standard Track Infinera Corporation
Ramesh Subrahmaniam Ramesh Subrahmaniam
Individual Individual
Jeff Tantsura Jeff Tantsura
Individual Nuage Networks
Utpal Mukhopadhyaya Utpal Mukhopadhyaya
Equinix Inc Equinix Inc
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Expires: May 18, 2018 November 14, 2017 Expires: August 10, 2018 February 6, 2018
Packet-Optical Integration in Segment Routing Packet-Optical Integration in Segment Routing
draft-anand-spring-poi-sr-04 draft-anand-spring-poi-sr-05
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 networks in an opaque
way into the segment routing domain. An instance of this class would way into the segment routing domain. An instance of this class would
be optical networks that are typically transport centric. In the IP be optical networks that are typically transport centric. In the IP
centric network, this will help in defining a common control protocol centric network, this will help in defining a common control protocol
for packet optical integration that will include optical paths as for packet optical integration that will include optical paths as
'transport segments' or sub-paths as an augmentation to packet paths. 'transport segments' or sub-paths as an augmentation to packet paths.
skipping to change at page 2, line 23 skipping to change at page 2, line 23
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) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 4, line 19 skipping to change at page 4, line 19
maintained separately. Consequently, coordinating packet and optical maintained separately. Consequently, coordinating packet and optical
networks for delivering services such as end-to-end traffic networks for delivering services such as end-to-end traffic
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) [I-D.ietf-spring-segment-routing]. Segment Routing (SR) [I-D.ietf-spring-segment-routing].
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.filsfils-spring-segment-routing-policy]. Specifically, the 5. [I-D.filsfils-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 transport
network are different from those outlined for the packet networks. network are different from those outlined for the packet networks.
Transport segment can be used to model abstracted paths through the Transport segment can be used to model abstracted paths through the
optical transport domain and integrate it with the packet network for optical transport domain and integrate it with the packet network for
delivering end-to-end services. In addition, this also introduces a delivering end-to-end services. In addition, this also introduces a
notion of a Packet optical gateway (POG). These are nodes in the notion of a Packet optical gateway (POG). These are nodes in the
network that map packet services to the optical domain that originate network that map packet services to the optical domain that originate
and terminate these transport segments. Given a transport segment, a and terminate these transport segments. Given a transport segment, a
POG will expand it to a path in the optical transport network. A POG POG will expand it to a path in the optical transport network. A POG
can be viewed as SR traffic engineering policy headend. can be viewed as SR traffic engineering policy headend.
skipping to change at page 8, line 37 skipping to change at page 8, line 37
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 optical transport 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 optical
transport domain between the two POG devices. For instance, those transport domain between the two POG devices. For instance, those
could define the path attributes such as path identifier, latency, could define the path attributes such as path identifier, latency,
bandwidth, quality, directionality, or optical path protection bandwidth, quality, directionality, or optical path protection
schemes. These attributes can be used to determine the "color" of the schemes. These attributes can be used to determine the "color" of the
SR-TE policy in the tuple <Source POG, Destination POG, color> used SR-TE policy in the tuple <Source POG, Destination POG, color> used
to prioritize different candidate paths between the POGs. 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.
skipping to change at page 10, line 9 skipping to change at page 10, line 9
The allocation of BSID to a path can include dynamic, explicit or The allocation of BSID to a path can include dynamic, explicit or
generic allocation strategies as discussed in [I-D.filsfils-spring- generic allocation strategies as discussed in [I-D.filsfils-spring-
segment-routing-policy]. We discuss PCEP and BGP-LS specific extensions segment-routing-policy]. We discuss PCEP and BGP-LS specific extensions
in the subsequent section. in the 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.draft-sivabalan-pce-segment-routing]): to [I-D.ietf-pce-segment-routing]):
Value Meaning Reference Value Meaning Reference
-------- ------------------------------------ ----------------- -------- ------------------------------------ -----------------
27 TRANSPORT-SR-PCE-CAPABILITY This document 27 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.draft-sivabalan-pce-binding-label-sid-01] 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, suggested value 32
Length: variable. Length: variable.
Binding Type: 0 or 1 as defined in Binding Type: 0 or 1 as defined in
[I-D.draft-sivabalan-pce-binding-label-sid-01] [I-D.draft-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 (recommended value
is 32) for TRANSPORT-SEGMENT-BINDING-TLV as specified in this document: is 32) for TRANSPORT-SEGMENT-BINDING-TLV as specified in this document:
1 Transport Segment Label (This document) 1 Transport Segment Label (This document)
skipping to change at page 14, line 41 skipping to change at page 14, line 41
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 27 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.draft-sivabalan-pce-binding-label-sid-01] by extending Binding SIDs [I-D.draft-sivabalan-pce-binding-label-sid]
Value Description Reference Value Description Reference
32 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
skipping to change at page 15, line 31 skipping to change at page 15, line 31
12 Acknowledgements 12 Acknowledgements
We would like to thank Peter Psenak, and Radhakrishna We would like to thank Peter Psenak, and Radhakrishna
Valiveti for their comments and review of this document. Valiveti for their comments and review of this document.
13 References 13 References
13.1 Normative References 13.1 Normative References
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
and R. Shakir, "Segment Routing Architecture", draft-ietf- Litkowski, S., and R. Shakir, "Segment Routing Architecture",
spring-segment-routing-12 (work in progress), June 2017. draft-ietf-spring-segment-routing-15 (work in progress),
January 2018.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<http://www.rfc-editor.org/info/rfc7752>.
[I-D.sivabalan-pce-binding-label-sid] [I-D.sivabalan-pce-binding-label-sid]
Sivabalan, S., Filsfils, C., Previdi, S., Tantsura, J., Sivabalan, S., Filsfils, C., Previdi, S., Tantsura, J.,
Hardwick, J., and Dhody, D., "Carrying Binding Label/ Hardwick, J., and Dhody, D., "Carrying Binding Label/
Segment-ID in PCE-based Networks.", draft-sivabalan-pce- Segment-ID in PCE-based Networks.", draft-sivabalan-pce-
binding-label-sid-03 (work in progress), July 2017. binding-label-sid-03 (work in progress), July 2017.
[I-D.ietf-pce-segment-routing] [I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing", and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-10 (work in progress), draft-ietf-pce-segment-routing-11 (work in progress),
October 2017. November 2017.
[I-D.filsfils-spring-segment-routing-policy] [I-D.filsfils-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad, Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad,
F., Lin, S., bogdanov@google.com, b., Horneffer, M., F., Talaulikar,K., Hegde, S., Voyer, D., Lin, S.,
Steinberg, D., Decraene, B., and S. Litkowski, "Segment Bogdanov, A., Horneffer, M., Steinberg, D., Decraene, B.,
Routing Policy for Traffic Engineering", draft-filsfils- Litkowski, S., and Mattes, P., "Segment Routing Policy for
spring-segment-routing-policy-01 (work in progress), July Traffic Engineering",
2017. draft-filsfils-spring-segment-routing-policy-04
(work in progress), December 2017.
13.2 Informative References 13.2 Informative References
[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
skipping to change at page 17, line 4 skipping to change at page 16, line 37
Email: manand@infinera.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
755 Ravendale Drive
Mountain View CA 94043
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
 End of changes. 16 change blocks. 
28 lines changed or deleted 28 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/