Using Multipoint LDP When the Backbone Has No Route to the Root
RFC 6512
|
| Document |
Type |
|
RFC - Proposed Standard
(February 2012; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Replaces |
|
draft-wijnands-mpls-mldp-recurs-fec
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
Submitted to IESG for Publication
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 6512 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Adrian Farrel
|
|
IESG note |
|
Loa Andersson (loa@pi.nu) is the Document Shepherd.
|
|
Send notices to |
|
(None)
|
Internet Engineering Task Force (IETF) IJ. Wijnands
Request for Comments: 6512 E. Rosen
Category: Standards Track Cisco Systems
ISSN: 2070-1721 M. Napierala
AT&T
N. Leymann
Deutsche Telekom
February 2012
Using Multipoint LDP When the Backbone Has No Route to the Root
Abstract
The control protocol used for constructing Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a
field that identifies the address of a "root node". Intermediate
nodes are expected to be able to look up that address in their
routing tables. However, this is not possible if the route to the
root node is a BGP route and the intermediate nodes are part of a
BGP-free core. This document specifies procedures that enable an MP
LSP to be constructed through a BGP-free core. In these procedures,
the root node address is temporarily replaced by an address that is
known to the intermediate nodes and is on the path to the true root
node.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6512.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Wijnands, et al. Standards Track [Page 1]
RFC 6512 Using mLDP with Recursive Opaque Values February 2012
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................3
2. The Recursive Opaque Value ......................................5
2.1. Encoding ...................................................5
2.2. Procedures .................................................5
3. The VPN-Recursive Opaque Value ..................................6
3.1. Encoding ...................................................6
3.2. Procedures .................................................7
3.2.1. Non-Segmented Inter-AS P-Tunnels ....................7
3.2.2. Limited Carrier's Carrier Function ..................9
4. IANA Considerations ............................................10
5. Security Considerations ........................................10
6. Acknowledgments ................................................10
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................11
Wijnands, et al. Standards Track [Page 2]
RFC 6512 Using mLDP with Recursive Opaque Values February 2012
1. Introduction
The document [mLDP] extends LDP [LDP] to support multipoint Label
Switched Paths. These extensions are known as "Multipoint LDP", or
more simply, as "mLDP". [mLDP] defines several LDP Forwarding
Equivalence Class (FEC) element encodings: "Point-to-Multipoint"
(P2MP), "Multipoint-to-Multipoint (MP2MP) Upstream", and "MP2MP
Downstream".
The encoding for these three FEC elements, as defined in [mLDP], is
shown in Figure 1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Show full document text