Internet DRAFT - draft-ietf-pim-p2mp-policy-ping
draft-ietf-pim-p2mp-policy-ping
Network Working Group H. Bidgoli, Ed.
Internet-Draft Nokia
Intended status: Standards Track V. Voyer
Expires: 23 April 2024 Bell Canada
P. Parekh
Cisco System
Z. Zhang
Juniper Networks
21 October 2023
P2MP Policy Ping
draft-ietf-pim-p2mp-policy-ping-04
Abstract
SR P2MP policies are set of policies that enable architecture for
P2MP service delivery. A P2MP Policy consists of candidate paths
that connects the Root of the Tree to a set of Leaves. The P2MP
policy is composed of replication segments. A replication segment is
a forwarding instruction for a candidate path which is downloaded to
the Root, transit nodes and the leaves.
This document describes a simple and efficient mechanism that can be
used to detect data plane failures in P2MP Policy Candidate Paths
(CPs) and Path Instances (PIs).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 23 April 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bidgoli, et al. Expires 23 April 2024 [Page 1]
Internet-Draft P2MP Policy Ping October 2023
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. MPLS P2MP Policy Ping and Traceroute . . . . . . . . . . 3
3.2. Packet format and new TLVs . . . . . . . . . . . . . . . 4
3.2.1. Identifying a P2MP Policy . . . . . . . . . . . . . . 4
3.2.1.1. P2MP Policy CP FEC Stack Sub-TLVs . . . . . . . . 4
3.3. Limiting the Scope of Response . . . . . . . . . . . . . 5
4. Implementation Status . . . . . . . . . . . . . . . . . . . . 6
4.1. Nokia Implementation . . . . . . . . . . . . . . . . . . 6
5. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Each P2MP Policy can have multiple Candidate Paths (CP)s. The CP
with highest preference is the active CP while all other CPs are the
backup CPs. A CP can have multiple PIs to allow global optimization
of the CP via Make Before Break procedures between the active PI and
the newly setup and optimized PI.
It is desirable to test the end to end connectivity of a CP, whether
it is the active CP or a backup CP and all the CP's PIs. This
document describes a mechanism that can be used to detect data plane
failures in P2MP Policy CP and its associate Path Instances (PI).
This draft is only for replication SIDs that use MPLS encap for their
forwarding and not SRv6. It reuses most of the concepts in [RFC6425]
Bidgoli, et al. Expires 23 April 2024 [Page 2]
Internet-Draft P2MP Policy Ping October 2023
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"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.
3. Motivation
A P2MP Policy and its corresponding Replication Segments are usually
setup via a controller, the root and the leaves are discovered as per
[draft-ietf-pim-sr-p2mp-policy]. The tree is calculated from the
root to the leaves. There is no underlay protocol to signal the P2MP
Policy from the root to the Leaf routers, as such when a P2MP tree
fails to deliver user traffic, the failure can be difficult to pin
point without a ping/traceroute mechanism to isolate the fault in the
P2MP tree. The P2MP Policy ping/traceroute can be utilize to detect
faults on the path of the tree and its associated replication
segments [draft-ietf-spring-segment-routing-policy-13]. These tools
can be used to periodically ping the leaves to ensure connectivity.
If the ping fails, trace route can be initiated to determine where
the failure lies. The ping/traceroute can be initiated from the node
that initiates the P2MP policy.
3.1. MPLS P2MP Policy Ping and Traceroute
Ping/Traceroute packets are forwarded on the P2MP Policy, on a
specific CP or its active PI toward the leaf routers. They are
replicated at the replication point based on the replication segment
forwarding information on the corresponding node. This draft only
addresses the replication segments that use MPLS encap only, future
drafts will address the SRv6 forwarding. The packet are processed
accordingly when their TTL expires or when the egress router (leaf)
is reached. The appropriate respond is send back to the root as per
procedures in [RFC6425]
This draft reuses most procedures for mLDP in RFC [RFC6425]
This draft also reuses the same destination UDP port as [RFC8029]
The implementation should take into account that there can be many
CPs under the P2MP Policy and the implementation should allow each CP
and its corresponding PI to be tested via Ping and Trace route. The
Ping and Traceroute packet is forwarded via that specific CP and its
corresponding replication segments. On the egress node the
corresponding CP and its PI should respond irrespective if it is the
active CP or a backup CP.
Bidgoli, et al. Expires 23 April 2024 [Page 3]
Internet-Draft P2MP Policy Ping October 2023
Two replication segments can be connected via a unicast SR domain.
In this scenario the SR tunnel labels need to be programmed with the
right TTL depending on the which type of hierarchical MPLS TTL mode
is used. As an example pipe vs uniform mode. When in SR domain the
P2MP Tree PING and Traceroute will be processed on the two connecting
replication segments based on the replication SID and its TTL. As
such the SR domain will act as a single hop on the replication SID
and the replication SID TTL is subtracted by one before the unicast
SR SIDs are pushed on the replication SID. To detect failure in SR
domain is beyond the scope of this draft.
3.2. Packet format and new TLVs
The packet format used is as per [RFC8029] section 3. Some new TLVs
and sub-TLVs are required to support the new functionality. They are
described in the following sections.
3.2.1. Identifying a P2MP Policy
[RFC8029] defines a simple and efficient mechanism to detect data-
plane failures in Multiprotocol Label Switching (MPLS) Label Switched
Paths (LSPs). In order to identify the correct replication segment
for the CP and its PI, the echo request message MUST carry an
Identifier TLV for the Candidate path and the Path instance that is
under test. This draft defines a new sub-TLV: a P2MP policy MPLS
Candidate Path sub-TLV. The new sub-TLV is assigned Sub-Type
identifiers (TBD), and is described in the following sections.
artwork
Sub-Type Length Value Field
-------- ------ -----------
TBD xx P2MP Policy MPLS Candidate Path
3.2.1.1. P2MP Policy CP FEC Stack Sub-TLVs
The format of the P2MP Policy MPLS Candidate Path sub-TLV value field
is specified in the following figure. The value fields are taken
from the definitions of the P2MP Policy section 3 of
[draft-ietf-pim-sr-p2mp-policy]
Bidgoli, et al. Expires 23 April 2024 [Page 4]
Internet-Draft P2MP Policy Ping October 2023
artwork
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Address Length| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Root Address ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Address Family: Two-octet quantity, containing a value from
ADDRESS FAMILY NUMBERS in [IANA-AF] that encodes the address
family for the Root Address.
* Address Length: Length of the Root Address in octets, IPv4 or
IPv6.
* Root Address: The address of Root node of P2MP tree instantiated
by the SR P2MP Policy
* Tree-ID: A identifier that is unique in context of the Root. This
is an unsigned 32-bit number.
* Instance-ID: 32 bit value to identify the Path-Instance ID
[draft-ietf-pim-sr-p2mp-policy]
3.3. Limiting the Scope of Response
As per [RFC6425] section 3.2 Four sub-TLVs are used for the inclusion
in the P2MP Responder Identifier TLV carried on the echo request
message.
The Sub-TLVs for IPv4 and IPv6 egress address P2MP responder is in
par with [RFC6425] section 3.2.1
The Sub-TLVs for IPv4 and IPv6 node address P2MP responder is in par
with [RFC6425] section 3.2.2
Bidgoli, et al. Expires 23 April 2024 [Page 5]
Internet-Draft P2MP Policy Ping October 2023
4. Implementation Status
Note to the RFC Editor: please remove this section before
publication. This section records the status of known
implementations of the protocol defined by this specification at the
time of posting of this Internet-Draft, and is based on a proposal
described in RFC [RFC7942]. The description of implementations in
this section is intended to assist the IETF in its decision processes
in progressing drafts to RFCs. Please note that the listing of any
individual implementation here does not imply endorsement by the
IETF. Furthermore, no effort has been spent to verify the
information presented here that was supplied by IETF contributors.
This is not intended as, and must not be construed to be, a catalog
of available implementations or their features. Readers are advised
to note that other implementations may exist. According to RFC 7942
[RFC7942], "this will allow reviewers and working groups to assign
due consideration to documents that have the benefit of running code,
which may serve as evidence of valuable experimentation and feedback
that have made the implemented protocols more mature. It is up to
the individual working groups to use this information as they see
fit".
4.1. Nokia Implementation
Nokia has implemented [draft-ietf-pim-sr-p2mp-policy] and
[draft-ietf-spring-segment-routing-policy-13]. In addition, Nokia
has implemented P2MP policy ping as defined in this draft to verify
the end to end connectivity of a P2MP tree in segment routing domain.
The implementation supports SR-MPLS encapsulation and has all the
MUST and SHOULD clause in this draft. The implementation is at
general availability maturity and is compliant with the latest
version of the draft. The documentation for implementation can be
found at Nokia help and the point of contact is
hooman.bidgoli@nokia.com.
5. IANA Consideration
IANA has assigned the following code points for sub-type values to
the following sub-TLVs under TLV type 1 (Target FEC Stack) from the
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
Ping Parameters" registry, "TLVs and sub-TLVs" sub-registry. This
sub-type value is assigned from the standards Action of range 0-16383
for TLV type 1 (Target FEC Stack)
41: P2MP Policy MPLS Candidate Path
Bidgoli, et al. Expires 23 April 2024 [Page 6]
Internet-Draft P2MP Policy Ping October 2023
6. Security Considerations
Overall, the security needs for P2MP policy ping is same as
[RFC8029]. The P2MP policy ping is susceptible to the same three
attack vectors as explained in RFC8029 section 5. The same
procedures and RECOMMENDATIONS explained in RFC8029 section 5 should
be taken and implemented to mitigate these attack vectors for P2MP
policy Ping as well.
7. Acknowledgments
8. References
8.1. Normative References
[RFC2119] "S. Brandner, "Key words for use in RFCs to Indicate
Requirement Levels"", March 1997.
[RFC8029] "K. Kompella, G. Swallow, C. Pgnataro, N. kumar, S. Aldrin
M. Chen, "Detecting Multiprotocol Label Switched (MPLS)
Data-Plane Failures.", February 2006.
[RFC8174] "B. Leiba, "ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words"", May 2017.
8.2. Informative References
[draft-ietf-pim-sr-p2mp-policy]
"D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang,
"draft-ietf-pim-sr-p2mp-policy"", October 2019.
[draft-ietf-spring-segment-routing-policy-13]
"D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang,
"draft-ietf-spring-sr-replication-segment"", July 2020.
[RFC6425] "S. Saxena, G. Swallow, Z. Ali, A. Farrel, S. Yasukawa,
T.Nadeau "Detecting Data-Plane Failures in Point-to-
Multipoint MPLS"", November 2011.
[RFC7942] "S. Saxena, G. Swallow, Z. Ali, A. Farrel, S. Yasukawa,
T.Nadeau "Detecting Data-Plane Failures in Point-to-
Multipoint MPLS"", July 2016.
Authors' Addresses
Bidgoli, et al. Expires 23 April 2024 [Page 7]
Internet-Draft P2MP Policy Ping October 2023
Hooman Bidgoli (editor)
Nokia
Ottawa
Canada
Email: hooman.bidgoli@nokia.com
Daniel Voyer
Bell Canada
Montreal
Canada
Email: daniel.voyer@bell.ca
Rishabh Parekh
Cisco System
San Jose,
United States of America
Email: riparekh@cisco.com
Zhaohui Zhang
Juniper Networks
Boston,
United States of America
Email: zzhang@juniper.net
Bidgoli, et al. Expires 23 April 2024 [Page 8]
