Using Multipoint LDP When the Backbone Has No Route to the Root
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: RFC Editor <firstname.lastname@example.org>, mpls mailing list <email@example.com>, mpls chair <firstname.lastname@example.org> Subject: Protocol Action: 'Using Multipoint LDP when the Backbone has no Route to the Root' to Proposed Standard (draft-ietf-mpls-mldp-recurs-fec-04.txt) The IESG has approved the following document: - 'Using Multipoint LDP when the Backbone has no Route to the Root' (draft-ietf-mpls-mldp-recurs-fec-04.txt) as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-recurs-fec/
Technical Summary LDP is one of the core MPLS protocols. It was orginally designed to establish point-to-point and multipoint-to-point LSPs that reflected the topology as understood by the IGP routing protocol. LDP has since been extended for several different uses. When LDP is used as the control protocol for constructing Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") it 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, if the route to the root node is a BGP route, and if the intermediate nodes are part of a BGP-free core, this lookup will fail. This document specifies procedures which enable a 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. Working Group Summary The document has been well reviewed by the MPLS working group. There were no issues arrising. Document Quality There is one known implementation of this specification, and a number of other vendors have indicated their intention to implement. Personnel Loa Andersson (email@example.com) is the Document Shepherd. Adrian Farrel (firstname.lastname@example.org) is the Responsible AD.