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

Versions: 00

BIER                                                      Zhaohui. Zhang
Internet-Draft                                               Shaowen. Ma
Intended status: Standards Track                        Juniper Networks
Expires: September 6, 2018                                  Zheng. Zhang
                                                         ZTE Corporation
                                                           March 5, 2018


                       Supporting BIER with RIFT
                       draft-zzhang-bier-rift-00

Abstract

   This document specifies extensions to RIFT protocol to support BIER.

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 September 6, 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



Zhang, et al.           Expires September 6, 2018               [Page 1]


Internet-Draft                  bier-rift                     March 2018


   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.  Terminologies . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Advertising BIER Information For non-MPLS Encapsulation . . .   3
   4.  Advertising BIER Information Northbound . . . . . . . . . . .   4
   5.  Advertising BIER Information Southbound . . . . . . . . . . .   4
     5.1.  Local BIER Information  . . . . . . . . . . . . . . . . .   4
     5.2.  Proxied BFR-ID Ranges . . . . . . . . . . . . . . . . . .   4
   6.  Information Elements Schema . . . . . . . . . . . . . . . . .   5
     6.1.  bier.thrift . . . . . . . . . . . . . . . . . . . . . . .   5
     6.2.  Additions to encoding.thrift  . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Terminologies

   Familiarity with BIER and RIFT protocols and procedures is assumed.
   Some terminologies are listed below for convenience.

   [To be added.]

2.  Introduction

   BIER [RFC8279] ... (to be expanded)

   RIFT [I-D.przygienda-rift] is a new protocol specifically designed
   for CLOS and fat-tree network topologies.  As a hybrid between Link
   State Routing and Distance Vector Routing, it does LSR in northbound
   (towards the spine) and DVR in southbound (towards the leaves).

   [I-D.ietf-bier-isis-extensions] and
   [I-D.ietf-bier-ospf-bier-extensions] specify ISIS/OSPF extensions to
   support BIER in an ISIS/OSPF domain.  The same approach applies to
   RIFT in the northbound LSR.

   [I-D.zwzw-bier-prefix-redistribute] specifies methods to advertise
   BIER information via default or summary/aggregate routes advertised




Zhang, et al.           Expires September 6, 2018               [Page 2]


Internet-Draft                  bier-rift                     March 2018


   from one IGP area/domain to another.  Similar approach applies to
   RIFT in the southbound DVR.

   BIER encapsulation, whether it is based on MPLS or not, is covered in
   [RFC8296].  However, the OSPF/ISIS extensions for BIER only covers
   signaling needed for MPLS encapsulation.  RIFT is targeted at DC
   deployments, where MPLS may not be used.  This document covers
   signaling for both BIER MPLS and non-MPLS encapsulation with RIFT.

   The details are provided in following sections.

3.  Advertising BIER Information For non-MPLS Encapsulation

   In the BIER architecture, a BIER sub-domain may have multiple
   BitStringLengths (BSLs) and multiple Encapsulations (Encaps).  A
   single multicast packet coming from outside the BIER sub-domain may
   be sent as multiple BIER packets, one for each set that is identified
   by a SetID (SI).  An incoming BIER packet is forwarded according to a
   BIFT for the <SD,Encap,BSL,SI> tuple.  Each BIFT is identified by a
   20-bit opaque number (BIFT-ID) in the packet.

   With MPLS encapsulation, the BIFT-ID for an incoming BIER packet is
   simply an MPLS label allocated by the receiving BFR for the BIFT.
   For each <SD,BSL> tuple, OSPF/ISIS advertises a block of contiguous
   labels, one label for each SI needed for the tuple, in the MPLS
   Encapsulation sub-sub-TLV as part of the BIER sub-TLV, which is
   attached to the Extended Reachability TLV (ISIS case) or the Extended
   Prefix TLV (OSPF case) for the BFR's BIER Prefix.

   With non-MPLS encapsulation, the BIFT-ID in the packet is at the same
   position as the label in MPLS encapsulation case.  Its semantics is
   no different from the MPLS case in that as an 20-bit opaque value, it
   leads to the BIFT according to which the BIER packet is forwarded.
   Beyond the semantics, there are two differences from the MPLS case
   though:

   o  MPLS infrastructure is not needed.

   o  While each BFR could allocate local BIFT-IDs independently and
      advertise them just like in MPLS case, for the same
      <SD,Encap,BSL,SI> tuple all BFRs could optionally auto-derive or
      be provisioned with the same BIFT-ID and no signaling is needed in
      that case.

   One may consider that if MPLS would allow to use consistently
   provisioned BIER labels on all BFRs, then the second difference
   listed above does not exist anymore.




Zhang, et al.           Expires September 6, 2018               [Page 3]


Internet-Draft                  bier-rift                     March 2018


   In this specification, if locally significant BIFT-IDs are to be used
   with non-MPLS encapsulation, the BIFT-IDs are advertised the same way
   as in the MPLS case - by a BIFT-ID block, which is a block of
   contiguous labels in MPLS case or a block of contiguous opaque 20-bit
   values in non-MPLS case.  The only difference is the type of
   encapsulation.

   If consistently provisioned or auto-derived BIFT-IDs are used with
   non-MPLS encapsulation, then no BIFT-ID block is signaled.  Just the
   encapsulation type is signaled.

4.  Advertising BIER Information Northbound

   Nothing special here compared to OSPF/ISIS.  A node's local BIER
   information as described in the previous section is attached to a
   local BIER Prefix.  Details to be added.

