< draft-ietf-mpls-mldp-in-band-wildcard-encoding-01.txt   draft-ietf-mpls-mldp-in-band-wildcard-encoding-02.txt >
MPLS Working Group IJ. Wijnands, Ed. MPLS Working Group IJ. Wijnands, Ed.
Internet-Draft E. Rosen Internet-Draft E. Rosen
Intended status: Standards Track Cisco Updates: 6826,7246 (if approved) Cisco
Expires: September 4, 2014 A. Gulko Intended status: Standards Track A. Gulko
Thomson Reuters Expires: February 13, 2015 Thomson Reuters
U. Joorde U. Joorde
Deutsche Telekom Deutsche Telekom
J. Tantsura J. Tantsura
Ericsson Ericsson
March 3, 2014 August 12, 2014
mLDP In-Band Signaling with Wildcards mLDP In-Band Signaling with Wildcards
draft-ietf-mpls-mldp-in-band-wildcard-encoding-01 draft-ietf-mpls-mldp-in-band-wildcard-encoding-02
Abstract Abstract
There are scenarios in which an IP multicast tree traverses an MPLS There are scenarios in which an IP multicast tree traverses an MPLS
domain. In these scenarios, it can be desirable to convert the IP domain. In these scenarios, it can be desirable to convert the IP
multicast tree "seamlessly" to an MPLS multipoint label switched path multicast tree "seamlessly" to an MPLS multipoint label switched path
(MP-LSP) when it enters the MPLS domain, and then to convert it back (MP-LSP) when it enters the MPLS domain, and then to convert it back
to an IP multicast tree when it exits the MPLS domain. Previous to an IP multicast tree when it exits the MPLS domain. Previous
documents specify procedures that allow certain kinds of IP multicast documents specify procedures that allow certain kinds of IP multicast
trees (either "Source-Specific Multicast" trees or "Bidirectional trees (either "Source-Specific Multicast" trees or "Bidirectional
Multicast" trees) to be attached to an MPLS Multipoint Label Switched Multicast" trees) to be attached to an MPLS Multipoint Label Switched
Path (MP-LSP). However, the previous documents do not specify Path (MP-LSP). However, the previous documents do not specify
procedures for attaching IP "Any Source Multicast" trees to MP-LSPs, procedures for attaching IP "Any Source Multicast" trees to MP-LSPs,
nor do they specify procedures for aggregating multiple IP multicast nor do they specify procedures for aggregating multiple IP multicast
trees onto a single MP-LSP. This document specifies the procedures trees onto a single MP-LSP. This document specifies the procedures
to support these functions. It does so by defining "wildcard" to support these functions. It does so by defining "wildcard"
encodings that make it possible to specify, when setting up an MP- encodings that make it possible to specify, when setting up an MP-
LSP, that a set of IP multicast trees, or a shared IP multicast tree, LSP, that a set of IP multicast trees, or a shared IP multicast tree,
should be attached to that MP-LSP. Support for non-bidirectional IP should be attached to that MP-LSP. Support for non-bidirectional IP
"Any Source Multicast" trees is subject to certain applicability "Any Source Multicast" trees is subject to certain applicability
restrictions that are discussed in this document. restrictions that are discussed in this document. This document
updates RFCs 6826 and 7246.
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 http://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 September 4, 2014. This Internet-Draft will expire on February 13, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5
3. Wildcards in mLDP Opaque Value TLVs . . . . . . . . . . . . . 7 3. Wildcards in mLDP Opaque Value TLVs . . . . . . . . . . . . . 6
3.1. Encoding the Wildcards . . . . . . . . . . . . . . . . . 7 3.1. Encoding the Wildcards . . . . . . . . . . . . . . . . . 7
3.2. Wildcard Semantics . . . . . . . . . . . . . . . . . . . 7 3.2. Wildcard Semantics . . . . . . . . . . . . . . . . . . . 7
3.3. Backwards Compatibility . . . . . . . . . . . . . . . . . 8 3.3. Backwards Compatibility . . . . . . . . . . . . . . . . . 8
3.4. Applicability Restrictions with regard to ASM . . . . . . 8 3.4. Applicability Restrictions with regard to ASM . . . . . . 8
4. Some Wildcard Use Cases . . . . . . . . . . . . . . . . . . . 9 4. Some Wildcard Use Cases . . . . . . . . . . . . . . . . . . . 9
4.1. PIM shared tree forwarding . . . . . . . . . . . . . . . 9 4.1. PIM shared tree forwarding . . . . . . . . . . . . . . . 9
4.2. IGMP/MLD Proxying . . . . . . . . . . . . . . . . . . . . 10 4.2. IGMP/MLD Proxying . . . . . . . . . . . . . . . . . . . . 10
4.3. Selective Source mapping . . . . . . . . . . . . . . . . 11 4.3. Selective Source mapping . . . . . . . . . . . . . . . . 10
5. Procedures for Wildcard Source Usage . . . . . . . . . . . . 11 5. Procedures for Wildcard Source Usage . . . . . . . . . . . . 11
6. Procedures for Wildcard Group Usage . . . . . . . . . . . . . 12 6. Procedures for Wildcard Group Usage . . . . . . . . . . . . . 12
7. Determining the MP-LSP Root (Ingress LSR) . . . . . . . . . . 13 7. Determining the MP-LSP Root (Ingress LSR) . . . . . . . . . . 12
8. Anycast RP . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Anycast RP . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
[RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] specify [RFC6826] and [RFC7246] specify procedures for mLDP ("Multicast
procedures for mLDP ("Multicast Extensions to the Label Distribution Extensions to the Label Distribution Protocol") that allow an IP
Protocol") that allow an IP multicast tree (either a "Source-Specific multicast tree (either a "Source-Specific Multicast" tree or a
Multicast" tree or a "Bidirectional multicast" tree) to be attached "Bidirectional multicast" tree) to be attached "seamlessly" to an
"seamlessly" to an MPLS Multipoint Label Switched Path (MP-LSP). MPLS Multipoint Label Switched Path (MP-LSP). This can be useful,
This can be useful, for example, when there is multicast data that for example, when there is multicast data that originates in a domain
originates in a domain that supports IP multicast, then has to be that supports IP multicast, then has to be forwarded across a domain
forwarded across a domain that supports MPLS multicast, then has to that supports MPLS multicast, then has to forwarded across another
forwarded across another domain that supports IP multicast. By domain that supports IP multicast. By attaching an IP multicast tree
attaching an IP multicast tree to an MP-LSP, data that is traveling to an MP-LSP, data that is traveling along the IP multicast tree can
along the IP multicast tree can be moved seamlessly to the MP-LSP be moved seamlessly to the MP-LSP when it enters the MPLS multicast
when it enters the MPLS multicast domain. The data then travels domain. The data then travels along the MP-LSP through the MPLS
along the MP-LSP through the MPLS domain. When the data reaches the domain. When the data reaches the boundary of the MPLS domain, it
boundary of the MPLS domain, it can be moved seamlessly to an IP can be moved seamlessly to an IP multicast tree. This ability to
multicast tree. This ability to attach IP multicast trees to MPLS attach IP multicast trees to MPLS MP-LSPs can be useful in either VPN
MP-LSPs can be useful in either VPN context or global context. context or global context.
In mLDP, every MP-LSP is identified by the combination of a "root In mLDP, every MP-LSP is identified by the combination of a "root
node" (or "Ingress LSR") and an "Opaque Value" that, in the context node" (or "Ingress LSR") and an "Opaque Value" that, in the context
of the root node, uniquely identifies the MP-LSP. These are encoded of the root node, uniquely identifies the MP-LSP. These are encoded
into an mLDP "FEC Element". To set up an MP-LSP, the Egress LSRs into an mLDP "FEC Element". To set up an MP-LSP, the Egress LSRs
originate mLDP control messages containing the FEC element. A given originate mLDP control messages containing the FEC element. A given
FEC Element value identifies a single MP-LSP, and is passed upstream FEC Element value identifies a single MP-LSP, and is passed upstream
from the Egress LSRs, through the intermediate LSRs, to the Ingress from the Egress LSRs, through the intermediate LSRs, to the Ingress
LSR. LSR.
In IP multicast, a multicast tree is identified by the combination of In IP multicast, a multicast tree is identified by the combination of
an IP source address ("S") and an IP group address ("G"), usually an IP source address ("S") and an IP group address ("G"), usually
written as "(S,G)". A tree carrying traffic of multiple sources is written as "(S,G)". A tree carrying traffic of multiple sources is
identified by its group address, and the identifier is written as identified by its group address, and the identifier is written as
"(*,G)". "(*,G)".
When an MP-LSP is being set up, the procedures of [RFC6826] and When an MP-LSP is being set up, the procedures of [RFC6826] and
[I-D.ietf-l3vpn-mldp-vrf-in-band-signaling], known as "mLDP In-Band [RFC7246], known as "mLDP In-Band Signaling", allow the Egress LSRs
Signaling", allow the Egress LSRs of the MP-LSP to encode the of the MP-LSP to encode the identifier of an IP multicast tree in the
identifier of an IP multicast tree in the "Opaque Value" field of the "Opaque Value" field of the mLDP FEC Element that identifies the MP-
mLDP FEC Element that identifies the MP-LSP. Only the Egress and LSP. Only the Egress and Ingress LSRs are aware that the mLDP FEC
Ingress LSRs are aware that the mLDP FEC Elements contain encodings Elements contain encodings of the IP multicast tree identifier;
of the IP multicast tree identifier; intermediate nodes along the MP- intermediate nodes along the MP-LSP do not take any account of the
LSP do not take any account of the internal structure of the FEC internal structure of the FEC Element's Opaque Value, and the
Element's Opaque Value, and the internal structure of the Opaque internal structure of the Opaque Value does not affect the operation
Value does not affect the operation of mLDP. By using mLDP In-Band of mLDP. By using mLDP In-Band Signaling, the Egress LSRs of an MP-
Signaling, the Egress LSRs of an MP-LSP inform the Ingress LSR that LSP inform the Ingress LSR that they expect traffic of the identified
they expect traffic of the identified IP multicast tree (and only IP multicast tree (and only that traffic) to be carried on the MP-
that traffic) to be carried on the MP-LSP. That is, mLDP In-Band LSP. That is, mLDP In-Band Signaling not only sets up the MP-LSP, it
Signaling not only sets up the MP-LSP, it also binds a given IP also binds a given IP multicast tree to the MP-LSP.
multicast tree to the MP-LSP.
If multicast is being done in a VPN context, the mLDP FEC elements If multicast is being done in a VPN context [RFC7246], the mLDP FEC
also contain a "Route Distinguisher" (RD) (see elements also contain a "Route Distinguisher" (RD) (see [RFC7246]),
[I-D.ietf-l3vpn-mldp-vrf-in-band-signaling]), as the IP multicast as the IP multicast trees are identified not merely by "(S,G)" but by
trees are identified not merely by "(S,G)" but by "(RD,S,G)". The "(RD,S,G)". The procedures of this document are also applicable in
procedures of this document are also applicable in this case. Of this case. Of course, when an Ingress LSR processes an In-Band
course, when an Ingress LSR processes an In-Band Signaling Opaque Signaling Opaque Value that contains an RD, it does so in the context
Value that contains an RD, it does so in the context of the VPN of the VPN associated with that RD.
associated with that RD.
If mLDP In-Band Signaling is not used, some other protocol must be If mLDP In-Band Signaling is not used, some other protocol must be
used to bind an IP multicast tree to the MP-LSP, and this requires used to bind an IP multicast tree to the MP-LSP, and this requires
additional communication mechanisms between the Ingress LSR and the additional communication mechanisms between the Ingress LSR and the
Egress LSRs of the MP-LSP. The purpose of mLDP In-Band Signaling is Egress LSRs of the MP-LSP. The purpose of mLDP In-Band Signaling is
to eliminate the need for these other protocols. to eliminate the need for these other protocols.
When following the procedures of [RFC6826] and When following the procedures of [RFC6826] and [RFC7246] for non-
[I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] for non-bidirectional bidirectional trees, the Opaque Value has an IP Source Address (S)
trees, the Opaque Value has an IP Source Address (S) and an IP Group and an IP Group Address (G) encoded into it, thus enabling it to
Address (G) encoded into it, thus enabling it to identify a identify a particular IP multicast (S,G) tree. Only a single IP
particular IP multicast (S,G) tree. Only a single IP source-specific source-specific multicast tree (i.e., a single "(S,G)") can be
multicast tree (i.e., a single "(S,G)") can be identified in a given identified in a given FEC element. As a result, a given MP-LSP can
FEC element. As a result, a given MP-LSP can carry data from only a carry data from only a single IP source-specific multicast tree
single IP source-specific multicast tree (i.e., a single "(S,G) (i.e., a single "(S,G) tree"). However, there are scenarios in which
tree"). However, there are scenarios in which it would be desirable it would be desirable to aggregate a number of (S,G) trees on a
to aggregate a number of (S,G) trees on a single MP-LSP. Aggregation single MP-LSP. Aggregation allows a given number of IP multicast
allows a given number of IP multicast trees to using a smaller number trees to use a smaller number of MP-LSPs, thus saving state in the
of MP-LSPs, thus saving state in the network. network.
In addition, [RFC6826] and In addition, [RFC6826] and [RFC7246] do not support the attachment of
[I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] do not support the an "Any Source Multicast" (ASM) shared tree to an MP-LSP, except in
attachment of an "Any Source Multicast" (ASM) shared tree to an MP- the case where the ASM shared tree is a "bidirectional" tree (i.e., a
LSP, except in the case where the ASM shared tree is a tree set up by BIDIR-PIM [RFC5015]). However, there are scenarios in
"bidirectional" tree (i.e., a tree set up by BIDIR-PIM [RFC5015]). which it would be desirable to attach a non-bidirectional ASM shared
However, there are scenarios in which it would be desirable to attach tree to an MP-LSP.
a non-bidirectional ASM shared tree to an MP-LSP.
This document specifies a way to encode an mLDP "Opaque Value" in This document specifies a way to encode an mLDP "Opaque Value" in
which either the "S" or the "G" or both are replaced by a "wildcard" which either the "S" or the "G" or both are replaced by a "wildcard"
(written as "*"). Procedures are described for using the wildcard (written as "*"). Procedures are described for using the wildcard
encoding to map non-bidirectional ASM shared trees to MP-LSPs, and encoding to map non-bidirectional ASM shared trees to MP-LSPs, and
for mapping multiple (S,G) trees (with a common value of S or a for mapping multiple (S,G) trees (with a common value of S or a
common value of G) to a single MP-LSP. common value of G) to a single MP-LSP.
Some example scenarios where wildcard encoding is useful are: Some example scenarios where wildcard encoding is useful are:
skipping to change at page 5, line 17 skipping to change at page 5, line 11
o IGMP/MLD proxying. o IGMP/MLD proxying.
o Selective Source mapping. o Selective Source mapping.
These scenarios are discussed in Section 4. Note that this list of These scenarios are discussed in Section 4. Note that this list of
scenarios is not meant to be exhaustive. scenarios is not meant to be exhaustive.
This draft specifies only the mLDP procedures that are specific to This draft specifies only the mLDP procedures that are specific to
the use of wildcards. mLDP In-Band Signaling procedures that are not the use of wildcards. mLDP In-Band Signaling procedures that are not
specific to the use of wildcards can be found in [RFC6826] and specific to the use of wildcards can be found in [RFC6826] and
[I-D.ietf-l3vpn-mldp-vrf-in-band-signaling]. Unless otherwise [RFC7246]. Unless otherwise specified in this document, those
specified in this document, those procedures still apply when procedures still apply when wildcards are used.
wildcards are used.
2. Terminology and Definitions 2. Terminology and Definitions
Readers of this document are assumed to be familiar with the Readers of this document are assumed to be familiar with the
terminology and concepts of the documents listed as Normative terminology and concepts of the documents listed as Normative
References. For convenience, some of the more frequently used terms References. For convenience, some of the more frequently used terms
appear below. appear below.
IGMP: IGMP:
Internet Group Management Protocol. Internet Group Management Protocol.
skipping to change at page 7, line 7 skipping to change at page 6, line 46
length field, followed by a value field. Note that the value length field, followed by a value field. Note that the value
field of a TLV may be sub-divided into a number of sub-fields. field of a TLV may be sub-divided into a number of sub-fields.
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" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
3. Wildcards in mLDP Opaque Value TLVs 3. Wildcards in mLDP Opaque Value TLVs
[RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] define the [RFC6826] and [RFC7246] define the following Opaque Value TLVs:
following Opaque Value TLVs: Transit IPv4 Source TLV, Transit IPv6 Transit IPv4 Source TLV, Transit IPv6 Source TLV, Transit VPNv4
Source TLV, Transit VPNv4 Source TLV, and Transit VPNv6 Source TLV. Source TLV, and Transit VPNv6 Source TLV. The value field of each
The value field of each such TLV is divided into a number of sub- such TLV is divided into a number of sub-fields, one of which
fields, one of which contains an IP source address, and one of which contains an IP source address, and one of which contains an IP group
contains an IP group address. Per those documents, these fields must address. Per those documents, these fields must contain valid IP
contain valid IP addresses. addresses.
This document extends the definition of those TLVs by allowing either This document extends the definition of those TLVs by allowing either
the IP Source Address field or the IP Group Address field (or both) the IP Source Address field or the IP Group Address field (or both)
to specify a "wildcard" rather than a valid IP address. to specify a "wildcard" rather than a valid IP address.
3.1. Encoding the Wildcards 3.1. Encoding the Wildcards
A value of all zeroes in the IP Source Address sub-field is used to A value of all zeroes in the IP Source Address sub-field is used to
represent a wildcard source address. A value of all zeroes in the IP represent a wildcard source address. A value of all zeroes in the IP
Group Address sub-field is used to represent the wildcard group Group Address sub-field is used to represent the wildcard group
skipping to change at page 7, line 46 skipping to change at page 7, line 36
Group Address sub-field contains an IP multicast group address that Group Address sub-field contains an IP multicast group address that
is in the SSM address range, the TLV identifies the collection of PIM is in the SSM address range, the TLV identifies the collection of PIM
trees with the given group address. trees with the given group address.
If the IP Source Address sub-field contains a non-zero IP address, If the IP Source Address sub-field contains a non-zero IP address,
and the IP Group Address sub-field contains the wildcard, the TLV and the IP Group Address sub-field contains the wildcard, the TLV
identifies the collection of PIM-SSM trees that have the source identifies the collection of PIM-SSM trees that have the source
address as their root. address as their root.
Procedures for the use of the wildcards are discussed in Sections 4, Procedures for the use of the wildcards are discussed in Sections 4,
5 and 6. Please note that, as always, the structure of the Opaque 5 and 6. Please note that, as always, the structure of an Opaque
Value TLVs does not actually affect the operation of mLDP, but only Value TLV does not affect the operation of mLDP. The structure is
affects the interface between mLDP and IP multicast at the Ingress meaningful only to the IP multicast modules at the ingress and egress
LSR. LSRs.
Procedures for the use of a wildcard group in the following TLVs Procedures for the use of a wildcard group in the following TLVs
(defined in [RFC6826] or [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling]) (defined in [RFC6826] or [RFC7246]) are outside the scope of the
are outside the scope of the current document: Transit IPv4 Bidir current document: Transit IPv4 Bidir TLV, Transit IPv6 Bidir TLV,
TLV, Transit IPv6 Bidir TLV, Transit VPNv4 Bidir TLV, Transit VPNv6 Transit VPNv4 Bidir TLV, Transit VPNv6 Bidir TLV.
Bidir TLV.
Procedures for the use of both a wildcard source and a wildcard group Procedures for the use of both a wildcard source and a wildcard group
in the same TLV are outside the scope of the current document. in the same TLV are outside the scope of the current document.
Note that the Bidir TLVs do not have a "Source Address" sub-field, Note that the Bidir TLVs do not have a "Source Address" sub-field,
and hence the notion of a wildcard source is not applicable to them. and hence the notion of a wildcard source is not applicable to them.
3.3. Backwards Compatibility 3.3. Backwards Compatibility
The procedures of this document do not change the behavior described The procedures of this document do not change the behavior described
in [RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling]. in [RFC6826] and [RFC7246].
A correctly operating Egress LSR that supports [RFC6826] and/or A correctly operating Egress LSR that supports [RFC6826] and/or
[I-D.ietf-l3vpn-mldp-vrf-in-band-signaling], but that does not [RFC7246], but that does not support this document, will never
support this document, will never generate mLDP FEC Element Opaque generate mLDP FEC Element Opaque values that contain source or group
values that contain source or group wildcards. wildcards.
Neither [RFC6826] nor [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] Neither [RFC6826] nor [RFC7246] specifies the behavior of an Ingress
specifies the behavior of an Ingress LSR that receives mLDP FEC LSR that receives mLDP FEC Element Opaque values that contain zeroes
Element Opaque values that contain zeroes in the Source Address or in the Source Address or Group Address sub-fields. However, if an
Group Address sub-fields. However, if an Ingress LSR supports Ingress LSR supports [RFC6826] and/or [RFC7246], but does not support
[RFC6826] and/or [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling], but this document, it has no choice but to treat any such received FEC
does not support this document, it has no choice but to treat any elements as invalid; the procedures specified in [RFC6826] and
such received FEC elements as invalid; the procedures specified in [RFC7246] do not work when the Opaque values contain zeroes in the
[RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] do not work Source Address or Group Address sub-fields.
when the Opaque values contain zeroes in the Source Address or Group
Address sub-fields.
The procedures of this document thus presuppose that if an Egress LSR The procedures of this document thus presuppose that if an Egress LSR
uses wildcard encodings when setting up an MP-LSP, then the Ingress uses wildcard encodings when setting up an MP-LSP, then the Ingress
LSR (i.e., the root of the multipoint LSP) supports the procedures of LSR (i.e., the root of the multipoint LSP) supports the procedures of
this document. An Egress LSR MUST NOT use wildcard encodings when this document. An Egress LSR MUST NOT use wildcard encodings when
setting up a particular multipoint LSP unless it is known a priori setting up a particular multipoint LSP unless it is known a priori
that the Ingress LSR supports the procedures of this document. How that the Ingress LSR supports the procedures of this document. How
this is known is outside the scope of this document. this is known is outside the scope of this document.
3.4. Applicability Restrictions with regard to ASM 3.4. Applicability Restrictions with regard to ASM
skipping to change at page 10, line 10 skipping to change at page 9, line 49
last hop router for group G learns that source S is transmitting to last hop router for group G learns that source S is transmitting to
G, the last hop router joins the (S,G) tree, and "prunes" S off the G, the last hop router joins the (S,G) tree, and "prunes" S off the
(*,G) tree. This allows each last hop router to receive the (*,G) tree. This allows each last hop router to receive the
multicast data along the shortest path from the source to the last multicast data along the shortest path from the source to the last
hop router. (Full details of this behavior can be found in hop router. (Full details of this behavior can be found in
[RFC4601].) [RFC4601].)
In some cases, however, a last hop router for group G may decide not In some cases, however, a last hop router for group G may decide not
to join the source trees, but rather to keep receiving all the to join the source trees, but rather to keep receiving all the
traffic for G from the (*,G) tree. In this case, we say that the traffic for G from the (*,G) tree. In this case, we say that the
last hop router has "threshold infinity" for group G. This is last hop router has "threshold infinity" for group G. This is
optional behaviour documented in [RFC4601]. "Threshold infinity" is optional behaviour documented in [RFC4601]. "Threshold infinity" is
often used in deployments where the RP is between the multicast often used in deployments where the RP is between the multicast
sources and the multicast receivers for group G, i.e., in deployments sources and the multicast receivers for group G, i.e., in deployments
where it is known that the shortest path from any source to any where it is known that the shortest path from any source to any
receiver of the group goes through the RP. In these deployments, receiver of the group goes through the RP. In these deployments,
there is no advantage for a last hop router to join a source tree, there is no advantage for a last hop router to join a source tree,
since the data is already traveling along the shortest path. The since the data is already traveling along the shortest path. The
only effect of executing the complicated procedures for joining a only effect of executing the complicated procedures for joining a
source tree and pruning the source off the shared tree would be to source tree and pruning the source off the shared tree would be to
increase the amount of multicast routing state that has to be increase the amount of multicast routing state that has to be
skipping to change at page 10, line 41 skipping to change at page 10, line 31
4.2. IGMP/MLD Proxying 4.2. IGMP/MLD Proxying
There are scenarios where the multicast senders and receivers are There are scenarios where the multicast senders and receivers are
directly connected to an MPLS routing domain, and where it is desired directly connected to an MPLS routing domain, and where it is desired
to use mLDP rather than PIM to set up "trees" through that domain. to use mLDP rather than PIM to set up "trees" through that domain.
In these scenarios we can apply "IGMP/MLD proxying" and eliminate the In these scenarios we can apply "IGMP/MLD proxying" and eliminate the
use of PIM. The senders and receivers consider the MPLS domain to be use of PIM. The senders and receivers consider the MPLS domain to be
single hop between each other. [RFC4605] documents procedures where single hop between each other. [RFC4605] documents procedures where
a multicast routing protocol is not nessesary to build a 'simple a multicast routing protocol is not necessary to build a 'simple
tree'. Within the MPLS domain, mLDP will be used to build a MP-LSP, tree'. Within the MPLS domain, mLDP will be used to build a MP-LSP,
but this is hidden from the senders and receivers. The procedures but this is hidden from the senders and receivers. The procedures
defined in [RFC4605] are applicable, since the senders and receivers defined in [RFC4605] are applicable, since the senders and receivers
are considered to be one hop away from each other. are considered to be one hop away from each other.
For mLDP to build the necessary MP-LSP, it needs to know the root of For mLDP to build the necessary MP-LSP, it needs to know the root of
the tree. Following the procedures as defined in [RFC4605] we depend the tree. Following the procedures as defined in [RFC4605] we depend
on manual configuration of the mLDP root for the ASM multicast group. on manual configuration of the mLDP root for the ASM multicast group.
Since the MP-LSP for a given ASM multicast group will carry traffic Since the MP-LSP for a given ASM multicast group will carry traffic
from all the sources for that group, the Opaque Value TLV used to from all the sources for that group, the Opaque Value TLV used to
skipping to change at page 12, line 27 skipping to change at page 12, line 17
2. If PIM is enabled and the identified group is a PIM-SSM group, 2. If PIM is enabled and the identified group is a PIM-SSM group,
all multicast sources known for the group on the Ingress LSR are all multicast sources known for the group on the Ingress LSR are
to be forwarded down the MP-LSP. In this scenario, it is assumed to be forwarded down the MP-LSP. In this scenario, it is assumed
that the Ingress LSR is already receiving all the necessary that the Ingress LSR is already receiving all the necessary
traffic. How the Ingress LSR receives this traffic is outside traffic. How the Ingress LSR receives this traffic is outside
the scope of this document. the scope of this document.
3. If PIM is not enabled for the identified group, the Ingress LSR 3. If PIM is not enabled for the identified group, the Ingress LSR
acts as if it had received a (*,G) IGMP/MLD report from a acts as if it had received a (*,G) IGMP/MLD report from a
downstream node, and the procedures as defined in [RFC4605] are downstream node, and the procedures as defined in [RFC4605] are
followed. followed. The ingress LSR should forward the (*,G) packets to
the egress LSR through the MP-LSP identified by the Opaque Value
TLV. (See also Section 4.2.)
6. Procedures for Wildcard Group Usage 6. Procedures for Wildcard Group Usage
The decision to use mLDP In-Band Signaling is made by the IP The decision to use mLDP In-Band Signaling is made by the IP
multicast component of an Egress LSR, based on provisioned policy. multicast component of an Egress LSR, based on provisioned policy.
The decision to use (or not to use) a wildcard in the IP Group The decision to use (or not to use) a wildcard in the IP Group
Address sub-field of an mLDP Opaque Value TLV is also made by the IP Address sub-field of an mLDP Opaque Value TLV is also made by the IP
multicast component of the Egress LSR, again based on provisioned multicast component of the Egress LSR, again based on provisioned
policy. As the policies needed in any one deployment may be very policy. As the policies needed in any one deployment may be very
different than the policies needed in another, this document does not different than the policies needed in another, this document does not
skipping to change at page 13, line 7 skipping to change at page 12, line 47
field contains a wildcard, the Ingress LSR examines its IP multicast field contains a wildcard, the Ingress LSR examines its IP multicast
routing table, to find all the IP multicast streams whose IP source routing table, to find all the IP multicast streams whose IP source
address is the address specified in the IP Source Address sub-field address is the address specified in the IP Source Address sub-field
of the TLV. All these streams SHOULD be forwarded down the MP-LSP of the TLV. All these streams SHOULD be forwarded down the MP-LSP
identified by the Opaque Value TLV. Note that some of these streams identified by the Opaque Value TLV. Note that some of these streams
may have SSM group addresses, while some may have ASM group may have SSM group addresses, while some may have ASM group
addresses. addresses.
7. Determining the MP-LSP Root (Ingress LSR) 7. Determining the MP-LSP Root (Ingress LSR)
Documents [RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] Documents [RFC6826] and [RFC7246] describe procedures by which an
describe procedures by which an Egress LSR may determine the MP-LSP Egress LSR may determine the MP-LSP root node address corresponding
root node address corresponding to a given IP multicast stream, based to a given IP multicast stream, based upon the IP address of the
upon the IP address of the source of the IP multicast stream. When a source of the IP multicast stream. When a wildcard source encoding
wildcard source encoding is used, PIM is enabled, and the group is a is used, PIM is enabled, and the group is a non-bidirectional ASM
non-bidirectional ASM group, a similar procedure is applied. The group, a similar procedure is applied. The only difference from the
only difference from the above mentioned procedures is that the Proxy above mentioned procedures is that the Proxy device or RP address is
device or RP address is used instead of the Source to discover the used instead of the Source to discover the mLDP root node address.
mLDP root node address.
Other procedures for determining the root node are also allowed, as Other procedures for determining the root node are also allowed, as
determined by policy. determined by policy.
8. Anycast RP 8. Anycast RP
In the scenarios where mLDP In-Band Signaling is used, it is unlikely In the scenarios where mLDP In-Band Signaling is used, it is unlikely
that the RP-to-Group mappings are being dynamically distributed over that the RP-to-Group mappings are being dynamically distributed over
the MPLS core. It is more likely that the RP address is statically the MPLS core. It is more likely that the RP address is statically
configured at each multicast site. In these scenarios, it is configured at each multicast site. In these scenarios, it is
skipping to change at page 13, line 41 skipping to change at page 13, line 32
We would like to thank Loa Andersson, Pranjal Dutta, Lizhong Jin, and We would like to thank Loa Andersson, Pranjal Dutta, Lizhong Jin, and
Curtis Villamizar for their review and comments. Curtis Villamizar for their review and comments.
10. IANA Considerations 10. IANA Considerations
There are no new allocations required from IANA. There are no new allocations required from IANA.
11. Security Considerations 11. Security Considerations
There are no security considerations other then ones already There are no security considerations other then ones already
mentioned in [RFC6826] and mentioned in [RFC6826] and [RFC7246].
[I-D.ietf-l3vpn-mldp-vrf-in-band-signaling].
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-l3vpn-mldp-vrf-in-band-signaling]
Wijnands, I., Hitchen, P., Leymann, N., Henderickx, W.,
arkadiy.gulko@thomsonreuters.com, a., and J. Tantsura,
"Multipoint Label Distribution Protocol In-Band Signaling
in a VRF Context", draft-ietf-l3vpn-mldp-vrf-in-band-
signaling-03 (work in progress), January 2014.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast "Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP Listener Discovery (MLD)-Based Multicast Forwarding
/MLD Proxying")", RFC 4605, August 2006. ("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC6826] Wijnands, IJ., Eckert, T., Leymann, N., and M. Napierala, [RFC6826] Wijnands, IJ., Eckert, T., Leymann, N., and M. Napierala,
"Multipoint LDP In-Band Signaling for Point-to-Multipoint "Multipoint LDP In-Band Signaling for Point-to-Multipoint
and Multipoint-to-Multipoint Label Switched Paths", RFC and Multipoint-to-Multipoint Label Switched Paths", RFC
6826, January 2013. 6826, January 2013.
[RFC7246] Wijnands, IJ., Hitchen, P., Leymann, N., Henderickx, W.,
Gulko, A., and J. Tantsura, "Multipoint Label Distribution
Protocol In-Band Signaling in a Virtual Routing and
Forwarding (VRF) Table Context", RFC 7246, June 2014.
12.2. Informative References 12.2. Informative References
[I-D.zzhang-l3vpn-mvpn-global-table-mcast] [I-D.zzhang-l3vpn-mvpn-global-table-mcast]
Zhang, J., Giuliano, L., Rosen, E., Subramanian, K., Zhang, J., Giuliano, L., Rosen, E., Subramanian, K.,
Pacella, D., and J. Schiller, "Global Table Multicast with Pacella, D., and J. Schiller, "Global Table Multicast with
BGP-MVPN Procedures", draft-zzhang-l3vpn-mvpn-global- BGP-MVPN Procedures", draft-zzhang-l3vpn-mvpn-global-
table-mcast-03 (work in progress), February 2014. table-mcast-04 (work in progress), May 2014.
[RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast
Rendevous Point (RP) mechanism using Protocol Independent Rendevous Point (RP) mechanism using Protocol Independent
Multicast (PIM) and Multicast Source Discovery Protocol Multicast (PIM) and Multicast Source Discovery Protocol
(MSDP)", RFC 3446, January 2003. (MSDP)", RFC 3446, January 2003.
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003. Protocol (MSDP)", RFC 3618, October 2003.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
 End of changes. 30 change blocks. 
124 lines changed or deleted 116 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/