< draft-ietf-bfd-multipoint-11.txt | draft-ietf-bfd-multipoint-12.txt > | |||
---|---|---|---|---|
Internet Engineering Task Force D. Katz | Internet Engineering Task Force D. Katz | |||
Internet-Draft Juniper Networks | Internet-Draft Juniper Networks | |||
Intended status: Standards Track D. Ward | Intended status: Standards Track D. Ward | |||
Expires: June 14, 2018 Cisco Systems | Expires: June 22, 2018 Cisco Systems | |||
S. Pallagatti, Ed. | S. Pallagatti, Ed. | |||
Individual contributor | Individual contributor | |||
December 11, 2017 | G. Mirsky, Ed. | |||
ZTE Corp. | ||||
December 19, 2017 | ||||
BFD for Multipoint Networks | BFD for Multipoint Networks | |||
draft-ietf-bfd-multipoint-11 | draft-ietf-bfd-multipoint-12 | |||
Abstract | Abstract | |||
This document describes extensions to the Bidirectional Forwarding | This document describes extensions to the Bidirectional Forwarding | |||
Detection (BFD) protocol for its use in multipoint and multicast | Detection (BFD) protocol for its use in multipoint and multicast | |||
networks. Comments on this draft should be directed to rtg- | networks. Comments on this draft should be directed to rtg- | |||
bfd@ietf.org. | bfd@ietf.org. | |||
Requirements Language | Requirements Language | |||
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", "NOT RECOMMENDED", "MAY", and | |||
document are to be interpreted as described in RFC 2119 [RFC2119]. | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | ||||
capitals, as shown here. | ||||
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 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 June 14, 2018. | This Internet-Draft will expire on June 22, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 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 22 ¶ | skipping to change at page 2, line 27 ¶ | |||
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. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 4 | 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4.1. Multipoint BFD Control Packets . . . . . . . . . . . . . 4 | 4.1. Multipoint BFD Control Packets . . . . . . . . . . . . . 4 | |||
4.2. Session Model . . . . . . . . . . . . . . . . . . . . . . 4 | 4.2. Session Model . . . . . . . . . . . . . . . . . . . . . . 5 | |||
4.3. Session Failure Semantics . . . . . . . . . . . . . . . . 5 | 4.3. Session Failure Semantics . . . . . . . . . . . . . . . . 5 | |||
4.4. State Variables . . . . . . . . . . . . . . . . . . . . . 5 | 4.4. State Variables . . . . . . . . . . . . . . . . . . . . . 5 | |||
4.4.1. New State Variables . . . . . . . . . . . . . . . . . 5 | 4.4.1. New State Variables . . . . . . . . . . . . . . . . . 5 | |||
4.4.2. State Variable Initialization and Maintenance . . . . 6 | 4.4.2. State Variable Initialization and Maintenance . . . . 6 | |||
4.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 6 | 4.5. State Machine . . . . . . . . . . . . . . . . . . . . . . 6 | |||
4.6. Session Establishment . . . . . . . . . . . . . . . . . . 7 | 4.6. Session Establishment . . . . . . . . . . . . . . . . . . 7 | |||
4.7. Discriminators and Packet Demultiplexing . . . . . . . . 7 | 4.7. Discriminators and Packet Demultiplexing . . . . . . . . 7 | |||
4.8. Packet consumption on tails . . . . . . . . . . . . . . . 8 | 4.8. Packet consumption on tails . . . . . . . . . . . . . . . 8 | |||
4.9. Bringing Up and Shutting Down Multipoint BFD Service . . 8 | 4.9. Bringing Up and Shutting Down Multipoint BFD Service . . 8 | |||
4.10. Timer Manipulation . . . . . . . . . . . . . . . . . . . 8 | 4.10. Timer Manipulation . . . . . . . . . . . . . . . . . . . 9 | |||
4.11. Detection Times . . . . . . . . . . . . . . . . . . . . . 9 | 4.11. Detection Times . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.12. State Maintenance for Down/AdminDown Sessions . . . . . . 9 | 4.12. State Maintenance for Down/AdminDown Sessions . . . . . . 9 | |||
4.12.1. MultipointHead Sessions . . . . . . . . . . . . . . 9 | 4.12.1. MultipointHead Sessions . . . . . . . . . . . . . . 10 | |||
4.12.2. MultipointTail Sessions . . . . . . . . . . . . . . 9 | 4.12.2. MultipointTail Sessions . . . . . . . . . . . . . . 10 | |||
4.13. Base Specification Text Replacement . . . . . . . . . . . 10 | 4.13. Base Specification Text Replacement . . . . . . . . . . . 10 | |||
4.13.1. Reception of BFD Control Packets . . . . . . . . . . 10 | 4.13.1. Reception of BFD Control Packets . . . . . . . . . . 10 | |||
4.13.2. Demultiplexing BFD Control Packets . . . . . . . . . 12 | 4.13.2. Demultiplexing BFD Control Packets . . . . . . . . . 13 | |||
4.13.3. Transmitting BFD Control Packets . . . . . . . . . . 13 | 4.13.3. Transmitting BFD Control Packets . . . . . . . . . . 14 | |||
5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 16 | 5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | |||
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 | 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 | |||
10. Normative References . . . . . . . . . . . . . . . . . . . . 17 | 10. Normative References . . . . . . . . . . . . . . . . . . . . 17 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
1. Introduction | 1. Introduction | |||
The Bidirectional Forwarding Detection protocol [RFC5880] specifies a | The Bidirectional Forwarding Detection protocol [RFC5880] specifies a | |||
method for verifying unicast connectivity between a pair of systems. | method for verifying unicast connectivity between a pair of systems. | |||
This document defines a method for using BFD to provide verification | This document defines a method for using BFD to provide verification | |||
of multipoint or multicast connectivity between a multipoint sender | of multipoint or multicast connectivity between a multipoint sender | |||
(the "head") and a set of one or more multipoint receivers (the | (the "head") and a set of one or more multipoint receivers (the | |||
"tails"). | "tails"). | |||
As multipoint transmissions are inherently unidirectional, this | As multipoint transmissions are inherently unidirectional, this | |||
mechanism purports only to verify this unidirectional connectivity. | mechanism purports only to verify this unidirectional connectivity. | |||
Although this seems in conflict with the "Bidirectional" in BFD, it | Although this seems in conflict with the "Bidirectional" in BFD, the | |||
is a natural fit for that protocol. | protocol is capable supporting this use case. | |||
This application of BFD allows for the tails to detect a lack of | This application of BFD allows for the tails to detect a lack of | |||
connectivity from the head. Due to unidirectional nature, virtually | connectivity from the head. Due to unidirectional nature, virtually | |||
all options and timing parameters are controlled by the head. | all options and timing parameters are controlled by the head. | |||
As an option, the tail may notify the head of the lack of multipoint | As an option, the tail may notify the head of the lack of multipoint | |||
connectivity. Details of tail notification to head are outside the | connectivity. Details of tail notification to head are outside the | |||
scope of this document. | scope of this document. | |||
Throughout this document, the term "multipoint" is defined as a | Throughout this document, the term "multipoint" is defined as a | |||
mechanism by which one or more systems receive packets sent by a | mechanism by which one or more systems receive packets sent by a | |||
single sender. This specifically includes such things as IP | single sender. This specifically includes such things as IP | |||
multicast and point-to-multipoint MPLS. | multicast and point-to-multipoint MPLS. | |||
Term "connectivity" in this document is not being used in context of | ||||
connectivity verification in transport network but as an alternative | ||||
to "continuity", i.e. existence of a path between the sender and the | ||||
receiver. | ||||
This document effectively modifies and adds to the base BFD | This document effectively modifies and adds to the base BFD | |||
specification. It is the intention of the authors to fold these | specification. It is the intention of the authors to fold these | |||
extensions into the base specification at the appropriate time. | extensions into the base specification at the appropriate time. | |||
2. Goals | 2. Goals | |||
The primary goal of this mechanism is to allow tails to rapidly | The primary goal of this mechanism is to allow tails to rapidly | |||
detect the fact that multipoint connectivity from the head has | detect the fact that multipoint connectivity from the head has | |||
failed. | failed. | |||
skipping to change at page 4, line 7 ¶ | skipping to change at page 4, line 12 ¶ | |||
A further goal is to support multiple, overlapping multipoint paths, | A further goal is to support multiple, overlapping multipoint paths, | |||
as well as multipoint paths with multiple heads, and to allow point- | as well as multipoint paths with multiple heads, and to allow point- | |||
to-point BFD sessions to operate simultaneously among the systems | to-point BFD sessions to operate simultaneously among the systems | |||
participating in Multipoint BFD. | participating in Multipoint BFD. | |||
A final goal is to integrate multipoint operation into the base | A final goal is to integrate multipoint operation into the base | |||
specification in such a way as to make it relatively easy to support | specification in such a way as to make it relatively easy to support | |||
both multipoint and point-to-point operation in a single | both multipoint and point-to-point operation in a single | |||
implementation. | implementation. | |||
It is a non-goal for this protocol to verify point-to-point | It is a non-goal for this protocol to verify point-to-point bi- | |||
connectivity between the head and any tails. This can be done | directional connectivity between the head and any tails. This can be | |||
independently (and with no penalty in protocol overhead) by using | done independently (and with no penalty in protocol overhead) by | |||
point-to-point BFD. | using point-to-point BFD. | |||
3. Overview | 3. Overview | |||
The heart of this protocol is the periodic transmission of BFD | The heart of this protocol is the periodic transmission of BFD | |||
Control packets along a multipoint path, from the head to all tails | Control packets along a multipoint path, from the head to all tails | |||
on the tree. The contents of the BFD packets provide the means for | on the tree. The contents of the BFD packets provide the means for | |||
the tails to calculate the detection time for path failure. If no | the tails to calculate the detection time for path failure. If no | |||
BFD Control packets are received by a tail for a detection time, the | BFD Control packets are received by a tail for a detection time, the | |||
tail declares the path to have failed. For some applications this is | tail declares the path to have failed. For some applications this is | |||
the only mechanism necessary; the head can remain ignorant of the | the only mechanism necessary; the head can remain ignorant of the | |||
skipping to change at page 5, line 5 ¶ | skipping to change at page 5, line 10 ¶ | |||
the M bit. This means that Multipoint BFD does not depend on the | the M bit. This means that Multipoint BFD does not depend on the | |||
recipient of a packet to know whether the packet was received over a | recipient of a packet to know whether the packet was received over a | |||
multipoint path. This can be useful in scenarios where this | multipoint path. This can be useful in scenarios where this | |||
information may not be available to the recipient. | information may not be available to the recipient. | |||
4.2. Session Model | 4.2. Session Model | |||
Multipoint BFD is modeled as a set of sessions of different types. | Multipoint BFD is modeled as a set of sessions of different types. | |||
The elements of procedure differ slightly for each type. | The elements of procedure differ slightly for each type. | |||
Point-to-point sessions, as described in [BFD], are of type | Point-to-point sessions, as described in [RFC5880], are of type | |||
PointToPoint. | PointToPoint. | |||
The head has a session of type MultipointHead that is bound to a | The head has a session of type MultipointHead that is bound to a | |||
multipoint path. Multipoint BFD Control packets are sent by this | multipoint path. Multipoint BFD Control packets are sent by this | |||
session over the multipoint path, and no BFD Control packets are | session over the multipoint path, and no BFD Control packets are | |||
received by it. | received by it. | |||
Each tail has a session of type MultipointTail associated with a | Each tail has a session of type MultipointTail associated with a | |||
multipoint path. These sessions receive BFD Control packets from the | multipoint path. These sessions receive BFD Control packets from the | |||
head over multipoint path. | head over multipoint path. | |||
skipping to change at page 5, line 36 ¶ | skipping to change at page 5, line 41 ¶ | |||
has lost contact with the head (or the head has been administratively | has lost contact with the head (or the head has been administratively | |||
disabled) and the tail should take appropriate action. | disabled) and the tail should take appropriate action. | |||
4.4. State Variables | 4.4. State Variables | |||
Multipoint BFD introduces some new state variables, and modifies the | Multipoint BFD introduces some new state variables, and modifies the | |||
usage of a few existing ones. | usage of a few existing ones. | |||
4.4.1. New State Variables | 4.4.1. New State Variables | |||
A number of state variables are added to the base specification in | A number of state variables and their values are added to the base | |||
support of Multipoint BFD. | BFD [RFC5880] and base S-BFD [RFC7880] specifications in support of | |||
Multipoint BFD. | ||||
bfd.SessionType | bfd.SessionType | |||
The type of this session. Allowable values are: | The type of this session as defined in [RFC7880]. Newly added | |||
values are: | ||||
PointToPoint: Classic point-to-point BFD. | PointToPoint: Classic point-to-point BFD. | |||
MultipointHead: A session on the head responsible for the | MultipointHead: A session on the head responsible for the | |||
periodic transmission of multipoint BFD Control packets | periodic transmission of multipoint BFD Control packets | |||
along the multipoint path. | along the multipoint path. | |||
MultipointTail: A multipoint session on a tail. | MultipointTail: A multipoint session on a tail. | |||
This variable MUST be initialized to the appropriate type when | This variable MUST be initialized to the appropriate type when | |||
skipping to change at page 7, line 47 ¶ | skipping to change at page 8, line 7 ¶ | |||
and with Your Discr set to zero. | and with Your Discr set to zero. | |||
IP and MPLS multipoint tails MUST demultiplex BFD packets based on a | IP and MPLS multipoint tails MUST demultiplex BFD packets based on a | |||
combination of the source address, My Discriminator and the identity | combination of the source address, My Discriminator and the identity | |||
of the multipoint tree which the Multipoint BFD Control packet was | of the multipoint tree which the Multipoint BFD Control packet was | |||
received from. Together they uniquely identify the head of the | received from. Together they uniquely identify the head of the | |||
multipoint path. Bootstrapping BFD session to a multipoint LSP in | multipoint path. Bootstrapping BFD session to a multipoint LSP in | |||
case of penultimate hop popping is outside the scope of this | case of penultimate hop popping is outside the scope of this | |||
document. | document. | |||
Note that, unlike PointToPoint sessions, the discriminator values on | Note that, unlike PointToPoint sessions, the My Discriminator value | |||
all multipoint session types MUST NOT be changed during the life of a | on MultipointHead session MUST NOT be changed during the life of a | |||
session. This is a side effect of the more complex demultiplexing | session. This is a side effect of the more complex demultiplexing | |||
scheme. | scheme. | |||
4.8. Packet consumption on tails | 4.8. Packet consumption on tails | |||
BFD packets received on tails for a multicast group MUST be consumed | BFD packets received on tails for a multicast group MUST be consumed | |||
by tails and MUST not be forwarded to receivers. Session of type | by tails and MUST NOT be forwarded to receivers. Session of type | |||
MultipointTail MUST identify the packet as BFD with the help of | MultipointTail MUST identify the packet as BFD with the help of | |||
destination UDP port number "3784" on IP multipoint path. For | destination UDP port number "3784" on IP multipoint path. | |||
multipoint LSP, MultipointTail MUST use destination UDP port "3784" | ||||
and IP "127.0.0.0/8" range. Packet identified as BFD packet MUST be | For multipoint LSP, when IP/UDP encapsulation of BFD control packet | |||
consumed by MultipointTail and demultiplex as described in | used, MultipointTail MUST use destination UDP port "3784" and | |||
Section 4.13.2 | "127.0.0.0/8" range for IPv4 or "0:0:0:0:0:FFFF:7F00:0/104" range for | |||
IPv6. Packet identified as BFD packet MUST be consumed by | ||||
MultipointTail and demultiplex as described in Section 4.13.2. Use | ||||
of other types of encapsulation for multipoint LSP is outside the | ||||
scope of this document. | ||||
4.9. Bringing Up and Shutting Down Multipoint BFD Service | 4.9. Bringing Up and Shutting Down Multipoint BFD Service | |||
Because there is no three-way handshake in Multipoint BFD, a newly | Because there is no three-way handshake in Multipoint BFD, a newly | |||
started head (that does not have any previous state information | started head (that does not have any previous state information | |||
available) SHOULD start with bfd.SessionState set to Down and with | available) SHOULD start with bfd.SessionState set to Down and with | |||
bfd.RequiredMinRxInterval set to zero in the MultipointHead session. | bfd.RequiredMinRxInterval set to zero in the MultipointHead session. | |||
The session SHOULD remain in this state for a time equal to | The session SHOULD remain in this state for a time equal to | |||
(bfd.DesiredMinTxInterval * bfd.DetectMult). This will ensure that | (bfd.DesiredMinTxInterval * bfd.DetectMult). This will ensure that | |||
all MultipointTail sessions are reset (so long as the restarted head | all MultipointTail sessions are reset (so long as the restarted head | |||
skipping to change at page 9, line 5 ¶ | skipping to change at page 9, line 17 ¶ | |||
4.10. Timer Manipulation | 4.10. Timer Manipulation | |||
Because of the one-to-many mapping, a session of type MultipointHead | Because of the one-to-many mapping, a session of type MultipointHead | |||
SHOULD NOT initiate a Poll Sequence in conjunction with timer value | SHOULD NOT initiate a Poll Sequence in conjunction with timer value | |||
changes. However to indicate change in packet MultipointHead session | changes. However to indicate change in packet MultipointHead session | |||
MUST send packet with P bit set. MultipointTail session MUST NOT | MUST send packet with P bit set. MultipointTail session MUST NOT | |||
reply if packet has M, P bit set and bfd.RequiredMinRxInterval set to | reply if packet has M, P bit set and bfd.RequiredMinRxInterval set to | |||
0. | 0. | |||
The MultipointHead MUST send bfd.DetectMult packets with P bit set at | The MultipointHead, when changing the transmit interval to higher | |||
the old transmit interval before using the higher value in order to | value, MUST send BFD control packets with P bit set at the old | |||
avoid false detection timeouts at the tails. MultipointHead May also | transmit interval before using the higher value in order to avoid | |||
wait some amount of time before making the changes to the transmit | false detection timeouts at the tails. MultipointHead MAY also wait | |||
some amount of time before making the changes to the transmit | ||||
interval (through configuration). | interval (through configuration). | |||
Change in the value of bfd.RequiredMinRxInterval is outside the scope | Change in the value of bfd.RequiredMinRxInterval is outside the scope | |||
of this document. | of this document. | |||
4.11. Detection Times | 4.11. Detection Times | |||
Multipoint BFD is inherently asymmetric. As such, each session type | Multipoint BFD is inherently asymmetric. As such, each session type | |||
has a different approach to detection times. | has a different approach to detection times. | |||
skipping to change at page 13, line 31 ¶ | skipping to change at page 13, line 48 ¶ | |||
combination of other fields, possibly including source | combination of other fields, possibly including source | |||
addressing information, the My Discriminator field, and the | addressing information, the My Discriminator field, and the | |||
interface over which the packet was received. The exact | interface over which the packet was received. The exact | |||
method of selection is application-specific and is thus | method of selection is application-specific and is thus | |||
outside the scope of this specification. | outside the scope of this specification. | |||
If a matching session is found, and bfd.SessionType is not | If a matching session is found, and bfd.SessionType is not | |||
PointToPoint, the packet MUST be discarded. | PointToPoint, the packet MUST be discarded. | |||
If a matching session is not found, a new session of type | If a matching session is not found, a new session of type | |||
PointToPoint may be created, or the packet may be discarded. | PointToPoint MAY be created, or the packet MAY be discarded. | |||
This choice is outside the scope of this specification. | This choice is outside the scope of this specification. | |||
If the State field is Init and bfd.SessionType is not | If the State field is Init and bfd.SessionType is not | |||
PointToPoint, the packet MUST be discarded. | PointToPoint, the packet MUST be discarded. | |||
4.13.3. Transmitting BFD Control Packets | 4.13.3. Transmitting BFD Control Packets | |||
The following procedure replaces section 6.8.7 of [RFC5880]. | The following procedure replaces section 6.8.7 of [RFC5880]. | |||
BFD Control packets MUST be transmitted periodically at the rate | BFD Control packets MUST be transmitted periodically at the rate | |||
skipping to change at page 14, line 20 ¶ | skipping to change at page 14, line 37 ¶ | |||
A system MUST NOT periodically transmit BFD Control packets if | A system MUST NOT periodically transmit BFD Control packets if | |||
bfd.RemoteMinRxInterval is zero. | bfd.RemoteMinRxInterval is zero. | |||
If bfd.SessionType is MultipointHead, the transmit interval MUST be | If bfd.SessionType is MultipointHead, the transmit interval MUST be | |||
set to bfd.DesiredMinTxInterval (this should happen automatically, as | set to bfd.DesiredMinTxInterval (this should happen automatically, as | |||
bfd.RemoteMinRxInterval will be zero.) | bfd.RemoteMinRxInterval will be zero.) | |||
If bfd.SessionType is not MultipointHead, the transmit interval MUST | If bfd.SessionType is not MultipointHead, the transmit interval MUST | |||
be recalculated whenever bfd.DesiredMinTxInterval changes, or | be recalculated whenever bfd.DesiredMinTxInterval changes, or | |||
whenever bfd.RemoteMinRxInterval changes, and is equal to the greater | whenever bfd.RemoteMinRxInterval changes, and is equal to the greater | |||
of those two values. See [BFD] sections 6.8.2 and 6.8.3 for details | of those two values. See [RFC5880] sections 6.8.2 and 6.8.3 for | |||
on transmit timers. | details on transmit timers. | |||
A system MUST NOT set the Demand (D) bit if bfd.SessionType is | A system MUST NOT set the Demand (D) bit if bfd.SessionType is | |||
MultipointTail. | MultipointTail. | |||
A system MUST NOT set the Demand (D) bit if bfd.SessionType | A system MUST NOT set the Demand (D) bit if bfd.SessionType | |||
PointToPoint unless bfd.DemandMode is 1, bfd.SessionState is Up, and | PointToPoint unless bfd.DemandMode is 1, bfd.SessionState is Up, and | |||
bfd.RemoteSessionState is Up. | bfd.RemoteSessionState is Up. | |||
If bfd.SessionType is PointToPoint or MultipointHead, a BFD Control | If bfd.SessionType is PointToPoint or MultipointHead, a BFD Control | |||
packet SHOULD be transmitted during the interval between periodic | packet SHOULD be transmitted during the interval between periodic | |||
skipping to change at page 16, line 36 ¶ | skipping to change at page 17, line 7 ¶ | |||
If authentication is in use, all tails must be configured to have a | If authentication is in use, all tails must be configured to have a | |||
common authentication key in order to receive the multipoint BFD | common authentication key in order to receive the multipoint BFD | |||
Control packets. | Control packets. | |||
6. IANA Considerations | 6. IANA Considerations | |||
This document has no actions for IANA. | This document has no actions for IANA. | |||
7. Security Considerations | 7. Security Considerations | |||
Implementations that creates MultpointTail sessions dynamically upon | Implementations that create MultpointTail sessions dynamically upon | |||
receipt of Multipoint BFD Control packets MUST implement protective | receipt of Multipoint BFD Control packets MUST implement protective | |||
measures to prevent infinite number of MultipointTail session being | measures to prevent infinite number of MultipointTail sessions being | |||
created. Below lists some points to be considered in such | created. Below are listed some points to be considered in such | |||
implementations. | implementations. | |||
If a Multipoint BFD Control packet did not arrive on a multicast | If a Multipoint BFD Control packet did not arrive on a multicast | |||
tree (ex: on expected interface, with expected MPLS label, etc), | tree (ex: on expected interface, with expected MPLS label, etc), | |||
then a MultipointTail session should not be created. | then a MultipointTail session should not be created. | |||
If redundant streams are expected for a given multicast stream, | If redundant streams are expected for a given multicast stream, | |||
then the implementations should not create more MultipointTail | then the implementations should not create more MultipointTail | |||
sessions than the number of streams. Additionally, when the | sessions than the number of streams. Additionally, when the | |||
number of MultipointTail sessions exceeds the number of expected | number of MultipointTail sessions exceeds the number of expected | |||
skipping to change at page 17, line 33 ¶ | skipping to change at page 18, line 5 ¶ | |||
[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>. | |||
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | |||
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, | (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, | |||
<https://www.rfc-editor.org/info/rfc5880>. | <https://www.rfc-editor.org/info/rfc5880>. | |||
[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. | ||||
Pallagatti, "Seamless Bidirectional Forwarding Detection | ||||
(S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, | ||||
<https://www.rfc-editor.org/info/rfc7880>. | ||||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
Authors' Addresses | Authors' Addresses | |||
Dave Katz | Dave Katz | |||
Juniper Networks | Juniper Networks | |||
1194 N. Mathilda Ave. | 1194 N. Mathilda Ave. | |||
Sunnyvale, California 94089-1206 | Sunnyvale, California 94089-1206 | |||
USA | USA | |||
Email: dkatz@juniper.net | Email: dkatz@juniper.net | |||
skipping to change at page 18, line 4 ¶ | skipping to change at page 18, line 31 ¶ | |||
Email: dkatz@juniper.net | Email: dkatz@juniper.net | |||
Dave Ward | Dave Ward | |||
Cisco Systems | Cisco Systems | |||
170 West Tasman Dr. | 170 West Tasman Dr. | |||
San Jose, California 95134 | San Jose, California 95134 | |||
USA | USA | |||
Email: wardd@cisco.com | Email: wardd@cisco.com | |||
Santosh Pallagatti (editor) | Santosh Pallagatti (editor) | |||
Individual contributor | Individual contributor | |||
Email: santosh.pallagatti@gmail.com | Email: santosh.pallagatti@gmail.com | |||
Greg Mirsky (editor) | ||||
ZTE Corp. | ||||
Email: gregimirsky@gmail.com | ||||
End of changes. 28 change blocks. | ||||
42 lines changed or deleted | 68 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/ |