BIER WG                                                    Yongqing. Zhu
Internet-Draft                                              Huanan. Chen
Intended status: Standards Track                           China Telecom
Expires: March 23, 2018                                      Quan. Xiong
                                                             Fangwei. Hu
                                                         ZTE Corporation
                                                      September 19, 2017


                           BIER-TE Forwarding
                  draft-zcxh-bier-te-forwarding-00.txt

Abstract

   Traffic Engineering for Bit Index Explicit Replication (BIER-TE)
   shares part of architecture, definition and packet format with Bit
   Index Explicit Replication (BIER) according to the introduction in
   [I-D.eckert-bier-te-arch].  But BIER-TE supports the traffic
   engineering by explicit hop-by-hop forwarding and loose hop
   forwarding of packets.

   This document proposes a set of extensions to realize the BIER-TE
   forwarding including the assignment of BitPositions to adjacencies
   and the configuration of Bit Index Forwarding Table (BIFT).

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 https://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 March 23, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Zhu, et al.              Expires March 23, 2018                 [Page 1]


Internet-Draft             BIER-TE Forwarding             September 2017


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Operation Overview  . . . . . . . . . . . . . . . . . . .   3
     1.3.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  BIER-TE Forwarding  . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  The Assignment of BitPositions to Adjacencies . . . . . .   5
     2.2.  The configuration of BIFT . . . . . . . . . . . . . . . .   5
   3.  BIER-TE Forwarding Example  . . . . . . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Traffic Engineering for Bit Index Explicit Replication (BIER-TE)
   shares part of architecture, definition and packet format with Bit
   Index Explicit Replication (BIER) according to the introduction in
   [I-D.eckert-bier-te-arch].  But BIER-TE supports the traffic
   engineering by explicit hop-by-hop forwarding and loose hop
   forwarding of packets.

   [I-D.ietf-bier-mpls-encapsulation] specifies a BIER encapsulation
   that BIER header contains a bitstring in which each bit represents
   one egress router in the domain.  But in BIER-TE, every BitPosition
   of the BitString of a BIER-TE packet indicates one or more
   adjacencies which BFRs will transit packets passing though.  BFRs
   recognizes BitStrings or packets for every Sub-Domain-ID(SD),
   BitStringLength(BSL) and Set Identification(SI) combination.

   [I-D.eckert-bier-te-arch] discussed the process of the BIER-TE
   forwarding including Bit Index Forwarding Table (BIFT) and forwarding
   example.  The BIER-TE controller host determines and assigns the
   BitPositions to the adjacencies which explicit paths can be built
   through them and then pushes the BitPositions/adjacencies to the BIFT



Zhu, et al.              Expires March 23, 2018                 [Page 2]


Internet-Draft             BIER-TE Forwarding             September 2017


   which indexed by SI:BitPosition.  The BIFT is configured to the
   routers known as "Bit-Forwarding Router" (BFR) which should be able
   to send packets to adjacencies connecting to other BFRs.

1.1.  Motivation

   As defined in [I-D.ietf-bier-architecture], a multicast data packet
   enters a domain at a "Bit-Forwarding Ingress Router" (BFIR), and
   leaves at one or more "Bit-Forwarding Egress Routers" (BFERs).  For a
   multicast forwarding, the controller host needs to assign lots of
   BitPositions and use multiple SI and BSL within the same sub-domain.
   The distinct SD, BSL and SI combinations MUST be mapped to more than
   one BitStrings and carried in different packets.

   As discussed in [I-D.eckert-bier-te-arch], the BIER-TE controller
   host tracks the BFR topology of the BIER-TE domain and determines the
   BitPositions and related BIFTs.Different with BIER, the BIFT related
   to the BitPositions which associated with a particular SD, BSL and SI
   combination need to be built throughout the whole network in BIER-TE.

   The BFRs need to forward the packets based on the BitString and BIFT
   with a SD, BSL and SI combination.The BitPositions of these
   adjacencies passing through BFIR to each BFER must be assigned in the
   same SD, BSL and SI combination to ensure the multicast flow be
   forwarded to the BFER within the same packet.  The assignment of
   BitPositions and the configuration of BIFT should be taken to
   considerations in detail.

