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

Versions: 00 01 02 03 04 05

BIER                                                        Zheng. Zhang
Internet-Draft                                           ZTE Corporation
Intended status: Standards Track                                  Bo. Wu
Expires: March 26, 2020                                       Individual
                                                          Zhaohui. Zhang
                                                        Juniper Networks
                                                      IJsbrand. Wijnands
                                                     Cisco Systems, Inc.
                                                      September 23, 2019


                        BIER Prefix Redistribute
                 draft-zwzw-bier-prefix-redistribute-03

Abstract

   This document defines a BIER proxy function to interconnect different
   underlay routing protocol areas in a network.  And a new BIER proxy
   range sub-TLV is also defined to convey BIER BFR-id information
   across the routing areas.

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 March 26, 2020.








Zhang, et al.            Expires March 26, 2020                 [Page 1]


Internet-Draft          BIER Prefix Redistribute          September 2019


Copyright Notice

   Copyright (c) 2019 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.  Problem statement . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Proposal  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Advertisement . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  BIER proxy range sub-TLV  . . . . . . . . . . . . . . . .   6
   4.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Problem statement






















Zhang, et al.            Expires March 26, 2020                 [Page 2]


Internet-Draft          BIER Prefix Redistribute          September 2019


         +-------------------------------------------------------+
         |              +----+             +----+         PIM    |
         |         +----+ R1 +-------------+ R2 +-----+          |
         |         |    +----+             +----+     |          |
         |         |                                  |          |
         |         |     OSPF area 0 / ISIS           |          |
         |         |                                  |          |
         |         |     +----+            +----+     |          |
         |         +-----+    +------------+    +-----+          |
         |  +------------+ R3 +---+    +---+ R4 +------------+   |
         |  |            +----+   |    |   +----+            |   |
         |  |                     |    |                     |   |
         |  |     OSPF area 1     |    |    OSPF area 2      |   |
         |  |                     |    |                     |   |
         |  |  +----+     +----+  |    |   +----+    +----+  |   |
         |  +--+ Rm +-----+ Rn +--+    +---+ Rx +----+ Ry +--+   |
         |     +----+     +----+           +----+    +----+      |
         +-------------------------------------------------------+
                                Figure 1

   Figure 1 shows that there are three areas in a traditional network.
   In some deployment situations, different routing protocols may also
   be used in a network.  There are just small number of routers in each
   area of the network.  Currently, multicast services are provided in
   this hybrid network by using protocol independent feature of PIM.

   BIER could be a candidate multicast protocol to replace PIM to reduce
   multicast states in the hybrid network.  BIER [RFC8279] is a new
   architecture for the forwarding of multicast data packets.  It does
   not require a protocol for explicitly building multicast distribution
   trees, nor does it require intermediate nodes to maintain any per-
   flow state.  In order to build BIER forwarding plane, BIER key
   parameters must be flooded in one BIER domain such as BFR-prefix,
   BFR-id, subdomain-id, and so on.  The routing protocols which are
   used to flood these BIER parameters are called BIER routing underlay.
   The associated routing protocol extensions are defined in documents
   such as [RFC8401], [RFC8444], [I-D.ietf-bier-idr-extensions],
   [I-D.ietf-bier-ospfv3-extensions], and so on.













Zhang, et al.            Expires March 26, 2020                 [Page 3]


