Segmented MVPN Using IP Lookup for BIER
draft-xie-bier-mvpn-segmented-01

Network Working Group                                             J. Xie
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                                 L. Geng
Expires: January 3, 2019                                         L. Wang
                                                            China Mobile
                                                              M. McBride
                                                                  G. Yan
                                                                  Huawei
                                                            July 2, 2018

                Segmented MVPN Using IP Lookup for BIER
                    draft-xie-bier-mvpn-segmented-01

Abstract

   This document specifies an alternative of the control plane and data
   plane procedures that allow segmented MVPN using BIER.  This allows
   the use of a more efficient explicit-tracking as the BIER overlay,
   with a slight change in the forwarding procedure of a segmentation
   point BFR by a lookup of the IP header.  This document updates [I-
   D.ietf-bier-mvpn].

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

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 January 3, 2019.

Xie, et al.              Expires January 3, 2019                [Page 1]
Internet-Draft      draft-xie-bier-mvpn-segmented-00           July 2018

Copyright Notice

   Copyright (c) 2018 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
   (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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Statement and Considerations  . . . . . . . . . . . .   3
     3.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Considerations  . . . . . . . . . . . . . . . . . . . . .   4
   4.  Segmented MVPN using IP Lookup for BIER . . . . . . . . . . .   4
     4.1.  Explicit-tracking using LIR-pF Flag . . . . . . . . . . .   4
     4.2.  Forwarding Procedure of Segmentation Point  . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   When using BIER to transport an MVPN data packet through a BIER
   domain, an ingress PE functions as a BFIR (see [RFC8279]).  The BFIR
   must determine the set of BFERs to which the packet needs to be
   delivered.  This can be done through an explicit-tracking function
   using a LIR and/or LIR-pF flag in BGP MVPN routes, per the
   [RFC6513],[RFC6514],[RFC6625],[I-D.ietf-bess-mvpn-expl-track], and
   [I-D.ietf-bier-mvpn].

   Using a LIR-pF Flag will bring some extra benefits, as [I-D.ietf-
   bier-mvpn] and [I-D.ietf-bess-mvpn-expl-track] have stated.  But
   unfortunately, the LIR-pF explicit tracking for a segmented MVPN
   deployment is not allowed in the current draft [I-D.ietf-bier-mvpn],

Xie, et al.              Expires January 3, 2019                [Page 2]
Internet-Draft      draft-xie-bier-mvpn-segmented-00           July 2018

   because the draft requires a per-flow upstream-assigned label to do
   the data-plane per-flow lookup on the segmentation point BFR.

   This document specifies an alternative of the control plane and data
   plane procedures that allow segmented MVPN using BIER in both
   segments.  This allows the use of the more efficient LIR-pF explicit-
   tracking as the BIER overlay, with a slight change in the forwarding
   procedure of a segmentation point BFR by using IP lookup.  This will
   bring some significant benefits to the segmented MVPN deployment,
   including:

   o  Getting a much better multicast join latency by eliminating the
      round trip interaction of S-PMSI AD routes and Leaf AD routes.
      Especially, the S-PMSI A-D routes may need a data-driven procedure
      to trigger, and make the multicast join latency even worse.

   o  Greatly reducing the number of S-PMSI A-D routes that BFIR and
      BFERs need to save.

   o  Consolidated forwarding procedure of IP lookup for every BIER
      Overlay functioning routers, such as BFIR, BFER, segmentation
      point BFR, and segmentation point BFR with BFER function.

2.  Terminology

   Readers of this document are assumed to be familiar with the
   terminology and concepts of the documents listed as Normative
   References.

3.  Problem Statement and Considerations

3.1.  Problem Statement

   BIER is a stateless multicast forwarding by introducing a multicast-
   specific BIER header in the data plane.  The maximal number of BFERs
   a packet can reach is limited by the bit string length of a BIER
   header.  For a network with many routers in multiple IGP areas
   (typically an Inter-Area network), it may be more expected to use a
   segmented MVPN when deploying BIER than traditional MVPN.

   However, it is not allowed in the [I-D.ietf-bier-mvpn] to use a LIR-
   pF explicit-tracking when deploying a segmented MVPN.  This will lead
   to a low efficiency of explicit-tracking, and cause a worse multicast
   join latency.  Here we take a scenario of inter-area segmented MVPN
   with both segments using BIER as an example.

Xie, et al.              Expires January 3, 2019                [Page 3]
Internet-Draft      draft-xie-bier-mvpn-segmented-00           July 2018

3.2.  Considerations

   A BFIR is always needed to know the BFERs interested in a specific
   flow.  This is a function of a BIER overlay defined in [RFC8279].  A
   segmentation point BFR in a segmented MVPN deployment, saying ABR,
   will play similar roles of both BFIR and BFER.  It needs to do a
   disposition of a BIER Header, and then do an imposition of a new BIER
   Header.  It requires the ABR router to maintain per-flow states, and
   especially, such per-flow states always include a set of BFERs who
   are intrested in a specific flow by using an explicit-tracking
   procedure.

   This behavior is completely different from a traditional segmented
   MVPN deployment, e.g, with both of the two segments using P2MP label
   switch.

   In a traditional segmented MVPN with both segments using P2MP label
   switch, it is expected to receive a MPLS packet and replicate to
   downstream routers after swap the MPLS Label.  A lookup of IP packet
   is not expected.  Also, in a traditional segmented MVPN deployment,
   an MPLS label represents a P-tunnel, which may carry one, many or
   even all multicast flow(s) of a VPN, so it is not always a per-flow
   state on the segmentation point router.

   In conclusion, the pattern of forwarding packets on segmentation
   points only by lookup of MPLS label mapped from multicast flow(s) is
   significantly unnecessary when BIER is introduced.  Instead, doing a
   per-flow lookup of IP header on segmentation points is more efficient
   and consolidated.

4.  Segmented MVPN using IP Lookup for BIER

4.1.  Explicit-tracking using LIR-pF Flag

   In a scenario of Inter-area Segmented MVPN with both segments using
   BIER, the determination of the set of BFERs that need to receive the
   a specific multicast flow of (C-S1,C-G1) in each segment, can be
   obtained by using a LIR-pF flag.  Suppose a topology of this:

       (Ingress PE)PE1-------P1-------ABR-------P2------PE2(Egress PE)
                   |                  |                 |
                   |   Ingress Area   |   Egress Area   |
                   |  ( BIER SD<X> )  |  ( BIER SD<Y> ) |

                        Figure 1: Example topology

   PE1 is Ingress PE, and the area of { PE1 -- P1 -- ABR } is called an
   Ingress Area.

Xie, et al.              Expires January 3, 2019                [Page 4]
Internet-Draft      draft-xie-bier-mvpn-segmented-00           July 2018

   PE2 is Egress PE, and the area of { ABR -- P2 -- PE2 } is called an
   Egress Area.

   The Ingress PE is configured to use a BIER tunnel type for a MVPN
   instance for the Ingress Area, and the ABR is configured to use a
   BIER tunnel type for the MVPN instance for the Egress Area.

   The Ingress PE originates a wildcard S-PMSI A-D route (C-*,C-*) and
   the PTA of that route has the following settings:

   o  The LIR-pF and LIR flags be set.

   o  The tunnel type be set to "BIER".

   o  A non-zero MPLS label be specified.

   ABR receives the S-PMSI A-D route from the Ingress PE, and re-
   advertises the route to the Egress PE, with a PTA type "BIER", and
   PTA flags of LIR and LIR-pF, and a new non-zero upstream-assigned
   MPLS label allocated by ABR per-VPN.

   Egress PE receives the S-PMSI A-D route from the ABR, and checks if
   it need to response with a Leaf A-D route to this S-PMSI A-D route
   using the process of the "match for reception" and "match for
   tracking" as defined in [I-D.bess-mvpn-expl-track].  In this example,
   for a C-flow of (C-S1, C-G1), the checking result of "matched for
   tracking" is the S-PMSI(C-*, C-*), and the checking result of
   "matched for reception" is also the S-PMSI(C-*, C-*).  Egress PE will
   then send a Leaf A-D route (RD, C-S1, C-G1, Root=PE1, Leaf=PE2) to
   the ABR with a PTA flag LIR-pF, and a Leaf A-D route (RD, C-*, C-*,
   Root=PE1, Leaf=PE2) without a PTA flag LIR-pF.

   ABR then has an explicit-tracking result of a new per-flow
   information of (RD, C-S1, C-G1, Root=PE1) with Egress PE as its leaf
   or BFER.  ABR's "matched for tracking" result to this flow(RD, C-S1,
   C-G1, PE1) will then be updated with a new record, and ABR then sends
   a Leaf A-D route (RD, C-S1, C-G1, Root=PE1, Leaf=ABR) to Ingress PE.

   Ingress PE then has an explicit-tracking result of a new per-flow
   information of (RD, C-S1, C-G1, Root=PE1) with ABR as its leaf or
   BFER.

   From this procedure description one can see that:

   1.  The S-PMSI A-D(C-*, C-*) route is functioning as a per-VPN anchor
       of the upstream and the downstream(s), which can be called a BIER
       FEC in this document, saying BIER FEC(*,*).

