OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com>, l3vpn mailing list <firstname.lastname@example.org>, l3vpn chair <email@example.com> Subject: Protocol Action: 'OSPFv3 as a PE-CE routing protocol' to Proposed Standard (draft-ietf-l3vpn-ospfv3-pece-11.txt) The IESG has approved the following document: - 'OSPFv3 as a PE-CE routing protocol' (draft-ietf-l3vpn-ospfv3-pece-11.txt) as a Proposed Standard This document is the product of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ospfv3-pece/
Technical Summary The initial BGP/MPLS IP VPN specification enabled PE routers to learn routes within customer sites through static routing, or through a dynamic routing protocol instantiated on the PE-CE link. Specifically, RFC4364 includes support for dynamic routing protocols such as BGP, RIP, and OSPFv2. The OSPFv2 as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks specification (RFC4577) further updates the operation of OSPFv2 as the PE-CE routing protocol by detailing additional extensions to enable intra-domain routing connectivity between OSPFv2-based customer sites. This document defines the mechanisms required to enable the operation of OSPFv3 as the PE-CE Routing Protocol in BGP MPLS/IP VPNs. In doing so, it reuses, and extends where necessary, the "BGP/MPLS IP VPN" method for IPv6 VPNs defined in RFC4659, and OSPFv2 as the PE-CE routing protocol defined in RFC4577. This document also includes the specifications for maintaining intra-domain routing connectivity between OSPFv3-based customer sites across a SP backbone. Working Group Summary This document is a product of L3VPN WG. The document underwent WG Last Calls in both the L3VPN and OSPF WGs. Document Quality There is at least one known implementation of this protocol. Personnel Ben Niven-Jenkins is the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director.