SPRING Working Group G. Van de Velde, Ed. Internet-Draft Nokia Intended status: Standards Track G. Fioccola, Ed. Expires: September 10, 2017 Telecom Italia P. Muley Nokia March 9, 2017 Flow Aware IPv6 Segment Routing draft-vandevelde-spring-flow-aware-v6transport-00 Abstract Flow-Aware transport of Pseudowires over an MPLS Packet Switched Network (RFC6391) introduces an ECMP use-case, making assumption that the payload of a pseudowire comprises of a number of distinct flows. RFC6391 provides a mechanism for fine flow granularity beyond the individual pseudowire, helping better flow granularity for ECMP purpose. To identify the granular pseudowire flows the concept of MPLS Flow Label is introduced. Furthermore RFC6391 defines the required LDP protocol extensions to exchange the MPLS Flow Label between LDP speakers. Another method to exchange MPLS flow labels is found in draft-ietf- bess-fat-pw-bgp. Draft-ietf-bess-fat-pw-bgp defines extensions required to synchronise flow label state between PEs using BGP-based signalling procedures. This draft assumes MPLS is the transport technology used. This draft extends the applicability of draft-ietf-bess-fat-pw-bgp and uses the BGP derived flow label for IPv6 Segment Routing transport. The PE responsible for imposing the IPv6 Segment Routing top level header will in addition to an IPv6 header AND the IPv6 Source Routing header ALSO impose the BGP derived Flow Label as the IPv6 outer header flow Label. This functionality will provide fine ECMP granularity of IPv6 Segment routing enabled pseudowire transport services. 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 [1]. Van de Velde, et al. Expires September 10, 2017 [Page 1] Internet-Draft Flow Aware IPv6 Segment Routing March 2017 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 September 10, 2017. Copyright Notice Copyright (c) 2017 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. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation and Use Case . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 Van de Velde, et al. Expires September 10, 2017 [Page 2] Internet-Draft Flow Aware IPv6 Segment Routing March 2017 1. Introduction The IPv6 Header Format defined in RFC2460 introduces the availability of an 20-bit flow label in the base IPv6 Header. The draft draft-ietf-bess-fat-pw-bgp defines the exchange of a flow label (RFC6391) between two BGP speakers. The application realm in draft-ietf-bess-fat-pw-bgp is MPLS and the embodiment of the exchanged flow label is an additional MPLS Label Stack Entry (LSE) imposed at the Bottom of Stack. The original flow-Aware Transport of pseudowires flow label defined in RFC6391 assumes an MPLS enabled dataplane and did not consider an IPv6 Segment Routing Dataplane. The 20-bit label value exchanged through BGP according draft-ietf-bess-fat-pw-bgp can be used by a PE router imposing the outer IPv6 Segment Routing header upon an ingress packet. The 20-bit Flow-Aware transport for pseudowires flow label is copied into the outer IPv6 header 20-bit IPv6 Flow label header field. Together with the imposed Segment Routing IPv6 Source Routing Header (SRH) the 20-bit value will allow any router within the IPv6 segment routing domain use traditional IPv6 hashing ECMP mechanisms with fine granularity for an IPv6 pseudowire transpoort service. An additional benefit is that this technology allows a network management station, having awareness of the flow-aware transport of pseudowires flow labels AND the IPv6 Flow Label imposed upon the IPv6 SRv6 packet AND the imposed IPv6 Source Routing packet Header, allows to harvest advanced network wide analytics and passive monitoring data. Indeed the IPv6 source routing header provides exact information about the traffic exchanged between ingress and egress PE, and in addition the IPv6 Flow Label provides the granular awareness of the flows within this aggregate flow. 2. Operation Assume the following simple network topology: Source---PE1----SRv6 Network----PE2---Destination Source sends a packet to Destination. The packet on its journey towards Destination is received by PE1. PE1 adds relevant IPv6 segment Routing headers to reach Destination by (1) steering the packet through the network towards the egress PE2, and (2) on PE2 hand-off the packet into the appropriate (VPLS) service context. In addition, the Flow Aware IPv6 Segment Routing flow label is copied to the transport IPv6 Segment Routing transport header to provide ECMP entropy on more granular level as a single pseudowaire transport tunnel. Van de Velde, et al. Expires September 10, 2017 [Page 3] Internet-Draft Flow Aware IPv6 Segment Routing March 2017 Routers within the IPv6 Segment Routing network steer the packets from ingress PE1 to egress PE2 as instructed by the imposed SRv6 Source Routing Header. However, when a router has multiple equal cost paths available, then ECMP can be used to loadbalance the flows. The information within the IPv6 Segment Routing header including the 20-bit flow label field is used for load-balancing purpose. This technology allows load-balancing with fine granular flow identification within a single pseudowire. 3. Motivation and Use Case [5] discusses the desired capabilities for MPLS flow identification to implement in-band performance monitoring of user data packets. A method of loss and delay measurement in MPLS networks was defined in RFC6374. But, when used to measure packet loss, RFC6374 depends on the use of the injected OAM packets to designate the beginning and the end of the packet batch over which the measure is done. As described in [6], this method does not work properly in case of packet misordering and the problem can be defeated by the method proposed in [4]. In general, modern networks, if not oversubscribed, normally drop very few packets, thus packet loss measurement is highly sensitive to counter errors. Also, on the other side, it may be useless to assess active performance measurement methods with synthetic traffic. At the same time network operators need to be able to measure the loss, the delay and the delay variation of the actual data traffic by using passive performance measurement methods, because of more demanding service level requirements. Without some form of marking, such as that proposed in [4], it may not be possible to achieve the required accuracy in performance measurement of data traffic. One of the most efficient and straightforward method is the Alternate Marking described in [4]. The solution here proposed extends this passive performance measurement technique in the context of IPv6 Segment Routing network and the application is based on the Ipv6 Flow Label Marking. 4. Security Considerations tbc 5. Acknowledgements tbc Van de Velde, et al. Expires September 10, 2017 [Page 4] Internet-Draft Flow Aware IPv6 Segment Routing March 2017 6. IANA Considerations 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 7.2. Informative References [2] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, DOI 10.17487/RFC6391, November 2011, . [3] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, . [4] Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, "Alternate Marking method for passive performance monitoring", draft-ietf-ippm-alt-mark-04 (work in progress), March 2017. [5] Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. Mirsky, "MPLS Flow Identification Considerations", draft- ietf-mpls-flow-ident-04 (work in progress), February 2017. [6] Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., Mirsky, G., and G. Fioccola, "RFC6374 Synonymous Flow Labels", October 2016. Authors' Addresses Gunter Van de Velde (editor) Nokia Antwerp BE Email: gunter.van_de_velde@nokia.com Van de Velde, et al. Expires September 10, 2017 [Page 5] Internet-Draft Flow Aware IPv6 Segment Routing March 2017 Giuseppe Fioccola (editor) Telecom Italia Torino Italy Email: giuseppe.fioccola@telecomitalia.it Praveen Muley Nokia 805 E. Middle field road Mountain View, California 94043 USA Email: praveen.muley@nokia.com Van de Velde, et al. Expires September 10, 2017 [Page 6]