1.2.  Operation Overview

   Based on the discussion above, this document proposes a set of
   extensions to realize the BIER-TE forwarding including the assignment
   of BitPositions to adjacencies and the configuration of BIFT.  The
   main point is that the assignment of BitPositions and the
   configuration of the BIFT MUST be accomplished based on the explicit
   paths of multicast flow and be completed after the BFIR and BFERs are
   configured.  The controller host SHOULD take charge of the management
   about multicast flow information.

   The controller host dosen't need to track the topology to determine
   what adjacencies require BitPositions.  The controller host MAY
   compute the explicit paths from BFIR to each BFER first and then
   assign the BitPositions including SD,BSL and SI combination to the
   adjacencies which the paths passing though respectively based on the
   policy.  The assignment results need to meet the requirement that the
   BitPositions of the adjacencies from BFIR to each BFER could belong
   to a SD, BSL and SI combination.  And then the controller pushes
   those BitPositions/adjacencies to the BIFT of the BFRs.  The



Zhu, et al.              Expires March 23, 2018                 [Page 3]


Internet-Draft             BIER-TE Forwarding             September 2017


   configuration of BIFT is not completed in BFR topology but
   incremental configuration based on the requirement of multicast
   flows.

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

2.  BIER-TE Forwarding

   This document proposes a general mechanism to extend the process in
   [I-D.eckert-bier-te-arch].  The operation for BIER-TE forwarding is
   as follows.

   The controller host which representing the control plane of BIER-TE
   discovers the network topology information.

   When the multicast flows needs to be forwarded in the BIER-TE
   network, the controller host tracks the multicast flow overlay to
   determine which multicast flow needs to be sent by a BFIR to which
   BFERs.

   And based on the topology, the controller host needs to calculate the
   explicit paths from BFIR to every BFER across the BIER-TE domain
   according to the algorithms which is outside the scope of this
   document.

   The BIER-TE controller host assigns the BitPositions including SD,
   BSL and SI combination to the adjacencies according to the assignment
   method and policy as discussed on the session 3.1.  The BIFT for
   related BFRs which the explicit paths passing through SHOULD be
   populated by the controller host and configured once the BitPositions
   assigned with the detail in session 3.2 .

   Finally, the BIER-TE controller host calculates the BitStrings
   according to the explicit paths and its related explicit SD, BSL and
   SI combination and pushes them into the BFIR as discussed in
   [I-D.eckert-bier-te-arch].

   Once the BIFTs and BitStrings was programmed into the data plane of
   BFRs by the BIER-TE controller host, they can be used to forward
   packets according to the rules specified in the BIER-TE forwarding
   Procedures defined in [I-D.eckert-bier-te-arch].






Zhu, et al.              Expires March 23, 2018                 [Page 4]


Internet-Draft             BIER-TE Forwarding             September 2017


2.1.  The Assignment of BitPositions to Adjacencies

   The BIER-TE controller host assigns the BitPositions including SD,
   BSL and SI combination to the adjacencies based on the explicit paths
   passing though.  One or more BitPositions MAY be assigned to an
   adjacency with the different SD, BSL and SI combination.  The
   assignment need to meet the requirement that the BitPositions of the
   adjacencies from BFIR to each BFER could belong to a SD, BSL and SI
   combination.

   This document proposes a merthord for the assignment of BitPosition
   to adjacencies and defines two types of the assignment policy of
   BitPositions as following.

   If the multicast flow needs to be sent from a BFIR to M BFERs along M
   explicit paths, the controller host MAY assign BitPositions for all
   adjacencies of M explicit paths with the K sets of SD, BSL and SI
   combinations which K M according to the assignment policy.

   EXCLUSIVE-TYPE: Each multicast flow MAY use one or more SD, BSL and
   SI combination exclusively.

   SHARING-TYPE: More than one multicast flows MAY share the same SD,
   BSL and SI combination.  If the adjacencies of a path have been
   assigned to the same SI except some adjacencies which have not been
   assigned ever, the controller host SHOULD assign BP for these no-
   assigned adjacencies the same SI with the others.  The premise is the
   index of the SI is enough for the assignment.

   OPTIONALY, the policy of assignment MAY be configured by customers
   based on the requirement outside of the document.

