Internet DRAFT - draft-venaas-bier-pfm-sd
draft-venaas-bier-pfm-sd
Network Working Group S. Venaas
Internet-Draft IJ. Wijnands
Intended status: Experimental M. Mishra
Expires: April 25, 2019 Cisco Systems, Inc.
M. Sivakumar
Juniper Networks
October 22, 2018
PIM Flooding Mechanism and Source Discovery for BIER
draft-venaas-bier-pfm-sd-00
Abstract
PIM Flooding Mechanism and Source Discovery (PFM-SD) is a mechanism
for source discovery within a PIM domain. PIM signaling over BIER
has been defined, allowing for BIER to interoperate with PIM. This
document defines PFM-SD over BIER, such that PFM-SD can be used by
PIM in a PIM domain to discover sources that are reachable via BIER.
Also, this document provides PFM-SD extensions to discover the BIER
ingress router closest to the source. This can be used by BIER
overlays, such as PIM signaling over BIER, to determine which router
to signal.
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 April 25, 2019.
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
Venaas, et al. Expires April 25, 2019 [Page 1]
Internet-Draft PIM Source Discovery for BIER October 2018
(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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. PFM over BIER . . . . . . . . . . . . . . . . . . . . . . . . 3
3. PFM Ingress BIER Router TLV . . . . . . . . . . . . . . . . . 3
4. Group Source Holdtime Metric TLV . . . . . . . . . . . . . . 4
5. BIER signaling enhancements . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
PIM Flooding Mechanism (PFM) and Source Discovery (SD) [RFC8364]
provides a generic flooding mechanism for distributing information
throughout a PIM domain. In particular it allows for source
discovery. There are various deployment scenarios where PIM and BIER
need to co-exist. For instance, consider migration scenarios where a
few routers in a PIM domain are upgraded to support BIER. In that
case, one may use PIM Signaling Through BIER Core
[I-D.ietf-bier-pim-signaling], allowing PIM to build trees passing
through the BIER routers. This document defines PFM over BIER. This
allows PFM to pass through the BIER routers, allowing PFM to be used
in the PIM domain.
One challenge with PIM signaling over BIER
[I-D.ietf-bier-pim-signaling] is to determine which BIER router is
closest to the source. A number of options are discussed in that
document. This document provides an alternative solution for
discovering which BIER router to signal. It may also be used with
other signaling mechanisms such as IGMP/MLD [I-D.ietf-bier-mld].
This is achieved by introducing two new PFM TLVs. When a BIER router
forwards a PFM message into BIER, it adds a new TLV specifying the
BIER sub-domain, its BFR-ID and its BIER prefix. Also, any Group
Source Holdtime TLVs, defined in [RFC8364], are replaced with new
TLVs that include the router's cost of reaching the sources.
Venaas, et al. Expires April 25, 2019 [Page 2]
Internet-Draft PIM Source Discovery for BIER October 2018
1.1. Conventions Used in This Document
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 RFC 2119 [RFC2119].
2. PFM over BIER
When a BIER enabled router accepts a PFM message from a PIM neighbor
according to [RFC8364], it SHOULD in addition to the forwarding
defined in [RFC8364], also send a copy to all BIER routers (an
implementation SHOULD allow the set of BIER routers to send PFM
messages to, to be configured).
When a router receives a BIER encapsulated PFM message, it MUST
process the message according to [RFC8364], except there is no
requirement for the message to come from a PIM neighbor, and there is
no RPF check. The message MUST be forwarded out on the PIM
interfaces according to [RFC8364]. It MAY also be BIER forwarded, if
the router acts as a border router between BIER domains.
3. PFM Ingress BIER Router TLV
When a router is forwarding a PFM message into a BIER domain, it MUST
add this TLV. If the TLV is already present, all occurrences should
be removed. This TLV encodes the BIER prefix, sub-domain ID and BFR-
ID of the router. This TLV SHOULD only be present within the BIER
domain. When a router receives a PFM message with this TLV, all
occurrences of the TLV SHOULD be removed. If the router is
forwarding the message into a new BIER domain, it should add a new
TLV with its own prefix, sub-domain ID and BFR-ID. A PFM message is
expected to have at most one such TLV. A router MUST NOT add more
than one such TLV. When forwarding a PFM message, the TLV in the
received message MUST be removed from the forwarded message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-domain-id | Reserved | BFR-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFR-prefix (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: The Transitive bit is set to 0.
Type: Type is TBD.
Venaas, et al. Expires April 25, 2019 [Page 3]
Internet-Draft PIM Source Discovery for BIER October 2018
Length: The length of the value in octets.
Sub-domain-id: The ID of the sub-domain that this PFM is forwarded
into. The length is 1 octet.
Reserved: MUST be set to 0, and ignored when received. The length
is 1 octet.
BFR-id: The BFR-id of the router that added this TLV in the sub-
domain specified. The length is 2 octets.
BFR-prefix: The BFR-prefix of the router that added this TLV in the
sub-domain specified. This length is 4 octets for IPv4 and 16
octets for IPv6.
4. Group Source Holdtime Metric TLV
When a router forwards a PFM message into a BIER domain, it should
replace all Group Source Holdtime TLVs defined in [RFC8364] with the
Group Source Holdtime Metric TLVs defined here. They are the same,
except here we also add metric preference and metric. The metric
preference and metric MUST be set to this router's metric and
preference to reach the specified source. If the source is not
reachable, the TLV MUST be omitted. This TLV is used together with
the PFM Ingress BIER Router TLV is used to indicate the ingress
router's cost of reaching the source.
When a router receives a message containing this TLV, it SHOULD store
this information, but it MUST NOT forward these TLVs. If forwarding
into another BIER domain, the metric preference and metric MUST be
updated with this router's cost of reaching the source. If
forwarding into a PIM domain, all the TLVs SHOULD be replaced with
Group Source Holdtime TLVs as defined in [RFC8364]. The same
information is used, except that the metric preference and metric are
left out. One could potentially make use of the metric in a PIM
domain as well, but it is not clear whether this is useful, and the
PIM routers may not support this TLV.
Venaas, et al. Expires April 25, 2019 [Page 4]
Internet-Draft PIM Source Discovery for BIER October 2018
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Count | Src Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address 1 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric Preference 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address 2 (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric Preference 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Address m (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric Preference m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric m |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: The Transitive bit is set to 0.
Type: Type is TBD.
Length: The length of the value in octets.
Group Address: The group that sources are to be announced for. The
format for this address is given in the Encoded-Group format in
[RFC7761].
Src Count: The number of source addresses that are included.
Src Holdtime: The Holdtime (in seconds) for the included source(s).
Src Address: The source address for the corresponding group. The
format for these addresses is given in the Encoded-Unicast address
in [RFC7761].
Venaas, et al. Expires April 25, 2019 [Page 5]
Internet-Draft PIM Source Discovery for BIER October 2018
Metric Preference: Preference value assigned to the unicast routing
protocol that provided the route to the source.
Metric: The unicast routing table metric associated with the route
used to reach the source. The metric is in units applicable to
the unicast routing protocol used.
5. BIER signaling enhancements
A BIER border router SHOULD cache all the Group Source Holdtime
Metric TLVs it receives, along with the respective PFM Ingress BIER
Router TLV. This allows the router to determine which sources are
active, and which BIER border router is closest to the source. The
sub-domain ID, BFR-id and BFR-prefix in the TLV provide the necessary
information for use by signaling mechanisms such as
[I-D.ietf-bier-pim-signaling] to signal the preferred ingress router.
It may also be used by [I-D.ietf-bier-mld]. IGMP/MLD reports would
generally be sent to all BIER routers as it is not known which
sources are active and which routers can reach them. But by using
the enhancements in this document, a source-specific report can be
sent to the router closest to the source. Also a group report might
be set to the set of routers that are closest to the sources for that
group. This reduces the amount of receiver state on the BIER
routers, and also the amount of messages each routers needs to
process.
6. Security Considerations
TBD
7. IANA Considerations
This document defines two new PFM TLVs that needs to be assigned from
the "PIM Flooding Mechanism Message Types" registry.
8. References
8.1. Normative References
[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>.
Venaas, et al. Expires April 25, 2019 [Page 6]
Internet-Draft PIM Source Discovery for BIER October 2018
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC8364] Wijnands, IJ., Venaas, S., Brig, M., and A. Jonasson, "PIM
Flooding Mechanism (PFM) and Source Discovery (SD)",
RFC 8364, DOI 10.17487/RFC8364, March 2018,
<https://www.rfc-editor.org/info/rfc8364>.
8.2. Informative References
[I-D.ietf-bier-mld]
Pfister, P., Wijnands, I., Venaas, S., Wang, C., Zhang,
Z., and M. Stenberg, "BIER Ingress Multicast Flow Overlay
using Multicast Listener Discovery Protocols", draft-ietf-
bier-mld-01 (work in progress), June 2018.
[I-D.ietf-bier-pim-signaling]
Bidgoli, H., Dolganow, A., Kotalwar, J., Xu, F., mishra,
m., and Z. Zhang, "PIM Signaling Through BIER Core",
draft-ietf-bier-pim-signaling-04 (work in progress),
October 2018.
Authors' Addresses
Stig Venaas
Cisco Systems, Inc.
Tasman Drive
San Jose CA 95134
USA
Email: stig@cisco.com
IJsbrand Wijnands
Cisco Systems, Inc.
De kleetlaan 6a
Diegem 1831
Belgium
Email: ice@cisco.com
Venaas, et al. Expires April 25, 2019 [Page 7]
Internet-Draft PIM Source Discovery for BIER October 2018
Mankamana Mishra
Cisco Systems, Inc.
Tasman Drive
San Jose CA 95134
USA
Email: mankamis@cisco.com
Mahesh Sivakumar
Juniper Networks
1133 Innovation Way
Sunnyvale CA 94089
USA
Email: sivakumar.mahesh@gmail.com
Venaas, et al. Expires April 25, 2019 [Page 8]
