< draft-li-idr-sr-policy-path-mtu-01.txt   draft-li-idr-sr-policy-path-mtu-02.txt >
Interdomain Routing Working Group C. Li Interdomain Routing Working Group C. Li
Internet-Draft Z. Li Internet-Draft Huawei Technologies
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Y. Zhu
Expires: June 30, 2019 December 27, 2018 Expires: January 2, 2020 China Telecom
Z. Li
Huawei Technologies
July 1, 2019
Segment Routing Path MTU in BGP Segment Routing Path MTU in BGP
draft-li-idr-sr-policy-path-mtu-01 draft-li-idr-sr-policy-path-mtu-02
Abstract Abstract
Segment routing is a source routing paradigm that explicitly Segment Routing is a source routing paradigm that explicitly
indicates the forwarding path for packets at the ingress node. An SR indicates the forwarding path for packets at the ingress node. An SR
policy is a set of candidate SR paths consisting of one or more policy is a set of candidate SR paths consisting of one or more
segment lists with necessary path attributes. However, the path segment lists with necessary path attributes. However, the path
maximum transmission unit (MTU) information for SR path is not maximum transmission unit (MTU) information for SR path is not
available in the SR policy since the SR does not require signaling. available in the SR policy since the SR does not require signaling.
This document defines extensions to BGP to distribute path MTU This document defines extensions to BGP to distribute path MTU
information within SR policies. information within SR policies.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 40
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 June 30, 2019. This Internet-Draft will expire on January 2, 2020.
Copyright Notice Copyright 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
(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
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 20 skipping to change at page 2, line 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. SR Policy for Path MTU . . . . . . . . . . . . . . . . . . . 3 3. SR Policy for Path MTU . . . . . . . . . . . . . . . . . . . 3
3.1. SR Path MTU Sub-TLV . . . . . . . . . . . . . . . . . . . 4 3.1. SR Path MTU Sub-TLV . . . . . . . . . . . . . . . . . . . 4
4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
Segment routing (SR) [RFC8402] is a source routing paradigm that Segment routing (SR) [RFC8402] is a source routing paradigm that
explicitly indicates the forwarding path for packets at the ingress explicitly indicates the forwarding path for packets at the ingress
node. The ingress node steers packets into a specific path according node. The ingress node steers packets into a specific path according
to the Segment Routing Policy ( SR Policy) as defined in to the Segment Routing Policy ( SR Policy) as defined in
[I-D.ietf-spring-segment-routing-policy]. For distributing SR [I-D.ietf-spring-segment-routing-policy]. In order to distribute SR
policies to the headend, [I-D.ietf-idr-segment-routing-te-policy] policies to the headend, [I-D.ietf-idr-segment-routing-te-policy]
specifies a mechanism by using BGP, and new sub-TLVs are defined for specifies a mechanism by using BGP.
SR Policies in BGP UPDATE message.
The maximum transmission unit (MTU) is the largest size packet or The maximum transmission unit (MTU) is the largest size packet or
frame, in bytes, that can be sent in a network. An MTU that is too frame, in bytes, that can be sent in a network. An MTU that is too
large might cause retransmissions. Too small an MTU might cause the large might cause retransmissions. Too small an MTU might cause the
router to send and handle relatively more header overhead and router to send and handle relatively more header overhead and
acknowledgments. When an LSP is created across a set of links with acknowledgments. When an LSP is created across a set of links with
different MTU sizes, the ingress router needs to know what the different MTU sizes, the ingress router needs to know what the
smallest MTU is on the LSP path. If this MTU is larger than the MTU smallest MTU is on the LSP path. If this MTU is larger than the MTU
of one of the intermediate links, traffic might be dropped, because of one of the intermediate links, traffic might be dropped, because
MPLS packets cannot be fragmented. Also, the ingress router may not MPLS packets cannot be fragmented. Also, the ingress router may not
be aware of this type of traffic loss, because the control plane for be aware of this type of traffic loss, because the control plane for
the LSP would still function normally. [RFC3209] specify the the LSP would still function normally. [RFC3209] specify the
mechanism of MTU signaling in RSVP. mechanism of MTU signaling in RSVP. Likewise, SRv6 pakcets will be
dropped if the packet size is larger than path MTU, since IPv6 packet
can not be fragmented on transmission [RFC8200] .
However, the path maximum transmission unit (MTU) information for SR However, the path maximum transmission unit (MTU) information for SR
path is not available since the SR does not require signaling. This path is not available since the SR does not require signaling. This
document defines extensions to BGP to distribute path MTU information document defines extensions to BGP to distribute path MTU information
within SR policies. The MTU information can be obtained via IGP within SR policies. The MTU information can be obtained via IGP
[I-D.hu-lsr-isis-path-mtu], BGP-LS [I-D.zhu-idr-bgp-ls-path-mtu] or [I-D.hu-lsr-isis-path-mtu], BGP-LS [I-D.zhu-idr-bgp-ls-path-mtu] or
some other means. some other means.
2. Terminology 2. Terminology
This memo makes use of the terms defined in [RFC8402] and [RFC3209]. This memo makes use of the terms defined in [RFC8402] and [RFC3209].
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 3, line 23 skipping to change at page 3, line 27
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. SR Policy for Path MTU 3. SR Policy for Path MTU
As defined in [I-D.ietf-idr-segment-routing-te-policy] , the SR As defined in [I-D.ietf-idr-segment-routing-te-policy] , the SR
Policy Encoding structure is as follows: policy encoding structure is as follows:
SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint> SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
Attributes: Attributes:
Tunnel Encaps Attribute (23) Tunnel Encaps Attribute (23)
Tunnel Type: SR Policy Tunnel Type: SR Policy
Binding SID Binding SID
Preference Preference
Priority Priority
Policy Name Policy Name
Explicit NULL Label Policy (ENLP) Explicit NULL Label Policy (ENLP)
Segment List Segment List
Weight Weight
Segment Segment
Segment Segment
... ...
... ...
As introduced in Section 1, each SR path may have a path MTU, an SR As introduced in Section 1, each SR path has it's path MTU. SR
policy carrying a SR path MTU is expressed as below: policy with SR path MTU information is expressed as below:
SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint> SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
Attributes: Attributes:
Tunnel Encaps Attribute (23) Tunnel Encaps Attribute (23)
Tunnel Type: SR Policy Tunnel Type: SR Policy
Binding SID Binding SID
Preference Preference
Priority Priority
Policy Name Policy Name
Explicit NULL Label Policy (ENLP) Explicit NULL Label Policy (ENLP)
Segment List Segment List
Weight Weight
Path MTU Path MTU
Segment Segment
Segment Segment
... ...
... ...
3.1. SR Path MTU Sub-TLV 3.1. SR Path MTU Sub-TLV
This section defines an SR Path MTU sub-TLV, and it is included in
the segment list sub-TLV.
An SR Path MTU sub-TLV is associated with an SR path specified by a An SR Path MTU sub-TLV is associated with an SR path specified by a
segment list sub-TLV or path segment as defined in segment list sub-TLV or path segment as defined in
[I-D.cheng-spring-mpls-path-segment] and [I-D.ietf-spring-mpls-path-segment] and
[I-D.li-spring-srv6-path-segment], and it MUST appear only once [I-D.li-spring-srv6-path-segment], and it MUST appear only once
within a Segment List sub-TLV. It has the following format: within a Segment List sub-TLV. It has the 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 | RESERVED | | Type | Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path MTU | | Path MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Path MTU sub-TLV Figure 1. Path MTU sub-TLV
Where: Where:
Type: to be assigned by IANA (suggested value 11). Type: to be assigned by IANA.
Length: the total length of the value field not including Type and Length: the total length of the value field not including Type and
Length fields. Length fields.
Reserved: 16 bits reserved and MUST be set to 0 on transmission and Reserved: 16 bits reserved and MUST be set to 0 on transmission and
MUST be ignored on receipt. MUST be ignored on receipt.
Path MTU: 4 bytes value of Path MTU. The value can be calculated by Path MTU: 4 bytes value of path MTU in octets. The value can be
a central controller or other devices based on the information that calculated by a central controller or other devices based on the
learned via IGP of BGP-LS or other means. information that learned via IGP of BGP-LS or other means.
Whenever the path MTU of a physical or logical interface is changed, Whenever the path MTU of a physical or logical interface is changed,
a new SR policy with new path MTU information should be updated a new SR policy with new path MTU information should be updated
accordingly by BGP. accordingly by BGP.
4. Operations 4. Operations
The document does not bring new operation beyong the description of The document does not bring new operation beyong the description of
operations defined in [I-D.ietf-idr-segment-routing-te-policy]. The operations defined in [I-D.ietf-idr-segment-routing-te-policy]. The
existing operations defined in existing operations defined in
skipping to change at page 5, line 35 skipping to change at page 5, line 31
will be advertised by BGP update messages. The operation of will be advertised by BGP update messages. The operation of
advertisement is the same as defined in advertisement is the same as defined in
[I-D.ietf-idr-segment-routing-te-policy], as well as the receiption. [I-D.ietf-idr-segment-routing-te-policy], as well as the receiption.
The consumer of the SR policies is not the BGP process. The The consumer of the SR policies is not the BGP process. The
operation of sending information to consumers is out of scope of this operation of sending information to consumers is out of scope of this
document. document.
5. IANA Considerations 5. IANA Considerations
TBA This document defines a new Sub-TLV in registries "SR Policy List
Sub- TLVs" [I-D.ietf-idr-segment-routing-te-policy]:
Value Description Reference
---------------------------------------------------------------------
TBA Path MTU sub-TLV This document
6. Security Considerations 6. Security Considerations
TBA TBA
7. Acknowledgements 7. Acknowledgements
TBA TBA
8. References 8. References
skipping to change at page 5, line 46 skipping to change at page 6, line 4
6. Security Considerations 6. Security Considerations
TBA TBA
7. Acknowledgements 7. Acknowledgements
TBA TBA
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-idr-segment-routing-te-policy] [I-D.ietf-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Jain, D., Mattes, P., Rosen, Previdi, S., Filsfils, C., Jain, D., Mattes, P., Rosen,
E., and S. Lin, "Advertising Segment Routing Policies in E., and S. Lin, "Advertising Segment Routing Policies in
BGP", draft-ietf-idr-segment-routing-te-policy-05 (work in BGP", draft-ietf-idr-segment-routing-te-policy-06 (work in
progress), November 2018. progress), May 2019.
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
bogdanov@google.com, b., and P. Mattes, "Segment Routing bogdanov@google.com, b., and P. Mattes, "Segment Routing
Policy Architecture", draft-ietf-spring-segment-routing- Policy Architecture", draft-ietf-spring-segment-routing-
policy-02 (work in progress), October 2018. policy-03 (work in progress), May 2019.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
8.2. Informative References 8.2. Informative References
[I-D.cheng-spring-mpls-path-segment]
Cheng, W., Wang, L., Li, H., Chen, M., Gandhi, R., Zigler,
R., and S. Zhan, "Path Segment in MPLS Based Segment
Routing Network", draft-cheng-spring-mpls-path-segment-03
(work in progress), October 2018.
[I-D.hu-lsr-isis-path-mtu] [I-D.hu-lsr-isis-path-mtu]
Hu, Z., Zhu, Y., Li, Z., and L. Dai, "IS-IS Extensions for Hu, Z., Zhu, Y., Li, Z., and L. Dai, "IS-IS Extensions for
Path MTU", draft-hu-lsr-isis-path-mtu-00 (work in Path MTU", draft-hu-lsr-isis-path-mtu-00 (work in
progress), June 2018. progress), June 2018.
[I-D.ietf-spring-mpls-path-segment]
Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler,
"Path Segment in MPLS Based Segment Routing Network",
draft-ietf-spring-mpls-path-segment-00 (work in progress),
March 2019.
[I-D.li-spring-srv6-path-segment] [I-D.li-spring-srv6-path-segment]
Li, C., Chen, M., Dhody, D., Li, Z., Dong, J., and R. Li, C., Cheng, W., Chen, M., Dhody, D., Li, Z., Dong, J.,
Gandhi, "Path Segment for SRv6 (Segment Routing in IPv6)", and R. Gandhi, "Path Segment for SRv6 (Segment Routing in
draft-li-spring-srv6-path-segment-00 (work in progress), IPv6)", draft-li-spring-srv6-path-segment-01 (work in
October 2018. progress), June 2019.
[I-D.zhu-idr-bgp-ls-path-mtu] [I-D.zhu-idr-bgp-ls-path-mtu]
Zhu, Y., Hu, Z., Yan, G., and J. Yao, "BGP-LS Extensions Zhu, Y., Hu, Z., Yan, G., and J. Yao, "BGP-LS Extensions
for Advertising Path MTU", draft-zhu-idr-bgp-ls-path- for Advertising Path MTU", draft-zhu-idr-bgp-ls-path-
mtu-00 (work in progress), June 2018. mtu-00 (work in progress), June 2018.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
Authors' Addresses Authors' Addresses
Cheng Li Cheng Li
Huawei Technologies Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd. Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: chengli13@huawei.com Email: chengli13@huawei.com
YongQing Zhu
China Telecom
109, West Zhongshan Road, Tianhe District.
Guangzhou
China
Email: zhuyq.gd@chinatelecom.cn
Zhenbin Li Zhenbin Li
Huawei Technologies Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd. Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: lizhenbin@huawei.com Email: lizhenbin@huawei.com
 End of changes. 25 change blocks. 
39 lines changed or deleted 56 lines changed or added

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