Internet-Draft          BIER Prefix Redistribute          September 2019


                        +----+             +----+
                   +----+ R1 +-------------+ R2 +-----+
                   |    +----+             +----+     |
                   |          OSPF / ISIS             |
                   |           BIER domain 1          |
                   |                                  |
                   |     +----+            +----+     |
                   +-----+    +------------+    +-----+
            +------------+ R3 +---+    +---+ R4 +------------+
            |            +----+   |    |   +----+            |
            |        OSPF         |    |        OSPF         |
            |                     |    |                     |
            |    BIER domain 2    |    |    BIER domain 3    |
            |  +----+     +----+  |    |   +----+    +----+  |
            +--+ Rm +-----+ Rn +--+    +---+ Rx +----+ Ry +--+
               +----+     +----+           +----+    +----+
                                 Figure 2

   Based on the BIER design, a BIER domain is limited by the underlay
   routing protocols flooding scope.  As in a hybrid network depicted in
   figure 2, in case we want deploy BIER instead of PIM, there are
   several BIER domains because of different underlay routing protocols
   limitation.  Multiple encapsulating/ decapsulation executions are
   needed to across multiple BIER domains.  These executions slow down
   the forwarding efficiency.  The border routers also need to maintain
   overlay state, which is undesired.

   Except the hybrid network, there is the situation that several areas
   formed by one same IGP protocol need to be merged into one BIER
   domain in existing network.  The prefix redistribution method defined
   in this document can be used too.

2.  Proposal


















Zhang, et al.            Expires March 26, 2020                 [Page 4]


Internet-Draft          BIER Prefix Redistribute          September 2019


         +-------------------------------------------------------+
         |              +----+             +----+         BIER   |
         |         +----+ R1 +-------------+ R2 +-----+ domain 1 |
         |         |    +----+             +----+     |          |
         |         |            OSPF/ISIS             |          |
         |         |                                  |          |
         |         |     +----+            +----+     |          |
         |         +-----+    +------------+    +-----+          |
         |  +------------+ R3 +---+    +---+ R4 +------------+   |
         |  |            +----+   |    |   +----+            |   |
         |  |                     |    |                     |   |
         |  |     OSPF area 1     |    |    OSPF area 2      |   |
         |  |                     |    |                     |   |
         |  |  +----+     +----+  |    |   +----+    +----+  |   |
         |  +--+ Rm +-----+ Rn +--+    +---+ Rx +----+ Ry +--+   |
         |     +----+     +----+           +----+    +----+      |
         +-------------------------------------------------------+
                                Figure 3

   It is more efficient to deploy BIER by creating one BIER domain for
   the hybrid network to achieve forwarding benefit.

   Since the limitation of the BIER routing protocol scope, BFR-id is
   confined to only one routing area.  A BIER proxy function is
   introduced to transport BIER BFR-id information in a BIER domain
   across multiple routing protocol areas.  So BIER forwarding tables
   can be built across multiple underlay routing protocols to replace
   encapsulation/decapsulation processing.  In the current deployment,
   border router (ABR) has a similar role, ABR summaries unicast routing
   information from one routing protocol area and sends it to another
   routing area by new routing protocol messages.  So ABR can implement
   BIER proxy function to summarize BIER BFR-id information from one
   routing protocol area and sends it to another routing area.

   In figure 3, R3 and R4 connect two areas which running different
   routing protocols, they can be used as BIER proxies to transport BIER
   information.  For example, after R3 receives BFR-ids information from
   OSPF area 1 and sends it to ISIS routing area, the routers in ISIS
   routing area can generate BIER forwarding items toward the BFR-ids in
   OSPF area 1.  Similarly, R3 receives BFR-ids information from ISIS
   area and sends it to OSPF area 1, the routers in OSPF area 1 can
   build BIER forwarding items toward the BFR-ids in ISIS area.  R4 does
   the same function, the BIER forwarding plane is constructed
   accordingly.







Zhang, et al.            Expires March 26, 2020                 [Page 5]


Internet-Draft          BIER Prefix Redistribute          September 2019