2.2.  The configuration of BIFT

   The BIFT is populated by the BIER-TE control plane and exists in all
   BFRs as defined in [I-D.eckert-bier-te-arch].  This document proposes
   an extension to BIFT as the table 1 shown.

   BIFT-id represents a particular BIFT and corresponds to a particular
   combination of SD, BSL, and SI.  The value of BITF-id MUST be
   assigned by BIER-TE controller host and unique throughout the BIER-TE
   domain.  The BIFT-id can be used in BIER encapsulation as discussed
   in [I-D.ietf-bier-mpls-encapsulation].  BIFT-type indicates the type
   of BIFT including BIER and BIER-TE.







Zhu, et al.              Expires March 23, 2018                 [Page 5]

Internet-Draft             BIER-TE Forwarding             September 2017


              Table 1 Extension of BIFT
------------------------------------------------------------------------------------
| Index:                              |  Adjacencies:                              |
| BIFT-id (<SD:BSL:SI>) : BitPosition | <empty> or one or more per entry           |
| BIFT-type: BIER-TE                                                               |
====================================================================================
| BIFT-id:1                           |  forward_connected(interface,neighbor,DNR) |
------------------------------------------------------------------------------------
| BIFT-id:2                           |  forward_connected(interface,neighbor,DNR) |
|                                     |  forward_connected(interface,neighbor,DNR) |
------------------------------------------------------------------------------------
| BIFT-id:3                           |  local_decap([VRF])                        |
------------------------------------------------------------------------------------
| BIFT-id:4                           |  forward_routed([VRF,]l3-neighbor)         |
------------------------------------------------------------------------------------
| BIFT-id:5                           |  <empty>                                   |
------------------------------------------------------------------------------------
| BIFT-id:6                           |  ECMP({adjacency1,...adjacencyN}, seed)    |
------------------------------------------------------------------------------------
 ...
| ID:BitStringLength |                       ...                                   |
------------------------------------------------------------------------------------


   The BIFT in one sub-domain of a BFR is a table indexed by BIFT-
   id:BitPosition which populated by the controller host and configured
   once the BitPositions assigned.  One or more BitPositions in table
   MAY correspond to the same adjacency.  The configuration of BIFT is
   not completed before the service deployment but incremental
   configuration based on the requirement of multicast flows.  The
   difference is that the configuration of BIFT is not to replace the
   table in BFR but update and add the BIFT-id:BitPosition items into
   BIFT.

   When links or nodes fail or recover in the topology or service is
   deleted by customers, the related items need to be removed from BIFT
   with little effect on other BIFT items of other flows.

3.  BIER-TE Forwarding Example

   Step by step example of basic BIER-TE forwarding and using the
   network defined in [I-D.eckert-bier-te-arch].  The extension process
   for BIER-TE forwarding is shown as follows.








Zhu, et al.              Expires March 23, 2018                 [Page 6]


Internet-Draft             BIER-TE Forwarding             September 2017


                          [Bier-Te Controller Host]
                                  /   | \
                                 v    v  v

                      | a13   a1 |
                      +- BFIR2 --+          |
                      |          | a2   a6  |           LAN2
                      |          +-- BFR3 --+           |
                      |          |          |  a7  a11  |
                 Src -+                     +-- BFER1 --+
                      |          | a3   a8  |           |
                      |          +-- BFR4 --+           +-- Rcv1
                      |          |          |           |
                      |          |
                      | a14  a4  |
                      +- BFIR1 --+          |
                      |          +-- BFR5 --+ a10  a12  |
                    LAN1         | a5   a9  +-- BFER2 --+
                                            |           +-- Rcv2
                                                        |
                                                        LAN3

                  IP |.....    BIER-TE network   ......| IP

                        Figure 1 Forwarding Example

   aXX indicate the Adjacencies number assigned by the BIER-TE
   controller host according to the BIER-TE topology.

   1, The BIER-TE controller discovers the network topology information
   and assigns the Adjacencies number for the adjacencies as the figure
   shown.

   2, The BIER-TE controller tracks the multicast flow overlay to
   determine what multicast flow needs to be sent by which BFIR to which
   BFERs.  Example is from BFIR2 to BFER1 and BFER2.

   3, The BIER-TE controller computes the two optimal paths from BFIR2
   to BFER1 and from BFIR2 to BFER2 respectively.  The result is shown
   as follows.

   a.BFIR2->BFER1:SRC->a13->a2->a7->a11->RCV

   b.BFIR2->BFER2:SRC->a13->a2->a8->a5->a10->a12->RCV

   4, The BIER-TE controller host assigns BP for the path from BFIR2 to
   BFER1 with the assignment method and the policy type is EXCLUSIVE-




