[Pce] Draft -06 available with most WG LC comments addressed//was: WGLC for draft-ietf-pce-vn-association-05

[Zhenghaomian <[e-mail]>]

Hi Adrian, All,

Thank you all for the WG LC comments, and we have addressed most of the comments fixed. Given the quite big changes we update the draft to -06 and you are welcome to review again.

Some of the explanation on the revision can be also found inline.

Best wishes,
Haomian (on behalf of all authors & contributors)



发件人: Adrian Farrel [mailto:[e-mail]]
发送时间: 2022年2月26日 16:39
收件人: 'Dhruv Dhody' <[e-mail]>; [e-mail]
抄送: [e-mail]; 'pce-chairs' <[e-mail]>
主题: RE: [Pce] WGLC for draft-ietf-pce-vn-association-05

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.
[Haomian] changed to ‘cross-domain tunnel’.
---

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

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

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

[Haomian] done.
---

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

[Haomian] changed to Virtual Network Identifier in all section 4.
---

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.
[Haomian]  propose as follow:

OLD:
Length: Variable Length

NEW:
Length: Variable Length, which covers all the Virtual Network Identifiers.

END

BTW, is it a MUST to have a maximum value?
---

4.

How does internationalization work for the Virtual Network Name?
Why is ASCII acceptable?
[Haomian] not changed, looking for future advice. My personal taking is ‘all ASCII should find the same processing rule for internationalization’.

---

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.
[Haomian]  propose as follow:
OLD:
Virtual Network Name (variable): an unique symbolic name for the VN.
NEW:
Virtual Network Identifier (variable): an symbolic name for the VN that is unique in this TLV.
END
---

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.
[Haomian] Tried to break the current text, moving the useful text into other sections, and removing duplication.
---

9.6

I think the whole point of this document is to change network operations
[Haomian] not quite sure on ‘how big the operation is changed.’ I am trying to propose as follow:
OLD:
Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440].
NEW:
Besides the network operation mechanism specified in [RFC5440], mechanisms defined in this document change the network operations as described in section 3. .
END

---
[Haomian] All the following nits are fixed.
==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
[Haomian] This part is further improved in other WG LC comments. And the option 1 from Ramon is used now, see https://mailarchive.ietf.org/arch/msg/pce/cWKcwMhhNGIyUgXQYmwsWkSzd94/ .

---

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]<mailto:[e-mail]>> On Behalf Of Dhruv Dhody
Sent: 22 February 2022 12:18
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; pce-chairs <[e-mail]<mailto:[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/