[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-hu-idr-bgp-ls-path-mtu) 00

Network Working Group                                             Y. Zhu
Internet-Draft                                             China Telecom
Intended status: Standards Track                                   Z. Hu
Expires: January 1, 2019                                          G. Yan
                                                                  J. Yao
                                                     Huawei Technologies
                                                           June 30, 2018


               BGP-LS Extensions for Advertising Path MTU
                    draft-zhu-idr-bgp-ls-path-mtu-00

Abstract

   BGP Link State (BGP-LS) describes a mechanism by which link-state and
   TE information can be collected from networks and shared with
   external components using the BGP routing protocol.  The centralized
   controller (PCE/SDN) completes the service path calculation based on
   the information transmitted by the BGP-LS and delivers the result to
   the Path Computation Client (PCC) through the PCEP protocol.

   Segment Routing (SR) leverages the source routing paradigm, which can
   be directly applied to the MPLS architecture with no change on the
   forwarding plane and applied to the IPv6 architecture, with a new
   type of routing header, called SRH.  The SR uses the IGP protocol as
   the control protocol.  Compared to the MPLS tunneling technology, the
   SR does not require signaling.  Therefore, the SR does not support
   the negotiation of the Path MTU.  Since Multiple labels or SRv6 SIDs
   are pushed in the packets, it is more likely that the MTU exceeds the
   limit in the SR tunneling technology.

   This document specify the extension to BGP Link State (BGP-LS) to
   carry maximum transmission unit (MTU) messages.  The PCE/SDN
   calculates the Path MTU while completing the service path calculation
   based on the information transmitted by the BGP-LS.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.





Zhu, et al.              Expires January 1, 2019                [Page 1]


Internet-Draft BGP-LS Extensions for Advertising Path MTU      June 2018


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 1, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Deploying scenarios . . . . . . . . . . . . . . . . . . . . .   4
   3.  BGP_LS Extensions for Path MTU  . . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   [RFC7752]describes the implementation mechanism of BGP-LS by which
   link-state and TE information can be collected from networks and
   shared with external components using the BGP routing protocol
   [RFC4271].  BGP-LS allows the necessary Link-State Database (LSDB)
   and Traffic Engineering Database (TED) information to be collected




Zhu, et al.              Expires January 1, 2019                [Page 2]


Internet-Draft BGP-LS Extensions for Advertising Path MTU      June 2018


   from the IGP within the network, filtered according to configurable
   policy, and distributed to the PCE as necessary.

   The appropriate MTU size guarantees efficient data transmission.  If
   the MTU size is too small and the packet size is large, fragmentation
   may occur too much and packets are discarded by the QoS queue.  If
   the MTU configuration is too large, packet transmission may be slow.
   PathMTU is the maximum length of a packet that can pass through a
   path without fragmentation.  [RFC1191] describes a technique for
   dynamically discovering the maximum transmission unit (MTU) of an
   arbitrary internet path.

   The traditional MPLS tunneling technology has signaling for
   establishing a path.  [RFC3988] defines the mechanism for
   automatically discovering the Path MTU of LSPs of LDP tunnels.  For a
   certain FEC, the LSR compares the MTU advertised by all downstream
   devices with the MTU of the FEC output interface in the local device,
   and calculates the minimum value for the upstream device.

   [RFC3209] specify the mechanism of MTU signaling in RSVP-TE.  The
   ingress node of the RSVP-TE tunnel sends a Path message to the
   downstream device.  The Adspec object in the Path message carries the
   MTU.  Each node along the tunnel receives a Path message, compares
   the MTU value in the Adspec object with the interface MTU value and
   MPLS MTU configured on the physical output interface of the local
   tunnel , obtains the minimum MTU value, and puts it into the newly
   constructed Path message and continues to send it to the downstream
   equipment.  Thus, the MTU carried in the Path message received by the
   Egress node is the minimum value of the path MTU.  The Egress node
   brings the negotiated Path MTU back to the Ingress node through the
   Resv message.

   Segment Routing (SR) described in [I-D.ietf-spring-segment-routing]
   leverages the source routing paradigm.  Segment Routing can be
   directly applied to the MPLS architecture with no change on the
   forwarding plane [I-D.ietf-spring-segment-routing-mpls] and applied
   to the IPv6 architecture with a new type of routing header called the
   SR header (SRH) [I-D.ietf-6man-segment-routing-header].
   [I-D.ietf-idr-bgp-ls-segment-routing-ext] defines SR extensions to
   BGP-LS and specifies the TLVs and sub-TLVs for advertising SR
   information.  Based on the SR information reported by the BGP-LS, the
   SDN can calculate the end-to-end explicit SR-TE paths or SR Policies.

   Nevertheless, Segment Routing is a tunneling technology based on the
   IGP protocol as the control protocol, and there is no signaling for
   establishing the path. so the Segment Routing tunnel cannot currently
   support the negotiation mechanism of the MTU.  Multiple labels or
   SRv6 SIDs are pushed in the packets.  This causes the length of the



Zhu, et al.              Expires January 1, 2019                [Page 3]