3.  Advertisement

   According to [RFC8279], each BFER needs to have a unique (in each
   sub-domain) BFR-id, and each BFR and BFER floods itself BIER info
   sub-TLV and associated sub-sub-TLVs in the BIER domain.  To keep
   consistent with the definition in [RFC8444],
   [I-D.ietf-bier-ospfv3-extensions], and [RFC8401], BIER info sub-TLV
   defined in [RFC8401] and BIER sub-TLV defined in [RFC8444],
   [I-D.ietf-bier-ospfv3-extensions] is reused to convey the BFR-id
   information.  OSPF extended Prefix Opaque LSA [RFC7684] and TLVs 235,
   237 defined in [RFC5120], or TLVs 135 [RFC5305], or TLV 236 [RFC5308]
   are still used to carry the BFR-id / BFR-prefix information.

   The key parameters got from the original routing protocol should be
   adapted to the format of next routing protocol, such as BFR-prefix,
   BFR-id, subdomain-id, and so on.  Some parameters like BAR, MT-ID has
   local significance, So they should be set to same values with BIER
   proxy own advertisement when BIER proxy advertise them to the next
   routing area.

   And as the two BIER info sub-sub-TLVs (sub-TLVs) including MPLS
   encapsulation and BSL conversion also have local significance.  The
   information carried in these two sub-sub-TLV need not, but MAY, be
   advertised to next routing area.

3.1.  BIER proxy range sub-TLV

   In case unicast default route and aggregated / summarized routes are
   used in some routing areas and routers in next area can not see the
   specific BFR-prefix routes from original area, the prefix advertised
   should be set to default route or aggregated / summarized routes.
   Like in figure 3, in case R3/R4 does not advertise specific ISIS
   unicast routes to OSPF area and only advertises unicast default route
   or aggregated / summarized route to OSPF area 1/2, when R3/R4
   advertises BIER info sub-TLV to OSPF area 1/2, R3 MUST advertise the
   prefix with default route or aggregated / summarized route.  In that
   case, multiple BFR-ids will be mapped to one prefix.  In order to
   advertise BFR-ids optimally, we define a new BIER proxy range sub-TLV
   to advertise the information of BFR-ids.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Type       |   Length      | subdomain-id  |    resv       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           BFR-id              |          BFR-id range         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Zhang, et al.            Expires March 26, 2020                 [Page 6]


Internet-Draft          BIER Prefix Redistribute          September 2019


   o  Type: TBD to indicate the BIER proxy range sub-TLV.

   o  Length: variable.

   o  Subdomain-id: The subdomain-id from original advertisement.

   o  resv: The reserved field.

   o  BFR-id: The first BFR-id from original advertisement.

   o  BFR-id range: The range of BFR-ids with one subdomain-id.

   The BIER proxy range sub-TLV is attached to the aggregated /
   summarized route prefix or default route prefix.  The summarized /
   aggregated / default prefix may need multiple BIER proxy range sub-
   TLVs if the BFR-ids covered by the prefix are allocated from
   different ranges (even if they're from a single range but if some
   BFR-ids in the range map to some BIER prefixes that are covered by a
   different summarized / aggregated prefix, then that single large
   range needs to be broken into smaller ranges).

   The BFR-ids associated with the summarized prefix can be advertised
   individally in the BIER range sub-TLV.  Though BFR-id's range can
   increase advertisement efficiency, necessary configuration / policy
   should be provided to guide the range generation of BFR-ids.
   Otherwise unwanted amount of updates may occur when a BFR-id is
   removed from the range.

   Because a summarized / default prefix covers many BIER prefixes, the
   mapping between a BIER prefix and its BFR-id is no longer conveyed in
   the routing underlay.  As a result, the mapping must be provided by
   other means, e.g. in the multicast overlay.

4.  Example

   As in figure 3, R3 and R4 as BIER proxy, R3 as an example should
   advertise the BIER BFR-ids information from ISIS area to OSPF area 1
   with the advertiser set to R3 itself, and advertise BIER info from
   OSPF area 1 to ISIS area as well.  In case R3 and R4 generates
   specific BFR-prefix and BFR-ids from the original area to the next
   area, BIER info sub-TLV defined in [RFC8401] and BIER sub-TLV defined
   in [RFC8444], or [I-D.ietf-bier-ospfv3-extensions] is reused to
   convey the BFR-id information.  All the routers generate BIER
   forwarding items to other area toward BIER proxy according to
   [RFC8279].

   In case BIER proxy can not advertise specific BFR-prefix but
   aggregated / summarized / default prefix from the original area to



