Re: [Pce] WGLC for draft-ietf-pce-vn-association-05

[Adrian Farrel <[e-mail]>]

Hi,

 

Here is my review of draft-ietf-pce-vn-association-05 as part of the WG

last call.

 

I think the document is technically ready to proceed, but it needs quite

a bit of work to polish the text. After the number of edits I am 

proposing I feel like I have rewritten the document!

 

My comments are below.

 

Thanks,

Adrian

 

==Minor==

 

3.

 

   In order to set up the end-to-end tunnel, multiple segments need to

   be stitched, by the border nodes in each domain who receives the

   instruction from their child PCE (PNC).

 

What end-to-end tunnel? This has not been mentioned before and I can't 

see one in the figure.

 

---

 

3.

 

   Local polices on the PCE MAY define the computational and

   optimization behavior for the LSPs in the VN.

 

Why is this "MAY"? Isn't it good enough to write:

 

   Local polices on the PCE define the computational and

   optimization behavior for the LSPs in the VN.

 

---

 

3.

 

   If an implementation encounters more than one

   VNAG, it MUST consider the first occurrence and ignore the others.

 

I think...

 

   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.

 

---

 

3.

 

   Operator-configured Association Range MUST NOT be set for this

   association-type and MUST be ignored.

 

I know what you are trying to say, but you have crossed the line into

describing implementations.

 

Perhaps

OLD

   This Association-Type is dynamic in nature and created by the Parent

   PCE (MDSC) for the LSPs belonging to the same VN or customer.  These

   associations are conveyed via PCEP messages to the PCEP peer.

   Operator-configured Association Range MUST NOT be set for this

   association-type and MUST be ignored.

NEW

   The Association IDs (VNAG IDs) for this Association Type are dynamic

   in nature and created by the Parent PCE (MDSC) for the LSPs belonging

   to the same VN or customer.  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 in an Operator-Configured

   Association Range TLV, it MUST ignore the associated Start-Assoc-ID

   and Range values.

END

 

---

 

4.

 

   o  VIRTUAL-NETWORK-TLV: Used to communicate the VN Identifier.

 

It is confusing that you say VN Identifier (which sounds like VNAG

identifier), but then the text and figure shows "VN name" or "Virtual

Network Name". You need to:

- select Identifier or Name

- select VN or Virtual Network

 

---

 

4. (for VIRTUAL-NETWORK-TLV)

 

   Length: Variable Length

 

Length of what and in what units?

Just the Virtual Network Name or the whole TLV?

Probably in octets.

What is the maximum allowed value? Surely not 2^16.

 

---

 

4.

 

How does internationalization work for the Virtual Network Name?

Why is ASCII acceptable?

 

---

 

4.

 

Does the Virtual Network Name need to be unique across all VNAGs? I

suspect that it doesn't because its use is basically out of scope of

this work.

 

---

 

Does section 5 add anything to the document? There has already been

discussion of parent and child PCEs and a lot of the material in this

section is a direct quote from elsewhere in the document.

 

I would suggest a very hard look to see whether anything needs to be

retained or the whole section can be removed.

 

---

 

9.6

 

I think the whole point of this document is to change network operations

 

---

 

==Nits==

 

LSP is going to need to be expanded on first use in each of:

- the document title

- the abstract

- section 1

 

---

 

Abstract

 

s/extend/extend the/

 

s/virtual network control/control of virtual networks/

 

s/using PCE/using the PCE/

 

---

 

1. para 1

 

Should include a reference to RFC 5440

 

 

OLD

   computations in response to Path Computation Clients' (PCCs)

   requests.

NEW

   computations in response to requests from Path Computation Clients

   (PCCs).

END

 

---

 

1.

 

OLD

   A stateful PCE has access to not only the information

   carried by the network's Interior Gateway Protocol (IGP), but also

   the set of active paths and their reserved resources for its

   computations.

NEW

   For its computations, a stateful PCE has access to not only the

   information carried by the network's Interior Gateway Protocol (IGP),

   but also the set of active paths and their reserved resources.

END

 

---

 

1.

 

s/to define association/to define associations/

 

---

 

ACTN needs to be expanded on first use.

 

---

 

1.

 

The last three paragraphs seem to introduce material in the wrong order.

I think you need four paragraphs:

 

- 8453, introduce ACTN and VN. Include the explanation of VN and 

  customer from the final paragraph

- 8637 paragraph as is

- Remainder of the text from the first para on the need (starting at

  "In this context..."). 

- The statement of what this document is.

 

So, something like (with nit fixes)...

 

   [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].

   

   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 Virtual Network (VN) (or customer).  

 

---

 

3.

 

s/but not limited/but is not limited/

 

OLD

   o  Path Computation: When computing path for a LSP, the impact of

      this LSP, on the other LSPs belonging to the same VN is useful to

      analyze.  The aim would be optimize overall VN and all LSPs,

      rather than a single LSP.  Also, the optimization criteria such as

      minimize the load of the most loaded link (MLL) [RFC5541] and

      other could be applied for all the LSP belonging to the same VN,

      identified by the VN association.

