PCEP Extension for Native IP Network
draft-ietf-pce-pcep-extension-native-ip-02
PCE Working Group A. Wang
Internet-Draft China Telecom
Intended status: Standards Track B. Khasanov
Expires: May 20, 2019 Huawei
S. Cheruathur
Juniper Networks
C. Zhu
ZTE Corporation
S. Fang
Huawei
November 16, 2018
PCEP Extension for Native IP Network
draft-ietf-pce-pcep-extension-native-ip-02
Abstract
This document defines the PCEP extension for CCDR application in
Native IP network. The scenario and architecture of CCDR in native
IP is described in [I-D.ietf-teas-native-ip-scenarios] and
[I-D.ietf-teas-pce-native-ip]. This draft describes the key
information that is transferred between PCE and PCC to accomplish the
end2end traffic assurance in Native IP network under central control
mode.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 20, 2019.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang, et al. Expires May 20, 2019 [Page 1]
Internet-Draft PCEP Extension for Native IP Network November 2018
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 2
3. CCI Objects . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. CCI Object associated TLV . . . . . . . . . . . . . . . . . . 3
4.1. Peer Address List TLV . . . . . . . . . . . . . . . . . . 4
4.2. Peer Prefix Association TLV . . . . . . . . . . . . . . . 5
4.2.1. Prefix sub TLV . . . . . . . . . . . . . . . . . . . 6
4.3. Explicit Peer Route TLV . . . . . . . . . . . . . . . . . 6
5. Management Consideration . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Traditionally, MPLS-TE traffic assurance requires the corresponding
network devices support MPLS or the complex RSVP/LDP/Segment Routing
etc. technologies to assure the end-to-end traffic performance. But
in native IP network, there will be no such signaling protocol to
synchronize the action among different network devices. It is
necessary to use the central control mode that described in [RFC8283]
to correlate the forwarding behavior among different network devices.
Draft [I-D.ietf-teas-pce-native-ip] describes the architecture and
solution philosophy for the end2end traffic assurance in Native IP
network via Dual/Multi BGP solution. This draft describes the
corresponding PCEP extension to transfer the key information about
peer address list, peer prefix association and the explicit peer
route on on-path router.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Show full document text