5.  Advertising BIER Information Southbound

5.1.  Local BIER Information

   Similar to the northbound case, a node's local BIER information is
   attached to a local BIER prefix that is advertised southbound.

5.2.  Proxied BFR-ID Ranges

   On the southbound, a node advertises a default route, plus certain
   prefixes to prevent blackholing or suboptimal routing upon link
   failures.  Those prefixes and default route are like the summary
   routes and default route in [I-D.zwzw-bier-prefix-redistribute], and
   similarly they carry BFR-IDs corresponding to the covered BIER
   Prefixes.

   Consider a RIFT network with a BIER sub-domain of 200 BFIR/BFERs.
   Each non-leaf node is provisioned that BFR-ID 1-200 are used.
   Suppose a node X advertise southbound a default route RT1 and
   disaggregation routes RT2/RT3.  RT2 and RT3 MUST advertise BFR-IDs
   covered by them (e.g.  BFR-ID 100/102/150 covered by RT2 and BFR-ID
   101/103 covered by RT3), while the default route RT1 can always
   advertise that all BFR-ID 1~200 are covered by it and does not need
   to exclude BFR-ID 100/102/150 and 101/103 that are covered by RT2/
   RT3.  When a southern node receives RT1 and RT2/RT3, it installs BFR-
   ID 100/102/150 in its BIFT according to RT2, 101/103 in its BIFT
   according to RT3, and installs other BFR-IDs (or just a default
   route) in its BIFT according to RT1.






Zhang, et al.           Expires September 6, 2018               [Page 4]


Internet-Draft                  bier-rift                     March 2018


6.  Information Elements Schema

   This document introduces a bier.thrif schema with definitions to be
   used in RIFT encoding.thrift.

6.1.  bier.thrift

    typedef i8       SubdomainIdType
    typedef i16      BfrIdType
    typedef i8       BARType
    typedef i8       IPAType
    typedef i16      BSLType     /* Number of bits */
    typedef i32      BiftIdType  /* Only the most significant 20 bits are used */

    enum EncapsulationType {
       mpls         = 0;
       non-mpls     = 1;
    }

    /* Similar to the label range in OSPF/ISIS extensions for BIER */
    struct BiftIdBlock {
        1: required BiftIdType       bift_id_base;
        2. required i8               bift_id_range;
    }

    /* Similar to the MPLS Encapsulation sub-sub-TLV in OSPF/ISIS */
    struct EncapStruct {
        1: required EncapsulationType      encap_type;
        2: required BSLType                bsl;
        3: optional BiftIdBlock            bift_id_block;
    }

    /*BIER node information. Similar to BIER sub-TLV in OSPF/ISIS. */
    struct BierInfo {
        1: required SubdomainIdType    subdomain_id;
        2: required BfrIdType          bfr_id;
        3: required BARType            bar;
        4: required IPAType            ipa;
        5. required EncapStruct        encaps;       /* one or more */
    }

    struct ProxyBfrIdRange {
        1: required SubdomainIdType    subdomain_id;
        2: required BfrIdType          bfr_id_base;
        3: required BSLType            bfr_id_range;
    }





Zhang, et al.           Expires September 6, 2018               [Page 5]


Internet-Draft                  bier-rift                     March 2018


6.2.  Additions to encoding.thrift

   The PrefixAttributes in encoding.rift now has two optional elements:

    struct PrefixAttributes {
        ...
        2: optional BierInfo         bier_info;    /* BIER info for a
                                                    * local BIER Prefix */
        3. optional ProxyBfrIdRange  proxy_bfr_id; /* one or more proxy
                                                    * BFR-ID ranges covered
                                                    * by this prefix */
    }

7.  IANA Considerations

8.  Acknowledgements

9.  References

9.1.  Normative References

   [I-D.przygienda-rift]
              Przygienda, T., Sharma, A., Atlas, A., and J. Drake,
              "RIFT: Routing in Fat Trees", draft-przygienda-rift-05
              (work in progress), March 2018.

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

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

   [RFC8296]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
              Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
              for Bit Index Explicit Replication (BIER) in MPLS and Non-
              MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
              2018, <https://www.rfc-editor.org/info/rfc8296>.

9.2.  Informative References







Zhang, et al.           Expires September 6, 2018               [Page 6]


Internet-Draft                  bier-rift                     March 2018


   [I-D.ietf-bier-isis-extensions]
              Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang,
              "BIER support via ISIS", draft-ietf-bier-isis-
              extensions-09 (work in progress), February 2018.

   [I-D.ietf-bier-ospf-bier-extensions]
              Psenak, P., Kumar, N., Wijnands, I., Dolganow, A.,
              Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions
              for BIER", draft-ietf-bier-ospf-bier-extensions-15 (work
              in progress), February 2018.

   [I-D.zwzw-bier-prefix-redistribute]
              Zhang, Z., Bo, W., Zhang, Z., and I. Wijnands, "BIER
              Prefix Redistribute", draft-zwzw-bier-prefix-
              redistribute-00 (work in progress), January 2018.

Authors' Addresses

   Zhaohui Zhang
   Juniper Networks

   EMail: zzhang@juniper.net


   Shaowen Ma
   Juniper Networks

   EMail: mashao@juniper.net


   Zheng Zhang
   ZTE Corporation

   EMail: zhang.zheng@zte.com.cn

















Zhang, et al.           Expires September 6, 2018               [Page 7]


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