draft-ietf-pim-p2mp-policy-ping-00.txt   draft-ietf-pim-p2mp-policy-ping-01.txt 
Network Working Group H. Bidgoli, Ed. Network Working Group H. Bidgoli, Ed.
Internet-Draft Nokia Internet-Draft Nokia
Intended status: Standards Track V. Voyer Intended status: Standards Track V. Voyer
Expires: 11 June 2022 Bell Canada Expires: 15 June 2022 Bell Canada
P. Parekh P. Parekh
Cisco System Cisco System
Z. Zhang Z. Zhang
Juniper Networks Juniper Networks
8 December 2021 12 December 2021
P2MP Policy Ping P2MP Policy Ping
draft-ietf-pim-p2mp-policy-ping-00 draft-ietf-pim-p2mp-policy-ping-01
Abstract Abstract
SR P2MP policies are set of policies that enable architecture for SR P2MP policies are set of policies that enable architecture for
P2MP service delivery. A P2MP Policy consists of candidate paths P2MP service delivery. A P2MP Policy consists of candidate paths
that connects the Root of the Tree to a set of Leaves. The P2MP that connects the Root of the Tree to a set of Leaves. The P2MP
policy is composed of replication segments. A replication segment is policy is composed of replication segments. A replication segment is
a forwarding instruction for a candidate path which is downloaded to a forwarding instruction for a candidate path which is downloaded to
the Root, transit nodes and the leaves. the Root, transit nodes and the leaves.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 11 June 2022. This Internet-Draft will expire on 15 June 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 3, line 44 skipping to change at page 3, line 44
replicated at the replication point based on the replication segment replicated at the replication point based on the replication segment
forwarding information on the corresponding node. This draft only forwarding information on the corresponding node. This draft only
addresses the replication segments that use MPLS encap only, future addresses the replication segments that use MPLS encap only, future
drafts will address the SRv6 forwarding. The packet are processed drafts will address the SRv6 forwarding. The packet are processed
accordingly when their TTL expires or when the egress router (leaf) accordingly when their TTL expires or when the egress router (leaf)
is reached. The appropriate respond is send back to the root as per is reached. The appropriate respond is send back to the root as per
procedures in [RFC6425] procedures in [RFC6425]
This draft reuses most procedures for mLDP in RFC [RFC6425] This draft reuses most procedures for mLDP in RFC [RFC6425]
This draft also reuses the same destination UDP port as [RFC4379] This draft also reuses the same destination UDP port as [RFC8029]
The implementation should take into account that there can be many The implementation should take into account that there can be many
CPs under the P2MP Policy and the implementation should allow each CP 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 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 Ping and Traceroute packet is forwarded via that specific CP and its
corresponding replication segments. On the egress node the corresponding replication segments. On the egress node the
corresponding CP and its PI should respond irrespective if it is the corresponding CP and its PI should respond irrespective if it is the
active CP or a backup CP. active CP or a backup CP.
Two replication segments can be connected via a unicast SR domain. Two replication segments can be connected via a unicast SR domain.
skipping to change at page 4, line 18 skipping to change at page 4, line 18
is used. As an example pipe vs uniform mode. When in SR domain the 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 P2MP Tree PING and Traceroute will be processed on the two connecting
replication segments based on the replication SID and its TTL. As 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 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 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 SR SIDs are pushed on the replication SID. To detect failure in SR
domain is beyond the scope of this draft. domain is beyond the scope of this draft.
3.2. Packet format and new TLVs 3.2. Packet format and new TLVs
The packet format used is as per [RFC4379] section 3. Some 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 and sub-TLVs are required to support the new functionality. They are
described in the following sections. described in the following sections.
3.2.1. Identifying a P2MP Policy 3.2.1. Identifying a P2MP Policy
[RFC4379] defines how an MPLS TE LSP under test may be identified in [RFC8029] a simple and efficient mechanism to detect data-plane
an echo request.In order to identify the correct replication segment failures in Multiprotocol Label Switching (MPLS) Label Switched Paths
for the CP and its PI, the echo request message MUST carry a Target (LSPs). In order to identify the correct replication segment for the
FEC Stack TLV, and this MUST carry exactly one of one new sub-TLV: a CP and its PI, the echo request message MUST carry a Target FEC Stack
P2MP policy MPLS CP FEC Stack sub-TLV. The new sub-TLV is assigned TLV, this draft defines a new sub-TLV: a P2MP policy MPLS CP FEC
Sub-Type identifiers as follows, and are described in the following Stack sub-TLV. The new sub-TLV is assigned Sub-Type identifiers
sections. (TBD), and are described in the following sections.
artwork artwork
Sub-Type Length Value Field Sub-Type Length Value Field
-------- ------ ----------- -------- ------ -----------
42 xx P2MP Policy MPLS CP TBD xx P2MP Policy MPLS CP
3.2.1.1. P2MP Policy CP FEC Stack Sub-TLVs 3.2.1.1. P2MP Policy CP FEC Stack Sub-TLVs
The format of the P2MP Policy Session sub-TLV value field is The format of the P2MP Policy Session sub-TLV value field is
specified in the following figure. The value fields are taken from specified in the following figure. The value fields are taken from
the definitions of the P2MP Policy section 3 of the definitions of the P2MP Policy section 3 of
[draft-ietf-pim-sr-p2mp-policy-02] [draft-ietf-pim-sr-p2mp-policy-02]
artwork artwork
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
skipping to change at page 6, line 9 skipping to change at page 6, line 9
in the P2MP Responder Identifier TLV carried on the echo request in the P2MP Responder Identifier TLV carried on the echo request
message. message.
The Sub-TLVs for IPv4 and IPv6 egress address P2MP responder is in The Sub-TLVs for IPv4 and IPv6 egress address P2MP responder is in
par with [RFC6425] section 3.2.1 par with [RFC6425] section 3.2.1
The Sub-TLVs for IPv4 and IPv6 node address P2MP responder is in par The Sub-TLVs for IPv4 and IPv6 node address P2MP responder is in par
with [RFC6425] section 3.2.2 with [RFC6425] section 3.2.2
4. IANA Consideration 4. IANA Consideration
Two new sub-TLV types are defined for inclusion within the LSP ping IANA is requested to assign a value (TBD) to the P2MP Policy MPLS CP
[RFC4379] Target FEC Stack TLV (TLV type 1). from the mpls-lsp-ping parameters, TLV types 1, 16 and 21
5. Security Considerations 5. Security Considerations
TBD TBD
6. Acknowledgments 6. Acknowledgments
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] "S. Brandner, "Key words for use in RFCs to Indicate [RFC2119] "S. Brandner, "Key words for use in RFCs to Indicate
Requirement Levels"", March 1997. 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 [RFC8174] "B. Leiba, "ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words"", May 2017. 2119 Key Words"", May 2017.
7.2. Informative References 7.2. Informative References
[draft-ietf-pim-sr-p2mp-policy-02] [draft-ietf-pim-sr-p2mp-policy-02]
"D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang, "D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang,
"draft-voyer-pim-sr-p2mp-policy"", October 2019. "draft-ietf-pim-sr-p2mp-policy"", October 2019.
[draft-ietf-spring-segment-routing-policy-13] [draft-ietf-spring-segment-routing-policy-13]
"D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang, "D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang,
"draft-voyer-pim-sr-p2mp-policy "draft-voyer-spring-sr- "draft-ietf-spring-sr-replication-segment"", July 2020.
replication-segment"", July 2020.
[RFC4379] "K. Kompella, G. Swallow", February 2006.
[RFC6425] "S. Saxena, G. Swallow, Z. Ali, A. Farrel, S. Yasukawa, [RFC6425] "S. Saxena, G. Swallow, Z. Ali, A. Farrel, S. Yasukawa,
T.Nadeau "Detecting Data-Plane Failures in Point-to- T.Nadeau "Detecting Data-Plane Failures in Point-to-
Multipoint MPLS"", November 2011. Multipoint MPLS"", November 2011.
Authors' Addresses Authors' Addresses
Hooman Bidgoli (editor) Hooman Bidgoli (editor)
Nokia Nokia
Ottawa Ottawa
Canada Canada
skipping to change at page 7, line 30 skipping to change at page 7, line 30
San Jose, San Jose,
United States of America United States of America
Email: riparekh@cisco.com Email: riparekh@cisco.com
Zhaohui Zhang Zhaohui Zhang
Juniper Networks Juniper Networks
Boston, Boston,
United States of America United States of America
Email: zzhang@juniper.com Email: zzhang@juniper.net
 End of changes. 13 change blocks. 
21 lines changed or deleted 22 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/