BIER Zheng. Zhang
Internet-Draft ZTE Corporation
Intended status: Standards Track Bo. Wu
Expires: March 26, 2020 Individual
Zhaohui. Zhang
Juniper Networks
IJsbrand. Wijnands
Cisco Systems, Inc.
September 23, 2019
BIER Prefix Redistribute
draft-zwzw-bier-prefix-redistribute-03
Abstract
This document defines a BIER proxy function to interconnect different
underlay routing protocol areas in a network. And a new BIER proxy
range sub-TLV is also defined to convey BIER BFR-id information
across the routing areas.
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 March 26, 2020.
Zhang, et al. Expires March 26, 2020 [Page 1]
Internet-Draft BIER Prefix Redistribute September 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
(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. Problem statement . . . . . . . . . . . . . . . . . . . . . . 2
2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Advertisement . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. BIER proxy range sub-TLV . . . . . . . . . . . . . . . . 6
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Problem statement
Zhang, et al. Expires March 26, 2020 [Page 2]
Internet-Draft BIER Prefix Redistribute September 2019
+-------------------------------------------------------+
| +----+ +----+ PIM |
| +----+ R1 +-------------+ R2 +-----+ |
| | +----+ +----+ | |
| | | |
| | OSPF area 0 / ISIS | |
| | | |
| | +----+ +----+ | |
| +-----+ +------------+ +-----+ |
| +------------+ R3 +---+ +---+ R4 +------------+ |
| | +----+ | | +----+ | |
| | | | | |
| | OSPF area 1 | | OSPF area 2 | |
| | | | | |
| | +----+ +----+ | | +----+ +----+ | |
| +--+ Rm +-----+ Rn +--+ +---+ Rx +----+ Ry +--+ |
| +----+ +----+ +----+ +----+ |
+-------------------------------------------------------+
Figure 1
Figure 1 shows that there are three areas in a traditional network.
In some deployment situations, different routing protocols may also
be used in a network. There are just small number of routers in each
area of the network. Currently, multicast services are provided in
this hybrid network by using protocol independent feature of PIM.
BIER could be a candidate multicast protocol to replace PIM to reduce
multicast states in the hybrid network. BIER [RFC8279] is a new
architecture for the forwarding of multicast data packets. It does
not require a protocol for explicitly building multicast distribution
trees, nor does it require intermediate nodes to maintain any per-
flow state. In order to build BIER forwarding plane, BIER key
parameters must be flooded in one BIER domain such as BFR-prefix,
BFR-id, subdomain-id, and so on. The routing protocols which are
used to flood these BIER parameters are called BIER routing underlay.
The associated routing protocol extensions are defined in documents
such as [RFC8401], [RFC8444], [I-D.ietf-bier-idr-extensions],
[I-D.ietf-bier-ospfv3-extensions], and so on.
Zhang, et al. Expires March 26, 2020 [Page 3]
Internet-Draft BIER Prefix Redistribute September 2019
+----+ +----+
+----+ R1 +-------------+ R2 +-----+
| +----+ +----+ |
| OSPF / ISIS |
| BIER domain 1 |
| |
| +----+ +----+ |
+-----+ +------------+ +-----+
+------------+ R3 +---+ +---+ R4 +------------+
| +----+ | | +----+ |
| OSPF | | OSPF |
| | | |
| BIER domain 2 | | BIER domain 3 |
| +----+ +----+ | | +----+ +----+ |
+--+ Rm +-----+ Rn +--+ +---+ Rx +----+ Ry +--+
+----+ +----+ +----+ +----+
Figure 2
Based on the BIER design, a BIER domain is limited by the underlay
routing protocols flooding scope. As in a hybrid network depicted in
figure 2, in case we want deploy BIER instead of PIM, there are
several BIER domains because of different underlay routing protocols
limitation. Multiple encapsulating/ decapsulation executions are
needed to across multiple BIER domains. These executions slow down
the forwarding efficiency. The border routers also need to maintain
overlay state, which is undesired.
Except the hybrid network, there is the situation that several areas
formed by one same IGP protocol need to be merged into one BIER
domain in existing network. The prefix redistribution method defined
in this document can be used too.
2. Proposal
Zhang, et al. Expires March 26, 2020 [Page 4]
Internet-Draft BIER Prefix Redistribute September 2019
+-------------------------------------------------------+
| +----+ +----+ BIER |
| +----+ R1 +-------------+ R2 +-----+ domain 1 |
| | +----+ +----+ | |
| | OSPF/ISIS | |
| | | |
| | +----+ +----+ | |
| +-----+ +------------+ +-----+ |
| +------------+ R3 +---+ +---+ R4 +------------+ |
| | +----+ | | +----+ | |
| | | | | |
| | OSPF area 1 | | OSPF area 2 | |
| | | | | |
| | +----+ +----+ | | +----+ +----+ | |
| +--+ Rm +-----+ Rn +--+ +---+ Rx +----+ Ry +--+ |
| +----+ +----+ +----+ +----+ |
+-------------------------------------------------------+
Figure 3
It is more efficient to deploy BIER by creating one BIER domain for
the hybrid network to achieve forwarding benefit.
Since the limitation of the BIER routing protocol scope, BFR-id is
confined to only one routing area. A BIER proxy function is
introduced to transport BIER BFR-id information in a BIER domain
across multiple routing protocol areas. So BIER forwarding tables
can be built across multiple underlay routing protocols to replace
encapsulation/decapsulation processing. In the current deployment,
border router (ABR) has a similar role, ABR summaries unicast routing
information from one routing protocol area and sends it to another
routing area by new routing protocol messages. So ABR can implement
BIER proxy function to summarize BIER BFR-id information from one
routing protocol area and sends it to another routing area.
In figure 3, R3 and R4 connect two areas which running different
routing protocols, they can be used as BIER proxies to transport BIER
information. For example, after R3 receives BFR-ids information from
OSPF area 1 and sends it to ISIS routing area, the routers in ISIS
routing area can generate BIER forwarding items toward the BFR-ids in
OSPF area 1. Similarly, R3 receives BFR-ids information from ISIS
area and sends it to OSPF area 1, the routers in OSPF area 1 can
build BIER forwarding items toward the BFR-ids in ISIS area. R4 does
the same function, the BIER forwarding plane is constructed
accordingly.
Zhang, et al. Expires March 26, 2020 [Page 5]
Internet-Draft BIER Prefix Redistribute September 2019
3. Advertisement
According to [RFC8279], each BFER needs to have a unique (in each
sub-domain) BFR-id, and each BFR and BFER floods itself BIER info
sub-TLV and associated sub-sub-TLVs in the BIER domain. To keep
consistent with the definition in [RFC8444],
[I-D.ietf-bier-ospfv3-extensions], and [RFC8401], BIER info sub-TLV
defined in [RFC8401] and BIER sub-TLV defined in [RFC8444],
[I-D.ietf-bier-ospfv3-extensions] is reused to convey the BFR-id
information. OSPF extended Prefix Opaque LSA [RFC7684] and TLVs 235,
237 defined in [RFC5120], or TLVs 135 [RFC5305], or TLV 236 [RFC5308]
are still used to carry the BFR-id / BFR-prefix information.
The key parameters got from the original routing protocol should be
adapted to the format of next routing protocol, such as BFR-prefix,
BFR-id, subdomain-id, and so on. Some parameters like BAR, MT-ID has
local significance, So they should be set to same values with BIER
proxy own advertisement when BIER proxy advertise them to the next
routing area.
And as the two BIER info sub-sub-TLVs (sub-TLVs) including MPLS
encapsulation and BSL conversion also have local significance. The
information carried in these two sub-sub-TLV need not, but MAY, be
advertised to next routing area.
3.1. BIER proxy range sub-TLV
In case unicast default route and aggregated / summarized routes are
used in some routing areas and routers in next area can not see the
specific BFR-prefix routes from original area, the prefix advertised
should be set to default route or aggregated / summarized routes.
Like in figure 3, in case R3/R4 does not advertise specific ISIS
unicast routes to OSPF area and only advertises unicast default route
or aggregated / summarized route to OSPF area 1/2, when R3/R4
advertises BIER info sub-TLV to OSPF area 1/2, R3 MUST advertise the
prefix with default route or aggregated / summarized route. In that
case, multiple BFR-ids will be mapped to one prefix. In order to
advertise BFR-ids optimally, we define a new BIER proxy range sub-TLV
to advertise the information of BFR-ids.
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 | subdomain-id | resv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFR-id | BFR-id range |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zhang, et al. Expires March 26, 2020 [Page 6]
Internet-Draft BIER Prefix Redistribute September 2019
o Type: TBD to indicate the BIER proxy range sub-TLV.
o Length: variable.
o Subdomain-id: The subdomain-id from original advertisement.
o resv: The reserved field.
o BFR-id: The first BFR-id from original advertisement.
o BFR-id range: The range of BFR-ids with one subdomain-id.
The BIER proxy range sub-TLV is attached to the aggregated /
summarized route prefix or default route prefix. The summarized /
aggregated / default prefix may need multiple BIER proxy range sub-
TLVs if the BFR-ids covered by the prefix are allocated from
different ranges (even if they're from a single range but if some
BFR-ids in the range map to some BIER prefixes that are covered by a
different summarized / aggregated prefix, then that single large
range needs to be broken into smaller ranges).
The BFR-ids associated with the summarized prefix can be advertised
individally in the BIER range sub-TLV. Though BFR-id's range can
increase advertisement efficiency, necessary configuration / policy
should be provided to guide the range generation of BFR-ids.
Otherwise unwanted amount of updates may occur when a BFR-id is
removed from the range.
Because a summarized / default prefix covers many BIER prefixes, the
mapping between a BIER prefix and its BFR-id is no longer conveyed in
the routing underlay. As a result, the mapping must be provided by
other means, e.g. in the multicast overlay.
4. Example
As in figure 3, R3 and R4 as BIER proxy, R3 as an example should
advertise the BIER BFR-ids information from ISIS area to OSPF area 1
with the advertiser set to R3 itself, and advertise BIER info from
OSPF area 1 to ISIS area as well. In case R3 and R4 generates
specific BFR-prefix and BFR-ids from the original area to the next
area, BIER info sub-TLV defined in [RFC8401] and BIER sub-TLV defined
in [RFC8444], or [I-D.ietf-bier-ospfv3-extensions] is reused to
convey the BFR-id information. All the routers generate BIER
forwarding items to other area toward BIER proxy according to
[RFC8279].
In case BIER proxy can not advertise specific BFR-prefix but
aggregated / summarized / default prefix from the original area to
Zhang, et al. Expires March 26, 2020 [Page 7]
Internet-Draft BIER Prefix Redistribute September 2019
the next area, BIER proxy range sub-TLV is used to convey the
information. Suppose that Rm is an ingress router, R1, R2, Rx and Ry
is egress router, the BFR-ids of these egress router are 31, 55, 112,
157. The BFR prefixes of them are 10.1.1.5, 10.1.1.50, 203.1.1.10,
203.1.1.60. Suppose that summarized prefixes are advertised into
OSPF area. The summarized prefixes are 10.1.1.0/24 and 203.1.1.0/24.
All the routers in OSPF area 1 compute forwarding table for unicast /
BIER according to the summarized prefixes, and they can get to these
prefixes by routes toward proxy R3.
Rm encapsulate multicast flow with BIER header that with 31, 55, 112
and 157 bit set in the BIER header (Supposed that 256 BitStringLength
is used). The routers in OSPF area 1 forward packet toward R3. R3
forwards packet according to the BFR-ids set in the BIER header
normally. Later packet reaches R1, R2 and R4. Similarly, R4
forwards packet into OSPF area 2 normally. Finally packet reaches Rx
and Ry.
5. IANA Considerations
IANA is requested to set up a new types of sub-TLV (TLV) registry
value for BIER proxy range advertisement in OSPF, ISIS, BGP, etc.
6. Security Considerations
Implementations must assure that malformed TLV and Sub-TLV
permutations do not result in errors which cause hard protocol
failures.
7. Acknowledgements
The authors would like to thank Stig Venaas for his valuable comments
and suggestions.
8. 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-07 (work in progress), September 2019.
[I-D.ietf-bier-ospfv3-extensions]
Psenak, P., Kumar, N., and I. Wijnands, "OSPFv3 Extensions
for BIER", draft-ietf-bier-ospfv3-extensions-00 (work in
progress), May 2019.
Zhang, et al. Expires March 26, 2020 [Page 8]
Internet-Draft BIER Prefix Redistribute September 2019
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
DOI 10.17487/RFC5308, October 2008,
<https://www.rfc-editor.org/info/rfc5308>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <https://www.rfc-editor.org/info/rfc7684>.
[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>.
Authors' Addresses
Zheng(Sandy) Zhang
ZTE Corporation
EMail: zzhang_ietf@hotmail.com
Bo Wu
Individual
EMail: w1973941761@163.com
Zhang, et al. Expires March 26, 2020 [Page 9]
Internet-Draft BIER Prefix Redistribute September 2019
Zhaohui Zhang
Juniper Networks
EMail: zzhang@juniper.net
IJsbrand Wijnands
Cisco Systems, Inc.
EMail: ice@cisco.com
Zhang, et al. Expires March 26, 2020 [Page 10]