draft-ietf-bier-tether-00.txt   draft-ietf-bier-tether-01.txt 
BIER Z. Zhang BIER Z. Zhang
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Standards Track N. Warnke Intended status: Standards Track N. Warnke
Expires: February 21, 2021 Deutsche Telekom Expires: July 8, 2021 Deutsche Telekom
I. Wijnands I. Wijnands
Cisco Systems Cisco Systems
D. Awduche D. Awduche
Verizon Verizon
August 20, 2020 January 4, 2021
Tethering A BIER Router To A BIER incapable Router Tethering A BIER Router To A BIER incapable Router
draft-ietf-bier-tether-00 draft-ietf-bier-tether-01
Abstract Abstract
This document specifies optional procedures to optimize the handling This document specifies optional procedures to optimize the handling
of Bit Index Explicit Replication (BIER) incapable routers, by of Bit Index Explicit Replication (BIER) incapable routers, by
attaching (tethering) a BIER router to a BIER incapable router. attaching (tethering) a BIER router to a BIER incapable router.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 21, 2021. This Internet-Draft will expire on July 8, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Additional Considerations . . . . . . . . . . . . . . . . . . 3 2. Additional Considerations . . . . . . . . . . . . . . . . . . 3
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Egress Protection . . . . . . . . . . . . . . . . . . . . . . 5
3.1. IGP Signaling . . . . . . . . . . . . . . . . . . . . . . 5 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. BGP Signaling . . . . . . . . . . . . . . . . . . . . . . 6 4.1. IGP Signaling . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4.2. BGP Signaling . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 9. Normative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Consider the scenario in Figure 1 where router X does not support Consider the scenario in Figure 1 where router X does not support
BIER. BIER.
------ BFR2 ------- BFER2 ------ BFR2 ------- BFER2
/ /
BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3 BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3
......... .........
skipping to change at page 3, line 25 skipping to change at page 3, line 25
BFRx ------ BFRn ------- BFERn BFRx ------ BFRn ------- BFERn
Figure 2: Tethered BFRx Figure 2: Tethered BFRx
Instead of BFR1 tunneling to BFR2, ..., BFRn directly, BFR1 will get Instead of BFR1 tunneling to BFR2, ..., BFRn directly, BFR1 will get
BIER packets to BFRx, who will then tunnel to BFR2, ..., BFRn. There 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 could be fat and local pipes between the tethered BFRx and X, so
ingress replication from BFRx is acceptable. ingress replication from BFRx is acceptable.
For BFR1 to tunnel BIER packets to BFRx, the BFR1-BFRx tunnel need to For BFR1 to tunnel BIER packets to BFRx, the BFR1-BFRx tunnel need to
be announced in Interial Gateway Protocol (IGP) as a forwarding be announced in Interior Gateway Protocol (IGP) as a forwarding
adjacency so that BFRx will appear on the Shortest Path First (SPF) adjacency so that BFRx will appear on the Shortest Path First (SPF)
tree. This needs to happen in a BIER specific topology so that tree. This needs to happen in a BIER specific topology so that
unicast traffic would not be tunneled to BFRx. Obviously this is unicast traffic would not be tunneled to BFRx. Obviously this is
operationally cumbersome. operationally cumbersome.
Section 6.9 of BIER architecture specification [RFC8279] describes a Section 6.9 of BIER architecture specification [RFC8279] describes a
method that tunnels BIER packets through incapable routers without method that tunnels BIER packets through incapable routers without
the need to announce tunnels. However that does not work here, the need to announce tunnels. However that does not work here,
because BFRx will not appear on the SPF tree of BFR1. because BFRx will not appear on the SPF tree of BFR1.
skipping to change at page 5, line 33 skipping to change at page 5, line 33
BFER1 -- BFR1 BFRxy ------------- BFERxy BFER1 -- BFR1 BFRxy ------------- BFERxy
\ / \ /
\ / ----- BFR5 ------- BFER5 \ / ----- BFR5 ------- BFER5
\ | / \ | /
Y ------- BFR6 ------- BFER6 Y ------- BFR6 ------- BFER6
\ \
----- BFRn ------- BFERn ----- BFRn ------- BFERn
Figure 5: One Helper for multiple helped Figure 5: One Helper for multiple helped
3. Specification 3. Egress Protection
The same principal can be used for egress protection. Consider the
following:
------------ BFER1 ------ ce1
/ ____ /
--- BFR1 --------------BFER2 ____
\
ce2
Figure 6: Egress Protection
ce1 is multi-homed to BFER1 and BFER2. Suppose both ce1 and ce2 need
to receive certain multicast traffic and the copy for ce1 in normal
situation follows the BFR1-BFER1-ce1 path while the copy for for ce2
follows the BFR1-BFER2-ce2 path (i.e. the packet that BFR1 receives
has two bits set for BFER1 and BFER2 respectively). If BFR1 detects
the node failure of BFER1, in-flight traffic with BFER1 bit set is
redirected to BFER2, who will then deliver to ce1 only. Note that
for the same multicast payload, BFER2 would receive two copies
(before the BFIR converges), one with the BFER1 bit set and one with
the BFER2 bit set. BFER2 will deliver the copy with the BFER1 bit to
ce1 upon detection of node failure of BFER1, but will not deliver the
same to ce2.
If ce2 is also multi-homed to BFER1 and BFER2, then BFER1 and BFER2
could egress-pretect each other. Each announces that it is the
helper node of the other, and the fact that each is capable of BIER
indicates that it is for egress protection only.
4. Specification
The procedures in this document apply when a BFRx is tethered to a The procedures in this document apply when a BFRx is tethered to a
BIER incapable router X as X's helper for BIER forwarding. BIER incapable router X as X's helper for BIER forwarding.
3.1. IGP Signaling 4.1. IGP Signaling
Suppose that the BIER domain uses BIER signaling extensions to ISIS Suppose that the BIER domain uses BIER signaling extensions to ISIS
[RFC8401] or OSPF [RFC8444]. The helper node (BFRx) MUST advertise [RFC8401] or OSPF [RFC8444]. The helper node (BFRx) MUST advertise
one or more BIER Helped Node sub-sub-TLVs (one for each helped node). one or more BIER Helped Node sub-sub-TLVs (one for each helped node).
The value is BIER prefix of the helped node (X) followed by a one- The value is BIER prefix of the helped node (X) followed by a one-
octet priority field, and one-octet reserved field. The length is 6 octet priority field, and one-octet reserved field. The length is 6
for IPv4 and 18 for IPv6 respectively. for IPv4 and 18 for IPv6 respectively.
The post-SPF processing procedures in Section 6.9 of the BIER The post-SPF processing procedures in Section 6.9 of the BIER
architecture specification [RFC8279] are modified as following for architecture specification [RFC8279] are modified as following for
skipping to change at page 6, line 33 skipping to change at page 7, line 17
could use H1 as LFA next hop to reach the BFER. If yes, H1 is could use H1 as LFA next hop to reach the BFER. If yes, H1 is
used as the next hop BFR for the BFER and the procedure stops. If used as the next hop BFR for the BFER and the procedure stops. If
not, go to the next helper in order. not, go to the next helper in order.
o If none of the helper nodes of N1 can be used, go to the next node o If none of the helper nodes of N1 can be used, go to the next node
in the list of incapable nodes. in the list of incapable nodes.
If the above procedure finishes without finding any helper, then the If the above procedure finishes without finding any helper, then the
original BFR next hop via a tunnel is used to reach the BFER. original BFR next hop via a tunnel is used to reach the BFER.
3.2. BGP Signaling 4.2. BGP Signaling
Suppose that the BIER domain uses BGP signaling Suppose that the BIER domain uses BGP signaling
[I-D.ietf-bier-idr-extensions] instead of IGP. BFR1..N advertises [I-D.ietf-bier-idr-extensions] instead of IGP. BFR1..N advertises
BIER prefixes that are reachable through them, with BIER Path BIER prefixes that are reachable through them, with BIER Path
Attributes (BPA) attached. There are three situations regarding X's Attributes (BPA) attached. There are three situations regarding X's
involvement: involvement:
(1) X does not participate in BGP peering at all (1) X does not participate in BGP peering at all
(2) X re-advertises the BIER prefixes but does not do next-hop-self (2) X re-advertises the BIER prefixes but does not do next-hop-self
skipping to change at page 7, line 28 skipping to change at page 8, line 14
o For BIER prefixes (with BIER Path Attribute) that X re-advertises o For BIER prefixes (with BIER Path Attribute) that X re-advertises
to other BFRs, the tunnel destination in the TEA is changed to the to other BFRs, the tunnel destination in the TEA is changed to the
helper BFRx. helper BFRx.
With the above, BFR1..N will tunnel BIER packets to BFRx (following With the above, BFR1..N will tunnel BIER packets to BFRx (following
the tunnel destination address in the TEA), who will then tunnel the tunnel destination address in the TEA), who will then tunnel
packets to other BFRs (again following the tunnel destination address packets to other BFRs (again following the tunnel destination address
in the TEA). Notice that what X does is not specific to BIER at all. in the TEA). Notice that what X does is not specific to BIER at all.
4. Security Considerations 5. Security Considerations
This specification does not introduce additional security concerns This specification does not introduce additional security concerns
beyond those already discussed in BIER architecture and OSPF/ISIS/BGP beyond those already discussed in BIER architecture and OSPF/ISIS/BGP
extensions for BIER signaling. extensions for BIER signaling.
5. IANA Considerations 6. IANA Considerations
This document requests a new sub-sub-TLV type value from the "Sub- This document requests a new sub-sub-TLV type value from the "Sub-
sub-TLVs for BIER Info Sub-TLV" registry in the "IS-IS TLV sub-TLVs for BIER Info Sub-TLV" registry in the "IS-IS TLV
Codepoints" registry: Codepoints" registry:
Type Name Type Name
---- ---- ---- ----
TBD1 BIER Helped Node TBD1 BIER Helped Node
This document also requests a new sub-TLV type value from the OSPFv2 This document also requests a new sub-TLV type value from the OSPFv2
Extended Prefix TLV Sub-TLV registry: Extended Prefix TLV Sub-TLV registry:
Type Name Type Name
---- ---- ---- ----
TBD2 BIER Helped Node TBD2 BIER Helped Node
6. Contributors 7. Contributors
The following also contributed to this document. The following also contributed to this document.
Zheng(Sandy) Zhang Zheng(Sandy) Zhang
ZTE Corporation ZTE Corporation
EMail: zzhang_ietf@hotmail.com EMail: zzhang_ietf@hotmail.com
Hooman Bidgoli Hooman Bidgoli
Nokia Nokia
EMail: hooman.bidgoli@nokia.com EMail: hooman.bidgoli@nokia.com
7. Acknowledgements 8. Acknowledgements
The author wants to thank Eric Rosen and Antonie Przygienda for their The author wants to thank Eric Rosen and Antonie Przygienda for their
review, comments and suggestions. review, comments and suggestions.
8. Normative References 9. Normative References
[I-D.ietf-bier-idr-extensions] [I-D.ietf-bier-idr-extensions]
Xu, X., Chen, M., Patel, K., Wijnands, I., and T. Xu, X., Chen, M., Patel, K., Wijnands, I., and T.
Przygienda, "BGP Extensions for BIER", draft-ietf-bier- Przygienda, "BGP Extensions for BIER", draft-ietf-bier-
idr-extensions-07 (work in progress), September 2019. idr-extensions-07 (work in progress), September 2019.
[I-D.ietf-idr-tunnel-encaps] [I-D.ietf-idr-tunnel-encaps]
Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP
Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel-
encaps-17 (work in progress), July 2020. encaps-20 (work in progress), November 2020.
[I-D.zzhang-bier-multicast-as-a-service] [I-D.zzhang-bier-multicast-as-a-service]
Zhang, Z., Rosen, E., Awduche, D., and L. Geng, Zhang, Z., Rosen, E., Awduche, D., and L. Geng,
"Multicast/BIER As A Service", draft-zzhang-bier- "Multicast/BIER As A Service", draft-zzhang-bier-
multicast-as-a-service-01 (work in progress), May 2020. multicast-as-a-service-01 (work in progress), May 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
 End of changes. 16 change blocks. 
24 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/