Xie, et al.              Expires January 3, 2019                [Page 5]
Internet-Draft      draft-xie-bier-mvpn-segmented-00           July 2018

   2.  The Leaf A-D(S,G) routes are functioning as a per-flow anchor of
       the downstream(s) and the upstream, which are also BIER FECs
       accordingly, saying BIER FEC(S,G).

   3.  The Tuple of (Root=PE1, RD) in S-PMSI (C-*, C-*) or Leaf AD(C-*,
       C-*) or Leaf AD(C-S, C-G) represents an VRF on the ABR
       implicitly.

   ABR knows the per-vpn infmation of a (Root=PE1, RD) tuple when
   receiving and re-advertising the S-PMSI A-D(*,*) route bound with a
   PTA, where:

   o  Inbound SD (InSD): in PTA of the received S-PMSI(*,*) route.

   o  Inbound VpnLabel (InVpnLabel): in PTA of the received S-PMSI(*,*)
      route.

   o  Inbound BfirId (InBfirId): in PTA of the received S-PMSI(*,*)
      route.

   o  Outbound SD(OutSD): in PTA of the re-advertised S-PMSI(*,*) route.

   o  Outbound VpnLabel (OutVpnLabel): in PTA of the re-advertised
      S-PMSI(*,*) route.

   o  Outbound BfirId (OutBfirId): in PTA of the re-advertised
      S-PMSI(*,*) route.

   ABR establishs a per-flow control-plane state accordingly like this:

   o  Per-flow upstream state, according to the Leaf A-D (C-S, C-G)
      route send to the Ingress PE: (PE1, RD, C-S1, C-G1, InSD,
      InBfirId, InVpnLabel).

   o  Per-flow downstream state(s), according to the Leaf A-D(C-S, C-G)
      route(s) received by the ABR from Egress PE(s): (PE1, RD, C-S1,
      C-G1, Leaf, OutSD, OutBfirId, OutVpnLabel).

   ABR knows the BIER Label(s) it allocated for InSD and OutSD, saying
   InBierLabel for InSD<X> and OutBierLabel for OutSD<Y>, and thus it
   can establish the per-flow forwarding state:

   o  Per-flow upstream forwarding state: (InBierLabel, InBfirId,
      InVpnLabel, C-S1, C-G1).

   o  Per-flow downstream(s) forwarding state: (InBierLabel, InBfirId,
      InVpnLabel, C-S1, C-G1, Leaf, OutBfirId, OutVpnLabel,
      OutBitString)

