Maximum Transmission Unit Extended Community for BGP-4
draft-zeng-idr-bgp-mtu-extension-01

Network Working Group                                            Q. Zeng
Internet-Draft                                                   J. Dong
Intended status: Standards Track                     Huawei Technologies
Expires: May 3, 2012                                    October 31, 2011

         Maximum Transmission Unit Extended Community for BGP-4
                  draft-zeng-idr-bgp-mtu-extension-01

Abstract

   Proper functioning of path Maximum Transmission Unit (MTU) discovery
   [RFC1191] requires that IP routers have knowledge of the MTU for each
   link to which they are connected.  As MPLS progresses, [RFC3988]
   specifies extensions to LDP in support of LDP LSP MTU discovery.  For
   the LSP created using Border Gateway Protocol (BGP) [RFC3107], it
   does not have the ability to signal the path MTU to the ingress Label
   Switching Router (LSR).  In the absence of this functionality, the
   MTU for the BGP LSP must be statically configured by network
   operators or by equivalent off-line mechanisms.

   This document defines the MTU Extended Community for BGP in support
   of BGP LSP MTU discovery.

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.

   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 http://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 May 3, 2012.

Copyright Notice

Zeng & Dong                Expires May 3, 2012                  [Page 1]
Internet-Draft      MTU Extended Community for BGP-4        October 2011

   Copyright (c) 2011 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
   (http://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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  BGP LSP MTU Discovery . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4
     3.2.  MTU Extended Community  . . . . . . . . . . . . . . . . . . 4
     3.3.  Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 4
     3.4.  Considerations on Route Flapping  . . . . . . . . . . . . . 5
     3.5.  BGP LSP and LDP LSP Stitching . . . . . . . . . . . . . . . 5
   4.  Applicability Considerations  . . . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7

Zeng & Dong                Expires May 3, 2012                  [Page 2]
Internet-Draft      MTU Extended Community for BGP-4        October 2011

1.  Introduction

   Proper functioning of [RFC1191] path Maximum Transmission Unit (MTU)
   discovery requires that IP routers have knowledge of the MTU for each
   link to which they are connected.  As MPLS progresses, [RFC3988]
   specifies some extensions to LDP in support of LDP LSP MTU discovery.
   For the LSP created using Border Gateway Protocol (BGP) [RFC3107], it
   does not have the ability to signal the path MTU to the ingress Label
   Switching Router (LSR).  Without knowledge of the path MTU of the
   whole BGP LSP, ingress BGP LSRs may transmit packets along that LSP
   which are either too big or too small, thus these packets may either
   be silently discarded by LSRs or be transmitted inefficiently.  In
   the absence of MTU discovery functionality, the MTU for each BGP LSP
   must be statically configured by network operators or by equivalent
   off-line mechanisms.

   This document defines the MTU Extended Community for BGP in support
   of BGP LSP MTU discovery.

2.  Problem Statement

   For some inter-AS services and also for network scalability, the LSPs
   need to be established using Labeled BGP [RFC3107].  Typical
   scenarios include inter-AS VPN Option C, Carrier's Carrier [RFC4364]
   and Seamless MPLS [I-D.ietf-mpls-seamless-mpls].

   Taking "Inter-AS IP VPN Option C" as an example.  An ASBR must
   maintain labeled IPv4 /32 routes to the PE routers within its AS.
   And it uses EBGP to distribute these labeled /32 routes to other ASes
   using mechanism in [RFC3107].  ASBRs in transit ASes will also use
   BGP to pass along the labeled /32 routes.  In the AS of ingress PEs
   (from data plane perspective), the labeled /32 routes can be
   distributed to the PE routers using IBGP.  The /32 routes may also be
   redistributed into IGP of the Ingress AS (from data plane
   perspective).  Intra-AS LSPs between the PE nodes and ASBRs can be
   established using LDP [RFC5036] or RSVP-TE [RFC3209].

   For intra-AS LSPs established using LDP or RSVP-TE, Path MTU of the
   LSP could be discovered using mechanisms defined in [RFC3988] and
   [RFC3209] respectively.  But for the inter-AS LSP which is
   established using BGP, some mechanism is needed to discover the Path
   MTU.

3.  BGP LSP MTU Discovery

Zeng & Dong                Expires May 3, 2012                  [Page 3]
Internet-Draft      MTU Extended Community for BGP-4        October 2011

3.1.  Definitions

   BGP LSP Path MTU: The Path MTU of the LSP from a given BGP LSR to a
   specific prefix.  It is carried as a Extended Community with the BGP
   labeled IPv4 (or IPv6) route.  This size includes the IP header and
   data (or other payload) and the part of the label stack that is
   considered payload of this BGP LSP.

   BGP LSR Link MTU: If the two BGP LSRs are directly adjacent, the BGP
   LSR Link MTU is the interface MTU; If the two BGP LSRs are not
   directly adjacent, the BGP LSR Link MTU is the Path MTU of the
   underlying tunnel.  If there are multiple links between the two BGP
   LSRs, the BGP LSR Link MTU is the minimum of those link MTUs.

3.2.  MTU Extended Community

   BGP LSP Path MTU is carried in the MTU extended community for BGP-4.
   The MTU extended community is an optional transitive attribute.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | MTU extended community Type   |        Reserved               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Reserved              |        MTU Value              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   The MTU extended community type is to be assigned by IANA.  The first
   four octets of the value field should be reserved, and the MTU value
   is carried in the following two octets of the value field.

3.3.  Signaling

   The MTU is advertised hop-by-hop from BGP egress LSR to BGP ingress
   LSR along an BGP LSP.  The steps are as follows:

   A. If BGP speaker A is the originator of the labeled BGP route, and
   there is a intra-AS LSP to the prefix, A SHOULD set its BGP LSP Path
   MTU to the path MTU value it has discovered to this prefix, and
   advertise the labeled BGP route with the MTU Extended Community to
   its BGP Peer (its upstream BGP LSR).  If the prefix belongs to BGP
   speaker A, the BGP LSP Path MTU SHOULD be set to 65535.

   B. BGP speaker B receives the labeled BGP route with BGP LSP Path MTU
   from its BGP peer.

   a) B SHOULD compute the BGP LSR Link MTU to the Next Hop of the
   received message, then sets its BGP LSP Path MTU to the minimum of
   the received BGP LSP Path MTU and (the BGP LSR Link MTU - 4 octets).

