draft-ietf-bess-mvpn-expl-track-02.txt   draft-ietf-bess-mvpn-expl-track-03.txt 
BESS WG A. Dolganow BESS WG A. Dolganow
Internet-Draft J. Kotalwar Internet-Draft J. Kotalwar
Updates: 6625 (if approved) Nokia Updates: 6625 (if approved) Nokia
Intended status: Standards Track E. Rosen, Ed. Intended status: Standards Track E. Rosen, Ed.
Expires: December 7, 2017 Z. Zhang Expires: March 26, 2018 Z. Zhang
Juniper Networks, Inc. Juniper Networks, Inc.
June 5, 2017 September 22, 2017
Explicit Tracking with Wild Card Routes in Multicast VPN Explicit Tracking with Wild Card Routes in Multicast VPN
draft-ietf-bess-mvpn-expl-track-02 draft-ietf-bess-mvpn-expl-track-03
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 36 skipping to change at page 1, line 36
RFC6625. RFC6625.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 7, 2017. This Internet-Draft will expire on March 26, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
skipping to change at page 6, line 35 skipping to change at page 6, line 35
o Route1: A (C-*,C-*) S-PMSI A-D route, whose PTA specifies a o Route1: A (C-*,C-*) S-PMSI A-D route, whose PTA specifies a
tunnel. tunnel.
o Route2: A (C-S1,C-G1) S-PMSI A-D route, whose PTA specifies "no o Route2: A (C-S1,C-G1) S-PMSI A-D route, whose PTA specifies "no
tunnel info" and has LIR set. tunnel info" and has LIR set.
Route1 is (C-S1,C-G1)'s match for reception, and Route2 is Route1 is (C-S1,C-G1)'s match for reception, and Route2 is
(C-S1,C-G1)'s match for tracking. (C-S1,C-G1)'s match for tracking.
Note that if there is no installed S-PMSI A-D route for (C-S2,C-G2), Continuing this example, suppose:
then Route1 would be (C-S2,C-G2)'s match for reception and also its
match for tracking. Also note that if a match for tracking does not o PE1 has chosen PE2 as the upstream PE for a different flow,
have the LIR flag or the LIR-pF flag set, no explicit tracking (C-S2,C-G2).
information will be generated. See Section 5.
o PE2 has not originated an S-PMSI A-D route for (C-S2,C-G2).
In this case, PE1 would consider Route1 to be (C-S2,C-G2)'s match for
tracking as well as its match for reception.
Also note that if a match for tracking does not have the LIR flag or
the LIR-pF flag set, no explicit tracking information will be
generated. See Section 5.
As another example, suppose PE1 has installed the following two As another example, suppose PE1 has installed the following two
routes that were originated by PE2: routes that were originated by PE2:
o Route1: A (C-*,C-*) S-PMSI A-D route (irrespective of whether the o Route1: A (C-*,C-*) S-PMSI A-D route (irrespective of whether the
PTA specifies a tunnel) PTA specifies a tunnel)
o Route2: A (C-S1,C-G1) S-PMSI A-D route whose PTA specifies a o Route2: A (C-S1,C-G1) S-PMSI A-D route whose PTA specifies a
tunnel. tunnel.
skipping to change at page 13, line 47 skipping to change at page 13, line 50
when not desired (through either error or malfeasance), a significant when not desired (through either error or malfeasance), a significant
increase in control plane overhead can result. increase in control plane overhead can result.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://www.rfc-editor.org/info/rfc6513>. 2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>. <https://www.rfc-editor.org/info/rfc6514>.
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
RFC 6625, DOI 10.17487/RFC6625, May 2012, RFC 6625, DOI 10.17487/RFC6625, May 2012,
<http://www.rfc-editor.org/info/rfc6625>. <https://www.rfc-editor.org/info/rfc6625>.
[RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for [RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for
P-Multicast Service Interface Tunnel Attribute Flags", P-Multicast Service Interface Tunnel Attribute Flags",
RFC 7902, DOI 10.17487/RFC7902, June 2016, RFC 7902, DOI 10.17487/RFC7902, June 2016,
<http://www.rfc-editor.org/info/rfc7902>. <https://www.rfc-editor.org/info/rfc7902>.
9.2. Informative References 9.2. Informative References
[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T.,
Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area
Point-to-Multipoint (P2MP) Segmented Label Switched Paths Point-to-Multipoint (P2MP) Segmented Label Switched Paths
(LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015,
<http://www.rfc-editor.org/info/rfc7524>. <https://www.rfc-editor.org/info/rfc7524>.
Authors' Addresses Authors' Addresses
Andrew Dolganow Andrew Dolganow
Nokia Nokia
600 March Rd. 438B Alexandra Rd #08-07/10
Ottawa, Ontario K2K 2E6 Alexandra Technopark
Canada Singapore 119968
Email: andrew.dolganow@nokia.com Email: andrew.dolganow@nokia.com
Jayant Kotalwar Jayant Kotalwar
Nokia Nokia
701 East Middlefield Rd 701 East Middlefield Rd
Mountain View, California 94043 Mountain View, California 94043
United States United States
Email: jayant.kotalwar@nokia.com Email: jayant.kotalwar@nokia.com
 End of changes. 14 change blocks. 
20 lines changed or deleted 28 lines changed or added

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