rtgwg Vic. Liu Internet-Draft China Mobile Intended status: Informational July 15, 2013 Expires: January 16, 2014 Probelm Statement for MTU Configuration draft-liu-rtgwg-mtu-config-ps-00 Abstract This document describes problem statement of MTU configuration IP and MPLS network along with the test case and result in multi-vendor network. Necessary considerations and recommendation are also discussed. 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 January 16, 2014. Copyright Notice Copyright (c) 2013 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. Liu Expires January 16, 2014 [Page 1] Internet-Draft draft-liu-rtgwg-mtu-config-ps-00 July 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 4.1. ISIS negotiations and configuration . . . . . . . . . . . 3 4.2. MPLS MTU configuration . . . . . . . . . . . . . . . . . 4 5. Test on MTU configuration . . . . . . . . . . . . . . . . . . 4 5.1. Basic test description . . . . . . . . . . . . . . . . . 4 5.2. Test result and analysis . . . . . . . . . . . . . . . . 7 6. Considerations and recommendations . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. Informative References . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction MTU for Jumbo frames is needed in practical network, This document describes a test on MTU configuration based on IS-IS and MPLS protocol with routers from different vendors. By test of upgrading MTU from 1500 to 4470 in multi-vendor network, we bring up a problem statement of MTU configuration that measure ISIS negotiation. With the discussion, necessary considerations and recommendation are also discussed. 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 [RFC2119]. 2. Terminology Throughout this document, the use of the terms "Provider Edge (PE) and Customer Edge (CE)" or "PE/CE" will be replaced by "PE" in all cases except when a network device is a CE when used in the carrier's carrier model. 3. Requirements This section briefly describes enterprise customers and operational requirement on network MTU configuration along with a list of problems on MTU configuration over multi-vendor equipment. The MTU default configuration is 1500 in China Mobile backbone network. However some enterprise customers requested that IP datagram's up to a length of 1600 bytes (including the IP header, Liu Expires January 16, 2014 [Page 2] Internet-Draft draft-liu-rtgwg-mtu-config-ps-00 July 2013 aka. baby giant) must not be fragmented in the supplier's network (from CE to CE). The receiving sequence of data packets at the destination location must match the sending sequence at the source location. Besides, from the network operational point of view, TD- LTE network also has the MTU requirement. As the CE connect to eNodeB with packet of 1500. It will be jumbo frame in S1-U port(GTP header will be added). To avoid fragment from CE to CE, it required MTU to support IP datagrams length of 1600 bytes at least. In above, we decided to upgrade MTU from 1500 to 4470(same as POS MTU) in the backbone routers. In the rest of this draft, we are introduce a multi-vender test on MTU from 1500 to 4470 in IP networks and MPLS-VPN networks along with problem statement during this configuration. 4. Problem statement This section list a number of problems we met during configure MTU from 1500 to 4470 in IP networks and MPLS-VPN networks with routers from different vendors. 4.1. ISIS negotiations and configuration In IP networks, we tested routers from 4 vendors, indicated as A, B, C and D as the rest of the draft. As all the four router being configure to 4470. The ISIS protocol status is listed as table 1 below. ISIS negotiation appears 'Init' as MTU being configured to 4470 across 4 routers from different vendors. +------------+-----------+------------+ | Router 1 | Router 2 | ISIS status| +------------+-----------+------------+ | A | B | UP | +------------+-----------+------------+ | B | C | Init | +------------+-----------+------------+ | C | D | UP | +------------+-----------+------------+ | D | A | Init | +------------+-----------+------------+ | B | D | Init | +------------+-----------+------------+ | A | C | Init | +------------+-----------+------------+ Table 1 Probelm of ISIS negotiation status Liu Expires January 16, 2014 [Page 3] Internet-Draft draft-liu-rtgwg-mtu-config-ps-00 July 2013 4.2. MPLS MTU configuration In MPLS networks, we figure out that the MPLS diagrams should be calculate to MTU configuration. However, as we configured and add 2 MPLS labels (8 bytes) to MTU in this 4 router. We captured fragments on some pairs among 4 routers. 5. Test on MTU configuration This section introduction test on MTU configuration in IP networks and MPLS networks based on multi-vendor devices. 5.1. Basic test description This test contain 3 test cases: Fist we configured MTU from 1500 to 4470 in IP network to test ISIS status on 4 routers from different routers. To reproduce this problem introduced on 3.1. Then, based on the test result, we establish MPLS network to test how MPLS MTU cause that problem in 3.2. Finally, we set up a network hybrid with IP and MPLS to test the performance of MTU configurations. Test equipment are from 4 different vendors indicated as A, B, C and D in the following parts of discussion. TC1: Test of ISIS MTU. The basic topology of ISIS MTU testing can be depicted as follows. +---------+ +---------+ | Router1 |-----------| Router2 | +---------+ 10GE +---------+ | | 10GE | 10GE | VLAN | VLAN | Port1 | Port2 | +---------------------------+ | Tester | +---------------------------+ Figure 1 Basic topology for ISIS MTU testing As figure 1 shows, two routers connect with each other by a 10GE link. Each router connect to the tester by a 10GE link. The tester generates unidirectional/bidirectional traffic between port 1 and port 2 with the traffic load of 10G. The frame length generate by tester is equals to the desired MTU parameter, 4470. We configure Liu Expires January 16, 2014 [Page 4] Internet-Draft draft-liu-rtgwg-mtu-config-ps-00 July 2013 MTU parameter on router 1 from 1500 to 4470 and check the ISIS protocol status and then configure the MTU parameter on router 2 from 1500 to 4470 and check ISIS protocol status again to make sure the ISIS status is up. If ISIS is not up, we increase MTU on one side until the ISIS status is up. As ISIS is established, we inject the traffic from the tester and capture the packet on port 1 and port 2 to check if there is a fragment on the packet. The routers from 4 vendors are being tested as the sequence table below. +------------+-----------+ | Router1 | Router2 | +------------+-----------+ | A | B | +------------+-----------+ | B | C | +------------+-----------+ | C | D | +------------+-----------+ | D | A | +------------+-----------+ | B | D | +------------+-----------+ | A | C | +------------+-----------+ Table 2 TC1 test sequence table TC2: The test topology of MPLS-VPN test can be depicted as follows. +---------+ MPLS +---------+ MPLS +---------+ | Router1 |-----------| Router2 |-----------| Router3 | +---------+ 10GE +---------+ 10GE +---------+ | | |10GE |10GE |VLAN |VLAN | | | Port1 +---------------------------+ Port2 | -------| Tester |------- +---------------------------+ Figure 2 Basic topology for MPLS-VPN MTU testing Liu Expires January 16, 2014 [Page 5] Internet-Draft draft-liu-rtgwg-mtu-config-ps-00 July 2013 As figure 2 shows, there are 3 routers form 4 different vendors to build a MPLS network which Router1, Router3 take part as LER, Router 2 as LSR. VLAN are been established between PE and Tester. The whole network connect by 10GE link as the figure shows. The tester generates unidirectional/bidirectional traffic between port 1 and port 2 with the traffic load of 10G. While MTU parameter is set as the ISIS MTU test of each vendors. And the tester generate traffic with the packet length of 4474(4474+4 bit VLAN tag). We capture packet on tester's port1 and port2 to check if there is a fragment packet. If there is, we increase one of the router's MTU parameter and capture again. The routers from 4 vendors are being tested as the sequence table below. +------------+-----------+------------+ | Router1 | Router2 | Router3 | +------------+-----------+------------+ | B | A | C | +------------+-----------+------------+ | A | B | C | +------------+-----------+------------+ | B | C | D | +------------+-----------+------------+ | A | D | D | +------------+-----------+------------+ Table 3 TC2 test sequence table TC.3 MTU performance test This test case mainly test the performance on IP and MPLS networks. The topology can be depicted as below VLAN +---------+ MPLS ===========|B:Router1|================ || IP +---------+ IP || || || || || MPLS || IP || || || || || +---------+ MPLS +---------+ || |A:Router2|===========|D:Router3| || +---------+ IP +---------+ || || || || MPLS || IP MPLS || IP || || || Liu Expires January 16, 2014 [Page 6] Internet-Draft draft-liu-rtgwg-mtu-config-ps-00 July 2013 || +---------+ MPLS +---------+ || |C:Router4|===========|A:Router5| || +---------+ IP +---------+ || VLAN || IP VLAN || IP || Port3||Port4 Port5||Port6 || Port1 +---------------------------+ ============| Tester | Port2 +---------------------------+ Figure 3 Basic topology for MTU performance test As figure 3 shows, there are 5 routers to setup 4 vendor network with both MPLS and IP traffic. Router1, Router4 and Router5 act as PE while Router2 takes part as RR and Router3 as P. The whole network is being connect by 10GE links. The Tester connect with PE by two links while one is for VLAN traffic and other is for IP traffic. PE connect with RR and P also using two links. One is for MPLS traffic and other is for IP traffic. All ports on tester generate traffic load of 10GE with random frame length (minimum 64, MAX is equal to MTU of PE). The MTU parameter of routers on each port is set as the result in TC1 and TC2. This test case is to check the performance of latency and packet dropping rate with 24 hours. 5.2. Test result and analysis This section introduce test report of MTU configuration workable in IP network and MPLS networks. A. Report of MTU configure in IP network based on multi-vendor routers. In test case 1, ISIS MTU test. We firstly set all configure MTU to 4470 and we get the ISIS establish status as this table below +---------------------------------------+ | | A | B | C | D | +-------+-------+-------+-------+-------+ | A | \ | \ | \ | \ | +-------+-------+-------+-------+-------+ | B | UP | \ | \ | \ | +-------+-------+-------+-------+-------+ | C | Init | Init | \ | \ | +-------+-------+-------+-------+-------+ | D | Init | Init | UP | \ | +-------+-------+-------+-------+-------+ Liu Expires January 16, 2014 [Page 7] Internet-Draft draft-liu-rtgwg-mtu-config-ps-00 July 2013 Table 4 ISIS status with equal MTU By analyze the IP diagram figure below. We figure out the router of vendor A and vendor B is being configure based on L3 MTU which means the MTU parameter equals to L3 diagram length, 4470. And Vendor C and Vendor D is being configure based on L2 MTU which means the MTU configure parameter equals to L2 diagram length(without FCS), 4488 |---------------------L2---------------------| |--------L3--------| +------------+------+-----------+------+-----+ | Eth Header | VLAN | IP header | Data | FCS | +------------+------+-----------+------+-----+ Length: 14 | 4 | 20 | 4450 | 4 Figure 4 IP diagram We find out the minimum MTU configuration parameter that allow ISIS to establish as the table below: +--------+---------------+------------+ | Vendor | MTU | Configure | +--------+---------------+------------+ | A | 4470 | L3 MTU | +--------+---------------+------------+ | B | 4470 | L3 MTU | +--------+---------------+------------+ | C | 4484+4(VLAN) | L2 MTU | +--------+---------------+------------+ | D | 4484+4(VLAN) | L2 MTU | +--------+---------------+------------+ Table 5 ISIS status with equal MTU VLAN tag configuration in vendor A and vendor B is not counted in the MTU configuration. However, in vendor C and vendor D, because of its L2 MTU, so we have to count every tag in the IP diagram. B. ISIS MTU negotiation test result between routers from different vendors. Liu Expires January 16, 2014 [Page 8] Internet-Draft draft-liu-rtgwg-mtu-config-ps-00 July 2013 As test case 1, we modified the MTU from 1500 to 4470 on one side to another to test ISIS establish status as the table blow. (With 1 VLAN tag) +---------+--------+---------+---------+---------+ | | A:4470 | B:4470 | C:4488 | D:4488 | +---------+--------+---------+---------+---------+ | B:1500 | \ | Init | UP | UP | +---------+--------+---------+---------+---------+ | B:1500 | Init | \ | UP | UP | +---------+--------+---------+---------+---------+ | C:1518 | Init | Init | \ | UP | +---------+--------+---------+---------+---------+ | D:1518 | Init | Init | UP | \ | +---------+--------+---------+---------+---------+ Table 6 MTU measurement of ISIS UP/Init status By capture the packet from the ports on the tester and analysis of this result table, the negotiation method from vendor A and vendor B is strict to its MTU. However the Vendor C and vendor D is check MTU with the other side. C. MTU influence on the MPLS with multi-vendor router. In test case 2, we test MTU configuration on multi-vendor routers in MPLS-VPN networks. The MPLS diagram can be figure as figure 5 |---------------------L2---------------------| |--------L3--------| +------------+------+-----------+------+-----+ | Eth Header | MPLS | IP header | Data | FCS | +------------+------+-----------+------+-----+ Length: 14 | ? | 20 | 4450 | 4 Figure 5 MPLS diagram The ? marker can be explained as the MPLS frame length depends on how many labels used in this network. In our test models, the default MPLS labels is two(8 bits). As we configure the MTU 4470L3 on Vendor A and B (4484 L2 on Vendor C and D) on all of the fours router. We capture the packet from the tester's receiver ports and find Liu Expires January 16, 2014 [Page 9] Internet-Draft draft-liu-rtgwg-mtu-config-ps-00 July 2013 fragment. As we used two Vendor A's router with one Vendors B's router to build a MPLS network A-B-A and set the MTU parameter as 4470. There is no fragment. As the MTU is L2 MTU on vendor C and vendor D. We add two MPLS labels in C's and D's MTU but is still have fragment. As we increase C's and D's MTU. We get the result as: +-----+------------+-------------------------------+ | A | 4470+8 | Add 2 MPLS labels | +-----+------------+-------------------------------+ | B | 4470+8 | Add 2 MPLS labels | +-----+------------+-------------------------------+ | C | 4484+20 | Default is 5 MPLS labels | | | | and cannot modify | +-----+------------+-------------------------------+ | D | 4484+12 | Default is 3 MPLS labels | | | | and can modify manually | +-----+------------+-------------------------------+ Table 7 MPLS MTU configuraton of different verndors 6. Considerations and recommendations In this section, we summarize the analysis and come to the following considerations: a.Unified IP MTU negotiations should be taken into consideration. As we know from the test. The MTU configuration can be divided into two kinds, some vendor configure MTU based on L2 IP diagram, Vlan tag is not counted into MTU configuration. However some vendor configure MTU by L3 diagram which means MTU configuration should count in all diagram length. That will make confuse multi-vender in networking operation. b.Unified MPLS MTU configuration. In MPLS-VPN network, MPLS label should be calculate in MTU configuration. However, in multi-vendors networks, there is no standardization to make a unified MPLS MTU configuration. Vendors such as A and B, It add MPLS labels manually as configured. Vendor C add 5 fixed labels. Vendor D add 3 fixed label. If the MPLS label is not unified in MTU configuration, it will cause fragment in network operation. c.Unified default MTU negotiation. Vendor A and Vendor B is compare MTU by a strict mode in MTU negotiation that MTU in both side should be equal to establish ISIS. However Vendor C and Vendor D compare Liu Expires January 16, 2014 [Page 10] Internet-Draft draft-liu-rtgwg-mtu-config-ps-00 July 2013 MTU by a loose mode in MTU negotiation that ISIS is established by Minimum MTU of one side. Although it easier to for MTU negotiation, it's much easier to cause fragments for multi-vendor networking operations. With the consideration above, we summarize recommendations follows: We test MTU configuration in IP network and MPLS network with routers from different vendors. The variety forms of MTU configuration trigger fragment easily in multi-vender networks. However, in order to make network operation easier, we hope to bring out this problem statement for all vender to standardize the MTU configuration in IP network and MPLS network. Meantime, we want to write an operation guideline to open the test result to declare the problem and guide others in MTU configurations. 7. Acknowledgements 8. IANA Considerations The IANA has assigned { mplsStdMIB 11 } to the MPLS-L3VPN-STD-MIB module specified in [RFC 4362]. This document only makes extensions to the MPLS-L3VPN-STD-MIB module, there is no further IANA requirement. 9. Security Considerations No specific security issues with the proposed solutions are known. The proposed extension in this document does not introduce any new security considerations beyond that already apply to the base MPLS/ BGP L3VPN specification as [RFC 3031] and [RFC 4364]. 10. Informative References [RFC1981] McCann, J., "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC4821] Mathis, M., "Packetization Layer Path MTU Discovery", RFC 4821, March 2007. Author's Address Vic Liu China Mobile Email: LiuZhiheng@chinamobile.com Liu Expires January 16, 2014 [Page 11]