draft-ietf-mpls-p2mp-bfd-00.txt   draft-ietf-mpls-p2mp-bfd-01.txt 
MPLS Working Group G. Mirsky MPLS Working Group G. Mirsky
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track G. Mishra Intended status: Standards Track G. Mishra
Expires: 13 August 2022 Verizon Inc. Expires: 14 August 2022 Verizon Inc.
D. Eastlake D. Eastlake
Futurewei Technologies Futurewei Technologies
9 February 2022 10 February 2022
BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP
draft-ietf-mpls-p2mp-bfd-00 draft-ietf-mpls-p2mp-bfd-01
Abstract Abstract
This document describes procedures for using Bidirectional Forwarding This document describes procedures for using Bidirectional Forwarding
Detection (BFD) for multipoint networks to detect data plane failures Detection (BFD) for multipoint networks to detect data plane failures
in Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp) in Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp)
Label Switched Paths (LSPs) and Segment Routing (SR) point-to- Label Switched Paths (LSPs) and Segment Routing (SR) point-to-
multipoint policies with SR-MPLS data plane. multipoint policies with SR-MPLS data plane.
It also describes the applicability of LSP Ping, as in-band, and the It also describes the applicability of LSP Ping, as in-band, and the
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 13 August 2022. This Internet-Draft will expire on 14 August 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 28 skipping to change at page 2, line 28
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Multipoint BFD Encapsulation . . . . . . . . . . . . . . . . 3 3. Multipoint BFD Encapsulation . . . . . . . . . . . . . . . . 3
3.1. IP Encapsulation of Multipoint BFD . . . . . . . . . . . 4 3.1. IP Encapsulation of Multipoint BFD . . . . . . . . . . . 4
3.2. Non-IP Encapsulation of Multipoint BFD . . . . . . . . . 4 3.2. Non-IP Encapsulation of Multipoint BFD . . . . . . . . . 4
4. Bootstrapping Multipoint BFD . . . . . . . . . . . . . . . . 5 4. Bootstrapping Multipoint BFD . . . . . . . . . . . . . . . . 5
4.1. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Control Plane . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Control Plane . . . . . . . . . . . . . . . . . . . . . . 6
5. Operation of Multipoint BFD with Active Tail over P2MP MPLS 5. Operation of Multipoint BFD with Active Tail over P2MP MPLS
LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
[RFC8562] defines a method of using Bidirectional Detection (BFD) [RFC8562] defines a method of using Bidirectional Detection (BFD)
[RFC5880] to monitor and detect unicast failures between the sender [RFC5880] to monitor and detect unicast failures between the sender
(head) and one or more receivers (tails) in multipoint or multicast (head) and one or more receivers (tails) in multipoint or multicast
networks. networks.
[RFC8562] added two BFD session types - MultipointHead and [RFC8562] added two BFD session types - MultipointHead and
MultipointTail. Throughout this document, MultipointHead and MultipointTail. Throughout this document, MultipointHead and
skipping to change at page 5, line 6 skipping to change at page 5, line 6
3.2. Non-IP Encapsulation of Multipoint BFD 3.2. Non-IP Encapsulation of Multipoint BFD
In some environments, the overhead of extra IP/UDP encapsulations may In some environments, the overhead of extra IP/UDP encapsulations may
be considered burdensome, making the use of more compact G-ACh be considered burdensome, making the use of more compact G-ACh
encapsulation attractive. Also, the validation of the IP/UDP encapsulation attractive. Also, the validation of the IP/UDP
encapsulation of a BFD Control packet in a p2mp BFD session may fail encapsulation of a BFD Control packet in a p2mp BFD session may fail
because of a problem related to neither the MPLS label stack nor to because of a problem related to neither the MPLS label stack nor to
BFD. Avoiding unnecessary encapsulation of p2mp BFD over an MPLS LSP BFD. Avoiding unnecessary encapsulation of p2mp BFD over an MPLS LSP
improves the accuracy of the correlation of the detected failure and improves the accuracy of the correlation of the detected failure and
defect in MPLS LSP. Non-IP encapsulation for multipoint BFD over defect in MPLS LSP. Non-IP encapsulation for multipoint BFD over
p2mp MPLS LSP MUST use Generic Associated Channel (G-ACh) Label (GAL) p2mp MPLS LSP (shown in Figure 1) MUST use Generic Associated Channel
(see [RFC5586]) at the bottom of the label stack followed by an (G-ACh) Label (GAL) (see [RFC5586]) at the bottom of the label stack
Associated Channel Header (ACH). If a BFD Control packet in PW-ACH followed by an Associated Channel Header (ACH). If a BFD Control
encapsulation (without IP/UDP Headers) is to be used in ACH, an packet in PW-ACH encapsulation (without IP/UDP Headers) is to be used
implementation would not be able to verify the identity of the in ACH, an implementation would not be able to verify the identity of
MultipointHead and, as a result, will not properly demultiplex BFD the MultipointHead and, as a result, will not properly demultiplex
packets. Hence, a new channel type value is needed. The Channel BFD packets. Hence, a new channel type value is needed. The Channel
Type field in ACH MUST be set to TBA1 value Section 7. To provide Type field in ACH MUST be set to TBA1 value Section 7. To provide
the identity of the MultipointHead for the particular multipoint BFD the identity of the MultipointHead for the particular multipoint BFD
session, a Source Address TLV [RFC7212] MUST immediately follow a BFD session, a Source Address TLV, as defined in Section 4.1 [RFC7212],
Control message. MUST immediately follow a BFD Control message.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL | TC |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type = TBA1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ BFD Control Message ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0 | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (16 bits) | Address Family (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: VRRP Extension to Bootstrap P2MP BFD session
4. Bootstrapping Multipoint BFD 4. Bootstrapping Multipoint BFD
4.1. LSP Ping 4.1. LSP Ping
LSP Ping is the part of the on-demand OAM toolset used to detect and LSP Ping is the part of the on-demand OAM toolset used to detect and
localize defects in the data plane and verify the control plane localize defects in the data plane and verify the control plane
against the data plane by ensuring that the LSP is mapped to the same against the data plane by ensuring that the LSP is mapped to the same
FEC at both egress and ingress endpoints. FEC at both egress and ingress endpoints.
 End of changes. 9 change blocks. 
18 lines changed or deleted 38 lines changed or added

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