NEW

   o  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

      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.

END

 

---

 

3.

 

OLD

   o  Path Re-Optimization: The child PCE or the parent PCE would like

      to use advanced path computation algorithm and optimization

      technique that consider all the LSPs belonging to a VN/customer

      and optimize them all together during the re-optimization.

NEW

   o  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/customer, and optimize them all

      together during the path re-optimization.

END

 

---

 

3.

 

OLD

   This association is useful in PCEP session between parent PCE (MDSC)

   and child PCE (PNC).

NEW

   This association is also useful in a PCEP session between a parent 

   PCE (MDSC) and a child PCE (PNC).

END

 

s/refer/refers/

s/and the network resources/and network resources/

s/operator policy and/operator policy, and/

s/replied/returned/

s/part of response/part of the response/

 

---

 

3.

 

OLD

   The figure describes a typical VN operations using PCEP for

   illustration purpose.

NEW

   Figure 1 shows an example of a typical VN operation using PCEP.

END

 

---

 

3.

 

s/the different domain is/the different domains are

 

---

 

3.

 

The figure needs a number and a title. This will (of course) mean that

figure numbering in the rest of the document is out by one.

 

---

 

3.

 

The text after the figure is not specific to the figure, but makes it a

lot easier to understand (for example, what is a VNAG in the figure?).

Perhaps you should move that text up above the figure and above the 

reference to the figure.

 

---

 

3. 

 

OLD

   In this draft, this grouping is used to define associations between a

   set of LSPs and a virtual network, a new association group is defined

   below -

 

   o  VN Association Group (VNAG)

 

   One new Association type is defined as described in the Association

   object -

 

   o  Association type = TBD1 ("VN Association") for VNAG

 

   The scope and handling of VNAG identifier is similar to the generic

   association identifier defined in [RFC8697] .

 

   In this document VNAG object refers to an Association Object with the

   Association type set to "VNAG".

NEW

   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".

END

 

---

 

3.

 

OLD

   [RFC8697] specify the mechanism for the capability advertisement of

   the association types supported by a PCEP speaker by defining a

   ASSOC-Type-List TLV to be carried within an OPEN object.  This

   capability exchange for the association type described in this

   document (i.e.  VN Association Type) MUST be done before using the

   policy association.  Thus the PCEP speaker MUST include the VN

   Association Type (TBD1) in the ASSOC-Type-List TLV before using the

   VNAG in the PCEP messages.

NEW

   [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.

END

 

---

 

3.

 

s/Association-Type/Association Type/

 

---

 

4.

 

s/The format of VNAG/The format of VNAG object/

 

---

 

4.

 

To avoid duplication with what follows...

 

OLD

   This document defines one mandatory TLV "VIRTUAL-NETWORK-TLV" and one

   new optional TLV "VENDOR-INFORMATION-TLV"; apart from this TLV,

   VENDOR-INFORMATION-TLV can be used to carry arbitrary vendor specific

   information.

NEW

   This document defines one mandatory TLV "VIRTUAL-NETWORK-TLV" and one

   new optional TLV "VENDOR-INFORMATION-TLV".

END

 

---

 

4.

 

s/an unique/a unique/

 

---

 

4.

 

s/in VNAG object.If/in a VNAG object.  If/

 

---

 

5.

 

OLD

5.  Applicability to H-PCE architecture

NEW

5.  Applicability to H-PCE Architecture

END

 

---

 

8.1

 

   This document defines a new association type, originally defined in

   [RFC8697], for path protection.

 

This is confusing text and can be safely deleted.

 

---

 

8.2

 

   This document defines a new TLV for carrying additional information

   of LSPs within a path protection association group.

 

This is plain wrong!

 

Just delete it.

 

---

 

8.3

 

   This document defines new Error-Type and Error-Value related to path

   protection association.

 

This, too, is wrong.

 

Just delete it.

 

---

 

8.3

 

s/new error values/new error value/

 

---

 

9.1

 

s/MUST BE/must be/

 

From: Pce <[e-mail]> On Behalf Of Dhruv Dhody
Sent: 22 February 2022 12:18
To: [e-mail]
Cc: [e-mail]; pce-chairs <[e-mail]>
Subject: [Pce] WGLC for draft-ietf-pce-vn-association-05

 

Hi WG,

This email starts a 3-weeks working group last call for draft-ietf-pce-vn-association-05 [1 <https://datatracker.ietf.org/doc/draft-ietf-pce-vn-association/> ] to accommodate the upcoming draft submission deadline.  

Please indicate your support or concern for this draft. If you are opposed to the progression of the draft to RFC, please articulate your concern. If you support it, please indicate that you have read the latest version and it is ready for publication in your opinion. As always, review comments and nits are most welcome. 

The WG LC will end on Tuesday 15th March 2022.

A general reminder to the WG to be more vocal during the last-call/adoption and help us unclog our queues :)  

Thanks,
Dhruv & Julien

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-vn-association/