Zhu, et al.              Expires March 23, 2018                 [Page 7]


Internet-Draft             BIER-TE Forwarding             September 2017


   TYPE.  SD =0, SI=0, BSL=4, BIFT-id = 0, the BIFT-id:BitPosition is as
   follows:

   a13->0:1

   a2->0:2

   a7->0:3

   a11->0:4

   5, The BIER-TE controller host assigns BP for the path from BFIR2 to
   BFER2.  SD =0, SI=1, BSL=8, BIFT-id = 1, the BIFT-id:BitPosition is
   as follows:

   a13->1:1

   a2->1:2

   a8->1:3

   a5->1:4

   a10->1:5

   a12->1:6

   6, Based on the assignment, the BIER-TE controller populates the
   according BIFTs and forwards it to the BFRs as the following shown.

   BIFT BFIR2:

   0:1: local_decap()

   1:1: local_decap()

   0:2: forward_connected(BFR3)

   1:2: forward_connected(BFR3)

   BIFT BFR3:

   0:3: forward_connected(BFER1)

   1:3: forward_connected(BFR4)

   BIFT BFER1:




Zhu, et al.              Expires March 23, 2018                 [Page 8]


Internet-Draft             BIER-TE Forwarding             September 2017


   0:4: local_decap()

   1:3: forward_connected(BFR4)

   BIFT BFIR1:

   1:4: forward_connected(BFR5)

   BIFT BFR4:

   0:3: forward_connected(BFER1)

   1:4: forward_connected(BFR5)

   BIFT BFR5:

   1:5: forward_connected(BFER2)

   BIFT BFER2:

   1:6: local_decap()

   7, The BitString is splited into two sub-BitStrings according to the
   BIFT-id by the BIER-TE controller.Examples for SI:Bitstring is 0:1111
   and 1:00111111.

4.  Security Considerations

   TBD.

5.  IANA Considerations

   TBD.

6.  Acknowledgements

   TBD.

7.  Normative References

   [I-D.eckert-bier-te-arch]
              Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic
              Engineering for Bit Index Explicit Replication BIER-TE",
              draft-eckert-bier-te-arch-05 (work in progress), June
              2017.






Zhu, et al.              Expires March 23, 2018                 [Page 9]


Internet-Draft             BIER-TE Forwarding             September 2017


   [I-D.ietf-bier-architecture]
              Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
              S. Aldrin, "Multicast using Bit Index Explicit
              Replication", draft-ietf-bier-architecture-08 (work in
              progress), September 2017.

   [I-D.ietf-bier-mpls-encapsulation]
              Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J.,
              Aldrin, S., and I. Meilik, "Encapsulation for Bit Index
              Explicit Replication in MPLS and non-MPLS Networks",
              draft-ietf-bier-mpls-encapsulation-08 (work in progress),
              September 2017.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Authors' Addresses

   Yongqing Zhu
   China Telecom
   109 West Zhongshan Ave
   Guangzhou, Guangdong  510630
   China

   Phone: +86 20 38639581
   Email: zhuyq@gsta.com


   Huanan Chen
   China Telecom
   109 West Zhongshan Ave
   Guangzhou, Guangdong  510630
   China

   Phone: +86 20 38639346
   Email: chenhuanan@gsta.com


   Quan Xiong
   ZTE Corporation
   No.6 Huashi Park Rd
   Wuhan, Hubei  430223
   China

   Phone: +86 27 83531060
   Email: xiong.quan@zte.com.cn



Zhu, et al.              Expires March 23, 2018                [Page 10]


Internet-Draft             BIER-TE Forwarding             September 2017


   Fangwei Hu
   ZTE Corporation
   No.889 Bibo Rd
   Shanghai  201203
   China

   Phone: +86 21 68896273
   Email: hu.fangwei@zte.com.cn











































Zhu, et al.              Expires March 23, 2018                [Page 11]