Internet-Draft BGP-LS Extensions for Advertising Path MTU      June 2018


   packets encapsulated in the Segment Routing tunnel to increase during
   packet forwarding.  This is more likely to cause MTU overrun than
   traditional MPLS.

   This document specify the extension to BGP Link State (BGP-LS) to
   carry maximum transmission unit (MTU) messages.

2.  Deploying scenarios

   This document suggests a solution to extension to BGP Link State
   (BGP-LS) to carry maximum transmission unit (MTU) messages.  The MTU
   information of the link is acquired through the process of collecting
   link state and TE information by BGP-LS.  Concretely, a router
   maintains one or more databases for storing link-state information
   about nodes and links in any given area.  The router's BGP process
   can retrieve topology from these LSDBs and distribute it to a
   consumer, either directly or via a peer BGP speaker (typically a
   dedicated Route Reflector).  As for how IGP collects link MTU
   information and stores it in LSDB, which is beyond the scope of this
   article.

   As per [RFC7752], the collection of link-state and TE information and
   its distribution to consumers is shown in the following figure.

                              +-----------+
                              | Consumer  |
                              +-----------+
                                    ^
                                    |
                              +-----------+
                              |    BGP    |               +-----------+
                              |  Speaker  |               | Consumer  |
                              +-----------+               +-----------+
                                ^   ^   ^                       ^
                                |   |   |                       |
                +---------------+   |   +-------------------+   |
                |                   |                       |   |
          +-----------+       +-----------+             +-----------+
          |    BGP    |       |    BGP    |             |    BGP    |
          |  Speaker  |       |  Speaker  |    . . .    |  Speaker  |
          +-----------+       +-----------+             +-----------+
                ^                   ^                         ^
                |                   |                         |
               IGP                 IGP                       IGP

              Figure 1: Collection of Link-State and TE Information





Zhu, et al.              Expires January 1, 2019                [Page 4]


Internet-Draft BGP-LS Extensions for Advertising Path MTU      June 2018


3.  BGP_LS Extensions for Path MTU

   [RFC7752] defines the BGP-LS NLRI that can be a Node NLRI, a Link
   NLRI or a Prefix NLRI.  The corresponding BGP-LS attribute is a Node
   Attribute, a Link Attribute or a Prefix Attribute.  [RFC7752] defines
   the TLVs that map link-state information to BGP-LS NLRI and the BGP-
   LS attribute.  Therefore, according to this document, a new sub TLV
   is added to the Link Attribute TLV.

   The format of the sub-TLV is as shown below.


         x  TYPE   - TBD
         x  LENGTH - Total length of the value field, it should be 2
         x  VALUE  - 2-byte MTU value of the link

                              No. of Octets
         +-----------------+
         |    MTU value    |       2
         +-----------------+

                         Figure 2. Sub-TLV Format for MTU


   Whenever there is a change in MTU value represented by Link Attribute
   TLV, BGP-LS should re-originate the respective TLV with the new MTU
   value.

4.  IANA Considerations

   This document requests assigning a new code-points from the BGP-LS
   Link Descriptor and Attribute TLVs registry as specified in sections
   3.

5.  Security Considerations

   This document does not introduce security issues beyond those
   discussed in RFC7752.

6.  Acknowledgements

   The authors of this document would like to thank Gang Yan, Peng Wu,
   Zhenbin Li and Gang Zhao for their comments.








Zhu, et al.              Expires January 1, 2019                [Page 5]


Internet-Draft BGP-LS Extensions for Advertising Path MTU      June 2018


7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

7.2.  Informative References

   [I-D.ietf-6man-segment-routing-header]
              Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
              d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
              (SRH)", draft-ietf-6man-segment-routing-header-14 (work in
              progress), June 2018.

   [I-D.ietf-idr-bgp-ls-segment-routing-ext]
              Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H.,
              and M. Chen, "BGP Link-State extensions for Segment
              Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-08
              (work in progress), May 2018.

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing
              Architecture", draft-ietf-spring-segment-routing-15 (work
              in progress), January 2018.

   [I-D.ietf-spring-segment-routing-mpls]
              Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing with MPLS
              data plane", draft-ietf-spring-segment-routing-mpls-14
              (work in progress), June 2018.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              DOI 10.17487/RFC1191, November 1990,
              <https://www.rfc-editor.org/info/rfc1191>.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <https://www.rfc-editor.org/info/rfc3209>.

   [RFC3988]  Black, B. and K. Kompella, "Maximum Transmission Unit
              Signalling Extensions for the Label Distribution
              Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005,
              <https://www.rfc-editor.org/info/rfc3988>.



Zhu, et al.              Expires January 1, 2019                [Page 6]


Internet-Draft BGP-LS Extensions for Advertising Path MTU      June 2018


   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

   [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,
              <https://www.rfc-editor.org/info/rfc7752>.

Authors' Addresses

   Yongqing Zhu
   China Telecom
   109, West Zhongshan Road, Tianhe District.
   Guangzhou  510000
   China

   Email: zhuyq@gsta.com


   Zhibo Hu
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: huzhibo@huawei.com


   Gang Yan
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: yangang@huawei.com


   Junda Yao
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: yaojunda@huawei.com




Zhu, et al.              Expires January 1, 2019                [Page 7]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/