draft-ietf-bess-mvpn-expl-track-10.txt   draft-ietf-bess-mvpn-expl-track-11.txt 
BESS WG A. Dolganow BESS WG A. Dolganow
Internet-Draft J. Kotalwar Internet-Draft J. Kotalwar
Updates: 6514 6625 7524 (if approved) Nokia Updates: 6514 6625 7524 (if approved) Nokia
Intended status: Standards Track E. Rosen, Ed. Intended status: Standards Track E. Rosen, Ed.
Expires: March 29, 2019 Z. Zhang Expires: April 7, 2019 Z. Zhang
Juniper Networks, Inc. Juniper Networks, Inc.
September 25, 2018 October 4, 2018
Explicit Tracking with Wild Card Routes in Multicast VPN Explicit Tracking with Wild Card Routes in Multicast VPN
draft-ietf-bess-mvpn-expl-track-10 draft-ietf-bess-mvpn-expl-track-11
Abstract Abstract
The MVPN specifications provide procedures to allow a multicast The MVPN specifications provide procedures to allow a multicast
ingress node to invoke "explicit tracking" for a multicast flow or ingress node to invoke "explicit tracking" for a multicast flow or
set of flows, thus learning the egress nodes for that flow or set of set of flows, thus learning the egress nodes for that flow or set of
flows. However, the specifications are not completely clear about flows. However, the specifications are not completely clear about
how the explicit tracking procedures work in certain scenarios. This how the explicit tracking procedures work in certain scenarios. This
document provides the necessary clarifications. It also specifies a document provides the necessary clarifications. It also specifies a
new, optimized explicit tracking procedure. This new procedure new, optimized explicit tracking procedure. This new procedure
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 March 29, 2019. This Internet-Draft will expire on April 7, 2019.
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 6, line 35 skipping to change at page 6, line 35
As will be discussed in Section 5.2, any Leaf A-D route originated in As will be discussed in Section 5.2, any Leaf A-D route originated in
response to an S-PMSI A-D route that has LIR-pF set will carry a PTA response to an S-PMSI A-D route that has LIR-pF set will carry a PTA
whose LIR-pF flag is set. If an ingress node receives a Leaf A-D whose LIR-pF flag is set. If an ingress node receives a Leaf A-D
route whose "route key" field corresponds to the NLRI of an S-PMSI route whose "route key" field corresponds to the NLRI of an S-PMSI
A-D route whose PTA has LIR-pF set, but the Leaf A-D route lacks a A-D route whose PTA has LIR-pF set, but the Leaf A-D route lacks a
PTA or has a PTA where LIR-pF is clear, the ingress node can conclude PTA or has a PTA where LIR-pF is clear, the ingress node can conclude
that the egress node originating that Leaf A-D route does not support that the egress node originating that Leaf A-D route does not support
the LIR-pF flag. the LIR-pF flag.
The software at the ingress node SHOULD detect this, and should have The software at the ingress node MUST detect this, and MUST have a
a way of alerting the operator that the deployment is not properly way of alerting the operator that the deployment is not properly
configured. configured.
3. Match for Tracking vs. Match for Reception 3. Match for Tracking vs. Match for Reception
Section 3.2 of [RFC6625] specifies a set of rules for finding the Section 3.2 of [RFC6625] specifies a set of rules for finding the
S-PMSI A-D route that is the "match for data reception" (or more S-PMSI A-D route that is the "match for data reception" (or more
simply, the "match for reception") of a given (C-S,C-G) or (C-*,C-G) simply, the "match for reception") of a given (C-S,C-G) or (C-*,C-G)
state. These rules do not take into account the fact that some state. These rules do not take into account the fact that some
S-PMSI A-D routes may not be carrying PTAs at all, or may be carrying S-PMSI A-D routes may not be carrying PTAs at all, or may be carrying
PTAs that do not identify any P-tunnel. (A PTA that does not PTAs that do not identify any P-tunnel. (A PTA that does not
 End of changes. 5 change blocks. 
6 lines changed or deleted 6 lines changed or added

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