draft-ietf-mpls-mldp-in-band-wildcard-encoding-02.txt   draft-ietf-mpls-mldp-in-band-wildcard-encoding-03.txt 
MPLS Working Group IJ. Wijnands, Ed. MPLS Working Group IJ. Wijnands, Ed.
Internet-Draft E. Rosen Internet-Draft Cisco Systems, Inc.
Updates: 6826,7246 (if approved) Cisco Updates: 6826,7246 (if approved) E. Rosen
Intended status: Standards Track A. Gulko Intended status: Standards Track Juniper Networks, Inc.
Expires: February 13, 2015 Thomson Reuters Expires: May 30, 2015 A. Gulko
Thomson Reuters
U. Joorde U. Joorde
Deutsche Telekom Deutsche Telekom
J. Tantsura J. Tantsura
Ericsson Ericsson
August 12, 2014 November 26, 2014
mLDP In-Band Signaling with Wildcards mLDP In-Band Signaling with Wildcards
draft-ietf-mpls-mldp-in-band-wildcard-encoding-02 draft-ietf-mpls-mldp-in-band-wildcard-encoding-03
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
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 February 13, 2015. This Internet-Draft will expire on May 30, 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
skipping to change at page 5, line 26 skipping to change at page 5, line 26
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.
In-band signaling: In-band signaling:
Using the opaque value of a mLDP FEC element to carry the (S,G) or Using the opaque value of a mLDP FEC element to carry the (S,G) or
(*,G) identifying a particular IP multicast tree. (*,G) identifying a particular IP multicast tree. This draft also
allows (S,*) to be encoded in the opaque value; see Section 6.
Ingress LSR: Ingress LSR:
Root node of a MP-LSP. When mLDP In-Band Signaling is used, the Root node of a MP-LSP. When mLDP In-Band Signaling is used, the
Ingress LSR receives mLDP messages about a particular MP-LSP from Ingress LSR receives mLDP messages about a particular MP-LSP from
"downstream", and emits IP multicast control messages "upstream". "downstream", and emits IP multicast control messages "upstream".
The set of IP multicast control messages that are emitted upstream The set of IP multicast control messages that are emitted upstream
depends upon the contents of the LDP Opaque Value TLVs. The depends upon the contents of the LDP Opaque Value TLVs. The
Ingress LSR also receives IP multicast data messages from Ingress LSR also receives IP multicast data messages from
"upstream" and sends them "downstream" as MPLS packets on a MP- "upstream" and sends them "downstream" as MPLS packets on a MP-
LSP. LSP.
skipping to change at page 8, line 34 skipping to change at page 8, line 37
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
In general, support for non-bidirectional PIM ASM trees requires (a) In general, support for non-bidirectional PIM-ASM trees requires (a)
a procedure for determining the set of sources for a given ASM tree a procedure for determining the set of sources for a given ASM tree
("source discovery"), and (b) a procedure for pruning a particular ("source discovery"), and (b) a procedure for pruning a particular
source off a shared tree ("source pruning"). No such procedures are source off a shared tree ("source pruning"). No such procedures are
specified in this document. Therefore the combination of a wildcard specified in this document. Therefore the combination of a wildcard
source with an ASM group address MUST NOT be used unless it is known source with an ASM group address MUST NOT be used unless it is known
a priori that neither source discovery nor source pruning are needed. a priori that neither source discovery nor source pruning are needed.
How this is known is outside the scope of this document. Section 4 How this is known is outside the scope of this document. Section 4
describes some use cases in which source discovery and source pruning describes some use cases in which source discovery and source pruning
are not needed. are not needed.
There are of course use cases where source discovery and/or source There are of course use cases where source discovery and/or source
pruning is needed. These can be handled with procedures such as pruning is needed. These can be handled with procedures such as
those specified in [RFC6513], [RFC6514], and those specified in [RFC6513], [RFC6514], and [GTM]. Use of mLDP In-
[I-D.zzhang-l3vpn-mvpn-global-table-mcast]. Use of mLDP In-Band Band Signaling is NOT RECOMMENDED for those cases.
Signaling is NOT RECOMMENDED for those cases.
4. Some Wildcard Use Cases 4. Some Wildcard Use Cases
This section discusses a number of wildcard use cases. The set of This section discusses a number of wildcard use cases. The set of
use cases here is not meant to be exhaustive. In each of these use use cases here is not meant to be exhaustive. In each of these use
cases, the Egress LSRs construct mLDP Opaque Value TLVs that contain cases, the Egress LSRs construct mLDP Opaque Value TLVs that contain
wildcards in the IP Source Address or IP Group Address sub-fields. wildcards in the IP Source Address or IP Group Address sub-fields.
4.1. PIM shared tree forwarding 4.1. PIM shared tree forwarding
skipping to change at page 13, line 32 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 [RFC7246]. mentioned in [RFC5036], [RFC6826] and [RFC7246].
12. References 12. References
12.1. Normative References 12.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, 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 Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006. ("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[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., [RFC7246] Wijnands, IJ., Hitchen, P., Leymann, N., Henderickx, W.,
Gulko, A., and J. Tantsura, "Multipoint Label Distribution Gulko, A., and J. Tantsura, "Multipoint Label Distribution
Protocol In-Band Signaling in a Virtual Routing and Protocol In-Band Signaling in a Virtual Routing and
Forwarding (VRF) Table Context", RFC 7246, June 2014. Forwarding (VRF) Table Context", RFC 7246, June 2014.
12.2. Informative References 12.2. Informative References
[I-D.zzhang-l3vpn-mvpn-global-table-mcast] [GTM] Zhang, J., Giulano, 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", internet-draft draft-ietf-bess-mvpn-
table-mcast-04 (work in progress), May 2014. global-table-mcast-00, November 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,
skipping to change at page 14, line 45 skipping to change at page 14, line 44
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
VPNs", RFC 6513, February 2012. VPNs", RFC 6513, February 2012.
[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, February 2012. VPNs", RFC 6514, February 2012.
Authors' Addresses Authors' Addresses
IJsbrand Wijnands (editor) IJsbrand Wijnands (editor)
Cisco Cisco Systems, Inc.
De kleetlaan 6a De kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium BE
Email: ice@cisco.com Email: ice@cisco.com
Eric Rosen Eric C. Rosen
Cisco Juniper Networks, Inc.
1414 Massachusetts Avenue 10 Technology Park Drive
Boxborough, MA 01719 Westford, MA 01886
USA US
Email: erosen@cisco.com Email: erosen@juniper.net
Arkadiy Gulko Arkadiy Gulko
Thomson Reuters Thomson Reuters
195 Broadway 195 Broadway
New York NY 10007 New York NY 10007
USA US
Email: arkadiy.gulko@thomsonreuters.com Email: arkadiy.gulko@thomsonreuters.com
Uwe Joorde Uwe Joorde
Deutsche Telekom Deutsche Telekom
Hammer Str. 216-226 Hammer Str. 216-226
Muenster D-48153 Muenster D-48153
DE DE
Email: Uwe.Joorde@telekom.de Email: Uwe.Joorde@telekom.de
Jeff Tantsura Jeff Tantsura
Ericsson Ericsson
300 Holger Way 300 Holger Way
San Jose, california 95134 San Jose, CA 95134
usa US
Email: jeff.tantsura@ericsson.com Email: jeff.tantsura@ericsson.com
 End of changes. 17 change blocks. 
28 lines changed or deleted 31 lines changed or added

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