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

Versions: 00 01

BIER                                                            Z. Zhang
Internet-Draft                                          Juniper Networks
Intended status: Standards Track                               N. Warnke
Expires: August 3, 2019                                 Deutsche Telekom
                                                             I. Wijnands
                                                           Cisco Systems
                                                        January 30, 2019


           Tethering A BIER Router To A BIER-incapable Router
                      draft-zzhang-bier-tether-01

Abstract

   This document specifies optional procedures to optimize the handling
   of Bit Index Explicit Replication (BIER) incapable routers, by
   tethering a BIER router to a BIER incapable router.

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 August 3, 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



Zhang, et al.            Expires August 3, 2019                 [Page 1]


Internet-Draft                 bier-tether                  January 2019


   (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.  Terminologies . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Advertising from Helped Node  . . . . . . . . . . . . . .   4
     3.2.  Advertising from Helper Node  . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Terminologies

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

   [To be added].

2.  Introduction

   Consider the following scenario where router X does not support BIER.

                              ------ BFR2 ------- BFER2
                             /
      BFER1 ---  BFR1 ---- X ------- BFR3 ------- BFER3
                             .........
                             \
                              ------ BFRn ------- BFERn


   For BFR1 to forward BIER traffic towards BFR2...BFRn, it needs to
   tunnel individual copies through X.  This degrades to "ingress"
   replication to those BFRs.  If X's connections to BFRs are long
   distance or bandwidth limited, and n is large, it becomes very
   inefficient.

   A solution to the inefficient tunneling from BFRs is to tether a BFRx
   to X:



Zhang, et al.            Expires August 3, 2019                 [Page 2]


Internet-Draft                 bier-tether                  January 2019


                              ------ BFR2 ------- BFER2
                             /
      BFER1 ---  BFR1 ---- X ------- BFR3 ------- BFER3
                          / \  .........
                         /   \
                      BFRx    ------ BFRn ------- BFERn


   Instead of BFR1 tunneling to BFR2, ..., BFRn directly, BFR1 will get
   BIER packets to BFRx, who will then tunnel to BFR2, ..., BFRn.  There
   could be fat and local pipes between the tethered BFRx and X, so
   ingress replication from BFRx is acceptable.

   For BFR1 to tunnel BIER packets to BFRx, the BFR1-BFRx tunnel need to
   be announced in IGP as a forwarding adjacency so that BFRx will
   appear on the SPF tree.  This need to happen in a BIER specific
   topology so that unicast traffic would not be tunneled to BFRx.
   Obviously this is operationally cumbersome.

   Section 6.9 of BIER architecture specification [RFC8279] describes a
   method that tunnels BIER packets through incapable routers without
   the need to announce tunnels.  However that does not work here,
   because BFRx will not appear on the SPF tree of BFR1.

   There is a simple solution to the problem though.  Even though X does
   not support BIER forwarding, it could advertises BIER information as
   if it supported BIER so BFRs will send BIER packets to it.  The BIER
   packets have a BIER label in front of the BIER header and X will use
   the BIER label to label switch to BFRx, who will in turn do BIER
   forwarding to other BFRs but via tunneling as described in section
   6.9 of BIER architecture spec.

   Even though X advertises as if it supported BIER, BFRx needs to know
   that X does not really support BIER so it will tunnel to other BFRs
   through X.  The knowledge is through static provisioning or through
   additional signaling.  In the latter case, X could advertise that
   BFRx is its helper node, so that other BFRs could optionally use the
   Section 6.9 method to tunnel to BFRx, instead of sending native BIER
   packets to X and rely on X label switching to BFRx.  This also allows
   it to work in the non-MPLS case.

   Alternatively, instead of for X to advertise that it supports BIER
   but relies on helper BFRx, BFRx could advertise that it is X's helper
   and other BFRs will use BFRx (instead of X's children on the SPF
   tree) to replace X during its post-SPF processing as described in
   section 6.9 of BIER architecture spec.  That way, X does not need any
   special knowledge, provisioning or procedure.




Zhang, et al.            Expires August 3, 2019                 [Page 3]


Internet-Draft                 bier-tether                  January 2019


   The two options both have pros and cons - the first option only needs
   X and BFRx to support the new procedure while the second option does
   not require anything to be done to the BIER incapable X.

   BFRx could also be connected to other routers in the network so that
   it could send BIER packets through other routers as well, not
   necessarily tunneling through X.  To prevent routing loops, smallest
   metric, which is 1, must be announced for links between X and BFRx in
   both directions.

   While the example shows a local connection between BFRx and X, it
   does not have to be like that.  As long as packets can arrive at BFRx
   without requiring X to do BIER forwarding, it should work.  For
   example, X could label switch incoming BIER packets through a tunnel
   to BFRx, or other BFRs could tunnel BIER packets to BFRx based on X's
   advertisement that BFRx is its helper.  This does require a BIER
   specific topology in which the BFRx-X tunnel is announced with the
   smallest metric 1.

3.  Specification

   The procedures in this document apply when a BFRx is tethered to a
   BIER incapable router X as X's helper for BIER forwarding.

   BFRx MUST not send BIER packets natively to X even if X advertises
   BIER information.  BFRx knows that X does not really support BIER
   either from provisioning or from the BIER Helper Node sub-sub-TLV
   advertised by X.

   Either of the following two methods may be used for ISIS [RFC8401]
   and OSPF [I-D.ietf-bier-ospf-bier-extensions].

   A future revision will specify the extensions when BGP is used as the
   BIER signaling protocol [I-D.ietf-bier-idr-extensions].

3.1.  Advertising from Helped Node

   For non-MPLS encapsulation, X MUST advertise a BIER Helper Node sub-
   sub-TLV that specifies the BIER prefix of the helper BFRx.  Other
   BFRs MUST use the Section 6.9 procedure modified as following: X is
   treated as BIER incapable (because of the BIER Helper Node sub-sub-
   TLV), and is replaced with the BFRx (instead of X's children on the
   SPF tree) during the post-SPF processing.

   This requires other BFRs to recognize the BIER Helper Node sub-sub-
   TLV.  The same procedure MAY be used For MPLS encapsulation, though
   with the following alternative for MPLS encapsulation, tethering is




Zhang, et al.            Expires August 3, 2019                 [Page 4]


Internet-Draft                 bier-tether                  January 2019


   transparent to other BFRs (except the helper node BFRx) - they do not
   need to be aware that X does not support BIER at all.

   For MPLS encapsulation, X MAY advertises BIER information as if it
   supported BIER forwarding, including the MPLS Encapsulation sub-sub-
   TLV with a label range.  X MUST set up its forwarding state such that
   incoming packets with a BIER label in its advertised label range are
   label switched to BFRx, either over a direct link or through a
   tunnel.  The incoming label is swapped to a BIER label advertised by
   BFRx for the <sub-domain, bsl, set> that the incoming label
   corresponds to.

   Notice that both methods can be used for MPLS encapsulation at the
   same time.  In that case another BFR may send BIER packets to X
   natively, or tunnel to BFRx directly.

3.2.  Advertising from Helper Node

   With this method, the helper node (BFRx) MUST advertise a BIER Helped
   Node sub-sub-TLV that specifies the BIER incapable node (X) that this
   node helps.  When other BFRs follow the post-SPF processing
   procedures as specified in section 6.9 of the BIER architecture spec
   [RFC8279], they replace the helped node on the SPF tree with the
   helper node (instead of the children of the helped node).

4.  Security Considerations

   This specification does not introduce additional security concerns
   beyond those already discussed in BIER architecture and OSPF/ISIS/BGP
   extensions for BIER signaling.

5.  IANA Considerations

   This document requests two new sub-sub-TLV type values from the "Sub-
   sub-TLVs for BIER Info Sub-TLV" registry in the "IS-IS TLV
   Codepoints" registry:

        Type    Name
        ----    ----
        TBD1    BIER Helper Node
        TBD2    BIER Helped Node

   This document also requests two new sub-TLV type values from the
   OSPFv2 Extended Prefix TLV Sub-TLV registry:







Zhang, et al.            Expires August 3, 2019                 [Page 5]


Internet-Draft                 bier-tether                  January 2019


        Type    Name
        ----    ----
        TBD3    BIER Helper Node
        TBD4    BIER Helped Node

   All have the same format: the value is BIER prefix of the helper/
   helped node and the length is 4 for IPv4 and 16 for IPv6.

6.  Acknowledgements

   The author wants to thank Eric Rosen and Antonie Przygienda for their
   review, comments and suggestions.

7.  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-06 (work in progress), January 2019.

   [I-D.ietf-bier-ospf-bier-extensions]
              Psenak, P., Kumar, N., Wijnands, I., Dolganow, A.,
              Przygienda, T., Zhang, Z., and S. Aldrin, "OSPFv2
              Extensions for BIER", draft-ietf-bier-ospf-bier-
              extensions-18 (work in progress), June 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>.

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

Authors' Addresses

   Zhaohui Zhang
   Juniper Networks

   EMail: zzhang@juniper.net



Zhang, et al.            Expires August 3, 2019                 [Page 6]


Internet-Draft                 bier-tether                  January 2019


   Nils Warnke
   Deutsche Telekom

   EMail: Nils.Warnke@telekom.de


   IJsbrand Wijnands
   Cisco Systems

   EMail: ice@cisco.com









































Zhang, et al.            Expires August 3, 2019                 [Page 7]


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