Zeng & Dong                Expires May 3, 2012                  [Page 4]
Internet-Draft      MTU Extended Community for BGP-4        October 2011

   b).  If B distributes the route with the Next Hop attribute
   unchanged, it MUST keep the MTU Extended Community unchanged when
   advertising the message to its upstream BGP LSRs.

   c).  If B would change the Next Hop attribute to itself in the
   subsequent advertisement, it SHOULD set the MTU Extended Community in
   the message with its BGP LSP Path MTU obtained through step a).

3.4.  Considerations on Route Flapping

   Normally change of BGP path attributes would result in advertising a
   BGP update for the route.  In order to throttle the route updates
   caused by changes of BGP path MTU , this section specifies rules of
   route update when BGP LSP Path MTU changes:

   1.  If the BGP LSP Path MTU decreases, a new update SHOULD be
   advertised immediately;

   2.  If the BGP LSP Path MTU increases, the BGP speaker MAY hold down
   the update until there are changes of some other BGP attributes.

3.5.  BGP LSP and LDP LSP Stitching

   In scenarios where the labeled BGP routes are redistributed into IGP
   on a border router and an LDP LSP is established and stitched to the
   BGP LSP, the border router SHOULD use its BGP path MTU as the LDP LSP
   MTU, and the path MTU discovery of the LDP LSP will be performed
   according to [RFC3988].

4.  Applicability Considerations

   The BGP MTU Extended Community is applicable to labeled BGP defined
   in [RFC3107].  The application of BGP MTU Discovery may also be used
   for other inter-AS/inter-area routing scenarios.  Such use cases are
   for further study.

5.  IANA Considerations

   IANA is requested to assign a type and sub-type value for BGP MTU
   extended community.

6.  Security Considerations

   This extension to BGP does not change the underlying security issues
   in [RFC4271].

Zeng & Dong                Expires May 3, 2012                  [Page 5]
Internet-Draft      MTU Extended Community for BGP-4        October 2011

7.  Contributors

   The following individuals contributed to this document:

   Haibo Wang rainsword.wang@huawei.com

   Haijun Xu xuhaijun@huawei.com

8.  Acknowledgements

   The authors would like to thank Jeff Haas, Nagendra Kumar and David
   Freedman for their valuable discussions and suggestions.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3107]  Rekhter, Y. and E. Rosen, "Carrying Label Information in
              BGP-4", RFC 3107, May 2001.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, February 2006.

9.2.  Informative References

   [I-D.ietf-mpls-seamless-mpls]
              Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
              M., and D. Steinberg, "Seamless MPLS Architecture",
              draft-ietf-mpls-seamless-mpls-00 (work in progress),
              May 2011.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

   [RFC3988]  Black, B. and K. Kompella, "Maximum Transmission Unit
              Signalling Extensions for the Label Distribution

Zeng & Dong                Expires May 3, 2012                  [Page 6]
Internet-Draft      MTU Extended Community for BGP-4        October 2011

              Protocol", RFC 3988, January 2005.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, February 2006.

   [RFC4659]  De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
              "BGP-MPLS IP Virtual Private Network (VPN) Extension for
              IPv6 VPN", RFC 4659, September 2006.

Authors' Addresses

   Qing Zeng
   Huawei Technologies
   Huawei Building, No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: zengqing@huawei.com

   Jie Dong
   Huawei Technologies
   Huawei Building, No.156 Beiqing Rd.
   Beijing  100095
   China

   Email: jie.dong@huawei.com

Zeng & Dong                Expires May 3, 2012                  [Page 7]