Xie, et al.              Expires January 3, 2019                [Page 6]
Internet-Draft      draft-xie-bier-mvpn-segmented-00           July 2018

4.2.  Forwarding Procedure of Segmentation Point

   The Forwarding procedure of a segmentation point BFR is a combination
   of a deposition and a re-imposition of the whole BIER header and the
   upstream-assigned Vpn Label.  One can think it as swapping of a
   series of fields like below:

   o  swapping the InBierLabel with an OutBierLabel.

   o  swapping the InBfirId with an OutBfirId.

   o  swapping the InVpnLabel with an OutVpnLabel.

   o  swapping the InBitString with an OutBitString.

   The key of a per-flow lookup on ABR is a tuple of (InBierLabel,
   InBfirId, InVpnLabel) and a tuple of (C-S1, C-G1), representing a VRF
   and a flow respectively.  All the elements are from a BIER packet,
   and such an IP lookup can be seen the same as an MFIB lookup, if the
   (InBierLabel, InBfirId, InVpnLabel) tuple is mapped to a VRF locally
   on the ABR.

5.  Security Considerations

   The procedures of this document do not, in themselves, provide
   privacy, integrity, or authentication for the control plane or the
   data plane.

6.  IANA Considerations

   No IANA allocation is required.

7.  Acknowledgements

   TBD.

8.  References

8.1.  Normative References

   [I-D.ietf-bess-mvpn-expl-track]
              Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang,
              "Explicit Tracking with Wild Card Routes in Multicast
              VPN", draft-ietf-bess-mvpn-expl-track-09 (work in
              progress), April 2018.

Xie, et al.              Expires January 3, 2019                [Page 7]
Internet-Draft      draft-xie-bier-mvpn-segmented-00           July 2018

   [I-D.ietf-bier-mvpn]
              Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T.
              Przygienda, "Multicast VPN Using BIER", draft-ietf-bier-
              mvpn-11 (work in progress), March 2018.

   [RFC6513]  Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
              BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
              2012, <https://www.rfc-editor.org/info/rfc6513>.

   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
              <https://www.rfc-editor.org/info/rfc6514>.

   [RFC6625]  Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
              Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
              RFC 6625, DOI 10.17487/RFC6625, May 2012,
              <https://www.rfc-editor.org/info/rfc6625>.

   [RFC8279]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
              Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
              Explicit Replication (BIER)", RFC 8279,
              DOI 10.17487/RFC8279, November 2017,
              <https://www.rfc-editor.org/info/rfc8279>.

8.2.  Informative References

   [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

   Jingrong Xie
   Huawei Technologies

   Email: xiejingrong@huawei.com

   Liang Geng
   China Mobile
   Beijing 10053

   Email: gengliang@chinamobile.com

Xie, et al.              Expires January 3, 2019                [Page 8]
Internet-Draft      draft-xie-bier-mvpn-segmented-00           July 2018

   Lei Wang
   China Mobile
   Beijing 10053

   Email: wangleiyjy@chinamobile.com

   Mike McBride
   Huawei

   Email: mmcbride7@gmail.com

   Gang Yan
   Huawei

   Email: yangang@huawei.com

Xie, et al.              Expires January 3, 2019                [Page 9]