Dear Authors,
Thanks for your patience. Here’s my review.
I’ve supplied my comments in the form of an edited copy of the draft. Minor
editorial suggestions I’ve made in place without further comment, more
substantive comments are done in-line and prefixed with “jgs:”. You can use
your favorite diff tool to review them; I’ve attached the iddiff output for
your convenience if you’d like to use it. I’ve also pasted a traditional diff
below in case you want to use it for in-line reply. I’d appreciate feedback
regarding whether you found this a useful way to receive my comments as
compared to a more traditional numbered list of comments with selective
quotation from the draft.
Thanks,
—John
--- draft-ietf-pce-vn-association-08.txt 2022-09-20 16:26:37.000000000
-0400
+++ draft-ietf-pce-vn-association-08-jgs-comments.txt 2022-09-26
10:18:24.000000000 -0400
@@ -140,6 +140,34 @@
making it the base for PCE applicability for ACTN. In this text
child PCE would be same as Provisioning Network Controller (PNC), and
the parent PCE as Multi-domain Service Coordinator (MDSC) [RFC8453].
+
+---
+jgs: I found the last sentence to be unclear. I see that RFC 6805 §1.4
+defines Child PCE and Parent PCE:
+
+ Parent PCE: A PCE responsible for selecting a path across a parent
+ domain and any number of child domains by coordinating with child
+ PCEs and examining a topology map that shows domain inter-
+ connectivity.
+
+ Child PCE: A PCE responsible for computing the path across one or
+ more specific (child) domains. A child PCE maintains a relationship
+ with at least one parent PCE.
+
+and I see that RFC 8751 §1.2.1 talks about how in the ACTN context
+C-PCE maps to PNC and P-PCE maps to MDSC:
+
+ In this case, the P-PCE (as MDSC) interacts with multiple C-PCEs (as
+ PNCs) along the interdomain path of the LSP.
+
+So *maybe* the sentence above is trying to say something like,
+
+ As [RFC8751] explains, in the context of ACTN, the Child PCE is
+ identified with the PNC, and the Parent PCE is identified with
+ the MDSC.
+
+If that's not it, let's discuss please?
+---
In this context, there is a need to associate a set of LSPs with a VN
"construct" to facilitate VN operations in the PCE architecture.
@@ -150,7 +178,7 @@
policy actions, setting default behavior, etc.
This document specifies a PCEP extension to associate a set of LSPs
- based on Virtual Network (VN).
+ based on their Virtual Network (VN).
1.1. Requirement Language
@@ -186,7 +214,7 @@
* Path Computation: When computing a path for an LSP, it is useful
to analyze the impact of this LSP on the other LSPs belonging to
- the same VN. The aim would be optimize all LSPs belonging to the
+ the same VN. The aim would be to optimize all LSPs belonging to the
VN rather than a single LSP. Also, the optimization criteria
(such as minimizing the load of the most loaded link (MLL)
[RFC5541]) could be applied for all the LSPs belonging to the VN
@@ -250,19 +278,48 @@
(MDSC) and a child PCE (PNC). When computing the path, the child PCE
(PNC) refers to the VN association in the request from the parent PCE
(MDSC) and maps the VN to the associated LSPs and network resources.
- From the perspective of Parent PCE, it receives a virtual network
+ From the perspective of the Parent PCE, it receives a virtual network
creation request by its customer, with the VN uniquely identified by
- an Association ID in VNAG as well as the Virtual Network identifier.
+ an Association ID in the VNAG as well as the Virtual Network identifier.
+
+--
+jgs: in the preceding clause, do you mean that the VN is uniquely
+identified by either the Association ID or the VNI, or do you mean
+it's uniquely identified by the tuple (Association ID, VNI)? I think
+it's probably the latter, based on the defintion of the ASSOCIATION
+object in RFC 8697:
+
+ Association ID (2 bytes): The identifier of the association group.
+ When combined with other association parameters, such as an
+ Association Type and Association Source, this value uniquely
+ identifies an association group.
+
+Assuming that is right, perhaps rewrite like
+
+ From the perspective of the Parent PCE, it receives a virtual network
+ creation request by its customer, with the VN uniquely identified by
+ the combination of the Association ID in the VNAG and the Virtual
+ Network identifier.
+
+If that's wrong, let's discuss please.
+--
+
This VN may comprise multiple LSPs in the network in a single domain
- or across multiple domains. Parent PCE sends a PCInitiate Message
+ or across multiple domains. The Parent PCE sends a PCInitiate Message
with this association information in the VNAG Object. This in effect
binds an LSP that is to be instantiated at the child PCE with the VN.
The VN association information could be included as a part of the
response as well. Figure 1 shows an example of a typical VN
+
+--
+jgs: Do I correctly infer that it would also be fine for the VN association
+information to *not* be included as part of the response? ("Could" implies
+"could not".)
+--
operation using PCEP. It is worth noting that in a multi-domain
scenario, the different domains are controlled by different child
PCEs. In order to set up the cross-domain tunnel, multiple segments
- need to be stitched, by the border nodes in each domain who receives
+ need to be stitched, by the border nodes in each domain who receive
the instruction from their child PCE (PNC).
@@ -315,13 +372,25 @@
MPI -> PCEP
Figure 1: Example of VN operations in H-PCE Architecture
+
+--
+jgs: Figure 1 has a bunch of notations that are never referred to in the
+text. I'm guessing these were carried forward from some other use of the
+figure where they were actually referred to, but now they just create
+visual clutter and potential confusion. Things I flagged as not being
+referenced include: "with VNAG = 10", "A", "C", "B13", "B43", "B31",
+"B34", "B".
+
+I suggest either tidying the figure up, or expanding the explanation text
+to refer to the labels.
+--
Whenever changes occur with the instantiated LSP in a domain network,
the domain child PCE reports the changes using a PCRpt Message in
which the VNAG Object indicates the relationship between the LSP and
the VN.
- Whenever an update occurs with VNs in the Parent PCE (via the
+ Whenever an update occurs with VNs in the Parent PCE (due to the
customer's request), the parent PCE sends an PCUpd Message to inform
each affected child PCE of this change.
@@ -369,12 +438,27 @@
that uniquely identifies the VN. It SHOULD be a string of printable
ASCII [RFC0020] characters (i.e., 0x20 to 0x7E), without a NULL
terminator. The Virtual Network Identifier is a human-readable
+--
+jgs: Is there an established practice in PCE of using US-ASCII as the
+character set for human-readable strings? This would seem to be a
+practice that's discouraged by BCP 18, BCP 166. Was this discussed in
+the WG and a decision taken to not use internationalized strings?
+--
string that identifies a VN and can be specified with the association
information. An implementation could use the Virtual Network
Identifier to maintain a mapping to the VN association group and the
LSPs associated with the VN. The Virtual Network Identifier MAY be
specified by the customer or set via an operator policy or auto-
generated by the PCEP speaker.
+
+--
+jgs: At the top of the page you say it's a "mandatory TLV", but then in
+the paragraph right above you say it "can be" specified and an
+implementation "could" use it. "Can" and "could" don't imply "mandatory"
+in the normal English sense. Does "mandatory" have some special meaning
+in the context of PCE, is there some other explanation for this
+discrepancy, ... ?
+--
The VIRTUAL-NETWORK-TLV MUST be included in VNAG object. If a PCEP
speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it
@@ -452,21 +536,29 @@
6. Security Considerations
- This document defines one new type for association, which do not add
+ This document defines one new type for association, which does not add
any new security concerns beyond those discussed in [RFC5440],
[RFC8231] and [RFC8697] in itself.
Some deployments may find the Virtual Network Identifier and the VN
associations as extra sensitive; and thus should employ suitable PCEP
security mechanisms like TCP-AO [RFC5925] or TLS [RFC8253].
+--
+jgs: I have a few problems with the paragraph above. First, by "extra
+sensitive" do you mean "confidential"? If so, use that term or one like
+it, but in any case "extra sensitive" isn't specific enough.
+
+Second, assuming you do mean "confidential", TCP-AO isn't a suitable
+mitigation: AO doesn't provide confidentiality, only authentication.
+--
7. IANA Considerations
7.1. Association Object Type Indicator
- IANA is requested to make the assignment of a new value for the sub-
- registry "ASSOCIATION Type Field" (request to be created in
- [RFC8697]) within the "Path Computation Element Protocol (PCEP)
+ IANA is requested to make the assignment of a new value in the sub-
+ registry "ASSOCIATION Type Field"
+ within the "Path Computation Element Protocol (PCEP)
Numbers" registry, as follows:
Value Name Reference
@@ -538,8 +630,8 @@
8.6. Impact On Network Operations
[RFC8637] describe the network operations when PCE is used for VN
- operations. Section 3 further specify the operations when VN
- associations is used.
+ operations. Section 3 further specifies the operations when VN
+ associations are used.
9. References
PCE Working Group Y. Lee
Internet-Draft Samsung
Intended status: Standards Track H. Zheng
Expires: 12 November 2022 Huawei Technologies
D. Ceccarelli
Ericsson
11 May 2022
Path Computation Element Communication Protocol (PCEP) extensions for
establishing relationships between sets of Label Switched Paths and
Virtual Networks
draft-ietf-pce-vn-association-08
Abstract
This document describes how to extend the Path Computation Element
(PCE) Communication Protocol (PCEP) association mechanism introduced
by the PCEP Association Group specification, to further associate
sets of Label Switched Paths (LSPs) with a higher-level structure
such as a Virtual Network (VN) requested by a customer or
application. This extended association mechanism can be used to
facilitate control of virtual network using the PCE architecture.
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 12 November 2022.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Lee, et al. Expires 12 November 2022 [Page 1]
Internet-Draft PCE VN Association May 2022
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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Operation Overview . . . . . . . . . . . . . . . . . . . . . 4
4. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 6
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 8
5.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7.1. Association Object Type Indicator . . . . . . . . . . . . 9
7.2. PCEP TLV Type Indicator . . . . . . . . . . . . . . . . . 9
7.3. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . 9
8. Manageability Considerations . . . . . . . . . . . . . . . . 10
8.1. Control of Function and Policy . . . . . . . . . . . . . 10
8.2. Information and Data Models . . . . . . . . . . . . . . . 10
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 10
8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 10
8.5. Requirements On Other Protocols . . . . . . . . . . . . . 10
8.6. Impact On Network Operations . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to requests from Path Computation Clients
(PCCs) [RFC5440].
[RFC8051] describes general considerations for a stateful PCE
deployment and examines its applicability and benefits, as well as
its challenges and limitations through a number of use cases.
[RFC8231] describes a set of extensions to PCEP to provide stateful
control. For its computations, a stateful PCE has access to not only
Lee, et al. Expires 12 November 2022 [Page 2]
Internet-Draft PCE VN Association May 2022
the information carried by the network's Interior Gateway Protocol
(IGP), but also the set of active paths and their reserved resources.
The additional state allows the PCE to compute constrained paths
while considering individual Label Switched Paths (LSPs) and their
interactions.
[RFC8281] describes the setup, maintenance and teardown of PCE-
initiated LSPs under the stateful PCE model.
[RFC8697] introduces a generic mechanism to create a grouping of
LSPs. This grouping can then be used to define associations between
sets of LSPs or between a set of LSPs and a set of attributes.
[RFC8453] introduces a framework for Abstraction and Control of TE
Networks (ACTN) and describes various Virtual Network (VN) operations
initiated by a customer or application. A VN is a customer view of
the TE network. Depending on the agreement between client and
provider, various VN operations and VN views are possible.
[RFC8637] examines the PCE and ACTN architectures and describes how
the PCE architecture is applicable to ACTN. [RFC6805] and [RFC8751]
describes a hierarchy of stateful PCEs with Parent PCE coordinating
multi-domain path computation function between Child PCEs, and thus
making it the base for PCE applicability for ACTN. In this text
child PCE would be same as Provisioning Network Controller (PNC), and
the parent PCE as Multi-domain Service Coordinator (MDSC) [RFC8453].
---
jgs: I found the last sentence to be unclear. I see that RFC 6805 §1.4
defines Child PCE and Parent PCE:
Parent PCE: A PCE responsible for selecting a path across a parent
domain and any number of child domains by coordinating with child
PCEs and examining a topology map that shows domain inter-
connectivity.
Child PCE: A PCE responsible for computing the path across one or
more specific (child) domains. A child PCE maintains a relationship
with at least one parent PCE.
and I see that RFC 8751 §1.2.1 talks about how in the ACTN context
C-PCE maps to PNC and P-PCE maps to MDSC:
In this case, the P-PCE (as MDSC) interacts with multiple C-PCEs (as
PNCs) along the interdomain path of the LSP.
So *maybe* the sentence above is trying to say something like,
As [RFC8751] explains, in the context of ACTN, the Child PCE is
identified with the PNC, and the Parent PCE is identified with
the MDSC.
If that's not it, let's discuss please?
---
In this context, there is a need to associate a set of LSPs with a VN
"construct" to facilitate VN operations in the PCE architecture.
This association allows a PCE to identify which LSPs belong to a
certain VN. The PCE could then use this association to optimize all
LSPs belonging to the VN at once. The PCE could further take VN-
specific actions on the LSPs, such as relaxation of constraints,
policy actions, setting default behavior, etc.
This document specifies a PCEP extension to associate a set of LSPs
based on their Virtual Network (VN).
1.1. Requirement Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Lee, et al. Expires 12 November 2022 [Page 3]
Internet-Draft PCE VN Association May 2022
2. Terminology
The terminology is as per [RFC4655], [RFC5440], [RFC6805], [RFC8231]
and [RFC8453].
3. Operation Overview
As per [RFC8697], LSPs are associated with other LSPs with which they
interact by adding them to a common association group.
An association group based on VN is useful for various optimizations
that should be applied by considering all the LSPs in the
association. This includes, but is not limited to -
* Path Computation: When computing a path for an LSP, it is useful
to analyze the impact of this LSP on the other LSPs belonging to
the same VN. The aim would be to optimize all LSPs belonging to the
VN rather than a single LSP. Also, the optimization criteria
(such as minimizing the load of the most loaded link (MLL)
[RFC5541]) could be applied for all the LSPs belonging to the VN
identified by the VN association.
* Path Re-Optimization: The PCE would like to use advanced path
computation algorithms and optimization techniques that consider
all the LSPs belonging to a VN, and optimize them all together
during the path re-optimization.
In this document we define a new association group called the VN
Association Group (VNAG). This grouping is used to define the
association between a set of LSPs and a virtual network.
The Association Object contains a field to identify the type of
association, and this document defines a new Association Type value
of TBD1 to indicate that the association is a "VN Association". The
Association Identifier in the Association Object is the VNAG
Identifier and is handled in the same way as the generic association
identifier defined in [RFC8697].
In this document, "VNAG object" refers to an Association Object with
the Association type set to "VN Association".
Local polices on the PCE define the computational and optimization
behavior for the LSPs in the VN. An LSP MUST NOT belong to more than
one VNAG. If an implementation encounters more than one VNAG object
in a PCEP message, it MUST process the first occurrence and it MUST
ignore the others.
Lee, et al. Expires 12 November 2022 [Page 4]
Internet-Draft PCE VN Association May 2022
[RFC8697] specifies the mechanism by which a PCEP speaker can
advertise which association types it supports. This is done using
the ASSOC-Type-List TLV carried within an OPEN object. A PCEP
speaker MUST include the VN Association Type (TBD1) in the ASSOC-
Type-List TLV before using the VNAG object in a PCEP message. As per
[RFC8697], if the implementation does not support the VN Association
Type, it will return a PCErr message with Error-Type 26 "Association
Error" and Error-value 1 "Association Type is not supported".
The Association IDs (VNAG IDs) for this Association Type are dynamic
in nature (and created by the Parent PCE (MDSC) based on the VN
operations for the LSPs belonging to the same VN). Operator
configuration of VNAG IDs is not supported so there is no need for an
Operator-Configured Association Range to be set. Thus, the VN
Association Type (TBD1) MUST NOT be present in the Operator-
Configured Association Range TLV if that TLV is present in the OPEN
object. If an implementation encounters the VN Association Type
(TBD1) in an Operator-Configured Association Range TLV, it MUST
ignore the associated Start-Assoc-ID and Range values.
This association is useful in a PCEP session between a parent PCE
(MDSC) and a child PCE (PNC). When computing the path, the child PCE
(PNC) refers to the VN association in the request from the parent PCE
(MDSC) and maps the VN to the associated LSPs and network resources.
From the perspective of the Parent PCE, it receives a virtual network
creation request by its customer, with the VN uniquely identified by
an Association ID in the VNAG as well as the Virtual Network identifier.
--
jgs: in the preceding clause, do you mean that the VN is uniquely
identified by either the Association ID or the VNI, or do you mean
it's uniquely identified by the tuple (Association ID, VNI)? I think
it's probably the latter, based on the defintion of the ASSOCIATION
object in RFC 8697:
Association ID (2 bytes): The identifier of the association group.
When combined with other association parameters, such as an
Association Type and Association Source, this value uniquely
identifies an association group.
Assuming that is right, perhaps rewrite like
From the perspective of the Parent PCE, it receives a virtual network
creation request by its customer, with the VN uniquely identified by
the combination of the Association ID in the VNAG and the Virtual
Network identifier.
If that's wrong, let's discuss please.
--
This VN may comprise multiple LSPs in the network in a single domain
or across multiple domains. The Parent PCE sends a PCInitiate Message
with this association information in the VNAG Object. This in effect
binds an LSP that is to be instantiated at the child PCE with the VN.
The VN association information could be included as a part of the
response as well. Figure 1 shows an example of a typical VN
--
jgs: Do I correctly infer that it would also be fine for the VN association
information to *not* be included as part of the response? ("Could" implies
"could not".)
--
operation using PCEP. It is worth noting that in a multi-domain
scenario, the different domains are controlled by different child
PCEs. In order to set up the cross-domain tunnel, multiple segments
need to be stitched, by the border nodes in each domain who receive
the instruction from their child PCE (PNC).
Lee, et al. Expires 12 November 2022 [Page 5]
Internet-Draft PCE VN Association May 2022
******
..........*MDSC*..............................
. ****** .. MPI .
. . . PCEP .
. . . PCInitiate LSPx .
. . . with VNAG = 10 .
. . . .
. . . .
. . . .
v v v .
****** ****** ****** .
*PNC1* *PNC2* *PNC4* .
****** ****** ****** .
+---------------+ +---------------+ +---------------+ .
|A |----| |----| C| .
| | | | | | .
|DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | .
+------------B13+ +---------------+ +B43------------+ .
/ .
****** / .
*PNC3*<............/.....................
****** /
+---------------+/
B31 B34
| |
|DOMAIN 3 B|
+---------------+
MDSC -> Parent PCE
PNC -> Child PCE
MPI -> PCEP
Figure 1: Example of VN operations in H-PCE Architecture
--
jgs: Figure 1 has a bunch of notations that are never referred to in the
text. I'm guessing these were carried forward from some other use of the
figure where they were actually referred to, but now they just create
visual clutter and potential confusion. Things I flagged as not being
referenced include: "with VNAG = 10", "A", "C", "B13", "B43", "B31",
"B34", "B".
I suggest either tidying the figure up, or expanding the explanation text
to refer to the labels.
--
Whenever changes occur with the instantiated LSP in a domain network,
the domain child PCE reports the changes using a PCRpt Message in
which the VNAG Object indicates the relationship between the LSP and
the VN.
Whenever an update occurs with VNs in the Parent PCE (due to the
customer's request), the parent PCE sends an PCUpd Message to inform
each affected child PCE of this change.
4. Extensions to PCEP
The format of VNAG is as per the ASSOCIATION object [RFC8697].
Lee, et al. Expires 12 November 2022 [Page 6]
Internet-Draft PCE VN Association May 2022
This document defines one new mandatory TLV "VIRTUAL-NETWORK-TLV".
Optionally, the new TLV can be jointly used with the existing
"VENDOR-INFORMATION-TLV" specified in [RFC7470] as described below:
* VIRTUAL-NETWORK-TLV: Used to communicate the Virtual Network
Identifier.
* VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor
specific behavioral information, described in [RFC7470].
The format of VIRTUAL-NETWORK-TLV is as follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD2 | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Virtual Network Identifier //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The VIRTUAL-NETWORK-TLV formats
Type: TBD2 (to be allocated by IANA)
Length: Variable Length, which covers the value portion of the TLV.
Virtual Network Identifier (variable): a symbolic name for the VN
that uniquely identifies the VN. It SHOULD be a string of printable
ASCII [RFC0020] characters (i.e., 0x20 to 0x7E), without a NULL
terminator. The Virtual Network Identifier is a human-readable
--
jgs: Is there an established practice in PCE of using US-ASCII as the
character set for human-readable strings? This would seem to be a
practice that's discouraged by BCP 18, BCP 166. Was this discussed in
the WG and a decision taken to not use internationalized strings?
--
string that identifies a VN and can be specified with the association
information. An implementation could use the Virtual Network
Identifier to maintain a mapping to the VN association group and the
LSPs associated with the VN. The Virtual Network Identifier MAY be
specified by the customer or set via an operator policy or auto-
generated by the PCEP speaker.
--
jgs: At the top of the page you say it's a "mandatory TLV", but then in
the paragraph right above you say it "can be" specified and an
implementation "could" use it. "Can" and "could" don't imply "mandatory"
in the normal English sense. Does "mandatory" have some special meaning
in the context of PCE, is there some other explanation for this
discrepancy, ... ?
--
The VIRTUAL-NETWORK-TLV MUST be included in VNAG object. If a PCEP
speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it
MUST send a PCErr message with Error-Type=6 (mandatory object
missing) and Error-Value=TBD3 (VIRTUAL-NETWORK-TLV missing) and close
the session.
The format of VENDOR-INFORMATION-TLV is defined in [RFC7470].
Lee, et al. Expires 12 November 2022 [Page 7]
Internet-Draft PCE VN Association May 2022
5. Implementation Status
[Note to the RFC Editor - remove this section before publication, as
well as remove the reference to RFC 7942.]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
5.1. Huawei's Proof of Concept based on ONOS
The PCE function was developed in the ONOS open source platform.
This extension was implemented on a private version as a proof of
concept to ACTN.
* Organization: Huawei
* Implementation: Huawei's PoC based on ONOS
* Description: PCEP as a southbound plugin was added to ONOS. To
support ACTN, this extension in PCEP is used. Refer
https://wiki.onosproject.org/display/ONOS/PCEP+Protocol
* Maturity Level: Prototype
* Coverage: Full
* Contact: sati...@huawei.com
Lee, et al. Expires 12 November 2022 [Page 8]
Internet-Draft PCE VN Association May 2022
6. Security Considerations
This document defines one new type for association, which does not add
any new security concerns beyond those discussed in [RFC5440],
[RFC8231] and [RFC8697] in itself.
Some deployments may find the Virtual Network Identifier and the VN
associations as extra sensitive; and thus should employ suitable PCEP
security mechanisms like TCP-AO [RFC5925] or TLS [RFC8253].
--
jgs: I have a few problems with the paragraph above. First, by "extra
sensitive" do you mean "confidential"? If so, use that term or one like
it, but in any case "extra sensitive" isn't specific enough.
Second, assuming you do mean "confidential", TCP-AO isn't a suitable
mitigation: AO doesn't provide confidentiality, only authentication.
--
7. IANA Considerations
7.1. Association Object Type Indicator
IANA is requested to make the assignment of a new value in the sub-
registry "ASSOCIATION Type Field"
within the "Path Computation Element Protocol (PCEP)
Numbers" registry, as follows:
Value Name Reference
TBD1 VN Association Type [This I.D.]
7.2. PCEP TLV Type Indicator
IANA is requested to make the assignment of a new value for the
existing "PCEP TLV Type Indicators" sub-registry within the "Path
Computation Element Protocol (PCEP) Numbers" registry, as follows:
Value Name Reference
TBD2 VIRTUAL-NETWORK-TLV [This I.D.]
7.3. PCEP Error
IANA is requested to allocate new error value within the "PCEP-ERROR
Object Error Types and Values" sub-registry within the "Path
Computation Element Protocol (PCEP) Numbers" registry, as follows:
Error-Type Meaning
6 Mandatory Object missing
Error-value=TBD3: VIRTUAL-NETWORK TLV missing [This
I.D.]
Lee, et al. Expires 12 November 2022 [Page 9]
Internet-Draft PCE VN Association May 2022
8. Manageability Considerations
8.1. Control of Function and Policy
An operator MUST be allowed to mark LSPs that belong to the same VN.
This could also be done automatically based on the VN configuration.
8.2. Information and Data Models
The PCEP YANG module [I-D.ietf-pce-pcep-yang] should support the
association between LSPs including VN association.
8.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already
listed in [RFC5440].
8.4. Verify Correct Operations
Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in
[RFC5440].
8.5. Requirements On Other Protocols
Mechanisms defined in this document do not imply any new requirements
on other protocols.
8.6. Impact On Network Operations
[RFC8637] describe the network operations when PCE is used for VN
operations. Section 3 further specifies the operations when VN
associations are used.
9. References
9.1. Normative References
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Lee, et al. Expires 12 November 2022 [Page 10]
Internet-Draft PCE VN Association May 2022
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
[RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
Dhody, D., and Y. Tanaka, "Path Computation Element
Communication Protocol (PCEP) Extensions for Establishing
Relationships between Sets of Label Switched Paths
(LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020,
<https://www.rfc-editor.org/info/rfc8697>.
9.2. Informative References
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the
Path Computation Element Architecture to the Determination
of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
DOI 10.17487/RFC6805, November 2012,
<https://www.rfc-editor.org/info/rfc6805>.
Lee, et al. Expires 12 November 2022 [Page 11]
Internet-Draft PCE VN Association May 2022
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
[RFC8637] Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of
the Path Computation Element (PCE) to the Abstraction and
Control of TE Networks (ACTN)", RFC 8637,
DOI 10.17487/RFC8637, July 2019,
<https://www.rfc-editor.org/info/rfc8637>.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541,
DOI 10.17487/RFC5541, June 2009,
<https://www.rfc-editor.org/info/rfc5541>.
[RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific
Constraints in the Path Computation Element Communication
Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015,
<https://www.rfc-editor.org/info/rfc7470>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
"PCEPS: Usage of TLS to Provide a Secure Transport for the
Path Computation Element Communication Protocol (PCEP)",
RFC 8253, DOI 10.17487/RFC8253, October 2017,
<https://www.rfc-editor.org/info/rfc8253>.
[RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King,
"Hierarchical Stateful Path Computation Element (PCE)",
RFC 8751, DOI 10.17487/RFC8751, March 2020,
<https://www.rfc-editor.org/info/rfc8751>.
Lee, et al. Expires 12 November 2022 [Page 12]
Internet-Draft PCE VN Association May 2022
[I-D.ietf-pce-pcep-yang]
Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura,
"A YANG Data Model for Path Computation Element
Communications Protocol (PCEP)", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-yang-18, 25 January
2022, <https://www.ietf.org/archive/id/draft-ietf-pce-
pcep-yang-18.txt>.
Appendix A. Contributors
Dhruv Dhody
Huawei Technologies
Divyashree Technopark, Whitefield
Bangalore, Karnataka 560066
India
Email: dhruv.i...@gmail.com
Qin Wu
Huawei Technologies
China
Email: bill...@huawei.com
Xian Zhang
Huawei Technologies
China
Email: zhang.x...@huawei.com
Adrian Farrel
Old Dog Consulting
Email: adr...@olddog.co.uk
Authors' Addresses
Young Lee
Samsung
Seoul
South Korea
Email: younglee...@gmail.com
Haomian Zheng
Huawei Technologies
H1, Huawei Xiliu Beipo Village, Songshan Lake
Dongguan
Guangdong, 523808
China
Email: zhenghaom...@huawei.com
Lee, et al. Expires 12 November 2022 [Page 13]
Internet-Draft PCE VN Association May 2022
Daniele Ceccarelli
Ericsson
Torshamnsgatan,48
Stockholm
Sweden
Email: daniele.ceccare...@ericsson.com
Lee, et al. Expires 12 November 2022 [Page 14]
Title: Diff: draft-ietf-pce-vn-association-08.txt - draft-ietf-pce-vn-association-08-jgs-comments.txt
| |
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
|
|
|
| |
[RFC8637] examines the PCE and ACTN architectures and describes how
|
|
[RFC8637] examines the PCE and ACTN architectures and describes how
|
| |
the PCE architecture is applicable to ACTN. [RFC6805] and [RFC8751]
|
|
the PCE architecture is applicable to ACTN. [RFC6805] and [RFC8751]
|
| |
describes a hierarchy of stateful PCEs with Parent PCE coordinating
|
|
describes a hierarchy of stateful PCEs with Parent PCE coordinating
|
| |
multi-domain path computation function between Child PCEs, and thus
|
|
multi-domain path computation function between Child PCEs, and thus
|
| |
making it the base for PCE applicability for ACTN. In this text
|
|
making it the base for PCE applicability for ACTN. In this text
|
| |
child PCE would be same as Provisioning Network Controller (PNC), and
|
|
child PCE would be same as Provisioning Network Controller (PNC), and
|
| |
the parent PCE as Multi-domain Service Coordinator (MDSC) [RFC8453].
|
|
the parent PCE as Multi-domain Service Coordinator (MDSC) [RFC8453].
|
| |
|
|
jgs: I found the last sentence to be unclear. I see that RFC 6805 §1.4
|
| |
|
|
defines Child PCE and Parent PCE:
|
| |
|
|
Parent PCE: A PCE responsible for selecting a path across a parent
|
| |
|
|
domain and any number of child domains by coordinating with child
|
| |
|
|
PCEs and examining a topology map that shows domain inter-
|
| |
|
|
connectivity.
|
| |
|
|
Child PCE: A PCE responsible for computing the path across one or
|
| |
|
|
more specific (child) domains. A child PCE maintains a relationship
|
| |
|
|
with at least one parent PCE.
|
| |
|
|
and I see that RFC 8751 §1.2.1 talks about how in the ACTN context
|
| |
|
|
C-PCE maps to PNC and P-PCE maps to MDSC:
|
| |
|
|
In this case, the P-PCE (as MDSC) interacts with multiple C-PCEs (as
|
| |
|
|
PNCs) along the interdomain path of the LSP.
|
| |
|
|
So *maybe* the sentence above is trying to say something like,
|
| |
|
|
As [RFC8751] explains, in the context of ACTN, the Child PCE is
|
| |
|
|
identified with the PNC, and the Parent PCE is identified with
|
| |
|
|
the MDSC.
|
| |
|
|
If that's not it, let's discuss please?
|
| |
|
|
|
| |
In this context, there is a need to associate a set of LSPs with a VN
|
|
In this context, there is a need to associate a set of LSPs with a VN
|
| |
"construct" to facilitate VN operations in the PCE architecture.
|
|
"construct" to facilitate VN operations in the PCE architecture.
|
| |
This association allows a PCE to identify which LSPs belong to a
|
|
This association allows a PCE to identify which LSPs belong to a
|
| |
certain VN. The PCE could then use this association to optimize all
|
|
certain VN. The PCE could then use this association to optimize all
|
| |
LSPs belonging to the VN at once. The PCE could further take VN-
|
|
LSPs belonging to the VN at once. The PCE could further take VN-
|
| |
specific actions on the LSPs, such as relaxation of constraints,
|
|
specific actions on the LSPs, such as relaxation of constraints,
|
| |
policy actions, setting default behavior, etc.
|
|
policy actions, setting default behavior, etc.
|
| |
|
|
|
| |
This document specifies a PCEP extension to associate a set of LSPs
|
|
This document specifies a PCEP extension to associate a set of LSPs
|
| |
based on Virtual Network (VN).
|
|
based on their Virtual Network (VN).
|
| |
|
|
|
| |
1.1. Requirement Language
|
|
1.1. Requirement Language
|
| |
|
|
|
| |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
| |
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
|
| |
"OPTIONAL" in this document are to be interpreted as described in BCP
|
|
"OPTIONAL" in this document are to be interpreted as described in BCP
|
| |
14 [RFC2119] [RFC8174] when, and only when, they appear in all
|
|
14 [RFC2119] [RFC8174] when, and only when, they appear in all
|
| |
capitals, as shown here.
|
|
capitals, as shown here.
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
interact by adding them to a common association group.
|
|
interact by adding them to a common association group.
|
| |
|
|
|
| |
An association group based on VN is useful for various optimizations
|
|
An association group based on VN is useful for various optimizations
|
| |
that should be applied by considering all the LSPs in the
|
|
that should be applied by considering all the LSPs in the
|
| |
association. This includes, but is not limited to -
|
|
association. This includes, but is not limited to -
|
| |
|
|
|
| |
* Path Computation: When computing a path for an LSP, it is useful
|
|
* Path Computation: When computing a path for an LSP, it is useful
|
| |
to analyze the impact of this LSP on the other LSPs belonging to
|
|
to analyze the impact of this LSP on the other LSPs belonging to
|
| |
the same VN. The aim would be optimize all LSPs belonging to the
|
|
the same VN. The aim would be to optimize all LSPs belonging to the
|
| |
VN rather than a single LSP. Also, the optimization criteria
|
|
VN rather than a single LSP. Also, the optimization criteria
|
| |
(such as minimizing the load of the most loaded link (MLL)
|
|
(such as minimizing the load of the most loaded link (MLL)
|
| |
[RFC5541]) could be applied for all the LSPs belonging to the VN
|
|
[RFC5541]) could be applied for all the LSPs belonging to the VN
|
| |
identified by the VN association.
|
|
identified by the VN association.
|
| |
|
|
|
| |
* Path Re-Optimization: The PCE would like to use advanced path
|
|
* Path Re-Optimization: The PCE would like to use advanced path
|
| |
computation algorithms and optimization techniques that consider
|
|
computation algorithms and optimization techniques that consider
|
| |
all the LSPs belonging to a VN, and optimize them all together
|
|
all the LSPs belonging to a VN, and optimize them all together
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
object. If an implementation encounters the VN Association Type
|
|
object. If an implementation encounters the VN Association Type
|
| |
(TBD1) in an Operator-Configured Association Range TLV, it MUST
|
|
(TBD1) in an Operator-Configured Association Range TLV, it MUST
|
| |
ignore the associated Start-Assoc-ID and Range values.
|
|
ignore the associated Start-Assoc-ID and Range values.
|
| |
|
|
|
| |
This association is useful in a PCEP session between a parent PCE
|
|
This association is useful in a PCEP session between a parent PCE
|
| |
(MDSC) and a child PCE (PNC). When computing the path, the child PCE
|
|
(MDSC) and a child PCE (PNC). When computing the path, the child PCE
|
| |
(PNC) refers to the VN association in the request from the parent PCE
|
|
(PNC) refers to the VN association in the request from the parent PCE
|
| |
(MDSC) and maps the VN to the associated LSPs and network resources.
|
|
(MDSC) and maps the VN to the associated LSPs and network resources.
|
| |
From the perspective of Parent PCE, it receives a virtual network
|
|
From the perspective of the Parent PCE, it receives a virtual network
|
| |
creation request by its customer, with the VN uniquely identified by
|
|
creation request by its customer, with the VN uniquely identified by
|
| |
an Association ID in VNAG as well as the Virtual Network identifier.
|
|
an Association ID in the VNAG as well as the Virtual Network identifier.
|
| |
|
|
jgs: in the preceding clause, do you mean that the VN is uniquely
|
| |
|
|
identified by either the Association ID or the VNI, or do you mean
|
| |
|
|
it's uniquely identified by the tuple (Association ID, VNI)? I think
|
| |
|
|
it's probably the latter, based on the defintion of the ASSOCIATION
|
| |
|
|
object in RFC 8697:
|
| |
|
|
Association ID (2 bytes): The identifier of the association group.
|
| |
|
|
When combined with other association parameters, such as an
|
| |
|
|
Association Type and Association Source, this value uniquely
|
| |
|
|
identifies an association group.
|
| |
|
|
Assuming that is right, perhaps rewrite like
|
| |
|
|
From the perspective of the Parent PCE, it receives a virtual network
|
| |
|
|
creation request by its customer, with the VN uniquely identified by
|
| |
|
|
the combination of the Association ID in the VNAG and the Virtual
|
| |
|
|
Network identifier.
|
| |
|
|
If that's wrong, let's discuss please.
|
| |
This VN may comprise multiple LSPs in the network in a single domain
|
|
This VN may comprise multiple LSPs in the network in a single domain
|
| |
or across multiple domains. Parent PCE sends a PCInitiate Message
|
|
or across multiple domains. The Parent PCE sends a PCInitiate Message
|
| |
with this association information in the VNAG Object. This in effect
|
|
with this association information in the VNAG Object. This in effect
|
| |
binds an LSP that is to be instantiated at the child PCE with the VN.
|
|
binds an LSP that is to be instantiated at the child PCE with the VN.
|
| |
The VN association information could be included as a part of the
|
|
The VN association information could be included as a part of the
|
| |
response as well. Figure 1 shows an example of a typical VN
|
|
response as well. Figure 1 shows an example of a typical VN
|
| |
|
|
jgs: Do I correctly infer that it would also be fine for the VN association
|
| |
|
|
information to *not* be included as part of the response? ("Could" implies
|
| |
|
|
"could not".)
|
| |
operation using PCEP. It is worth noting that in a multi-domain
|
|
operation using PCEP. It is worth noting that in a multi-domain
|
| |
scenario, the different domains are controlled by different child
|
|
scenario, the different domains are controlled by different child
|
| |
PCEs. In order to set up the cross-domain tunnel, multiple segments
|
|
PCEs. In order to set up the cross-domain tunnel, multiple segments
|
| |
need to be stitched, by the border nodes in each domain who receives
|
|
need to be stitched, by the border nodes in each domain who receive
|
| |
the instruction from their child PCE (PNC).
|
|
the instruction from their child PCE (PNC).
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
|DOMAIN 3 B|
|
|
|DOMAIN 3 B|
|
| |
+---------------+
|
|
+---------------+
|
| |
|
|
|
| |
MDSC -> Parent PCE
|
|
MDSC -> Parent PCE
|
| |
PNC -> Child PCE
|
|
PNC -> Child PCE
|
| |
MPI -> PCEP
|
|
MPI -> PCEP
|
| |
|
|
|
| |
Figure 1: Example of VN operations in H-PCE Architecture
|
|
Figure 1: Example of VN operations in H-PCE Architecture
|
| |
|
|
jgs: Figure 1 has a bunch of notations that are never referred to in the
|
| |
|
|
text. I'm guessing these were carried forward from some other use of the
|
| |
|
|
figure where they were actually referred to, but now they just create
|
| |
|
|
visual clutter and potential confusion. Things I flagged as not being
|
| |
|
|
referenced include: "with VNAG = 10", "A", "C", "B13", "B43", "B31",
|
| |
|
|
"B34", "B".
|
| |
|
|
I suggest either tidying the figure up, or expanding the explanation text
|
| |
|
|
to refer to the labels.
|
| |
|
|
|
| |
Whenever changes occur with the instantiated LSP in a domain network,
|
|
Whenever changes occur with the instantiated LSP in a domain network,
|
| |
the domain child PCE reports the changes using a PCRpt Message in
|
|
the domain child PCE reports the changes using a PCRpt Message in
|
| |
which the VNAG Object indicates the relationship between the LSP and
|
|
which the VNAG Object indicates the relationship between the LSP and
|
| |
the VN.
|
|
the VN.
|
| |
|
|
|
| |
Whenever an update occurs with VNs in the Parent PCE (via the
|
|
Whenever an update occurs with VNs in the Parent PCE (due to the
|
| |
customer's request), the parent PCE sends an PCUpd Message to inform
|
|
customer's request), the parent PCE sends an PCUpd Message to inform
|
| |
each affected child PCE of this change.
|
|
each affected child PCE of this change.
|
| |
|
|
|
| |
4. Extensions to PCEP
|
|
4. Extensions to PCEP
|
| |
|
|
|
| |
The format of VNAG is as per the ASSOCIATION object [RFC8697].
|
|
The format of VNAG is as per the ASSOCIATION object [RFC8697].
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
Type: TBD2 (to be allocated by IANA)
|
|
Type: TBD2 (to be allocated by IANA)
|
| |
|
|
|
| |
Length: Variable Length, which covers the value portion of the TLV.
|
|
Length: Variable Length, which covers the value portion of the TLV.
|
| |
|
|
|
| |
Virtual Network Identifier (variable): a symbolic name for the VN
|
|
Virtual Network Identifier (variable): a symbolic name for the VN
|
| |
that uniquely identifies the VN. It SHOULD be a string of printable
|
|
that uniquely identifies the VN. It SHOULD be a string of printable
|
| |
ASCII [RFC0020] characters (i.e., 0x20 to 0x7E), without a NULL
|
|
ASCII [RFC0020] characters (i.e., 0x20 to 0x7E), without a NULL
|
| |
terminator. The Virtual Network Identifier is a human-readable
|
|
terminator. The Virtual Network Identifier is a human-readable
|
| |
|
|
jgs: Is there an established practice in PCE of using US-ASCII as the
|
| |
|
|
character set for human-readable strings? This would seem to be a
|
| |
|
|
practice that's discouraged by BCP 18, BCP 166. Was this discussed in
|
| |
|
|
the WG and a decision taken to not use internationalized strings?
|
| |
string that identifies a VN and can be specified with the association
|
|
string that identifies a VN and can be specified with the association
|
| |
information. An implementation could use the Virtual Network
|
|
information. An implementation could use the Virtual Network
|
| |
Identifier to maintain a mapping to the VN association group and the
|
|
Identifier to maintain a mapping to the VN association group and the
|
| |
LSPs associated with the VN. The Virtual Network Identifier MAY be
|
|
LSPs associated with the VN. The Virtual Network Identifier MAY be
|
| |
specified by the customer or set via an operator policy or auto-
|
|
specified by the customer or set via an operator policy or auto-
|
| |
generated by the PCEP speaker.
|
|
generated by the PCEP speaker.
|
| |
|
|
jgs: At the top of the page you say it's a "mandatory TLV", but then in
|
| |
|
|
the paragraph right above you say it "can be" specified and an
|
| |
|
|
implementation "could" use it. "Can" and "could" don't imply "mandatory"
|
| |
|
|
in the normal English sense. Does "mandatory" have some special meaning
|
| |
|
|
in the context of PCE, is there some other explanation for this
|
| |
|
|
discrepancy, ... ?
|
| |
|
|
|
| |
The VIRTUAL-NETWORK-TLV MUST be included in VNAG object. If a PCEP
|
|
The VIRTUAL-NETWORK-TLV MUST be included in VNAG object. If a PCEP
|
| |
speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it
|
|
speaker receives the VNAG object without the VIRTUAL-NETWORK-TLV, it
|
| |
MUST send a PCErr message with Error-Type=6 (mandatory object
|
|
MUST send a PCErr message with Error-Type=6 (mandatory object
|
| |
missing) and Error-Value=TBD3 (VIRTUAL-NETWORK-TLV missing) and close
|
|
missing) and Error-Value=TBD3 (VIRTUAL-NETWORK-TLV missing) and close
|
| |
the session.
|
|
the session.
|
| |
|
|
|
| |
The format of VENDOR-INFORMATION-TLV is defined in [RFC7470].
|
|
The format of VENDOR-INFORMATION-TLV is defined in [RFC7470].
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
|
|
|
| |
6. Security Considerations
|
|
6. Security Considerations
|
| |
|
|
|
| |
This document defines one new type for association, which do not add
|
|
This document defines one new type for association, which does not add
|
| |
any new security concerns beyond those discussed in [RFC5440],
|
|
any new security concerns beyond those discussed in [RFC5440],
|
| |
[RFC8231] and [RFC8697] in itself.
|
|
[RFC8231] and [RFC8697] in itself.
|
| |
|
|
|
| |
Some deployments may find the Virtual Network Identifier and the VN
|
|
Some deployments may find the Virtual Network Identifier and the VN
|
| |
associations as extra sensitive; and thus should employ suitable PCEP
|
|
associations as extra sensitive; and thus should employ suitable PCEP
|
| |
security mechanisms like TCP-AO [RFC5925] or TLS [RFC8253].
|
|
security mechanisms like TCP-AO [RFC5925] or TLS [RFC8253].
|
| |
|
|
jgs: I have a few problems with the paragraph above. First, by "extra
|
| |
|
|
sensitive" do you mean "confidential"? If so, use that term or one like
|
| |
|
|
it, but in any case "extra sensitive" isn't specific enough.
|
| |
|
|
Second, assuming you do mean "confidential", TCP-AO isn't a suitable
|
| |
|
|
mitigation: AO doesn't provide confidentiality, only authentication.
|
| |
|
|
|
| |
7. IANA Considerations
|
|
7. IANA Considerations
|
| |
|
|
|
| |
7.1. Association Object Type Indicator
|
|
7.1. Association Object Type Indicator
|
| |
|
|
|
| |
IANA is requested to make the assignment of a new value for the sub-
|
|
IANA is requested to make the assignment of a new value in the sub-
|
| |
registry "ASSOCIATION Type Field" (request to be created in
|
|
registry "ASSOCIATION Type Field"
|
| |
[RFC8697]) within the "Path Computation Element Protocol (PCEP)
|
|
within the "Path Computation Element Protocol (PCEP)
|
| |
Numbers" registry, as follows:
|
|
Numbers" registry, as follows:
|
| |
|
|
|
| |
Value Name Reference
|
|
Value Name Reference
|
| |
|
|
|
| |
TBD1 VN Association Type [This I.D.]
|
|
TBD1 VN Association Type [This I.D.]
|
| |
|
|
|
| |
7.2. PCEP TLV Type Indicator
|
|
7.2. PCEP TLV Type Indicator
|
| |
|
|
|
| |
|
|
|
|
Skipping
|
|
Skipping
|
| |
8.5. Requirements On Other Protocols
|
|
8.5. Requirements On Other Protocols
|
| |
|
|
|
| |
Mechanisms defined in this document do not imply any new requirements
|
|
Mechanisms defined in this document do not imply any new requirements
|
| |
on other protocols.
|
|
on other protocols.
|
| |
|
|
|
| |
8.6. Impact On Network Operations
|
|
8.6. Impact On Network Operations
|
| |
|
|
|
| |
[RFC8637] describe the network operations when PCE is used for VN
|
|
[RFC8637] describe the network operations when PCE is used for VN
|
| |
operations. Section 3 further specify the operations when VN
|
|
operations. Section 3 further specifies the operations when VN
|
| |
associations is used.
|
|
associations are used.
|
| |
|
|
|
| |
9. References
|
|
9. References
|
| |
|
|
|
| |
9.1. Normative References
|
|
9.1. Normative References
|
| |
|
|
|
| |
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
|
|
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
|
| |
RFC 20, DOI 10.17487/RFC0020, October 1969,
|
|
RFC 20, DOI 10.17487/RFC0020, October 1969,
|
| |
<https://www.rfc-editor.org/info/rfc20>.
|
|
<https://www.rfc-editor.org/info/rfc20>.
|
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
