draft-ietf-bess-mvpn-expl-track-07.txt   draft-ietf-bess-mvpn-expl-track-08.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: August 24, 2018 Z. Zhang Expires: August 30, 2018 Z. Zhang
Juniper Networks, Inc. Juniper Networks, Inc.
February 20, 2018 February 26, 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-07 draft-ietf-bess-mvpn-expl-track-08
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 August 24, 2018. This Internet-Draft will expire on August 30, 2018.
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 2, line 20 skipping to change at page 2, line 20
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
2. The Explicit Tracking Flags . . . . . . . . . . . . . . . . . 5 2. The Explicit Tracking Flags . . . . . . . . . . . . . . . . . 5
3. Match for Tracking vs. Match for Reception . . . . . . . . . 6 3. Match for Tracking vs. Match for Reception . . . . . . . . . 6
4. Ingress Node Initiation of Tracking . . . . . . . . . . . . . 7 4. Ingress Node Initiation of Tracking . . . . . . . . . . . . . 8
5. Egress Node Response to the Match for Tracking . . . . . . . 9 5. Egress Node Response to the Match for Tracking . . . . . . . 10
5.1. General Egress Node Procedures . . . . . . . . . . . . . 9 5.1. General Egress Node Procedures . . . . . . . . . . . . . 10
5.2. Responding to the LIR-pF Flag . . . . . . . . . . . . . . 10 5.2. Responding to the LIR-pF Flag . . . . . . . . . . . . . . 11
5.3. When the Egress Node is an ABR or ASBR . . . . . . . . . 13 5.3. When the Egress Node is an ABR or ASBR . . . . . . . . . 14
6. Ingress Node Handling of Received Leaf A-D Routes with 6. Ingress Node Handling of Received Leaf A-D Routes with
LIR-pF Set . . . . . . . . . . . . . . . . . . . . . . . . . 14 LIR-pF Set . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
[RFC6513] and [RFC6514] define the "Selective Provider Multicast [RFC6513] and [RFC6514] define the "Selective Provider Multicast
Service Interface Auto-Discovery route" (S-PMSI A-D route). Service Interface Auto-Discovery route" (S-PMSI A-D route).
Per those RFCs, the S-PMSI A-D route contains a Network Layer Per those RFCs, the S-PMSI A-D route contains a Network Layer
Reachability Information (NLRI) field that identifies a particular Reachability Information (NLRI) field that identifies a particular
multicast flow. In the terminology of those RFCs, each flow is multicast flow. In the terminology of those RFCs, each flow is
denoted by (C-S,C-G), where C-S is an IP source address and C-G is an denoted by (C-S,C-G), where C-S is an IP source address and C-G is an
skipping to change at page 5, line 30 skipping to change at page 5, line 30
[RFC6514] defines one flag in the PTA, the "Leaf Info Required" (LIR) [RFC6514] defines one flag in the PTA, the "Leaf Info Required" (LIR)
flag, that is used for explicit tracking. flag, that is used for explicit tracking.
This document defines a new flag in the flags field of the PMSI This document defines a new flag in the flags field of the PMSI
Tunnel attribute. This new flag is known as the "Leaf Info Required Tunnel attribute. This new flag is known as the "Leaf Info Required
per Flow" bit (LIR-pF). This flag may be set in the PTA of a per Flow" bit (LIR-pF). This flag may be set in the PTA of a
(C-*,C-*), (C-*,C-G), or (C-S,C-*) S-PMSI A-D route. The conditions (C-*,C-*), (C-*,C-G), or (C-S,C-*) S-PMSI A-D route. The conditions
under which it should be set by the originator of the route are under which it should be set by the originator of the route are
discussed in Section 4. The significance of the flag in a received discussed in Section 4. The significance of the flag in a received
S-PMSI A-D route is discussed in Sections 5 and 5.2. Note that S-PMSI A-D route is discussed in Sections 5 and 5.2.
support for this flag is OPTIONAL. This flag SHOULD NOT be set
unless it is known that all the PEs that are to receive the route If the LIR-pF flag is set in the PTA of an S-PMSI A-D route, the LIR
carrying the PTA support the flag. How this is known is outside the flag of that PTA MUST also be set.
scope of this document.
Note that support for the LIR-pF flag is OPTIONAL. This flag SHOULD
NOT be set unless it is known that all the PEs that are to receive
the route carrying the PTA support the flag. How this is known is
outside the scope of this document.
The LIR-pF flag may also be set in the PTA of a Leaf A-D route. The The LIR-pF flag may also be set in the PTA of a Leaf A-D route. The
conditions under which it should be set by the originator of the conditions under which it should be set by the originator of the
route are discussed in Section 5.2. The significance of the flag in route are discussed in Section 5.2. The significance of the flag in
a received Leaf A-D route is discussed in Section 6. a received Leaf A-D route is discussed in Section 6.
Use of this flag in the PTA carried by other route types is outside Use of this flag in the PTA carried by other route types is outside
the scope of this document. Use of this flag in the PTA carried by the scope of this document. Use of this flag in the PTA carried by
an S-PMSI A-D routes whose NLRI does not contain a wildcard is an S-PMSI A-D routes whose NLRI does not contain a wildcard is
outside the scope of this document. outside the scope of this document.
If the LIR-pF flag is set in the PTA of an S-PMSI A-D route, the LIR It is worth noting what will happen if the LIR-pF flag is set in the
flag of that PTA MUST also be set. (By setting LIR as well as PTA of, for example, a (C-*,C-*) S-PMSI A-D route originated by an
LIR-pF, one forces a response to be sent by an egress node that does ingress node, but one or more of the egress nodes do not support the
not support LIR-pF. It is possible to tell from that response that LIR-pF flag:
the egress node does not support LIR-pF. This may be an aid to
troubleshooting.) 1. The ingress node will not be able to determine the complete set
of egress node that are expecting a particular multicast flow
from that ingress node.
2. Depending upon the tunnel type, the ingress node may send a
particular multicast flow only to the egress nodes that do
support the LIR-pF flag. From the perspective of egress nodes
that do not support LIR-pF, certain flows may appear to be
"blackholed".
It is also worth noting that it is possible for an ingress node that
sets the LIR-pF flag in an S-PMSI A-D route to detect the presence of
egress nodes that do not support this flag.
Since an ingress node that sets the LIR-pF flag is also REQUIRED to
set the LIR flag, egress nodes that do not support the LIR-pF flag
will respond, as specified in [RFC6514], to the ingress node's
(C-*,C-*) S-PMSI A-D route with a Leaf A-D route operator.
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
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
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
that the egress node originating that Leaf A-D route does not support
the LIR-pF flag.
The software at the ingress node SHOULD detect this, and should have
a way of alerting the operator that the deployment is not properly
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
identify any P-tunnel is one whose "tunnel type" field has been set identify any P-tunnel is one whose "tunnel type" field has been set
skipping to change at page 12, line 6 skipping to change at page 13, line 6
If a Leaf A-D route is originated as a response to a match for If a Leaf A-D route is originated as a response to a match for
tracking whose PTA specifies "no tunnel info", the Leaf A-D route tracking whose PTA specifies "no tunnel info", the Leaf A-D route
MUST carry a PTA that specifies "no tunnel info". The LIR-pF flag in MUST carry a PTA that specifies "no tunnel info". The LIR-pF flag in
this PTA MUST be set. this PTA MUST be set.
In the case where the match for tracking and the match for reception In the case where the match for tracking and the match for reception
are the same, the PTA of the match may have both the LIR and the are the same, the PTA of the match may have both the LIR and the
LIR-pF flags set. This may cause the egress node to originate one LIR-pF flags set. This may cause the egress node to originate one
Leaf A-D route in response to the LIR bit, and one or more Leaf A-D Leaf A-D route in response to the LIR bit, and one or more Leaf A-D
routes in response to the LIR-pF bit. A Leaf A-D route originated in routes in response to the LIR-pF bit. Each such Leaf A-D route MUST
response to the LIR-pF bit MUST have a PTA. The LIR-pF flag of that have a PTA, and the LIR-pF flag of that PTA MUST be set. Note that
PTA MUST be set. In this case, the PTA of the match for tracking/ when the match for tracking is the same as the match for reception,
reception will have specified a tunnel type. The following rules the PTA of the match for tracking/reception will have specified a
specify how the PTA of the Leaf A-D route is to be constructed: tunnel type. The following rules specify how the PTA of the Leaf A-D
route is to be constructed:
o If the tunnel type of the PTA attached to the match for tracking/ o If the tunnel type of the PTA attached to the match for tracking/
reception is Ingress Replication, the Leaf A-D route's PTA MAY reception is Ingress Replication, the Leaf A-D route's PTA MAY
specify Ingress Replication. In this case, the MPLS Label field specify Ingress Replication. In this case, the MPLS Label field
of the PTA MAY be a non-zero value. If so, this label value will of the PTA MAY be a non-zero value. If so, this label value will
be used by the ingress PE when it transmits, to the egress PE, be used by the ingress PE when it transmits, to the egress PE,
packets of the flow identified in the Leaf A-D route's NLRI. packets of the flow identified in the Leaf A-D route's NLRI.
Alternatively, the egress PE MAY specify an MPLS label value of Alternatively, the egress PE MAY specify an MPLS label value of
zero, or it MAY specify a tunnel type of "no tunnel info". In zero, or it MAY specify a tunnel type of "no tunnel info". In
skipping to change at page 16, line 30 skipping to change at page 17, line 30
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 10.2. Informative References
[BIER-MVPN] [BIER-MVPN]
Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T.
Przygienda, "Multicast VPN Using BIER", internet-draft Przygienda, "Multicast VPN Using BIER", internet-draft
draft-ietf-bier-mvpn-09, November 2017. draft-ietf-bier-mvpn-10, February 2018.
[RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers,
"Multicast Virtual Private Network (MVPN): Using "Multicast Virtual Private Network (MVPN): Using
Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582,
July 2015, <https://www.rfc-editor.org/info/rfc7582>. July 2015, <https://www.rfc-editor.org/info/rfc7582>.
[RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., [RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y.,
and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs",
RFC 7900, DOI 10.17487/RFC7900, June 2016, RFC 7900, DOI 10.17487/RFC7900, June 2016,
<https://www.rfc-editor.org/info/rfc7900>. <https://www.rfc-editor.org/info/rfc7900>.
 End of changes. 10 change blocks. 
34 lines changed or deleted 69 lines changed or added

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