BIER Zhaohui. Zhang
Internet-Draft Shaowen. Ma
Intended status: Standards Track Juniper Networks
Expires: September 6, 2018 Zheng. Zhang
ZTE Corporation
March 5, 2018
Supporting BIER with RIFT
draft-zzhang-bier-rift-00
Abstract
This document specifies extensions to RIFT protocol to support BIER.
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 September 6, 2018.
Copyright Notice
Copyright (c) 2018 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
Zhang, et al. Expires September 6, 2018 [Page 1]
Internet-Draft bier-rift March 2018
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. Advertising BIER Information For non-MPLS Encapsulation . . . 3
4. Advertising BIER Information Northbound . . . . . . . . . . . 4
5. Advertising BIER Information Southbound . . . . . . . . . . . 4
5.1. Local BIER Information . . . . . . . . . . . . . . . . . 4
5.2. Proxied BFR-ID Ranges . . . . . . . . . . . . . . . . . . 4
6. Information Elements Schema . . . . . . . . . . . . . . . . . 5
6.1. bier.thrift . . . . . . . . . . . . . . . . . . . . . . . 5
6.2. Additions to encoding.thrift . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Terminologies
Familiarity with BIER and RIFT protocols and procedures is assumed.
Some terminologies are listed below for convenience.
[To be added.]
2. Introduction
BIER [RFC8279] ... (to be expanded)
RIFT [I-D.przygienda-rift] is a new protocol specifically designed
for CLOS and fat-tree network topologies. As a hybrid between Link
State Routing and Distance Vector Routing, it does LSR in northbound
(towards the spine) and DVR in southbound (towards the leaves).
[I-D.ietf-bier-isis-extensions] and
[I-D.ietf-bier-ospf-bier-extensions] specify ISIS/OSPF extensions to
support BIER in an ISIS/OSPF domain. The same approach applies to
RIFT in the northbound LSR.
[I-D.zwzw-bier-prefix-redistribute] specifies methods to advertise
BIER information via default or summary/aggregate routes advertised
Zhang, et al. Expires September 6, 2018 [Page 2]
Internet-Draft bier-rift March 2018
from one IGP area/domain to another. Similar approach applies to
RIFT in the southbound DVR.
BIER encapsulation, whether it is based on MPLS or not, is covered in
[RFC8296]. However, the OSPF/ISIS extensions for BIER only covers
signaling needed for MPLS encapsulation. RIFT is targeted at DC
deployments, where MPLS may not be used. This document covers
signaling for both BIER MPLS and non-MPLS encapsulation with RIFT.
The details are provided in following sections.
3. Advertising BIER Information For non-MPLS Encapsulation
In the BIER architecture, a BIER sub-domain may have multiple
BitStringLengths (BSLs) and multiple Encapsulations (Encaps). A
single multicast packet coming from outside the BIER sub-domain may
be sent as multiple BIER packets, one for each set that is identified
by a SetID (SI). An incoming BIER packet is forwarded according to a
BIFT for the <SD,Encap,BSL,SI> tuple. Each BIFT is identified by a
20-bit opaque number (BIFT-ID) in the packet.
With MPLS encapsulation, the BIFT-ID for an incoming BIER packet is
simply an MPLS label allocated by the receiving BFR for the BIFT.
For each <SD,BSL> tuple, OSPF/ISIS advertises a block of contiguous
labels, one label for each SI needed for the tuple, in the MPLS
Encapsulation sub-sub-TLV as part of the BIER sub-TLV, which is
attached to the Extended Reachability TLV (ISIS case) or the Extended
Prefix TLV (OSPF case) for the BFR's BIER Prefix.
With non-MPLS encapsulation, the BIFT-ID in the packet is at the same
position as the label in MPLS encapsulation case. Its semantics is
no different from the MPLS case in that as an 20-bit opaque value, it
leads to the BIFT according to which the BIER packet is forwarded.
Beyond the semantics, there are two differences from the MPLS case
though:
o MPLS infrastructure is not needed.
o While each BFR could allocate local BIFT-IDs independently and
advertise them just like in MPLS case, for the same
<SD,Encap,BSL,SI> tuple all BFRs could optionally auto-derive or
be provisioned with the same BIFT-ID and no signaling is needed in
that case.
One may consider that if MPLS would allow to use consistently
provisioned BIER labels on all BFRs, then the second difference
listed above does not exist anymore.
Zhang, et al. Expires September 6, 2018 [Page 3]
Internet-Draft bier-rift March 2018
In this specification, if locally significant BIFT-IDs are to be used
with non-MPLS encapsulation, the BIFT-IDs are advertised the same way
as in the MPLS case - by a BIFT-ID block, which is a block of
contiguous labels in MPLS case or a block of contiguous opaque 20-bit
values in non-MPLS case. The only difference is the type of
encapsulation.
If consistently provisioned or auto-derived BIFT-IDs are used with
non-MPLS encapsulation, then no BIFT-ID block is signaled. Just the
encapsulation type is signaled.
4. Advertising BIER Information Northbound
Nothing special here compared to OSPF/ISIS. A node's local BIER
information as described in the previous section is attached to a
local BIER Prefix. Details to be added.
5. Advertising BIER Information Southbound
5.1. Local BIER Information
Similar to the northbound case, a node's local BIER information is
attached to a local BIER prefix that is advertised southbound.
5.2. Proxied BFR-ID Ranges
On the southbound, a node advertises a default route, plus certain
prefixes to prevent blackholing or suboptimal routing upon link
failures. Those prefixes and default route are like the summary
routes and default route in [I-D.zwzw-bier-prefix-redistribute], and
similarly they carry BFR-IDs corresponding to the covered BIER
Prefixes.
Consider a RIFT network with a BIER sub-domain of 200 BFIR/BFERs.
Each non-leaf node is provisioned that BFR-ID 1-200 are used.
Suppose a node X advertise southbound a default route RT1 and
disaggregation routes RT2/RT3. RT2 and RT3 MUST advertise BFR-IDs
covered by them (e.g. BFR-ID 100/102/150 covered by RT2 and BFR-ID
101/103 covered by RT3), while the default route RT1 can always
advertise that all BFR-ID 1~200 are covered by it and does not need
to exclude BFR-ID 100/102/150 and 101/103 that are covered by RT2/
RT3. When a southern node receives RT1 and RT2/RT3, it installs BFR-
ID 100/102/150 in its BIFT according to RT2, 101/103 in its BIFT
according to RT3, and installs other BFR-IDs (or just a default
route) in its BIFT according to RT1.
Zhang, et al. Expires September 6, 2018 [Page 4]
Internet-Draft bier-rift March 2018
6. Information Elements Schema
This document introduces a bier.thrif schema with definitions to be
used in RIFT encoding.thrift.
6.1. bier.thrift
typedef i8 SubdomainIdType
typedef i16 BfrIdType
typedef i8 BARType
typedef i8 IPAType
typedef i16 BSLType /* Number of bits */
typedef i32 BiftIdType /* Only the most significant 20 bits are used */
enum EncapsulationType {
mpls = 0;
non-mpls = 1;
}
/* Similar to the label range in OSPF/ISIS extensions for BIER */
struct BiftIdBlock {
1: required BiftIdType bift_id_base;
2. required i8 bift_id_range;
}
/* Similar to the MPLS Encapsulation sub-sub-TLV in OSPF/ISIS */
struct EncapStruct {
1: required EncapsulationType encap_type;
2: required BSLType bsl;
3: optional BiftIdBlock bift_id_block;
}
/*BIER node information. Similar to BIER sub-TLV in OSPF/ISIS. */
struct BierInfo {
1: required SubdomainIdType subdomain_id;
2: required BfrIdType bfr_id;
3: required BARType bar;
4: required IPAType ipa;
5. required EncapStruct encaps; /* one or more */
}
struct ProxyBfrIdRange {
1: required SubdomainIdType subdomain_id;
2: required BfrIdType bfr_id_base;
3: required BSLType bfr_id_range;
}
Zhang, et al. Expires September 6, 2018 [Page 5]
Internet-Draft bier-rift March 2018
6.2. Additions to encoding.thrift
The PrefixAttributes in encoding.rift now has two optional elements:
struct PrefixAttributes {
...
2: optional BierInfo bier_info; /* BIER info for a
* local BIER Prefix */
3. optional ProxyBfrIdRange proxy_bfr_id; /* one or more proxy
* BFR-ID ranges covered
* by this prefix */
}
7. IANA Considerations
8. Acknowledgements
9. References
9.1. Normative References
[I-D.przygienda-rift]
Przygienda, T., Sharma, A., Atlas, A., and J. Drake,
"RIFT: Routing in Fat Trees", draft-przygienda-rift-05
(work in progress), March 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>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>.
9.2. Informative References
Zhang, et al. Expires September 6, 2018 [Page 6]
Internet-Draft bier-rift March 2018
[I-D.ietf-bier-isis-extensions]
Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang,
"BIER support via ISIS", draft-ietf-bier-isis-
extensions-09 (work in progress), February 2018.
[I-D.ietf-bier-ospf-bier-extensions]
Psenak, P., Kumar, N., Wijnands, I., Dolganow, A.,
Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions
for BIER", draft-ietf-bier-ospf-bier-extensions-15 (work
in progress), February 2018.
[I-D.zwzw-bier-prefix-redistribute]
Zhang, Z., Bo, W., Zhang, Z., and I. Wijnands, "BIER
Prefix Redistribute", draft-zwzw-bier-prefix-
redistribute-00 (work in progress), January 2018.
Authors' Addresses
Zhaohui Zhang
Juniper Networks
EMail: zzhang@juniper.net
Shaowen Ma
Juniper Networks
EMail: mashao@juniper.net
Zheng Zhang
ZTE Corporation
EMail: zhang.zheng@zte.com.cn
Zhang, et al. Expires September 6, 2018 [Page 7]