draft-ietf-bier-ping-03.txt   draft-ietf-bier-ping-04.txt 
Network Work group N. Kumar Network Work group N. Kumar
Internet-Draft C. Pignataro Internet-Draft C. Pignataro
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: July 26, 2018 N. Akiya Expires: April 24, 2019 N. Akiya
Big Switch Networks Big Switch Networks
L. Zheng L. Zheng
M. Chen M. Chen
Huawei Technologies Huawei Technologies
G. Mirsky G. Mirsky
Ericsson ZTE Corp.
January 22, 2018 October 21, 2018
BIER Ping and Trace BIER Ping and Trace
draft-ietf-bier-ping-03 draft-ietf-bier-ping-04
Abstract Abstract
Bit Index Explicit Replication (BIER) is an architecture that Bit Index Explicit Replication (BIER) is an architecture that
provides optimal multicast forwarding through a "BIER domain" without provides optimal multicast forwarding through a "BIER domain" without
requiring intermediate routers to maintain any multicast related per- requiring intermediate routers to maintain any multicast related per-
flow state. BIER also does not require any explicit tree-building flow state. BIER also does not require any explicit tree-building
protocol for its operation. A multicast data packet enters a BIER protocol for its operation. A multicast data packet enters a BIER
domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the
BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 26, 2018. This Internet-Draft will expire on April 24, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements notation . . . . . . . . . . . . . . . . . . 3 2.2. Requirements notation . . . . . . . . . . . . . . . . . . 4
3. BIER OAM . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. BIER OAM . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. BIER OAM message format . . . . . . . . . . . . . . . . . 4 3.1. BIER OAM message format . . . . . . . . . . . . . . . . . 4
3.2. Return Code . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Return Code . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. BIER OAM TLV . . . . . . . . . . . . . . . . . . . . . . 8 3.3. BIER OAM TLV . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. Original SI-BitString TLV . . . . . . . . . . . . . . 8 3.3.1. Original SI-BitString TLV . . . . . . . . . . . . . . 8
3.3.2. Target SI-BitString TLV . . . . . . . . . . . . . . . 9 3.3.2. Target SI-BitString TLV . . . . . . . . . . . . . . . 9
3.3.3. Incoming SI-BitString TLV . . . . . . . . . . . . . . 10 3.3.3. Incoming SI-BitString TLV . . . . . . . . . . . . . . 10
3.3.4. Downstream Mapping TLV . . . . . . . . . . . . . . . 10 3.3.4. Downstream Mapping TLV . . . . . . . . . . . . . . . 11
3.3.5. Responder BFER TLV . . . . . . . . . . . . . . . . . 13 3.3.5. Responder BFER TLV . . . . . . . . . . . . . . . . . 14
3.3.6. Responder BFR TLV . . . . . . . . . . . . . . . . . . 14 3.3.6. Responder BFR TLV . . . . . . . . . . . . . . . . . . 14
3.3.7. Upstream Interface TLV . . . . . . . . . . . . . . . 14 3.3.7. Upstream Interface TLV . . . . . . . . . . . . . . . 15
3.3.8. Reply-To TLV . . . . . . . . . . . . . . . . . . . . 15 3.3.8. Reply-To TLV . . . . . . . . . . . . . . . . . . . . 15
3.4. Multipath Entropy Data Encoding . . . . . . . . . . . . . 16
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. BIER OAM Processing . . . . . . . . . . . . . . . . . . . 16 4.1. BIER OAM Processing . . . . . . . . . . . . . . . . . . . 16
4.2. Per BFER ECMP Discovery . . . . . . . . . . . . . . . . . 16 4.2. Per BFER ECMP Discovery . . . . . . . . . . . . . . . . . 17
4.3. Sending BIER Echo Request . . . . . . . . . . . . . . . . 17 4.3. Sending BIER Echo Request . . . . . . . . . . . . . . . . 17
4.4. Receiving BIER Echo Request . . . . . . . . . . . . . . . 18 4.4. Receiving BIER Echo Request . . . . . . . . . . . . . . . 18
4.5. Sending Echo Reply . . . . . . . . . . . . . . . . . . . 20 4.5. Sending Echo Reply . . . . . . . . . . . . . . . . . . . 20
4.6. Receiving Echo Reply . . . . . . . . . . . . . . . . . . 21 4.6. Receiving Echo Reply . . . . . . . . . . . . . . . . . . 21
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
5.1. Message Types, Reply Modes, Return Codes . . . . . . . . 21 5.1. BIER OAM Registry . . . . . . . . . . . . . . . . . . . . 22
5.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.2. Message Types, Reply Modes, Return Codes . . . . . . . . 22
5.3. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 22 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23
8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
[RFC8279] introduces and explains BIER architecture that provides [RFC8279] introduces and explains BIER architecture that provides
optimal multicast forwarding through a "BIER domain" without optimal multicast forwarding through a "BIER domain" without
requiring intermediate routers to maintain any multicast related per- requiring intermediate routers to maintain any multicast related per-
flow state. BIER also does not require any explicit tree-building flow state. BIER also does not require any explicit tree-building
protocol for its operation. A multicast data packet enters a BIER protocol for its operation. A multicast data packet enters a BIER
domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the
skipping to change at page 4, line 23 skipping to change at page 4, line 29
3.1. BIER OAM message format 3.1. BIER OAM message format
The BIER OAM packet header format that follows BIER header is as The BIER OAM packet header format that follows BIER header is as
follows: follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Message Type | Proto | Reserved | | Ver | Message Type | Proto | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Message Type Dependent Data ~ ~ Message Type Dependent Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ver Ver
Set to 1. Set to 1.
Message Type Message Type
This document defines the following Message Types: This document defines the following Message Types:
skipping to change at page 4, line 46 skipping to change at page 5, line 7
1 BIER Echo Request 1 BIER Echo Request
2 BIER Echo Reply 2 BIER Echo Reply
Proto Proto
This field is used to define if there is any data packet This field is used to define if there is any data packet
immediately following the OAM payload which is used for passive immediately following the OAM payload which is used for passive
OAM functionality. This field is set to 0 if there is no data OAM functionality. This field is set to 0 if there is no data
packet following OAM payload. packet following OAM payload.
OAM Message Length
This field defines the length of the OAM message including the
header and Dependent Data field.
The Echo Request/Reply header format is as follows: The Echo Request/Reply header format is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Echo Req/Rep | Proto | Reserved | | Ver | Echo Req/Rep | Proto | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QTF | RTF | Reply mode | Return Code | Return Subcode| | QTF | RTF | Reply mode | Return Code | Return Subcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle | | Sender's Handle |
skipping to change at page 13, line 4 skipping to change at page 13, line 23
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved | | |M| Reserved | |
+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+ |
| | | |
| (Multipath Information) | | (Multipath Information) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M Flag M Flag
This flag is set to 0 if all packets will be forwarded out through This flag is set to 0 if all packets will be forwarded out through
interface defined in Downstream Mapping TLV. When set to 1, the interface defined in the Downstream Mapping TLV. When set to
Multipath Information will be defined with Bit masked Entropy 1, Multipath Information will be defined by the Bit masked Entropy
data. data.
Multipath Information Multipath Information
Entropy Data encoded as defined in section x3. Entropy Data encoded as defined in section 3.4
3.3.4.1.2. Egress BitString 3.3.4.1.2. Egress BitString
This Sub-TLV MAY be included by Responder BFR with the rewritten Responder BFR MAY include this Sub-TLV with the rewritten BitString
BitString in outgoing interface as defined in section 6.1 of in the outgoing interface as defined in section 6.1 of [RFC8279]
[RFC8279]
0 1 2 3 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID | Sub-domain ID |BS Len| Reserved | | Set ID | Sub-domain ID |BS Len| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitString (first 32 bits) ~ | BitString (first 32 bits) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BitString (last 32 bits) | | BitString (last 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.5. Responder BFER TLV 3.3.5. Responder BFER TLV
The Responder BFER TLV will be included by the BFER replying to the The BFER replying to the request MAY include the Responder BFER TLV.
request. This is used to identify the originator of BIER Echo Reply. This is used to identify the originator of BIER Echo Reply. This TLV
This TLV have the following format: has the following format:
0 1 2 3 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 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 = 5 | Length | | Type = 5 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | BFR-ID | | Reserved | BFR-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BFR-ID BFR-ID
The BFR-ID field carries the BFR-ID of replying BFER. This TLV The BFR-ID field carries the BFR-ID of replying BFER. This TLV
MAY be included by Responding BFER in BIER Echo Reply packet. MAY be included by Responding BFER in BIER Echo Reply packet.
3.3.6. Responder BFR TLV 3.3.6. Responder BFR TLV
The Responder BFR TLV will be included by the transit BFR replying to Any transit BFR replying to the request MAY include the Responder BFR
the request. This is used to identify the replying BFR without BFR- TLV. This is used to identify the replying BFR without BFR-ID. This
ID. This TLV have the following format: TLV has the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 6 | Length = variable | | TLV Type = 6 | Length = variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Address Type | | Reserved | Address Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ BFR-Prefix (4 or 16 bytes) ~ ~ BFR-Prefix (4 or 16 bytes) ~
skipping to change at page 14, line 33 skipping to change at page 15, line 7
Length Length
The Length field varies depending on the Address Type. The Length field varies depending on the Address Type.
Address Type Address Type
Set to 1 for IPv4 or 2 for IPv6. Set to 1 for IPv4 or 2 for IPv6.
BFR-Prefix BFR-Prefix
Carries the local BFR-Prefix of the replying BFR. This TLV MAY be This field carries the local BFR-Prefix of the replying BFR. This
included by Responding BFR in BIER Echo Reply packet. TLV MAY be included by Responding BFR in BIER Echo Reply packet.
3.3.7. Upstream Interface TLV 3.3.7. Upstream Interface TLV
The Upstream Interface TLV will be included by the replying BFR in The BFR replying to the request will include the Upstream Interface
Echo Reply. This is used to identify the incoming interface and the TLV. This is used to identify the incoming interface and the BIER-
BIER-MPLS label in the incoming Echo Request. This TLV have the MPLS label in the incoming Echo Request. This TLV has the following
following format: format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 7 | Length = variable | | TLV Type = 7 | Length = variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Address Type | | Reserved | Address Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Upstream Address (4 or 16 bytes) ~ ~ Upstream Address (4 or 16 bytes) ~
skipping to change at page 15, line 32 skipping to change at page 15, line 44
Set to 1 for IPv4 numbered, 2 for IPv4 Unnumbered 3 for IPv6 Set to 1 for IPv4 numbered, 2 for IPv4 Unnumbered 3 for IPv6
numbered or 4 for IPv6 Unnumbered. numbered or 4 for IPv6 Unnumbered.
Upstream Address Upstream Address
As defined in Section 3.3.4 As defined in Section 3.3.4
3.3.8. Reply-To TLV 3.3.8. Reply-To TLV
The Reply-To TLV MAY be included by the Initiator BFR in Echo The Initiator BFR MAY include Reply-To TLV in the Echo Request. This
Request. This is used by transit BFR or BFER when the reply mode is is used by transit BFR or BFER when the reply mode is 2. The IP
2. The IP address will be used to generate Echo Reply. This TLV address will be used to generate the Echo Reply. This TLV has the
have the following format: following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type = 8 | Length = variable | | TLV Type = 8 | Length = variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Address Type | | Reserved | Address Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Reply-To Address (4 or 16 bytes) ~ ~ Reply-To Address (4 or 16 bytes) ~
skipping to change at page 16, line 12 skipping to change at page 16, line 28
The Length field varies depending on the Address Type. The Length field varies depending on the Address Type.
Address Type Address Type
Set to 1 for IPv4 or 2 for IPv6. Set to 1 for IPv4 or 2 for IPv6.
Reply-To Address Reply-To Address
Set to any locally configured address to which the Echo reply Set to any locally configured address to which the Echo reply
should be sent to. should be sent.
3.4. Multipath Entropy Data Encoding
The size of Entropy field in BIER header is 20 bits as defined in
section 2 of [RFC8296]. This is similar to Multipath Type 9 encoding
defined in Section 3.4.1.1.1 of [RFC8029].
4. Procedures 4. Procedures
This section describes aspects of Ping and traceroute operations. This section describes aspects of Ping and traceroute operations.
While this document explains the behavior when Reply mode is "Reply While this document explains the behavior when Reply mode is "Reply
via BIER packet", the future version will be updated with details via BIER packet", the future version will be updated with details
about the format when the reply mode is "Reply via IP/UDP packet". about the format when the reply mode is "Reply via IP/UDP packet".
4.1. BIER OAM Processing 4.1. BIER OAM Processing
A BIER OAM packet MUST be sent to BIER control plane for OAM A BIER OAM packet MUST be sent to BIER control plane for OAM
processing if one of the following conditions is true: processing if one of the following conditions is true:
o The receiving BFR is a BFER. o The receiving BFR is a BFER.
o TTL of BIER-MPLS Label expired. o TTL of BIER-MPLS Label expired.
o Presence of Router Alert label in the label stack. o Router Alert label is present in the label stack.
4.2. Per BFER ECMP Discovery 4.2. Per BFER ECMP Discovery
As defined in [RFC8279], BIER follows unicast forwarding path and As defined in [RFC8279], BIER follows the unicast forwarding path and
allows load balancing over ECMP paths between BFIR and BFER. BIER allows load balancing over ECMP paths between BFIR and BFER. BIER
OAM MUST support ECMP path discovery between a BFIR and a given BFER OAM MUST support ECMP path discovery between a BFIR and a given BFER
and MUST support path validation and failure detection of any and MUST support path validation and failure detection of any
particular ECMP path between BFIR and BFER. particular ECMP path between BFIR and BFER.
[RFC8296] proposes the BIER header with Entropy field that can be [RFC8296] proposes the BIER header with Entropy field that can be
leveraged to exercise all ECMP paths. Initiator/BFIR will use leveraged to exercise all ECMP paths. The Initiator/BFIR will use
traceroute message to query each hop about the Entropy information traceroute message to query each hop about the Entropy information
for each downstream paths. To avoid complexity, it is suggested that for each downstream paths. To avoid complexity, it is suggested that
the ECMP query is performed per BFER by carrying required information the ECMP query is performed per BFER by carrying required information
in BIER OAM message. in BIER OAM message.
Initiator MUST include Multipath Entropy Data Sub-TLV in Downstream The Initiator MUST include Multipath Entropy Data Sub-TLV in
Mapping TLV. It MUST also include the BFER in BitString TLV to which Downstream Mapping TLV. It MUST also include the BFER in BitString
the Multipath query is performed. TLV to which the Multipath query is performed.
Any transit BFR will reply back with Bit-masked Entropy for each Any transit BFR will reply with Bit-masked Entropy for each
downstream path as defined in [RFC8029] downstream path as defined in [RFC8029]
4.3. Sending BIER Echo Request 4.3. Sending BIER Echo Request
Initiator MUST set the Message Type as 1 and Return Code as 0. The The Initiator MUST set the Message Type as 1 and Return Code as 0.
Proto field in OAM packet MUST be set to 0. The choice of Sender's The Proto field in OAM packet MUST be set to 0. The choice of
Handle and Sequence number is a local matter to Initiator and SHOULD Sender's Handle and Sequence number is a local matter to the
increment the Sequence number by 1 for every subsequent Echo Request. Initiator and SHOULD increment the Sequence number by 1 for every
The QTF field is set to Initiator's local timestamp format and subsequent Echo Request. The QTF field is set to Initiator's local
TimeStamp Sent field is set to the time that the Echo Request is timestamp format and TimeStamp Sent field is set to the time that the
sent. Echo Request is sent.
Initiator MUST include Original SI-BitString TLV. Initiator MUST NOT The Initiator MUST include Original SI-BitString TLV. The Initiator
include more than one Original SI-BitString TLV. Initiator infers MUST NOT include more than one Original SI-BitString TLV. The
the Set Identifier value and Sub-domain ID value from the respective Initiator infers the Set Identifier value and Sub-domain ID value
BitString that will be included in BIER header of the packet and from the respective BitString that will be included in BIER header of
includes the values in "SI" and Sub-Domain ID fields respectively. the packet and includes the values in "SI" and Sub-Domain ID fields
respectively.
In Ping mode, Initiator MAY include Target SI-BitString TLV to In Ping mode, the Initiator MAY include Target SI-BitString TLV to
control the responding BFER(s) by listing all the BFERs from which control the responding BFER(s) by listing all the BFERs from which
the Initiator expects a response. In trace route mode, Initiator MAY the Initiator expects a response. In trace route mode, the Initiator
include Target SI-Bitstring TLV to control the path trace towards any MAY include Target SI-Bitstring TLV to control the path trace towards
specific BFER or set of BFERs. Initiator on receiving a reply with any specific BFER or set of BFERs. The Initiator on receiving a
Return code as "Replying BFR is the only BFER in header Bitstring" or reply with Return code as "Replying BFR is the only BFER in header
"Replying router is one of the BFER in header Bitstring", SHOULD Bitstring" or "Replying router is one of the BFER in header
unset the respective BFR-id from Target SI-BitString for any Bitstring", SHOULD unset the respective BFR-id from Target SI-
subsequent Echo Request. BitString for any subsequent Echo Request.
When the Reply mode is set to 2, Initiator MUST include Reply-To TLV When the Reply mode is set to 2, the Initiator MUST include Reply-To
(section 3.3.8) in the Echo Request. Initiator MUST also listen to TLV (section 3.3.8) in the Echo Request. The Initiator MUST also
the UDP port defined in this TLV and process any segment received listen to the UDP port defined in this TLV and process any segment
with destination port as value defined in the TLV and sent to control received with destination port as the value defined in the TLV and
plane for BIER OAM payload processing. sent to control plane for BIER OAM payload processing.
Initiator MAY include Downstream Mapping TLV (section 3.3.4) in the The Initiator MAY include Downstream Mapping TLV (section 3.3.4) in
Echo Request to query additional information from transit BFRs and the Echo Request to query additional information from transit BFRs
BFERs. In case of ECMP discovery, Initiator MUST include the and BFERs. In case of ECMP discovery, the Initiator MUST include the
Multipath Entropy Data Sub-TLV and SHOULD set the Target SI-BitString Multipath Entropy Data Sub-TLV and SHOULD set the Target SI-BitString
TLV carrying a specific BFER id. TLV carrying a specific BFER ID.
Initiator MUST encapsulate the OAM packet with BIER header and MUST The Initiator MUST encapsulate the OAM packet with BIER header and
set the Proto as 5 and further encapsulates with BIER-MPLS label. In MUST set the Proto as 5 and further encapsulates with BIER-MPLS
ping mode, the BIER-MPLS Label TTL MUST be set to 255. In traceroute label. In ping mode, the BIER-MPLS Label TTL MUST be set to 255. In
mode, the BIER-MPLS Label TTL is set successively starting from 1 and traceroute mode, the BIER-MPLS Label TTL is set successively starting
MUST stop sending the Echo Request if it receives a reply with Return from 1 and MUST stop sending the Echo Request if it receives a reply
code as "Replying router is the only BFER in BIER header Bitstring" with Return code as "Replying router is the only BFER in BIER header
from all BFER listed in Target SI-BitString TLV. Bitstring" from all BFER listed in Target SI-BitString TLV.
4.4. Receiving BIER Echo Request 4.4. Receiving BIER Echo Request
Sending a BIER OAM Echo Request to control plane for payload Sending a BIER OAM Echo Request to control plane for payload
processing is triggered as mentioned in section 4.1. processing is triggered as mentioned in section 4.1.
Any BFR on receiving Echo Request MUST send Echo Reply with Return Any BFR on receiving Echo Request MUST send Echo Reply with Return
Code set to "Malformed Echo Request received", if the packet fails Code set to "Malformed Echo Request received", if the packet fails
sanity check. If the packet sanity check is fine, it SHOULD sanity check. If the packet sanity check is fine, it SHOULD initiate
initiates the below set of variables: the below set of variables:
Reply-Flag Reply-Flag
This flag is initially set to 1. This flag is initially set to 1.
Interface-I Interface-I
The incoming interface on which the Echo Request was received. The incoming interface on which the Echo Request was received.
This may be used to validate the DDMAP info and to populate the This may be used to validate the DDMAP info and to populate the
Upstream Interface TLV. Upstream Interface TLV.
skipping to change at page 18, line 32 skipping to change at page 19, line 4
This may be used to validate the DDMAP info and to populate the This may be used to validate the DDMAP info and to populate the
Upstream Interface TLV. Upstream Interface TLV.
BIER-Label-L BIER-Label-L
The BIER-MPLS Label received as the top label on received Echo The BIER-MPLS Label received as the top label on received Echo
Request. This may be used to validate if the packet is traversing Request. This may be used to validate if the packet is traversing
the desired Set Identifier and sub-domain path. the desired Set Identifier and sub-domain path.
Header-H Header-H
The BIER header from the received Echo Request. This may be used The BIER header from the received Echo Request. This may be used
to validate the DDMAP info and to populate the Incoming SI- to validate the DDMAP info and to populate the Incoming SI-
BitString TLV. In addition, it can be used to perform Entropy BitString TLV. Also, it can be used to perform Entropy
calculation considering different field in header and reply via calculation considering a different field in the header and reply
Multipath Entropy Data Sub-TLV. via Multipath Entropy Data Sub-TLV.
BFR MUST initialize Best-return-code variable to null value. BFR MUST initialize Best-return-code variable to null value.
BFR will populate Interface-I with interface over which the Echo BFR will populate Interface-I with interface over which the Echo
Request is received, top label in the MPLS stack of the received Echo Request is received, the top label in the MPLS stack of the received
Request to BIER-Label-L, and the BIER header to BIER-Header. If the Echo Request to BIER-Label-L, and the BIER header to BIER-Header. If
received Echo Request carries Target SI-BitString TLV, a BFR SHOULD the received Echo Request carries Target SI-BitString TLV, a BFR
run boolean AND operation between BitString in Header-H and BitString SHOULD run boolean AND operation between BitString in Header-H and
in Target SI-BitString TLV. If the resulting BitString is all-zero, BitString in Target SI-BitString TLV. If the resulting BitString is
reset Reply-Flag=0 and go to section 4.5. Else: all-zero, reset Reply-Flag=0 and go to section 4.5. Else:
o If the BIER-Label-L does not correspond to the local label o If the BIER-Label-L does not correspond to the local label
assigned for {sub-domain, BitStringLen, SI} in Original SI- assigned for {sub-domain, BitStringLen, SI} in Original SI-
BitString TLV, Set the Best-return-code to "Set-Identifier BitString TLV, Set the Best-return-code to "Set-Identifier
Mismatch" and Go to section 4.5. Mismatch" and Go to section 4.5.
* /* This detects any BIER-Label to {sub-domain, BitStringLen, * /* This detects any BIER-Label to {sub-domain, BitStringLen,
SI} synchronization problem in the upstream BFR causing any SI} synchronization problem in the upstream BFR causing any
unintended packet leak between sub-domains */ unintended packet leak between sub-domains */
skipping to change at page 19, line 32 skipping to change at page 20, line 4
BIER forwarding plane in the previous hop that may result in BIER forwarding plane in the previous hop that may result in
loop or packet duplication. */ loop or packet duplication. */
o Set the Best-return-code to "Invalid Multipath Info Request", when o Set the Best-return-code to "Invalid Multipath Info Request", when
the DDMAP TLV carries Multipath Entropy Data Sub-TLV and if the the DDMAP TLV carries Multipath Entropy Data Sub-TLV and if the
Target SI-BitString TLV in the received Echo Request carries more Target SI-BitString TLV in the received Echo Request carries more
than 1 BFER id. Go to section 4.5. Else, list the ECMP than 1 BFER id. Go to section 4.5. Else, list the ECMP
downstream neighbors to reach BFR-id in Target SI-BitString TLV, downstream neighbors to reach BFR-id in Target SI-BitString TLV,
calculate the Entropy considering the BitString in Header-H and calculate the Entropy considering the BitString in Header-H and
Multipath Entropy Data Sub-TLV from received Echo Request. Store Multipath Entropy Data Sub-TLV from received Echo Request. Store
the Data for each Downstream interface in temporary variable. Set the Data for each Downstream interface in a temporary variable.
the Best-return-code to 5 (Packet-Forward-Success) and goto Set the Best-return-code to 5 (Packet-Forward-Success) and goto
Section 4.5 Section 4.5
* /* This instructs to calculate the Entropy Data for each * /* This instructs to calculate the Entropy Data for each
downstream interface to reach the BFER in Target SI-BitString downstream interface to reach the BFER in Target SI-BitString
TLV by considering the incoming BitString and Entropy Data.*/ TLV by considering the incoming BitString and Entropy Data.*/
o Set the Best-return-code to "Replying router is the only BFER in o Set the Best-return-code to "Replying router is the only BFER in
BIER header Bitstring", and go to section 4.5 if the responder is BIER header Bitstring", and go to section 4.5 if the responder is
BFER and there is no more bits in BIER header Bitstring left for BFER and there are no more bits in BIER header Bitstring left for
forwarding. forwarding.
o Set the Best-return-code to "Replying router is one of the BFER in o Set the Best-return-code to "Replying router is one of the BFER in
BIER header Bitstring", and include Downstream Mapping TLV, if the BIER header Bitstring", and include Downstream Mapping TLV, if the
responder is BFER and there are more bits in BitString left for responder is BFER and there are more bits in BitString left for
forwarding. In addition, include the Multipath information as forwarding. Also, include the Multipath information as defined in
defined in Section 4.2 if the received Echo Request carries Section 4.2 if the received Echo Request carries Multipath Entropy
Multipath Entropy Data Sub-TLV. Go to section 4.5. Data Sub-TLV. Go to section 4.5.
o Set the Best-return-code to "No matching entry in forwarding o Set the Best-return-code to "No matching entry in forwarding
table", if the forwarding lookup defined in section 6.5 of table", if the forwarding lookup defined in section 6.5 of
[RFC8279] does not match any entry for the received BitString in [RFC8279] does not match any entry for the received BitString in
BIER header. BIER header.
* /* This detects any missing BFR-id in the BIER forwarding * /* This detects any missing BFR-id in the BIER forwarding
table. It could be noted that it is difficult to detect such table. It could be noted that it is difficult to detect such
missing BFR-id while sending the Request with more than one missing BFR-id while sending the Request with more than one
BFR-id in BitString and so may need to just include the BFER id BFR-id in BitString and so may need to include the BFER id that
that is not responding to detect such failure.*/ is not responding to detect such failure.*/
o Set the Best-return-code to "Packet-Forward-Success", and include o Set the Best-return-code to "Packet-Forward-Success", and include
Downstream Mapping TLV. Go to section 4.5 Downstream Mapping TLV. Go to section 4.5
4.5. Sending Echo Reply 4.5. Sending Echo Reply
If Reply-Flag=0; BFR MUST release the variables and MUST not send any If Reply-Flag=0; BFR MUST release the variables and MUST not send any
response to the Initiator. If Reply-Flag=1, proceed as below: response to the Initiator. If Reply-Flag=1, proceed as below:
The Responder BFR SHOULD include the BitString from Header-H to The Responder BFR SHOULD include the BitString from Header-H to
Incoming SI-BitString TLV and include the Set ID, Sub-domain ID and Incoming SI-BitString TLV and include the Set ID, Sub-domain ID and
BS Len corresponding to BIER-Label-L. Responder BFR SHOULD include BS Len that corresponds to BIER-Label-L. Responder BFR SHOULD
the Upstream Interface TLV and populate the address from Interface-I. include the Upstream Interface TLV and populate the address from
Interface-I.
When the Best-return-code is "Replying BFR is one of the BFER in When the Best-return-code is "Replying BFR is one of the BFER in
header Bitstring", it MUST include Responder BFER TLV. header Bitstring", it MUST include Responder BFER TLV.
If the received Echo Request had DDMAP with Multipath Entropy Data If the received Echo Request had DDMAP with Multipath Entropy Data
Sub-TLV, Responder BFR MUST include DDMAP as defined in Sub-TLV, Responder BFR MUST include DDMAP as defined in
Section 3.3.4 for each outgoing interface over which the packet Section 3.3.4 for each outgoing interface over which the packet
will be replicated and include the respective Multipath Entropy will be replicated and include the respective Multipath Entropy
Data Sub-TLV. For each outgoing interface, respective Egress Data Sub-TLV. For each outgoing interface, respective Egress
BitString MUST be included in DDMAP TLV. BitString MUST be included in DDMAP TLV.
skipping to change at page 21, line 4 skipping to change at page 21, line 26
Egress BitString MUST be included in DDMAP TLV. Egress BitString MUST be included in DDMAP TLV.
When the Best-return-code is "Replying BFR is the only BFER in header When the Best-return-code is "Replying BFR is the only BFER in header
Bitstring", it MUST include Responder BFER TLV. Bitstring", it MUST include Responder BFER TLV.
Responder MUST set the Message Type as 2 and Return Code as Best- Responder MUST set the Message Type as 2 and Return Code as Best-
return-code. The Proto field MUST be set to 0. return-code. The Proto field MUST be set to 0.
The Echo Reply can be sent either as BIER-encapsulated or IP/UDP The Echo Reply can be sent either as BIER-encapsulated or IP/UDP
encapsulated depending on the Reply mode in received Echo Request. encapsulated depending on the Reply mode in received Echo Request.
When the Reply mode in received Echo Request is set to 3, Responder When the Reply mode in received Echo Request is set to 3, Responder
appends BIER header listing the BitString with BFIR ID (from Header- appends BIER header listing the BitString with BFIR ID (from Header-
H), set the Proto to 5 and set the BFIR as 0. When the Reply mode in H), set the Proto to 5 and set the BFIR as 0. When the Reply mode in
received Echo Request is set to 2, Responder encapsulates with IP/UDP received Echo Request is set to 2, Responder encapsulates with IP/UDP
header. The UDP destination port MUST be set to TBD1 and source port header. The UDP destination port MUST be set to TBD1 and source port
MAY be set to TBD1 or other random local value. The source IP is any MAY be set to TBD1 or other random local value. The source IP is any
local address of the responder and destiantion IP is derived from local address of the responder and destination IP is derived from
Reply-To TLV. Reply-To TLV.
4.6. Receiving Echo Reply 4.6. Receiving Echo Reply
Initiator on receiving Echo Reply will use the Sender's Handle to The Initiator on receiving Echo Reply will use the Sender's Handle to
match with Echo Request sent. If no match is found, Initiator MUST match with Echo Request sent. If no match is found, the Initiator
ignore the Echo Reply. MUST ignore the Echo Reply.
If receiving Echo Reply have Downstream Mapping, Initiator SHOULD If receiving Echo Reply have Downstream Mapping, the Initiator SHOULD
copy the same to subsequent Echo Request(s). copy the same to subsequent Echo Request(s).
If one of the Echo Reply is received with Return Code as "Replying If one of the Echo Reply is received with Return Code as "Replying
BFR is one of the BFER in header Bitstring", it SHOULD reset the BFR- BFR is one of the BFER in header Bitstring", it SHOULD reset the BFR-
id of the responder from Target SI-BisString TLV in subsequent Echo id of the responder from Target SI-BisString TLV in subsequent Echo
Request. Request.
/* This helps avoiding any BFR that is both BFER and also transit /* This helps to avoid any BFR that is both BFER and also transit
BFR to continuously responding with Echo Reply.*/ BFR to continuously responding with Echo Reply.*/
5. IANA Considerations 5. IANA Considerations
This document request UDP port TBD1 to be allocated by IANA for BIER This document request UDP port TBD1 to be allocated by IANA for BIER
Echo. Echo.
This document request the IANA for creation and management of below This document request the IANA for creation and management of below
registries: registries and sub-registries:
5.1. Message Types, Reply Modes, Return Codes 5.1. BIER OAM Registry
This document request to assign the Message Types and Reply mode IANA is requested to create and maintain "BIER OAM Parameters"
mentioned in section 3.1, , Return code mentioned in Section 3.2. registry.
5.2. TLVs 5.2. Message Types, Reply Modes, Return Codes
IANA is requested to create "Message Type" sub-registry under "BIER
OAM Parameters" registry and assign the Message Types defined in
section 3.1
IANA is requested to also create "Echo Reply Mode" sub-registry under
"BIER OAM Parameters" registry and assign the Echo Reply Modes
defined in section 3.1
IANA is requested to create "Echo Return Codes" sub-registry under
"BIER OAM Parameters" registry and assign the Return Codes defined in
section 3.2
5.3. TLVs
The TLVs and Sub-TLVs defined in this document is not limited to Echo The TLVs and Sub-TLVs defined in this document is not limited to Echo
Request or Reply message types and is applicable for other message Request or Reply message types and is applicable for other message
types. The TLVs and Sub-TLVs requested by this document for IANA types. The TLVs and Sub-TLVs requested by this document for IANA
consideration are the following: consideration are the following:
Type Sub-Type Value Field Type Sub-Type Value Field
------- -------- ----------- ------- -------- -----------
1 Original SI-BitString 1 Original SI-BitString
2 Target SI-BitString 2 Target SI-BitString
skipping to change at page 22, line 20 skipping to change at page 23, line 8
4 Downstream Mapping 4 Downstream Mapping
4 1 Multipath Entropy Data 4 1 Multipath Entropy Data
4 2 Egress BitString 4 2 Egress BitString
5 Responder BFER 5 Responder BFER
6 Responder BFR 6 Responder BFR
7 Upstream Interface 7 Upstream Interface
6. Security Considerations 6. Security Considerations
The security consideration for BIER Ping is similar to ICMP or LSP The security consideration for BIER Ping is similar to ICMP or LSP
Ping. AS like ICMP or LSP ping, BFR may be exposed to Denial-of- Ping. As like ICMP or LSP ping, BFR may be exposed to Denial-of-
service attacks and it is RECOMMENDED to regulate the BIER Ping Service (DoS) attacks and it is RECOMMENDED to regulate the BIER Ping
packet flow to control plane. A rate limiter SHOULD be applied to packet flow to control plane. A rate limiter SHOULD be applied to
avoid any attack. avoid any attack.
As like ICMP or LSP Ping, a traceroute can be used to obtain network As like ICMP or LSP Ping, a traceroute can be used to obtain network
information. It is RECOMMENDED that the implementation check the information. It is RECOMMENDED that the implementation checks the
integrity of BFIR of the Echo messages against any local secured list integrity of BFIR of the Echo messages against any local secured list
before processing the message further before processing the message further
7. Acknowledgement 7. Acknowledgement
The authors would like to thank Antoni Przygienda, Eric Rosen, Faisal The authors would like to thank Antoni Przygienda, Eric Rosen, Faisal
Iqbal Jeffrey (Zhaohui) Zhang and Shell Nakash for thier review and Iqbal Jeffrey (Zhaohui) Zhang and Shell Nakash for their review and
comments. comments.
8. Contributing Authors 8. References
TBD
9. References
9.1. Normative References 8.1. Normative References
[I-D.ietf-bier-ospf-bier-extensions] [I-D.ietf-bier-ospf-bier-extensions]
Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., Psenak, P., Kumar, N., Wijnands, I., Dolganow, A.,
Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions Przygienda, T., Zhang, Z., and S. Aldrin, "OSPFv2
for BIER", draft-ietf-bier-ospf-bier-extensions-10 (work Extensions for BIER", draft-ietf-bier-ospf-bier-
in progress), December 2017. extensions-18 (work in progress), June 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
skipping to change at page 23, line 33 skipping to change at page 24, line 17
Explicit Replication (BIER)", RFC 8279, Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017, DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>. <https://www.rfc-editor.org/info/rfc8279>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non- for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>. 2018, <https://www.rfc-editor.org/info/rfc8296>.
9.2. Informative References 8.2. Informative References
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981, RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>. <https://www.rfc-editor.org/info/rfc792>.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM" D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291, Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011, DOI 10.17487/RFC6291, June 2011,
<https://www.rfc-editor.org/info/rfc6291>. <https://www.rfc-editor.org/info/rfc6291>.
skipping to change at page 25, line 4 skipping to change at page 25, line 28
Lianshu Zheng Lianshu Zheng
Huawei Technologies Huawei Technologies
China China
Email: vero.zheng@huawei.com Email: vero.zheng@huawei.com
Mach Chen Mach Chen
Huawei Technologies Huawei Technologies
Email: mach.chen@huawei.com Email: mach.chen@huawei.com
Greg Mirsky Greg Mirsky
Ericsson ZTE Corp.
Email: gregory.mirsky@ericsson.com Email: gregimirsky@gmail.com
 End of changes. 64 change blocks. 
136 lines changed or deleted 160 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/