Zhang, et al.            Expires March 26, 2020                 [Page 7]


Internet-Draft          BIER Prefix Redistribute          September 2019


   the next area, BIER proxy range sub-TLV is used to convey the
   information.  Suppose that Rm is an ingress router, R1, R2, Rx and Ry
   is egress router, the BFR-ids of these egress router are 31, 55, 112,
   157.  The BFR prefixes of them are 10.1.1.5, 10.1.1.50, 203.1.1.10,
   203.1.1.60.  Suppose that summarized prefixes are advertised into
   OSPF area.  The summarized prefixes are 10.1.1.0/24 and 203.1.1.0/24.
   All the routers in OSPF area 1 compute forwarding table for unicast /
   BIER according to the summarized prefixes, and they can get to these
   prefixes by routes toward proxy R3.

   Rm encapsulate multicast flow with BIER header that with 31, 55, 112
   and 157 bit set in the BIER header (Supposed that 256 BitStringLength
   is used).  The routers in OSPF area 1 forward packet toward R3.  R3
   forwards packet according to the BFR-ids set in the BIER header
   normally.  Later packet reaches R1, R2 and R4.  Similarly, R4
   forwards packet into OSPF area 2 normally.  Finally packet reaches Rx
   and Ry.

5.  IANA Considerations

   IANA is requested to set up a new types of sub-TLV (TLV) registry
   value for BIER proxy range advertisement in OSPF, ISIS, BGP, etc.

6.  Security Considerations

   Implementations must assure that malformed TLV and Sub-TLV
   permutations do not result in errors which cause hard protocol
   failures.

7.  Acknowledgements

   The authors would like to thank Stig Venaas for his valuable comments
   and suggestions.

8.  Normative References

   [I-D.ietf-bier-idr-extensions]
              Xu, X., Chen, M., Patel, K., Wijnands, I., and T.
              Przygienda, "BGP Extensions for BIER", draft-ietf-bier-
              idr-extensions-07 (work in progress), September 2019.

   [I-D.ietf-bier-ospfv3-extensions]
              Psenak, P., Kumar, N., and I. Wijnands, "OSPFv3 Extensions
              for BIER", draft-ietf-bier-ospfv3-extensions-00 (work in
              progress), May 2019.






Zhang, et al.            Expires March 26, 2020                 [Page 8]


Internet-Draft          BIER Prefix Redistribute          September 2019


   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
              Topology (MT) Routing in Intermediate System to
              Intermediate Systems (IS-ISs)", RFC 5120,
              DOI 10.17487/RFC5120, February 2008,
              <https://www.rfc-editor.org/info/rfc5120>.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, DOI 10.17487/RFC5305, October
              2008, <https://www.rfc-editor.org/info/rfc5305>.

   [RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
              DOI 10.17487/RFC5308, October 2008,
              <https://www.rfc-editor.org/info/rfc5308>.

   [RFC7684]  Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
              Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
              Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
              2015, <https://www.rfc-editor.org/info/rfc7684>.

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

   [RFC8401]  Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z.
              Zhang, "Bit Index Explicit Replication (BIER) Support via
              IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018,
              <https://www.rfc-editor.org/info/rfc8401>.

   [RFC8444]  Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A.,
              Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2
              Extensions for Bit Index Explicit Replication (BIER)",
              RFC 8444, DOI 10.17487/RFC8444, November 2018,
              <https://www.rfc-editor.org/info/rfc8444>.

Authors' Addresses

   Zheng(Sandy) Zhang
   ZTE Corporation

   EMail: zzhang_ietf@hotmail.com


   Bo Wu
   Individual

   EMail: w1973941761@163.com



Zhang, et al.            Expires March 26, 2020                 [Page 9]


Internet-Draft          BIER Prefix Redistribute          September 2019


   Zhaohui Zhang
   Juniper Networks

   EMail: zzhang@juniper.net


   IJsbrand Wijnands
   Cisco Systems, Inc.

   EMail: ice@cisco.com









































Zhang, et al.            Expires March 26, 2020                [Page 10]


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