draft-ietf-bfd-multipoint-17.txt   draft-ietf-bfd-multipoint-18.txt 
Internet Engineering Task Force D. Katz Internet Engineering Task Force D. Katz
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Updates: 5880 (if approved) D. Ward Updates: 5880 (if approved) D. Ward
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: December 6, 2018 S. Pallagatti, Ed. Expires: December 20, 2018 S. Pallagatti, Ed.
Individual contributor Individual contributor
G. Mirsky, Ed. G. Mirsky, Ed.
ZTE Corp. ZTE Corp.
June 4, 2018 June 18, 2018
BFD for Multipoint Networks BFD for Multipoint Networks
draft-ietf-bfd-multipoint-17 draft-ietf-bfd-multipoint-18
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. networks.
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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 December 6, 2018. This Internet-Draft will expire on December 20, 2018.
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 3, line 13 skipping to change at page 3, line 13
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, the Although this seems in conflict with the "Bidirectional" in BFD, the
protocol is capable of supporting this use case. Use of BFD in protocol is capable of supporting this use case. Use of BFD in
Demand mode enables a tail monitor availability of a multipoint path Demand mode enables a tail monitor availability of a multipoint path
even without the existence of some kind of a return path to the head. even without the existence of some kind of a return path to the head.
As an option, if a return path from a tail to the head exists, the
tail may notify the head of the lack of multipoint connectivity.
Details of tail notification to the head are outside the scope of
this document and are discussed in
[I-D.ietf-bfd-multipoint-active-tail].
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. For some applications such detection of connectivity from the head. For some applications such detection of
the failure at the tail is useful. For example, use of multipoint the failure at the tail is useful. For example, use of multipoint
BFD to enable fast failure detection and faster failover in multicast BFD to enable fast failure detection and faster failover in multicast
VPN described in [I-D.ietf-bess-mvpn-fast-failover]. Due to VPN described in [I-D.ietf-bess-mvpn-fast-failover]. Due to
unidirectional nature, virtually all options and timing parameters unidirectional nature, virtually all options and timing parameters
are controlled by the head. are controlled by the head.
As an option, the tail may notify the head of the lack of multipoint
connectivity. Details of tail notification to the head are outside
the scope of this document and are discussed in
[I-D.ietf-bfd-multipoint-active-tail].
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 the context Term "connectivity" in this document is not being used in the context
of connectivity verification in transport network but as an of connectivity verification in transport network but as an
alternative to "continuity", i.e., the existence of a forwarding path alternative to "continuity", i.e., the existence of a forwarding path
between the sender and the receiver. between the sender and the receiver.
skipping to change at page 9, line 31 skipping to change at page 9, line 31
5.10. Timer Manipulation 5.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 a change in the packets, changes. However, to indicate a change in the packets,
MultipointHead session MUST send packets with the P bit set. MultipointHead session MUST send packets with the P bit set.
MultipointTail session MUST NOT reply if the packet has M and P bits MultipointTail session MUST NOT reply if the packet has M and P bits
set and bfd.RequiredMinRxInterval set to 0. Because the Poll set and bfd.RequiredMinRxInterval set to 0. Because the Poll
Sequence is not used, the tail cannot negotiate down MultpointHead's Sequence is not used, the tail cannot negotiate down MultpointHead's
transmit interval. If the value Desired Min TX Interval in the transmit interval. If the value of Desired Min TX Interval in the
received by MultipointTail BFD Control packet is too high (that BFD Control packet received by MultipointTail is too high (that
determination may change in time based on the current environment) it determination may change in time based on the current environment) it
must be handled by the implementation and may be controlled by local must be handled by the implementation and may be controlled by local
policy, e.g., close the MultipointTail session. policy, e.g., close the MultipointTail session.
The MultipointHead, when changing the transmit interval to a higher The MultipointHead, when changing the transmit interval to a higher
value, MUST send BFD control packets with P bit set at the old value, MUST send BFD control packets with P bit set at the old
transmit interval before using the higher value in order to avoid transmit interval before using the higher value in order to avoid
false detection timeouts at the tails. MultipointHead session MAY false detection timeouts at the tails. MultipointHead session MAY
also wait some amount of time before making the changes to the also wait some amount of time before making the changes to the
transmit interval (through configuration). transmit interval (through configuration).
skipping to change at page 11, line 7 skipping to change at page 11, line 7
5.13. Base Specification Text Replacement 5.13. Base Specification Text Replacement
The following sections are meant to replace the corresponding The following sections are meant to replace the corresponding
sections in the base specification [RFC5880] in support of BFD for sections in the base specification [RFC5880] in support of BFD for
multipoint networks while not changing processing for point-to-point multipoint networks while not changing processing for point-to-point
BFD. BFD.
5.13.1. Reception of BFD Control Packets 5.13.1. Reception of BFD Control Packets
The following procedure replaces entire section 6.8.6 of [RFC5880]. The following procedure replaces the entire section 6.8.6 of
[RFC5880].
When a BFD Control packet is received, the following procedure MUST When a BFD Control packet is received, the following procedure MUST
be followed, in the order specified. If the packet is discarded be followed, in the order specified. If the packet is discarded
according to these rules, processing of the packet MUST cease at that according to these rules, processing of the packet MUST cease at that
point. point.
If the version number is not correct (1), the packet MUST be If the version number is not correct (1), the packet MUST be
discarded. discarded.
If the Length field is less than the minimum correct value (24 if If the Length field is less than the minimum correct value (24 if
skipping to change at page 14, line 49 skipping to change at page 14, line 49
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 MAY be controlled by a local policy and is This choice MAY be controlled by a local policy and is
outside the scope of this specification. 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.
5.13.3. Transmitting BFD Control Packets 5.13.3. Transmitting BFD Control Packets
The following procedure replaces entire section 6.8.7 of [RFC5880]. The following procedure replaces the entire 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
determined according to [RFC5880] section 6.8.2, except as specified determined according to [RFC5880] section 6.8.2, except as specified
in this section. in this section.
A system MUST NOT transmit any BFD Control packets if bfd.RemoteDiscr A system MUST NOT transmit any BFD Control packets if bfd.RemoteDiscr
is zero and the system is taking the Passive role. is zero and the system is taking the Passive role.
A system MUST NOT transmit any BFD Control packets if bfd.SessionType A system MUST NOT transmit any BFD Control packets if bfd.SessionType
is MultipointTail. is MultipointTail.
skipping to change at page 17, line 36 skipping to change at page 17, line 36
MultipointTail. MultipointTail.
Authentication Section Authentication Section
Included and set according to the rules in [RFC5880] section Included and set according to the rules in [RFC5880] section
6.7 if authentication is in use (bfd.AuthType is nonzero). 6.7 if authentication is in use (bfd.AuthType is nonzero).
Otherwise, this section is not present. Otherwise, this section is not present.
6. Assumptions 6. Assumptions
If authentication is in use, the head and all tails may be configured
to have a common authentication key in order for the tails to
validate multipoint BFD Control packets.
Shared keys in multipoint scenarios allow any tail to spoof the head Shared keys in multipoint scenarios allow any tail to spoof the head
from the viewpoint of any other tail. For this reason, using shared from the viewpoint of any other tail. For this reason, using shared
keys to authenticate BFD Control packets in multipoint scenarios is a keys to authenticate BFD Control packets in multipoint scenarios is a
significant security exposure unless all tails can be trusted not to significant security exposure unless all tails can be trusted not to
spoof the head. Otherwise, asymmetric message authentication would spoof the head. Otherwise, asymmetric message authentication would
be needed, e.g., protocols that use Timed Efficient Stream Loss- be needed, e.g., protocols that use Timed Efficient Stream Loss-
Tolerant Authentication (TESLA) as described in [RFC4082]. Tolerant Authentication (TESLA) as described in [RFC4082].
If authentication is in use, the head and all tails may be configured
to have a common authentication key in order for the tails to
validate multipoint BFD Control packets.
7. IANA Considerations 7. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
8. Security Considerations 8. Security Considerations
The same security considerations as those described in [RFC5880] The same security considerations as those described in [RFC5880]
apply to this document. Additionally, implementations that create apply to this document. Additionally, implementations that create
MultpointTail sessions dynamically upon receipt of Multipoint BFD MultpointTail sessions dynamically upon receipt of Multipoint BFD
Control packets MUST implement protective measures to prevent an Control packets MUST implement protective measures to prevent an
 End of changes. 11 change blocks. 
17 lines changed or deleted 19 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/