Explicit Path Routing for Dynamic Multi-Segment Pseudowires
RFC 7392
|
| Document |
Type |
|
RFC - Proposed Standard
(December 2014; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
Submitted to IESG for Publication
|
|
Document shepherd |
|
Andrew Malis
|
|
Shepherd write-up |
|
Show
(last changed 2014-06-05)
|
| IESG |
IESG state |
|
RFC 7392 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Yes
|
|
Telechat date |
|
|
|
Responsible AD |
|
Adrian Farrel
|
|
Send notices to |
|
(None)
|
| IANA |
IANA review state |
|
Version Changed - Review Needed
|
|
IANA action state |
|
RFC-Ed-Ack
|
Internet Engineering Task Force (IETF) P. Dutta
Request for Comments: 7392 M. Bocci
Category: Standards Track Alcatel-Lucent
ISSN: 2070-1721 L. Martini
Cisco Systems
December 2014
Explicit Path Routing for Dynamic Multi-Segment Pseudowires
Abstract
When set up through an explicit path, dynamic Multi-Segment
Pseudowires (MS-PWs) may be required to provide a simple solution for
1:1 protection with diverse primary and backup MS-PWs for a service,
or to enable controlled signaling (strict or loose) for special MS-
PWs. This document specifies the extensions and procedures required
to enable dynamic MS-PWs to be established along explicit paths.
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/rfc7392.
Copyright Notice
Copyright (c) 2014 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
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.
Dutta, et al. Standards Track [Page 1]
RFC 7392 MS-PW Explicit Routing December 2014
Table of Contents
1. Introduction ....................................................2
2. Requirements Language and Terminology ...........................3
3. Explicit Path in MS-PW Signaling ................................3
3.1. S-PE Addressing ............................................3
3.2. Explicit Route TLV (ER-TLV) ................................3
3.3. Explicit Route Hop TLV (ER-Hop TLV) ........................4
3.4. ER-Hop Semantics ...........................................4
3.4.1. ER-Hop Type: IPv4 Prefix ............................4
3.4.2. ER-Hop Type: IPv6 Prefix ............................4
3.4.3. ER-Hop Type: L2 PW Address ..........................5
4. Explicit Route TLV Processing ...................................6
4.1. Next-Hop Selection .........................................6
4.2. Adding ER Hops to the Explicit Route TLV ...................8
5. IANA Considerations .............................................8
6. Security Considerations .........................................8
7. Normative References ............................................9
Acknowledgements ...................................................9
Authors' Addresses ................................................10
1. Introduction
Procedures for dynamically establishing Multi-Segment Pseudowires
(MS-PWs), where their paths are automatically determined using a
dynamic routing protocol, are defined in [RFC7267]. For 1:1
protection of MS-PWs with primary and backup paths, MS-PWs need to be
established through a diverse set of Switching Provider Edges (S-PEs)
to avoid any single points of failure at the PW level. [RFC7267]
allows this through BGP-based mechanisms. This document defines an
additional mechanism that allows Source Terminating Provider Edges
(ST-PEs) to explicitly choose the path that a PW would take through
the intervening S-PEs. Explicit path routing of dynamic MS-PWs may
also be required for controlled setup of dynamic MS-PWs and network
resource management.
Note that in many deployments the ST-PE will not have a view of the
topology of S-PEs and so the explicit route will need to be supplied
from a management application. How that management application
determines the explicit route is outside the scope of this document.
Dutta, et al. Standards Track [Page 2]
Show full document text