idnits 2.17.1 draft-vandevelde-spring-flow-aware-v6transport-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 9, 2017) is 2604 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 199, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 205, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-ippm-alt-mark-04 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-flow-ident-04 -- Duplicate reference: RFC6374, mentioned in '6', was also mentioned in '3'. Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group G. Van de Velde, Ed. 3 Internet-Draft Nokia 4 Intended status: Standards Track G. Fioccola, Ed. 5 Expires: September 10, 2017 Telecom Italia 6 P. Muley 7 Nokia 8 March 9, 2017 10 Flow Aware IPv6 Segment Routing 11 draft-vandevelde-spring-flow-aware-v6transport-00 13 Abstract 15 Flow-Aware transport of Pseudowires over an MPLS Packet Switched 16 Network (RFC6391) introduces an ECMP use-case, making assumption that 17 the payload of a pseudowire comprises of a number of distinct flows. 18 RFC6391 provides a mechanism for fine flow granularity beyond the 19 individual pseudowire, helping better flow granularity for ECMP 20 purpose. To identify the granular pseudowire flows the concept of 21 MPLS Flow Label is introduced. Furthermore RFC6391 defines the 22 required LDP protocol extensions to exchange the MPLS Flow Label 23 between LDP speakers. 25 Another method to exchange MPLS flow labels is found in draft-ietf- 26 bess-fat-pw-bgp. Draft-ietf-bess-fat-pw-bgp defines extensions 27 required to synchronise flow label state between PEs using BGP-based 28 signalling procedures. This draft assumes MPLS is the transport 29 technology used. 31 This draft extends the applicability of draft-ietf-bess-fat-pw-bgp 32 and uses the BGP derived flow label for IPv6 Segment Routing 33 transport. The PE responsible for imposing the IPv6 Segment Routing 34 top level header will in addition to an IPv6 header AND the IPv6 35 Source Routing header ALSO impose the BGP derived Flow Label as the 36 IPv6 outer header flow Label. This functionality will provide fine 37 ECMP granularity of IPv6 Segment routing enabled pseudowire transport 38 services. 40 Requirements Language 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC 2119 [1]. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on September 10, 2017. 63 Copyright Notice 65 Copyright (c) 2017 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 82 3. Motivation and Use Case . . . . . . . . . . . . . . . . . . . 4 83 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 84 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 87 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 88 7.2. Informative References . . . . . . . . . . . . . . . . . 5 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 91 1. Introduction 93 The IPv6 Header Format defined in RFC2460 introduces the availability 94 of an 20-bit flow label in the base IPv6 Header. 96 The draft draft-ietf-bess-fat-pw-bgp defines the exchange of a flow 97 label (RFC6391) between two BGP speakers. The application realm in 98 draft-ietf-bess-fat-pw-bgp is MPLS and the embodiment of the 99 exchanged flow label is an additional MPLS Label Stack Entry (LSE) 100 imposed at the Bottom of Stack. 102 The original flow-Aware Transport of pseudowires flow label defined 103 in RFC6391 assumes an MPLS enabled dataplane and did not consider an 104 IPv6 Segment Routing Dataplane. The 20-bit label value exchanged 105 through BGP according draft-ietf-bess-fat-pw-bgp can be used by a PE 106 router imposing the outer IPv6 Segment Routing header upon an ingress 107 packet. The 20-bit Flow-Aware transport for pseudowires flow label 108 is copied into the outer IPv6 header 20-bit IPv6 Flow label header 109 field. Together with the imposed Segment Routing IPv6 Source Routing 110 Header (SRH) the 20-bit value will allow any router within the IPv6 111 segment routing domain use traditional IPv6 hashing ECMP mechanisms 112 with fine granularity for an IPv6 pseudowire transpoort service. 114 An additional benefit is that this technology allows a network 115 management station, having awareness of the flow-aware transport of 116 pseudowires flow labels AND the IPv6 Flow Label imposed upon the IPv6 117 SRv6 packet AND the imposed IPv6 Source Routing packet Header, allows 118 to harvest advanced network wide analytics and passive monitoring 119 data. Indeed the IPv6 source routing header provides exact 120 information about the traffic exchanged between ingress and egress 121 PE, and in addition the IPv6 Flow Label provides the granular 122 awareness of the flows within this aggregate flow. 124 2. Operation 126 Assume the following simple network topology: 128 Source---PE1----SRv6 Network----PE2---Destination 130 Source sends a packet to Destination. The packet on its journey 131 towards Destination is received by PE1. PE1 adds relevant IPv6 132 segment Routing headers to reach Destination by (1) steering the 133 packet through the network towards the egress PE2, and (2) on PE2 134 hand-off the packet into the appropriate (VPLS) service context. In 135 addition, the Flow Aware IPv6 Segment Routing flow label is copied to 136 the transport IPv6 Segment Routing transport header to provide ECMP 137 entropy on more granular level as a single pseudowaire transport 138 tunnel. 140 Routers within the IPv6 Segment Routing network steer the packets 141 from ingress PE1 to egress PE2 as instructed by the imposed SRv6 142 Source Routing Header. However, when a router has multiple equal 143 cost paths available, then ECMP can be used to loadbalance the flows. 144 The information within the IPv6 Segment Routing header including the 145 20-bit flow label field is used for load-balancing purpose. This 146 technology allows load-balancing with fine granular flow 147 identification within a single pseudowire. 149 3. Motivation and Use Case 151 [5] discusses the desired capabilities for MPLS flow identification 152 to implement in-band performance monitoring of user data packets. A 153 method of loss and delay measurement in MPLS networks was defined in 154 RFC6374. But, when used to measure packet loss, RFC6374 depends on 155 the use of the injected OAM packets to designate the beginning and 156 the end of the packet batch over which the measure is done. As 157 described in [6], this method does not work properly in case of 158 packet misordering and the problem can be defeated by the method 159 proposed in [4]. 161 In general, modern networks, if not oversubscribed, normally drop 162 very few packets, thus packet loss measurement is highly sensitive to 163 counter errors. Also, on the other side, it may be useless to assess 164 active performance measurement methods with synthetic traffic. At 165 the same time network operators need to be able to measure the loss, 166 the delay and the delay variation of the actual data traffic by using 167 passive performance measurement methods, because of more demanding 168 service level requirements. 170 Without some form of marking, such as that proposed in [4], it may 171 not be possible to achieve the required accuracy in performance 172 measurement of data traffic. One of the most efficient and 173 straightforward method is the Alternate Marking described in [4]. 174 The solution here proposed extends this passive performance 175 measurement technique in the context of IPv6 Segment Routing network 176 and the application is based on the Ipv6 Flow Label Marking. 178 4. Security Considerations 180 tbc 182 5. Acknowledgements 184 tbc 186 6. IANA Considerations 188 7. References 190 7.1. Normative References 192 [1] Bradner, S., "Key words for use in RFCs to Indicate 193 Requirement Levels", BCP 14, RFC 2119, 194 DOI 10.17487/RFC2119, March 1997, 195 . 197 7.2. Informative References 199 [2] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., 200 Regan, J., and S. Amante, "Flow-Aware Transport of 201 Pseudowires over an MPLS Packet Switched Network", 202 RFC 6391, DOI 10.17487/RFC6391, November 2011, 203 . 205 [3] Frost, D. and S. Bryant, "Packet Loss and Delay 206 Measurement for MPLS Networks", RFC 6374, 207 DOI 10.17487/RFC6374, September 2011, 208 . 210 [4] Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., 211 Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 212 "Alternate Marking method for passive performance 213 monitoring", draft-ietf-ippm-alt-mark-04 (work in 214 progress), March 2017. 216 [5] Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. 217 Mirsky, "MPLS Flow Identification Considerations", draft- 218 ietf-mpls-flow-ident-04 (work in progress), February 2017. 220 [6] Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., 221 Mirsky, G., and G. Fioccola, "RFC6374 Synonymous Flow 222 Labels", October 2016. 224 Authors' Addresses 226 Gunter Van de Velde (editor) 227 Nokia 228 Antwerp 229 BE 231 Email: gunter.van_de_velde@nokia.com 232 Giuseppe Fioccola (editor) 233 Telecom Italia 234 Torino 235 Italy 237 Email: giuseppe.fioccola@telecomitalia.it 239 Praveen Muley 240 Nokia 241 805 E. Middle field road 242 Mountain View, California 94043 243 USA 245 Email: praveen.muley@nokia.com