Internet DRAFT - draft-zzhang-bier-anycast
draft-zzhang-bier-anycast
BIER Working Group Z. Zhang
Internet-Draft Juniper Networks
Updates: 8279, 8401, 8444 (if approved) I. Wijnands
Intended status: Standards Track Arrcus
Expires: 9 August 2024 Z. Zhang
ZTE
M. Mishra
Cisco Systems
H. Chen
Futurewei
6 February 2024
BIER with Anycast
draft-zzhang-bier-anycast-03
Abstract
BIER architecture currently does not support anycast, in that each
BIER Forwarding Router (BFR) has its own unique BFR-prefix and BFR-
ID. BIER signaling protocols also check if there are duplicate BFR-
IDs advertised. This document discusses and specifies anycast
support with BIER. It updates RFC 8279, RFC 8401 and RFC 8444.
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 9 August 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Zhang, et al. Expires 9 August 2024 [Page 1]
Internet-Draft BIER-anycast February 2024
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. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4. Normative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
BIER architecture currently does not support anycast, in that each
BIER Forwarding Router (BFR) has its own unique BFR-prefix and BFR-
ID. BIER signaling protocols [RFC8401] [RFC8444] require the
checking for, and logging of duplicate BFR-IDs in advertisements, and
require duplicate BFR-IDs be treated as zero, i.e., those BFRs
advertising duplicate BFR-IDs will not be treated as BIER Forwarding
Ingress Routers (BFIR) or BIER Forwarding Egress Routers (BFER).
However, anycast is widely used in networks and it is desired and
feasiable to support anycast addresses as BFR-prefixes, especially
for egress protection purposes.
In a simple egress protection scenario, a flow overlay node N1
connects to BFER1 and BFER2 that advertise the same anycast BFR-
prefix with the same BFR-ID. For traffic that node N1 needs to
receive, a BFIR can set the bit corresponding to the BFR-ID in the
BitString. Either BFER1 or BFER2 will receive the traffic and
deliver to N1 after removing the BIER header. If it is desired for
BFER1 to be the primary while BFER2 to be the backup, then BFER2 can
advertise with a higher cost.
+-----+
+----+ |BFER1|_________+--+
|BFIR| +-----+ /|N1|
+----+ +-----+_______/ +--+
|BFER2|
+-----+
Zhang, et al. Expires 9 August 2024 [Page 2]
Internet-Draft BIER-anycast February 2024
In a more complicated scenario, a flow overlay node N1 may connect to
BFER1 and BFER2, while another node N2 may connect to BFER2 and
BFER3. In this case, BFER1 and BFER2 need to advertise an anycast
BFR-prefix1 while BFER2 and BFER3 need to advertise another anycast
BFR-prefix2.
+-----+
|BFER1|_________+--+
+-----+ /|N1|
+----+ +-----+_______/ +--+
|BFIR| |BFER2|_________+--+
+----+ +-----+ /|N2|
+-----+_______/ +--+
|BFER3|
+-----+
In this scenario, BFER2 advertises two anycast BFR-prefixes and two
corresponding BFR-IDs. Its BIFTs will have two entries for
decapsulation with local forwarding. A packet arriving on BFER2 may
have both bits set (for the two BFR-IDs corresponding to the two
anycast BFR-prefixes), or two copies of the same packet may arrive on
BFER2 (each with a different bit of the two bits being set). In both
cases, the flow overlay needs to make sure that N1 receives a copy
corresponding to one bit while N2 receives a copy corresponding to
the other bit. Flow overlay procedures that may be used/needed for
various protection scenarios will be specified in a separate
document.
Since each unique BFR-prefix needs a unique BFR-ID that takes one bit
position in the BitString, a network designer should minimize the
number of anycast BFR-prefixes. Limiting egress protection to the
first scenario where flow overlay nodes are uniformly connected is
recommended.
In both example scenarios above, there is no need for the BFERs to
advertise a non-anycast BFR-prefixes. Of course, there may be
scenarios where both anycast and non-anycast BFR-prefixes are
advertised by a BFER.
Zhang, et al. Expires 9 August 2024 [Page 3]
Internet-Draft BIER-anycast February 2024
All BFRs need to allow a non-zero BFR-ID advertised with the same
BFR-prefix from different BFRs. An operator needs to ensure that all
BFRs allow it when the anycast functionality is needed. At the
protocol level, there is no need to signal a BFR's capability of
allowing this. Signaling the capability will not help backward
compatiblity, but existence of BFRs not supporting the enhanced
detection procedure will not cause issues other than that the BFERs
with anycast BFR-IDs may not receive traffic. The operator needs to
upgrade those BFRs if the anycast functionaly is desired, and the
required error reporting from those BFRs can help the operator
identify the problem.
2. Specification
This document updates [RFC8279], [RFC8401], [RFC8444],
[I-D.ietf-bier-ospfv3-extensions],
[I-D.ietf-bier-lsr-non-mpls-extensions] and
[I-D.ietf-bier-idr-extensions] to allow BFERs advertise anycast
addresses as BFR-prefixes.
When a BIER signaling protocol checks for and logs duplicated BFR-IDs
in routing advertisements, only the same BFR-ID advertised with
different BFR-prefixes is considered as duplicate. The same BFR-
prefix MAY be advertised by different BFRs, but they MUST all
advertise the same BFR-ID.
It is RECOMMENDED that only BFERs advertises anycast BFR-prefixes. A
transit BFR (with BFR-ID 0) SHOULD NOT advertise anycast BFR-
prefixes, though otherwise the only consequence is additional useless
advertisement.
A BFER MAY advertise one non-anycast BFR-prefix and MAY advertise one
or more anycast BFR-prefixes. Multiple BFERs MAY advertise the same
anycast BFR-prefix. The same anycast BIER-prefix MUST be advertised
with the same non-zero BFR-ID.
Each BFR-prefix in a BIER sub-domain MUST have a unique BFR-ID if it
is not zero.
A BFER may be a BFIR at the same time. If a BFIR advertises one or
more anycast BFR-prefixes, it MUST uses the BFD-ID associated with
its non-anycast BFR-prefix in the BIER header that it imposes, unless
it is ok to associate the packet with any of the BFIRs having the
same anycast BFR-prefix whose BFR-ID is used in the BIER header.
Zhang, et al. Expires 9 August 2024 [Page 4]
Internet-Draft BIER-anycast February 2024
3. Security Considerations
This document does not introduce any new security concerns besides
what has been discussed in [RFC8279] or what is associated with
anycast.
4. 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>.
[I-D.ietf-bier-lsr-non-mpls-extensions]
Dhanaraj, S., Yan, G., Wijnands, I., Psenak, P., Zhang, Z.
J., and J. Xie, "LSR Extensions for BIER non-MPLS
Encapsulation", Work in Progress, Internet-Draft, draft-
ietf-bier-lsr-non-mpls-extensions-02, 27 January 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier-
lsr-non-mpls-extensions-02>.
[I-D.ietf-bier-ospfv3-extensions]
Psenak, P., Nainar, N. K., and I. Wijnands, "OSPFv3
Extensions for BIER", Work in Progress, Internet-Draft,
draft-ietf-bier-ospfv3-extensions-07, 1 December 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier-
ospfv3-extensions-07>.
[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>.
Zhang, et al. Expires 9 August 2024 [Page 5]
Internet-Draft BIER-anycast February 2024
Authors' Addresses
Zhaohui (Jeffrey) Zhang
Juniper Networks
Email: zzhang@juniper.net
IJsbrand Wijnands
Arrcus
Email: ice@braindump.be
Zheng Zhang
ZTE
Email: zhang.zhen@zte.com.cn
Mankamana Mishra
Cisco Systems
Email: mankamis@cisco.com
Huaimo Chen
Futurewei
Email: Huaimo.chen@futurewei.com
Zhang, et al. Expires 9 August 2024 [Page 6]
