draft-ietf-bess-mvpn-expl-track-05.txt   draft-ietf-bess-mvpn-expl-track-06.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: August 4, 2018 Z. Zhang Expires: August 4, 2018 Z. Zhang
Juniper Networks, Inc. Juniper Networks, Inc.
January 31, 2018 January 31, 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-05 draft-ietf-bess-mvpn-expl-track-06
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 5, line 5 skipping to change at page 5, line 5
a number of "segmentation domains". In each segmentation domain, a number of "segmentation domains". In each segmentation domain,
a given P-tunnel has an ingress node and a set of egress nodes. a given P-tunnel has an ingress node and a set of egress nodes.
The explicit tracking procedures allow an ingress node of a The explicit tracking procedures allow an ingress node of a
particular segmentation domain to determine, for a particular flow particular segmentation domain to determine, for a particular flow
or set of flows, the egress nodes of that segmentation domain. or set of flows, the egress nodes of that segmentation domain.
This has given rise to two further problems: This has given rise to two further problems:
* The explicit tracking procedures do not allow an ingress node * The explicit tracking procedures do not allow an ingress node
to "see" past the boundaries of the segmentation domain. to "see" past the boundaries of the segmentation domain.
This document does not address this problem.
* The prior specifications do not make it very clear whether a * The prior specifications do not make it very clear whether a
segmented tunnel egress node, upon receiving an S-PMSI A-D segmented tunnel egress node, upon receiving an S-PMSI A-D
route whose PTA specifies "no tunnel information", is expected route whose PTA specifies "no tunnel information", is expected
to forward the S-PMSI A-D route, with the same PTA, to the next to forward the S-PMSI A-D route, with the same PTA, to the next
segmentation domain. segmentation domain.
This problem is resolved in Section 5.3. These problems are addressed in Section 5.3.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL", when and only when appearing in all capital letters, are "OPTIONAL", when and only when appearing in all capital letters, are
to be interpreted as described in [RFC2119]. to be interpreted as described in [RFC2119].
2. The Explicit Tracking Flags 2. The Explicit Tracking Flags
[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.
skipping to change at page 13, line 5 skipping to change at page 13, line 5
but not a match for reception, the LIR bit in its PTA is ignored if but not a match for reception, the LIR bit in its PTA is ignored if
the LIR-pF bit is set. the LIR-pF bit is set.
5.3. When the Egress Node is an ABR or ASBR 5.3. When the Egress Node is an ABR or ASBR
When segmented P-tunnels are used, the ingress and egress nodes may When segmented P-tunnels are used, the ingress and egress nodes may
be ABRs or ASBRs. An egress ABR/ASBR that receives and installs an be ABRs or ASBRs. An egress ABR/ASBR that receives and installs an
S-PMSI A-D route also forwards that route. If the PTA of an S-PMSI A-D route also forwards that route. If the PTA of an
installed S-PMSI A-D route specifies a tunnel, the egress ABR/ASBR installed S-PMSI A-D route specifies a tunnel, the egress ABR/ASBR
MAY change the PTA to specify a different tunnel type (as discussed MAY change the PTA to specify a different tunnel type (as discussed
in [RFC6514] and/or [RFC7524]). in [RFC6514] and/or [RFC7524]). The egress ABR/ASBR may also need to
originate a Leaf A-D route, as specified in [RFC6514] and/or
[RFC7524].
However, if the PTA of the installed S-PMSI A-D route specifies "no Suppose the forwarded S-PMSI A-D route has a PTA specifying a tunnel,
tunnel info", the egress ABR/ASBR MUST pass the PTA along unchanged and also has LIR-pF set. The egress ABR/ASBR originates a
when it forwards the S-PMSI A-D route. (That is, a PTA specifying corresponding Leaf A-D route for a given (C-S,C-G) only if it knows
"no tunnel info" MUST NOT be changed into a PTA specifying a tunnel.) that it needs to receive that flow. It will know this by virtue of
receiving a corresponding Leaf A-D route from downstream. (In the
case where the PTA specifies a tunnel but LIR-pF is not set, this
document does not specify any new procedures.)
The procedures in the remainder of this section apply only when an
egress ABR/ASBR has installed an S-PMSI A-D route whose PTA specifies
"no tunnel info" but has LIR or LIR-pF set.
If the PTA of the installed S-PMSI A-D route specifies "no tunnel
info", the egress ABR/ASBR MUST pass the PTA along unchanged when it
forwards the S-PMSI A-D route. (That is, a PTA specifying "no tunnel
info" MUST NOT be changed into a PTA specifying a tunnel.)
Furthermore, if the PTA specifies "no tunnel info", the LIR and LIR- Furthermore, if the PTA specifies "no tunnel info", the LIR and LIR-
pF flags in the PTA MUST be passed along unchanged. pF flags in the PTA MUST be passed along unchanged.
In the case where the egress node of a given P-tunnel is a PE, it As a result of propagating such an S-PMSI A-D route, the egress ABR/
will know whether it needs to receive a given flow by virtue of its ASBR may receive one or more Leaf A-D routes that correspond to that
having received a PIM or IGMP Join for that flow from a Customer Edge S-PMSI A-D route. These routes will be received carrying an IP-
(CE) router. In the case where the egress node is not a PE, but address-specific Route Target (RT) Extended Community that specifies
rather an ABR or ASBR, it will not know whether it needs to receive a the address of the egress ABR/ASBR. The egress ABR/ASBR will
given flow unless it receives a Leaf A-D route whose NLRI specifies propagate these Leaf A-D routes, after changing the RT as follows.
that flow, and which carries an IP-address-specific Route Target (RT) The "global administrator" field of the modified RT will be set to
Extended Community that specifies the address of the egress ABR/ASBR. the IP address taken either from the S-PMSI A-D route's next hop
Therefore an egress ABR/ASBR MUST NOT originate a Leaf A-D route for field ([RFC6514]), or from its Segmented P2MP Next Hop Extended
a given flow UNLESS it has an installed Leaf A-D route for that flow, Community ([RFC7524]).
received from further downstream.
This will ensure that an egress ABR/ASBR only sends a Leaf A-D route
in response to a "match for tracking" if it is on the path to an
egress PE for the flow(s) identified in the corresponding S-PMSI A-D
route.
We can thus establish the following rule for egress ABRs/ASBRs. This procedure enables the ingress PE to explicitly track the egress
Suppose an egress ABR/ASBR receives an S-PMSI A-D route whose NLRI is PEs for a given flow, even if segmented tunnels are being used.
X, and whose PTA (a) specifies "no tunnel info" and (b) has LIR set. However, cross-domain explicit tracking utilizes S-PMSI A-D routes
The egress ABR/ASBR should not immediately originate a Leaf A-D route that do not specify tunnel information; therefore it can only be done
in response. Rather it should wait until it receives a Leaf A-D when the S-PMSI A-D route which is a flow's match for tracking is
route whose NLRI contains X in the "route key" field. If it receives different than the S-PMSI A-D route which is that flow's match for
such a Leaf A-D route, it redistributes that route, but first it reception.
changes that route's RT. The "global administrator" field of the
modified RT will be set to the IP address taken either from the
S-PMSI A-D route's next hop field, or from its Segmented P2MP Next
Hop Extended Community. (This is the same rule that is used for when
the PTA does specify a tunnel type.)
6. Acknowledgments 6. Acknowledgments
The authors wish to thank Robert Kebler for his ideas and comments. The authors wish to thank Robert Kebler for his ideas and comments.
7. IANA Considerations 7. IANA Considerations
The LIR-pF flag needs to be added to the "P-Multicast Service The LIR-pF flag needs to be added to the "P-Multicast Service
Interface Tunnel (PMSI Tunnel) Attribute Flags" in the "Border Interface Tunnel (PMSI Tunnel) Attribute Flags" in the "Border
Gateway Protocol (BGP) Parameters" registry. This registry is Gateway Protocol (BGP) Parameters" registry. This registry is
 End of changes. 7 change blocks. 
37 lines changed or deleted 38 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/