Internet DRAFT - draft-ietf-bier-tether
draft-ietf-bier-tether
BIER Z. Zhang
Internet-Draft Juniper Networks
Intended status: Standards Track N. Warnke
Expires: 19 August 2024 Deutsche Telekom
I. Wijnands
Arrcus
D. Awduche
Verizon
16 February 2024
Tethering A BIER Router To A BIER incapable Router
draft-ietf-bier-tether-05
Abstract
This document specifies optional procedures to optimize the handling
of Bit Index Explicit Replication (BIER) incapable routers, by
attaching (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", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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 19 August 2024.
Zhang, et al. Expires 19 August 2024 [Page 1]
Internet-Draft bier-tether February 2024
Copyright Notice
Copyright (c) 2024 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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Additional Considerations . . . . . . . . . . . . . . . . . . 3
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. IGP Signaling and Calculation . . . . . . . . . . . . . . 5
3.2. BGP Signaling . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Consider the scenario in Figure 1 where router X does not support
BIER.
------ BFR2 ------- BFER2
/
BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3
.........
\
------ BFRn ------- BFERn
Figure 1: Deployment with BIER incapable routers
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.
Zhang, et al. Expires 19 August 2024 [Page 2]
Internet-Draft bier-tether February 2024
A solution to the inefficient tunneling from BFRs is to attach
(tether) a BFRx to X as depicted in Figure 2:
------ BFR2 ------- BFER2
/
BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3
/ \ .........
/ \
BFRx ------ BFRn ------- BFERn
Figure 2: Tethered BFRx
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 Interior Gateway Protocol (IGP) as a forwarding
adjacency so that BFRx will appear on the Shortest Path First (SPF)
tree. This needs 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. 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
specification [RFC8279].
2. Additional Considerations
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.
Additionally, the helper BRFx can be a transit helper, i.e., it has
other connections (instead of being a stub helper that is only
connected to X), as long as BFRx won't send BIER packets tunneled to
it back towards the tunnel ingress. Figure 3 below is a simple case:
Zhang, et al. Expires 19 August 2024 [Page 3]
Internet-Draft bier-tether February 2024
------ BFR2 ------- BFER2
/
BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3
|
|
BFRx ------ BFR4 ------- BFER4
\
------ BFR5 ------- BFER5
Figure 3: A Safe Transit Helper
In the example of Figure 4, there is a connection between BFR1 and
BFRx. If the link metrics are all 1 on the three sides of
BFR1-X-BFRx triangle, loop won't happen but if the BFRx-X metric is 3
while other two sides of the triangle has metric 1 then BFRx will
send BIER packets tunneled to it from BFR1 back to BFR1, causing a
loop.
------ BFR2 ------- BFER2
/
BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3
\ / \ .........
\ / \
BFRx ------ BFRn ------- BFERn
Figure 4: Potential looping situation
This can easily be prevented if BFR1 does an SPF calculation with the
helper BFRx as the root. For any BFERn reached via X from BFR1, if
BFRx's SPF path to BFERn includes BFR1 then BFR1 must not use the
helper. Instead, BFR1 must directly tunnel packets for BFERn to X's
BFR (grand-)child on BFR1's SPF path to BFERn, per section 6.9 of
[RFC8279].
Notice that this SPF calculation on BFR1 with BFRx as the root is not
different from the SPF done for a neighbor as part of Loop-Free
Alternate (LFA) calculation. In fact, BFR1 tunneling packets to X's
helper is not different from sending packets to a LFA backup.
Also notice that, instead of a dedicated helper BFRx, any one or
multiple ones of BFR2..N can also be the helper (as long as the
connection between that BFR and X has enough bandwidth for
replication to multiple helpers through X). To allow multiple
helpers to help the same non-BFR, the "I am X's helper" advertisement
carries a priority. BFR1 will choose the helper advertising the
highest priority among those satisfying the loop-free condition
described above. When there are multiple helpers advertising the
Zhang, et al. Expires 19 August 2024 [Page 4]
Internet-Draft bier-tether February 2024
same priority and satisfying the loop-free condition, any one or
multiple ones could be used solely at the discretion of BFR1.
However, if multiple ones are used, it means that multiple copies may
be tunneled through X.
The situation in Figure 5 where a helper BFRxy helps two different
non-BFRs X and Y also works. It's just a special situation of a
transit helper.
----- BFR2 ------- BFER2
/
X ------- BFR3 ------- BFER3
/ | \
/ \ ----- BFR4 ------- BFER4
/ \
BFER1 -- BFR1 BFRxy ------------- BFERxy
\ /
\ / ----- BFR5 ------- BFER5
\ | /
Y ------- BFR6 ------- BFER6
\
----- BFRn ------- BFERn
Figure 5: One Helper for multiple helped
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.
3.1. IGP Signaling and Calculation
Suppose that the BIER domain uses BIER signaling extensions to ISIS
[RFC8401] or OSPF [RFC8444]. The helper node (BFRx) MUST advertise
one or more BIER Helped Node sub-sub-TLVs in the BIER Info sub-TLV in
the case of ISIS or BIER Helped Node sub-TLVs in the BIER sub-TLV in
the case of OSPF, one for each helped node:
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 | Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address of the Helped Node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zhang, et al. Expires 19 August 2024 [Page 5]
Internet-Draft bier-tether February 2024
The Type is TBD1 (in the case of ISIS), TBD2 (in the case of OSPFv2),
or TBD3 (in the case of OSPFv3). The Value field starts with a one-
octet Priority field, followed by a one-octet Reserved field, and
then the Address of the Helped Node (X). The Length is 6 for IPv4
and 18 for IPv6 respectively.
The post-SPF processing procedures in Section 6.9 of the BIER
architecture specification [RFC8279] are modified as following for
BIER tethering purpose.
At step 2, the removed node is added to an ordered list maintained
with each child that replaces the node. If the removed node already
has a non-empty list maintained with itself, add the removed node to
the tail of the list and copy the list to each child.
At the end, the calculating node BFR-B would use a unicast tunnel to
reach next hop BFRs for some BFERs. The next hop BFR has an ordered
list created at step 2 above, recording each BIER incapable node
replaced by their children along the way. For a particular BFER to
be reached via a tunnel to the next hop BFR, additional procedures
are performed as following.
* Starting with the first node in the ordered list of incapable
nodes, say N1, check if there is one or more helper nodes for N1.
If not, go the next node in the list.
* Order all the helper nodes of N1 based descending (priority, BIER
prefix). Starting with the first one, say H1, check if BFR-B
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
not, go to the next helper in order.
* If none of the helper nodes of N1 can be used, go to the next node
in the list of incapable nodes.
If the above procedure finishes without finding any helper, then the
original BFR next hop via a tunnel is used to reach the BFER.
3.2. BGP Signaling
Suppose that the BIER domain uses BGP signaling
[I-D.ietf-bier-idr-extensions] instead of IGP. BFR1..N advertises
BIER prefixes that are reachable through them, with BIER Path
Attributes (BPA) attached. There are three situations regarding X's
involvement:
(1) X does not participate in BGP peering at all
Zhang, et al. Expires 19 August 2024 [Page 6]
Internet-Draft bier-tether February 2024
(2) X re-advertises the BIER prefixes but it does not update the
BPA, as specified in [I-D.ietf-bier-idr-extensions].
In either case, the BFR1..N will tunnel BIER packets directly to each
other. It works but not efficiently as explained earlier.
To make tethering work well with BGP signaling, the following can be
done:
* Configure BGP sessions between X and BFR1..N and BFRx.
* When X re-advertises BIER prefixes to BFRx, it does not change
BIER Nexthop [I-D.ietf-bier-idr-extensions] in the BPA. When X
re-advertises BIER prefixes to BFR1..N, it does change the BIER
Nexthop to BFRx.
* BFRx advertises its own BIER prefix with BPA to X, and sets the
BIER Nexthop to itself. X then re-advertises BFRx's BIER prefix
to BFR1..N.
With the above, BFR1..N will tunnel BIER packets to BFRx (following
the BIER Nexthop), who will then tunnel packets to other BFRs (again
following the BIER Nexthop).
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 a new sub-sub-TLV type value from the "Sub-
sub-TLVs for BIER Info Sub-TLV" registry in the "IS-IS TLV
Codepoints" registry:
Type Name
---- ----
TBD1 BIER Helped Node
This document requests a new sub-TLV type value from the OSPFv2
Extended Prefix TLV Sub-TLV registry:
Type Name
---- ----
TBD2 BIER Helped Node
Zhang, et al. Expires 19 August 2024 [Page 7]
Internet-Draft bier-tether February 2024
This document also requests a new sub-TLV type value from the OSPFv3
Extended-LSA Sub-TLVs registry:
Type Name
---- ----
TBD3 BIER Helped Node
6. Contributors
The following also contributed to this document.
Zheng(Sandy) Zhang
ZTE Corporation
EMail: zzhang_ietf@hotmail.com
Hooman Bidgoli
Nokia
EMail: hooman.bidgoli@nokia.com
7. Acknowledgements
The author wants to thank Eric Rosen and Antonie Przygienda for their
review, comments and suggestions.
8. Normative References
[I-D.ietf-bier-idr-extensions]
Xu, X., Chen, M., Patel, K., Wijnands, I., Przygienda, T.,
and Z. J. Zhang, "BGP Extensions for BIER", Work in
Progress, Internet-Draft, draft-ietf-bier-idr-extensions-
10, 13 June 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-bier-idr-extensions-10>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
Zhang, et al. Expires 19 August 2024 [Page 8]
Internet-Draft bier-tether February 2024
[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
Zhaohui Zhang
Juniper Networks
Email: zzhang@juniper.net
Nils Warnke
Deutsche Telekom
Email: Nils.Warnke@telekom.de
IJsbrand Wijnands
Arrcus
Email: ice@braindump.be
Daniel Awduche
Verizon
Email: daniel.awduche@verizon.com
Zhang, et al. Expires 19 August 2024 [Page 9]
