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


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.

Table of Contents

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:

           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.

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", Internet-Draft draft-wang-teas-pce-native-ip-03, 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.

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