draft-ietf-bier-ping-02.txt   draft-ietf-bier-ping-03.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: January 22, 2018 N. Akiya Expires: July 26, 2018 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 Ericsson
July 21, 2017 January 22, 2018
BIER Ping and Trace BIER Ping and Trace
draft-ietf-bier-ping-02 draft-ietf-bier-ping-03
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 1, line 45 skipping to change at page 1, line 45
BIER data plane. BIER data plane.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 January 22, 2018. This Internet-Draft will expire on July 26, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
(http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . 4 2.2. Requirements notation . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Return Code . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . 11 3.3.4. Downstream Mapping TLV . . . . . . . . . . . . . . . 10
3.3.5. Responder BFER TLV . . . . . . . . . . . . . . . . . 14 3.3.5. Responder BFER TLV . . . . . . . . . . . . . . . . . 13
3.3.6. Responder BFR TLV . . . . . . . . . . . . . . . . . . 15 3.3.6. Responder BFR TLV . . . . . . . . . . . . . . . . . . 14
3.3.7. Upstream Interface TLV . . . . . . . . . . . . . . . 15 3.3.7. Upstream Interface TLV . . . . . . . . . . . . . . . 14
3.3.8. Reply-To TLV . . . . . . . . . . . . . . . . . . . . 16 3.3.8. Reply-To TLV . . . . . . . . . . . . . . . . . . . . 15
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. BIER OAM Processing . . . . . . . . . . . . . . . . . . . 17 4.1. BIER OAM Processing . . . . . . . . . . . . . . . . . . . 16
4.2. Per BFER ECMP Discovery . . . . . . . . . . . . . . . . . 17 4.2. Per BFER ECMP Discovery . . . . . . . . . . . . . . . . . 16
4.3. Sending BIER Echo Request . . . . . . . . . . . . . . . . 18 4.3. Sending BIER Echo Request . . . . . . . . . . . . . . . . 17
4.4. Receiving BIER Echo Request . . . . . . . . . . . . . . . 19 4.4. Receiving BIER Echo Request . . . . . . . . . . . . . . . 18
4.5. Sending Echo Reply . . . . . . . . . . . . . . . . . . . 21 4.5. Sending Echo Reply . . . . . . . . . . . . . . . . . . . 20
4.6. Receiving Echo Reply . . . . . . . . . . . . . . . . . . 22 4.6. Receiving Echo Reply . . . . . . . . . . . . . . . . . . 21
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
5.1. Message Types, Reply Modes, Return Codes . . . . . . . . 22 5.1. Message Types, Reply Modes, Return Codes . . . . . . . . 21
5.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 22
8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 23 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
[I-D.ietf-bier-architecture] introduces and explains BIER [RFC8279] introduces and explains BIER architecture that provides
architecture that provides optimal multicast forwarding through a optimal multicast forwarding through a "BIER domain" without
"BIER domain" without requiring intermediate routers to maintain any requiring intermediate routers to maintain any multicast related per-
multicast related per-flow state. BIER also does not require any flow state. BIER also does not require any explicit tree-building
explicit tree-building protocol for its operation. A multicast data protocol for its operation. A multicast data packet enters a BIER
packet enters a BIER domain at a "Bit-Forwarding Ingress Router" domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the
(BFIR), and leaves the BIER domain at one or more "Bit-Forwarding BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).
Egress Routers" (BFERs). The BFIR router adds a BIER header to the The BFIR router adds a BIER header to the packet. The BIER header
packet. The BIER header contains a bit-string in which each bit contains a bit-string in which each bit represents exactly one BFER
represents exactly one BFER to forward the packet to. The set of to forward the packet to. The set of BFERs to which the multicast
BFERs to which the multicast packet needs to be forwarded is packet needs to be forwarded is expressed by setting the bits that
expressed by setting the bits that correspond to those routers in the correspond to those routers in the BIER header.
BIER header.
This document describes the mechanism and basic BIER OAM packet This document describes the mechanism and basic BIER OAM packet
format that can be used to perform failure detection and isolation on format that can be used to perform failure detection and isolation on
BIER data plane without any dependency on other layers like IP layer. BIER data plane without any dependency on other layers like IP layer.
2. Conventions used in this document 2. Conventions used in this document
2.1. Terminology 2.1. Terminology
BFER - Bit Forwarding Egress Router BFER - Bit Forwarding Egress Router
skipping to change at page 4, line 15 skipping to change at page 4, line 9
2.2. Requirements notation 2.2. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. BIER OAM 3. BIER OAM
BIER OAM is defined in a way that it stays within BIER layer by BIER OAM is defined in a way that it stays within BIER layer by
following directly the BIER header without mandating the need for IP following directly the BIER header without mandating the need for IP
header. [I-D.ietf-bier-mpls-encapsulation] defines a 4-bit field as header. [RFC8296] defines a 4-bit field as "Proto" to identify the
"Proto" to identify the payload following BIER header. When the payload following BIER header. When the payload is BIER OAM, the
payload is BIER OAM, the "Proto" field will be set to 5 as defined in "Proto" field will be set to 5 as defined in [RFC8296]
[I-D.ietf-bier-mpls-encapsulation]
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 |
skipping to change at page 7, line 24 skipping to change at page 7, line 16
-------- --------------- -------- ---------------
0 No return code 0 No return code
1 Malformed Echo Request received 1 Malformed Echo Request received
2 One or more of the TLVs was not understood 2 One or more of the TLVs was not understood
3 Replying BFR is the only BFER in header Bitstring 3 Replying BFR is the only BFER in header Bitstring
4 Replying BFR is one of the BFER in header Bitstring 4 Replying BFR is one of the BFER in header Bitstring
5 Packet-Forward-Success 5 Packet-Forward-Success
6 Invalid Multipath Info Request 6 Invalid Multipath Info Request
8 No matching entry in forwarding table. 8 No matching entry in forwarding table.
9 Set-Identifier Mismatch 9 Set-Identifier Mismatch
10 DDMAP Mismatch
"No return code" will be used by Initiator in the Echo Request. This "No return code" will be used by Initiator in the Echo Request. This
Value MUST NOT be used in Echo Reply. Value MUST NOT be used in Echo Reply.
"Malformed Echo Request received" will be used by any BFR if the "Malformed Echo Request received" will be used by any BFR if the
received Echo Request packet is not properly formatted. received Echo Request packet is not properly formatted.
When any TLV included in the Echo Request is not understood by When any TLV included in the Echo Request is not understood by
receiver, the Return code will be set to "One or more of the TLVs was receiver, the Return code will be set to "One or more of the TLVs was
not understood" carrying the respective TLVs. not understood" carrying the respective TLVs.
skipping to change at page 8, line 5 skipping to change at page 7, line 47
more neighbors. more neighbors.
Any transit BFR will send the Echo Reply with "Packet-Forward- Any transit BFR will send the Echo Reply with "Packet-Forward-
Success", if the TLV in received Echo Request are understood and Success", if the TLV in received Echo Request are understood and
forwarding table have forwarding entries for the BitString. This is forwarding table have forwarding entries for the BitString. This is
used by transit BFR during traceroute mode. used by transit BFR during traceroute mode.
When Echo Request is received with multipath info for more than one When Echo Request is received with multipath info for more than one
BFER, the return-code is set to "Invalid Multipath Info Request". BFER, the return-code is set to "Invalid Multipath Info Request".
If the receiving BFER does not have any state entry in Overlay
Multicast table. For example, if there is no Opaque value in mLDP
table or S,G entry in respective PIM table, the return-code is set to
"No matching entry in forwarding table".
If the BitString cannot be matched in local forwarding table, the BFR If the BitString cannot be matched in local forwarding table, the BFR
will use "No matching entry in forwarding table" in the reply. will use "No matching entry in forwarding table" in the reply.
If the BIER-MPLS label in received Echo Request is not the one If the BIER-MPLS label in received Echo Request is not the one
assigned for SI in Original SI-BitString TLV, "Set-Identifier assigned for SI in Original SI-BitString TLV, "Set-Identifier
Mismatch" is set inorder to report the mismatch. Mismatch" is set inorder to report the mismatch.
3.3. BIER OAM TLV 3.3. BIER OAM TLV
This section defines various TLVs that can be used in BIER OAM This section defines various TLVs that can be used in BIER OAM
skipping to change at page 9, line 20 skipping to change at page 8, line 45
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Set ID field is set to the Set Identifier to which the BitString Set ID field is set to the Set Identifier to which the BitString
belongs to. This value is derived as defined in section 3 of belongs to. This value is derived as defined in [RFC8279]
[I-D.ietf-bier-architecture]
Sub-domain ID is set to the Sub domain value to which BFER in Sub-domain ID is set to the Sub domain value to which BFER in
BitString belongs to. BitString belongs to.
BS Len is set based on the length of BitString as defined in section BS Len is set based on the length of BitString as defined in
3 of [I-D.ietf-bier-mpls-encapsulation] [RFC8296]
The BitString field carries the set of BFR-IDs that Initiator will The BitString field carries the set of BFR-IDs that Initiator will
include in the BIER header. This TLV MUST be included by Initiator include in the BIER header. This TLV MUST be included by Initiator
in Echo Request packet in Echo Request packet
3.3.2. Target SI-BitString TLV 3.3.2. Target SI-BitString TLV
The Target SI-BitString TLV carries the set of BFER from which the The Target SI-BitString TLV carries the set of BFER from which the
Initiator expects the reply from.This TLV has the following format: Initiator expects the reply from.This TLV has the following format:
skipping to change at page 10, line 20 skipping to change at page 9, line 32
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Set ID field is set to the Set Identifier to which the BitString Set ID field is set to the Set Identifier to which the BitString
belongs to. This value is derived as defined in section 3 of belongs to. This value is derived as defined in [RFC8279]
[I-D.ietf-bier-architecture]
Sub-domain ID is set to the Sub domain value to which BFER in Sub-domain ID is set to the Sub domain value to which BFER in
BitString belongs to. BitString belongs to.
BS Len is set based on the length of BitString as defined in section BS Len is set based on the length of BitString as defined in
3 of [I-D.ietf-bier-mpls-encapsulation] [RFC8296]
The BitString field carries the set of BFR-IDs of BFER(s) that The BitString field carries the set of BFR-IDs of BFER(s) that
Initiator expects the response from. The BitString in this TLV may Initiator expects the response from. The BitString in this TLV may
be different from the BitString in BIER header and allows to control be different from the BitString in BIER header and allows to control
the BFER responding to the Echo Request. This TLV MUST be included the BFER responding to the Echo Request. This TLV MUST be included
by Initiator in BIER OAM packet if the Downstream Mapping TLV by Initiator in BIER OAM packet if the Downstream Mapping TLV
(section 3.3.4) is included. (section 3.3.4) is included.
3.3.3. Incoming SI-BitString TLV 3.3.3. Incoming SI-BitString TLV
skipping to change at page 11, line 20 skipping to change at page 10, line 26
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Set ID field is set to the Set Identifier to which the BitString Set ID field is set to the Set Identifier to which the BitString
belongs to. This value is derived as defined in section 3 of belongs to. This value is derived as defined in [RFC8279]
[I-D.ietf-bier-architecture]
Sub-domain ID is set to the Sub domain value to which BFER in Sub-domain ID is set to the Sub domain value to which BFER in
BitString belongs to. BitString belongs to.
BS Len is set based on the length of BitString as defined in section BS Len is set based on the length of BitString as defined in
3 of [I-D.ietf-bier-mpls-encapsulation] [RFC8296]
The BitString field copies the BitString from BIER header of the The BitString field copies the BitString from BIER header of the
incoming Echo Request. A Responder BFR SHOULD include this TLV in incoming Echo Request. A Responder BFR SHOULD include this TLV in
Echo Reply if the Echo Request is received with I flag set in Echo Reply if the Echo Request is received with I flag set in
Downstream Mapping TLV. Downstream Mapping TLV.
An Initiator MUST NOT include this TLV in Echo Request. An Initiator MUST NOT include this TLV in Echo Request.
3.3.4. Downstream Mapping TLV 3.3.4. Downstream Mapping TLV
skipping to change at page 14, line 17 skipping to change at page 13, line 17
data. data.
Multipath Information Multipath Information
Entropy Data encoded as defined in section x3. Entropy Data encoded as defined in section x3.
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 This Sub-TLV MAY be included by Responder BFR with the rewritten
BitString in outgoing interface as defined in section 6.1 of BitString in outgoing interface as defined in section 6.1 of
[I-D.ietf-bier-architecture] [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) |
skipping to change at page 17, line 34 skipping to change at page 16, line 34
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 Presence of Router Alert label in the label stack.
4.2. Per BFER ECMP Discovery 4.2. Per BFER ECMP Discovery
As defined in [I-D.ietf-bier-architecture], BIER follows unicast As defined in [RFC8279], BIER follows unicast forwarding path and
forwarding path and allows load balancing over ECMP paths between allows load balancing over ECMP paths between BFIR and BFER. BIER
BFIR and BFER. BIER OAM MUST support ECMP path discovery between a OAM MUST support ECMP path discovery between a BFIR and a given BFER
BFIR and a given BFER and MUST support path validation and failure and MUST support path validation and failure detection of any
detection of any particular ECMP path between BFIR and BFER. particular ECMP path between BFIR and BFER.
[I-D.ietf-bier-mpls-encapsulation] proposes the BIER header with [RFC8296] proposes the BIER header with Entropy field that can be
Entropy field that can be leveraged to exercise all ECMP paths. leveraged to exercise all ECMP paths. Initiator/BFIR will use
Initiator/BFIR will use traceroute message to query each hop about traceroute message to query each hop about the Entropy information
the Entropy information for each downstream paths. To avoid for each downstream paths. To avoid complexity, it is suggested that
complexity, it is suggested that the ECMP query is performed per BFER the ECMP query is performed per BFER by carrying required information
by carrying required information in BIER OAM message. in BIER OAM message.
Initiator MUST include Multipath Entropy Data Sub-TLV in Downstream Initiator MUST include Multipath Entropy Data Sub-TLV in Downstream
Mapping TLV. It MUST also include the BFER in BitString TLV to which Mapping TLV. It MUST also include the BFER in BitString TLV to which
the Multipath query is performed. the Multipath query is performed.
Any transit BFR will reply back with Bit-masked Entropy for each Any transit BFR will reply back 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
skipping to change at page 19, line 45 skipping to change at page 18, line 45
BitString TLV. In addition, it can be used to perform Entropy BitString TLV. In addition, it can be used to perform Entropy
calculation considering different field in header and reply via calculation considering different field in header and reply via
Multipath Entropy Data Sub-TLV. 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, top label in the MPLS stack of the received Echo
Request to BIER-Label-L, and the BIER header to BIER-Header. If the Request to BIER-Label-L, and the BIER header to BIER-Header. If the
received Echo Request carries Target SI-BitString TLV, a BFR SHOULD received Echo Request carries Target SI-BitString TLV, a BFR SHOULD
run boolean NAD operation between BitString in Header-H and BitString run boolean AND operation between BitString in Header-H and BitString
in Target SI-BitString TLV. If the resulting BitString is all-zero, in Target SI-BitString TLV. If the resulting BitString is all-zero,
reset Return-Flag=0 and go to section 4.5. Else: 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 */
o Set the Best-return-code to "One or more of the TLVs was not o Set the Best-return-code to "One or more of the TLVs was not
understood", if any of the TLVs in Echo Request message is not understood", if any of the TLVs in Echo Request message is not
understood. Go to section 4.5. understood. Go to section 4.5.
o If the BitString in Header-H does not match the BitString in o If the BitString in Header-H does not match the BitString in
Egress BitString Sub-TLV of DDMAP TLV, set the Best-return-code to Egress BitString Sub-TLV of DDMAP TLV, set the Best-return-code to
ERR-TBD. When there are more than one DDMAP TLV in the received "DDMAP Mismatch" and go to section 4.5. When there are more than
Request packet, the Downstream Address and Downstream Interface one DDMAP TLV in the received Request packet, the Downstream
Address should be matched with Interface-I to identify the right Address and Downstream Interface Address should be matched with
DDMAP TLV and then perform the BitString match. Interface-I to identify the right DDMAP TLV and then perform the
BitString match.
* /* This detects any deviation between in BIER control plane and * /* This detects any deviation between in BIER control plane and
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,
skipping to change at page 21, line 4 skipping to change at page 20, line 7
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. In addition, include the Multipath information as
defined in Section 4.2 if the received Echo Request carries defined in Section 4.2 if the received Echo Request carries
Multipath Entropy Data Sub-TLV. Go to section 4.5. Multipath Entropy 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
[I-D.ietf-bier-architecture] does not match any entry for the BIER header.
received BitString in 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 just include the BFER id
that is not responding to detect such failure.*/ that 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 Return-Flag=0; BFR MUST release the variables and MUST not send If Reply-Flag=0; BFR MUST release the variables and MUST not send any
any response to the Initiator. If Return-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 corresponding to BIER-Label-L. Responder BFR SHOULD include
the Upstream Interface TLV and populate the address from Interface-I. 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
skipping to change at page 23, line 33 skipping to change at page 22, line 33
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 check 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 and Jeffrey (Zhaohui) Zhang for thier review and comments. Iqbal Jeffrey (Zhaohui) Zhang and Shell Nakash for thier review and
comments.
8. Contributing Authors 8. Contributing Authors
TBD TBD
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-bier-architecture]
Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
S. Aldrin, "Multicast using Bit Index Explicit
Replication", draft-ietf-bier-architecture-07 (work in
progress), June 2017.
[I-D.ietf-bier-mpls-encapsulation]
Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J.,
Aldrin, S., and I. Meilik, "Encapsulation for Bit Index
Explicit Replication in MPLS and non-MPLS Networks",
draft-ietf-bier-mpls-encapsulation-07 (work in progress),
June 2017.
[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, "OSPF Extensions
for BIER", draft-ietf-bier-ospf-bier-extensions-07 (work for BIER", draft-ietf-bier-ospf-bier-extensions-10 (work
in progress), July 2017. in progress), December 2017.
[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,
<http://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,
<http://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029, Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017, DOI 10.17487/RFC8029, March 2017,
<http://www.rfc-editor.org/info/rfc8029>. <https://www.rfc-editor.org/info/rfc8029>.
[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 9.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,
<http://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,
<http://www.rfc-editor.org/info/rfc6291>. <https://www.rfc-editor.org/info/rfc6291>.
[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
Performing Label Switched Path Ping (LSP Ping) over MPLS Performing Label Switched Path Ping (LSP Ping) over MPLS
Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011, Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011,
<http://www.rfc-editor.org/info/rfc6424>. <https://www.rfc-editor.org/info/rfc6424>.
[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., [RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Yasukawa, S., and T. Nadeau, "Detecting Data-Plane
Failures in Point-to-Multipoint MPLS - Extensions to LSP Failures in Point-to-Multipoint MPLS - Extensions to LSP
Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011,
<http://www.rfc-editor.org/info/rfc6425>. <https://www.rfc-editor.org/info/rfc6425>.
Authors' Addresses Authors' Addresses
Nagendra Kumar Nagendra Kumar
Cisco Systems, Inc. Cisco Systems, Inc.
7200 Kit Creek Road 7200 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
US US
Email: naikumar@cisco.com Email: naikumar@cisco.com
 End of changes. 39 change blocks. 
111 lines changed or deleted 102 lines changed or added

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