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

Versions: 00

TEAS                                                       L. Huang, Ed.
Internet-Draft                                              China Mobile
Intended status: Standards Track                                 A. Wang
Expires: January 17, 2018                                  China Telecom
                                                           July 16, 2017


              BGP community based PCE in native IP network
                 draft-huang-teas-bgp-community-pce-00

Abstract

   This document describes a BGP community based method to steer traffic
   under the PCE architecture in the native IP network.

Status of This Memo

   This Internet-Draft is submitted to IETF 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 17, 2018.

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.








Huang & Wang            Expires January 17, 2018                [Page 1]


Internet-Draft         huang-bgp-community-pce-00              July 2017


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology and Abbreviations . . . . . . . . . . . . . . . .   2
   3.  Machanism . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   4

1.  Introduction

   In the draft [I-D.wang-teas-pce-native-ip], the scenario for TE in
   native IP network is described and a dual/multi-BGP sessions solution
   is proposed to meet the TE requirements.  This document is for the
   same scenario and requirements as [I-D.wang-teas-pce-native-ip],
   however, a BGP community based method is used for steering traffic
   instead of dual/multi-BGP sessions.

2.  Terminology and Abbreviations

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

3.  Machanism

   To differentiate traffics with various priority, BGP community is
   used to classify route prefixes.  Assign a specific next-hop address
   for a specific BGP community which could be done by BGP route policy.
   Then through controling the path for a specific next-hop address we
   can steer the related traffic.

   The following is an example with a simple topology:

















Huang & Wang            Expires January 17, 2018                [Page 2]


Internet-Draft         huang-bgp-community-pce-00              July 2017


              BGP                                         BGP

               |              For IP12 -- IP22             |
           lo1 +- - - - - - - - - - - - - - - - - - - - - -+ lo1
               |                                           |

               |                                           |

               |                                           |
                              For IP11 -- IP21
           lo0 +- - - - - - - - - - - - - - - - - - - - - -+ lo0

               |                                           |

               |             -----------------             |
                       //////     Path-1      \\\\\\
           +---+--+ ///                             \\\ +--+---+
    IP12---+      ||                                   ||      +---IP22
           |  R1  |                                     |  R2  |
    IP11---+      ||                                   ||      +---IP21
           +------+ \\\                             /// +------+
                       \\\\\\     Path-2      //////
                             -----------------


                 Figure 1: A simple topology as an example

   In this topology, assume traffic between IP11 and IP21 is normal
   traffic, traffic between IP12 and IP22 is high priority.  The
   following procedures can fulfill the differentiated traffic steering:

   (1) On R1, assign BGP community 100:100 for IP11 and 100:200 for
   IP12.  On R2, assign BGP community 100:100 for IP21 and 100:200 for
   IP22.

   (2) On R1, use BGP route policy to set the next-hop as lo0 for
   prefixes with community 100:100 and lo1 for prefixes with community
   100:200.  Make the same configuration on R2.

   (3) On R1, set an explicit route to R2's lo0 through path-1 and
   another explicit route to R2's lo1 through path-2.  On R2, set an
   explicit route to R1's lo0 through path-1 and another explicit route
   to R1's lo1 through path-2.

   Through the above procedures traffic with different priority can be
   steered to appointed path as needed.  More BGP communities and
   loopback interfaces/addresses can be created for more traffic classes
   in a more complex enviroment.



Huang & Wang            Expires January 17, 2018                [Page 3]


Internet-Draft         huang-bgp-community-pce-00              July 2017


   In a PCE enabled network, the above procedures can be fulfilled in a
   automated way.  PCE can set the binding of BGP community and route
   prefixes, BGP community and next-hops/loopback addresses.  PCE can
   change the BGP community for specific prefixes to steer the related
   traffic to a different priority/path.  PCE also can set explicit
   route hop by hop for a specific next-hop/loopback address to steer
   the related traffic as needed.  In addition, PCEP need to be extended
   to transfer the necessary parameters, such as BGP communities, next-
   hop/loopback addresses, related route prefixes and explicit route for
   a specific next-hop.  How to extend PCEP is out of this document's
   scope.

4.  Security Considerations

5.  IANA Considerations

6.  Normative References

   [I-D.wang-teas-pce-native-ip]
              Wang, A., Zhao, Q., Khasanov, B., Mi, K., Mallya, R., and
              S. Peng, "PCE in Native IP Network", draft-wang-teas-pce-
              native-ip-03 (work in progress), March 2017.

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

Authors' Addresses

   Lu Huang (editor)
   China Mobile
   32 Xuanwumen West Ave, Xicheng District
   Beijing  100053
   China

   Email: hlisname@yahoo.com


   Aijun Wang
   China Telecom
   Beiqijia Town, Changping District
   Beijing
   China

   Email: wangaj.bri@chinatelecom.cn





Huang & Wang            Expires January 17, 2018                [Page 4]


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