< draft-ietf-pce-binding-label-sid-02.txt   draft-ietf-pce-binding-label-sid-03.txt >
PCE Working Group S. Sivabalan PCE Working Group C. Filsfils
Internet-Draft C. Filsfils Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track S. Sivabalan
Expires: September 10, 2020 J. Tantsura Expires: December 24, 2020 Ciena Corporation
J. Tantsura
Apstra, Inc. Apstra, Inc.
J. Hardwick J. Hardwick
Metaswitch Networks Metaswitch Networks
S. Previdi S. Previdi
C. Li C. Li
Huawei Technologies Huawei Technologies
March 9, 2020 June 22, 2020
Carrying Binding Label/Segment-ID in PCE-based Networks. Carrying Binding Label/Segment-ID in PCE-based Networks.
draft-ietf-pce-binding-label-sid-02 draft-ietf-pce-binding-label-sid-03
Abstract Abstract
In order to provide greater scalability, network opacity, and service In order to provide greater scalability, network opacity, and service
independence, Segment Routing (SR) utilizes a Binding Segment independence, Segment Routing (SR) utilizes a Binding Segment
Identifier (BSID). It is possible to associate a BSID to RSVP-TE Identifier (BSID). It is possible to associate a BSID to RSVP-TE
signaled Traffic Engineering Label Switching Path or binding Segment- signaled Traffic Engineering Label Switching Path or binding Segment-
ID (SID) to SR Traffic Engineering path. Such a binding label/SID ID (SID) to SR Traffic Engineering path. Such a binding label/SID
can be used by an upstream node for steering traffic into the can be used by an upstream node for steering traffic into the
appropriate TE path to enforce SR policies. This document proposes appropriate TE path to enforce SR policies. This document proposes
skipping to change at page 2, line 7 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
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
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2020. This Internet-Draft will expire on December 24, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 6, line 34 skipping to change at page 6, line 34
TE-PATH-BINDING TLV is a generic TLV such that it is able to carry TE-PATH-BINDING TLV is a generic TLV such that it is able to carry
MPLS label binding as well as SRv6 Binding SID. It is formatted MPLS label binding as well as SRv6 Binding SID. It is formatted
according to the rules specified in [RFC5440]. according to the rules specified in [RFC5440].
Binding Type (BT): A one byte field identifies the type of binding Binding Type (BT): A one byte field identifies the type of binding
included in the TLV. This document specifies the following BT included in the TLV. This document specifies the following BT
values: values:
o BT = 0: The binding value is an MPLS label carried in the format o BT = 0: The binding value is an MPLS label carried in the format
specified in [RFC5462] where only the label value is valid, and specified in [RFC5462] where only the label value is valid, and
other fields (TC, S, and TTL) fields MUST be considered invalid. other fields fields MUST be considered invalid. The Length MUST
The Length MUST be set to 7. be set to 7.
o BT = 1: Similar to the case where BT is 0 except that all the o BT = 1: Similar to the case where BT is 0 except that all the
fields on the MPLS label entry are set on transmission. However, fields on the MPLS label entry are set on transmission. However,
the receiver MAY choose to override TC, S, and TTL values the receiver MAY choose to override TC, S, and TTL values
according its local policy. The Length MUST be set to 8. according its local policy. The Length MUST be set to 8.
o BT = 2: The binding value is a SRv6 SID with a format of an 16 o BT = 2: The binding value is a SRv6 SID with a format of an 16
byte IPv6 address, representing the binding SID for SRv6. The byte IPv6 address, representing the binding SID for SRv6. The
Length MUST be set to 20. Length MUST be set to 20.
skipping to change at page 8, line 19 skipping to change at page 8, line 19
than the current binding value, it MUST try to allocate the new than the current binding value, it MUST try to allocate the new
value. If the new binding value is successfully allocated, the PCC value. If the new binding value is successfully allocated, the PCC
MUST report the new value to the PCE. Otherwise, it MUST send a MUST report the new value to the PCE. Otherwise, it MUST send a
PCErr message with Error-Type = TBD2 ("Binding label/SID failure") PCErr message with Error-Type = TBD2 ("Binding label/SID failure")
and Error Value = TBD4 ("Unable to allocate the specified label/ and Error Value = TBD4 ("Unable to allocate the specified label/
SID"). SID").
In some cases, a stateful PCE can request the PCC to allocate a In some cases, a stateful PCE can request the PCC to allocate a
binding value. It may do so by sending a PCUpd message containing an binding value. It may do so by sending a PCUpd message containing an
empty TE-PATH-BINDING TLV, i.e., no binding value is specified empty TE-PATH-BINDING TLV, i.e., no binding value is specified
(making the length field of the TLV as 2). A PCE can also make the (making the length field of the TLV as 4). A PCE can also make the
request PCC to allocate a binding at the time of initiation by request PCC to allocate a binding at the time of initiation by
sending a PCInitiate message with an empty TE-PATH-BINDING TLV. sending a PCInitiate message with an empty TE-PATH-BINDING TLV.
5. Binding SID in SR-ERO 5. Binding SID in SR-ERO
In PCEP messages, LSP route information is carried in the Explicit In PCEP messages, LSP route information is carried in the Explicit
Route Object (ERO), which consists of a sequence of subobjects. Route Object (ERO), which consists of a sequence of subobjects.
[RFC8664] defines a new ERO subobject "SR-ERO subobject" capable of [RFC8664] defines a new ERO subobject "SR-ERO subobject" capable of
carrying a SID as well as the identity of the node/adjacency (NAI) carrying a SID as well as the identity of the node/adjacency (NAI)
represented by the SID. The NAI Type (NT) field indicates the type represented by the SID. The NAI Type (NT) field indicates the type
skipping to change at page 12, line 7 skipping to change at page 12, line 7
---------- ------- ---------- -------
TBD2 Binding label/SID failure: TBD2 Binding label/SID failure:
Error-value = TBD3: Invalid SID Error-value = TBD3: Invalid SID
Error-value = TBD4: Unable to allocate Error-value = TBD4: Unable to allocate
the specified the specified
label/SID label/SID
11. Acknowledgements 11. Acknowledgements
We like to thank Milos Fabian for his valuable comments. We like to thank Milos Fabian and Mrinmoy Das for thier valuable
comments.
12. References 12. References
12.1. Normative References 12.1. Normative 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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 13, line 50 skipping to change at page 13, line 50
[RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah,
A., and H. Gredler, "Segment Routing Prefix Segment A., and H. Gredler, "Segment Routing Prefix Segment
Identifier Extensions for BGP", RFC 8669, Identifier Extensions for BGP", RFC 8669,
DOI 10.17487/RFC8669, December 2019, DOI 10.17487/RFC8669, December 2019,
<https://www.rfc-editor.org/info/rfc8669>. <https://www.rfc-editor.org/info/rfc8669>.
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft- P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-06 (work in progress), ietf-spring-segment-routing-policy-07 (work in progress),
December 2019. May 2020.
[I-D.ietf-pce-pcep-extension-for-pce-controller] [I-D.ietf-pce-pcep-extension-for-pce-controller]
Zhao, Q., Li, Z., Negi, M., Peng, S., and C. Zhou, "PCEP Zhao, Q., Li, Z., Negi, M., Peng, S., and C. Zhou, "PCEP
Procedures and Protocol Extensions for Using PCE as a Procedures and Protocol Extensions for Using PCE as a
Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep- Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep-
extension-for-pce-controller-04 (work in progress), March extension-for-pce-controller-04 (work in progress), March
2020. 2020.
[I-D.ietf-pce-pcep-yang] [I-D.ietf-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
skipping to change at page 15, line 16 skipping to change at page 15, line 16
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
Divyashree Techno Park, Whitefield Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066 Bangalore, Karnataka 560066
India India
EMail: dhruv.ietf@gmail.com EMail: dhruv.ietf@gmail.com
Mahendra Singh Negi Mahendra Singh Negi
RtBrick India
N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3
Bangalore, Karnataka 560102
India
EMail: mahend.ietf@gmail.com EMail: mahend.ietf@gmail.com
Authors' Addresses Mike Koldychev
Siva Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario K2K 3E8 Kanata, Ontario K2K 3E8
Canada Canada
EMail: msiva@cisco.com Email: mkoldych@cisco.com
Zafar Ali
Cisco Systems, Inc.
Email: zali@cisco.com
Authors' Addresses
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Pegasus Parc Pegasus Parc
De kleetlaan 6a, DIEGEM BRABANT 1831 De kleetlaan 6a, DIEGEM BRABANT 1831
BELGIUM BELGIUM
EMail: cfilsfil@cisco.com EMail: cfilsfil@cisco.com
Siva Sivabalan
Ciena Corporation
EMail: msiva282@gmail.com
Jeff Tantsura Jeff Tantsura
Apstra, Inc. Apstra, Inc.
EMail: jefftant.ietf@gmail.com EMail: jefftant.ietf@gmail.com
Jonathan Hardwick Jonathan Hardwick
Metaswitch Networks Metaswitch Networks
100 Church Street 100 Church Street
Enfield, Middlesex Enfield, Middlesex
UK UK
 End of changes. 12 change blocks. 
17 lines changed or deleted 32 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/