Browse Prior Art Database

Multiple Provisioning Domain Architecture (RFC7556)

IP.com Disclosure Number: IPCOM000241848D
Original Publication Date: 2015-Jun-01
Included in the Prior Art Database: 2019-Feb-11
Document File: 25 page(s) / 40K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D. Anipko: AUTHOR

Related Documents

10.17487/RFC7556: DOI

Abstract

This document is a product of the work of the Multiple Interfaces Architecture Design team. It outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously. The framework defines the concept of a Provisioning Domain (PvD), which is a consistent set of network configuration information. PvD-aware nodes learn PvD-specific information from the networks they are attached to and/or other sources. PvDs are used to enable separation and configuration consistency in the presence of multiple concurrent connections.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 6% of the total text.

Internet Engineering Task Force (IETF) D. Anipko, Ed. Request for Comments: 7556 Unaffiliated Category: Informational June 2015 ISSN: 2070-1721

Multiple Provisioning Domain Architecture

Abstract

This document is a product of the work of the Multiple Interfaces Architecture Design team. It outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously. The framework defines the concept of a Provisioning Domain (PvD), which is a consistent set of network configuration information. PvD-aware nodes learn PvD-specific information from the networks they are attached to and/or other sources. PvDs are used to enable separation and configuration consistency in the presence of multiple concurrent connections.

Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes.

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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see 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/rfc7556.

Anipko Informational [Page 1]

RFC 7556 MPvD Architecture June 2015

Copyright Notice

Copyright (c) 2015 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.

Anipko Informational [Page 2]

RFC 7556 MPvD Architecture June 2015

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions and Types of PvDs . . . . . . . . . . . . . . . . 5 2.1. Explicit PvDs . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Implicit PvDs and Incremental Adoption of Explicit PvDs . 6 2.3. Relationship between PvDs and Interfaces . . . . . . . . 7 2.4. PvD Identity/Naming . . . . . . . . . . . . . . . . . . . 8 2.5. The Relationship to Dual-Stack Networks . . . . . . . . . 8 3. Conveying PvD Information . . . . . . . . . . . . . . . . . . 9 3.1. Separate Messages or One Message? . . . . . . . . . . . . 9 3.2. Securing PvD Information . . . . . . . . . . . . . . . . 10 3.3. Backward Compatibility . . . . . . . . . . . . . . . . . 10 3.4. Retracting/Updating PvD Information . ....

Processing...
Loading...