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

Versions: 00

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,
              <http://www.rfc-editor.org/info/rfc2119>.

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,
              <http://www.rfc-editor.org/info/rfc6391>.

   [3]        Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374,
              DOI 10.17487/RFC6374, September 2011,
              <http://www.rfc-editor.org/info/rfc6374>.

   [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]


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