Subject: [Pce] 答复: WGLC for draft-ietf-pce-vn-association-05

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Thu, 10 Mar 2022 07:11:31 +0000

I have read the latest version of the draft and support the WGLC.

Cheng

发件人: Pce [mailto:[email-masked]] 代表 Dhruv Dhody
发送时间: 2022年2月22日 20:18
收件人: [email-masked]
抄送: [email-masked]; pce-chairs <[email-masked]>
主题: [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/

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 14 Mar 2022 16:28:37 +0800

Hi, WG:

I have read this draft and support its publication with the following suggestions from Adrian Farrel.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Adrian Farrel
Sent: Saturday, February 26, 2022 4:39 PM
To: 'Dhruv Dhody' <[email-masked]>; [email-masked]
Cc: [email-masked]; 'pce-chairs' <[email-masked]>
Subject: 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.

---

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

Thanks,
Dhruv & Julien

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 14 Mar 2022 14:09:38 +0530

Hi WG,

The WGLC ends on Wednesday 16th March. The I-D is NOT long, please
review/respond to the list.

Thanks!
Dhruv

On Tue, Feb 22, 2022 at 6:02 PM Dhruv Dhody <[email-masked]> wrote:

> Looks like the chairs had a "collision" in sending out the WGLC notice!
> Apologies! :)
>
> The only parameter that was different was when the WGLC ends, and let's
> pick the larger of the two dates i.e.  WGLC will end on March 16, 2022.
>
> Thanks!
> Dhruv
>
>
> On Tue, Feb 22, 2022 at 5:48 PM Dhruv Dhody <[email-masked]> wrote:
>
>> 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.
>>
>> A general reminder to the WG to be more vocal during the
>> last-call/adoption and help us unclog our queues :)
>>
>> Thanks,
>> Dhruv & Julien
>>

---

From: "Ramon Casellas" <[email-masked]>
Date: Mon, 14 Mar 2022 10:01:32 +0100

Dear all,

I read the draft and I think it’s ready for publication. 

My only minor comment is that I was confused by the sentence “This document defines one mandatory TLV "VIRTUAL-NETWORK-TLV" and one

   new optional TLV "VENDOR-INFORMATION-TLV”. Later on , the reference to  RFC7470 is provided.

I believe the intent is to state that the latter can be used (optional) but no further guidelines are given in this regard. It is slightly redundant but  it does not hurt I guess.

Alternatively, it would be beneficial to state what other information can be provided in the VENDOR-INFORMATION-TLV (my personal opinion is to try to avoid those)

Regards

Ramon

 

 

From: Pce <[email-masked]> On Behalf Of Dhruv Dhody
Sent: lunes, 14 de marzo de 2022 9:40
To: [email-masked]
Cc: [email-masked]; pce-chairs <[email-masked]>
Subject: Re: [Pce] WGLC for draft-ietf-pce-vn-association-05

Hi WG, 

The WGLC ends on Wednesday 16th March. The I-D is NOT long, please review/respond to the list. 

Thanks! 

Dhruv

On Tue, Feb 22, 2022 at 6:02 PM Dhruv Dhody <[email-masked] <mailto:[email-masked]> > wrote:

Looks like the chairs had a "collision" in sending out the WGLC notice! Apologies! :) 

The only parameter that was different was when the WGLC ends, and let's pick the larger of the two dates i.e.  WGLC will end on March 16, 2022.

Thanks! 

Dhruv

On Tue, Feb 22, 2022 at 5:48 PM Dhruv Dhody <[email-masked] <mailto:[email-masked]> > wrote:

Hi WG,

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

Thanks,
Dhruv & Julien

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

---

From: Aihua Guo <[email-masked]>
Date: Tue, 15 Mar 2022 23:02:20 -0400

Hi WG,

I have read the draft and I support the publication of this draft.

Thanks,
Aihua

On Tue, Feb 22, 2022 at 7:19 AM Dhruv Dhody <[email-masked]> wrote:

> 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.
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>

---

From: "Ricard Vilalta" <[email-masked]>
Date: Wed, 16 Mar 2022 07:10:09 +0100

Hi WG,

Thanks,

Ricard

-- 

Ricard Vilalta

Senior Researcher

[email-masked]

Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)

Av. Carl Friedrich Gauss, 7 - Building B4

08860 - Castelldefels

Tel.: +34 93 645 29 00

DATA PROTECTION INFORMATION. Data controller: CENTRE TECNOLOGIC DE TELECOMUNICACIONS DE CATALUNYA (G62616586):

We inform you that your identification data and the data contained in the emails and attached files can be incorporated into our databases, in order to maintain professional and / or commercial relationships, and that it will be preserved throughout the relationship. According to the current regulations, you can exercise your right to access, rectification, erasure, restriction of processing, to portability and to object by sending an email to [email-masked].

This message and any attached document, where appropriate, may be confidential and intended for the original recipient only.

Before printing this e-mail or attachments, be sure it is necessary. It is in our hands to protect the environment.

De: Pce <[email-masked]> En nom de Aihua Guo
Enviat: miércoles, 16 de marzo de 2022 4:02
Per a: Dhruv Dhody <[email-masked]>
A/c: [email-masked]; [email-masked]; pce-chairs <[email-masked]>
Tema: Re: [Pce] WGLC for draft-ietf-pce-vn-association-05

Hi WG,

Thanks,

Aihua

On Tue, Feb 22, 2022 at 7:19 AM Dhruv Dhody <[email-masked] <mailto:[email-masked]> > wrote:

Hi WG,

Thanks,
Dhruv & Julien

_______________________________________________
Pce mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/pce

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 16 Mar 2022 23:50:35 -0400

Dear WG

I read the draft and support publication.

This document specifies a PCEP extension to associate a set of LSPs to a
newly defined VN association Group (VNAG).

Dear Authors,

Does this draft update RFC 8697 or any other PCEP RFC?

Thanks

Gyan

On Wed, Mar 16, 2022 at 2:10 AM Ricard Vilalta <[email-masked]>
wrote:

> <https://www.google.com/maps/search/Av.+Carl+Friedrich+Gauss,+7+-+Building+B4+08860+-+Castelldefels?entry=gmail&source=g>
>
> 08860 - Castelldefels
> <https://www.google.com/maps/search/Av.+Carl+Friedrich+Gauss,+7+-+Building+B4+08860+-+Castelldefels?entry=gmail&source=g>
>
> Tel.: +34 93 645 29 00
>
>
>
> DATA PROTECTION INFORMATION. Data controller: CENTRE TECNOLOGIC DE
> TELECOMUNICACIONS DE CATALUNYA (G62616586):
>
>
>
> We inform you that your identification data and the data contained in the
> emails and attached files can be incorporated into our databases, in order
> to maintain professional and / or commercial relationships, and that it
> will be preserved throughout the relationship. According to the current
> regulations, you can exercise your right to access, rectification, erasure,
> restriction of processing, to portability and to object by sending an email
> to [email-masked].
>
> This message and any attached document, where appropriate, may be
> confidential and intended for the original recipient only.
>
>
>
> Before printing this e-mail or attachments, be sure it is necessary. It
> is in our hands to protect the environment.
>
>
>
> *De:* Pce <[email-masked]> *En nom de *Aihua Guo
> *Enviat:* miércoles, 16 de marzo de 2022 4:02
> *Per a:* Dhruv Dhody <[email-masked]>
> *A/c:* [email-masked]; [email-masked]; pce-chairs <
> [email-masked]>
> *Tema:* Re: [Pce] WGLC for draft-ietf-pce-vn-association-05
>
>
>
> Hi WG,
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 17 Mar 2022 10:49:50 +0530

Hi Adrian, WG,

Just one point and starting a new thread ->

> How does internationalization work for the Virtual Network Name?

In the past, we had limited to ASCII, see SYMBOLIC-PATH-NAME TLV (RFC
8231).

I see a recent discussion (but not sure if it is resolved yet) for the
spring SR policy draft related to the same topic -
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ballot/
(search for ASCII)

I think it is wise for PCE WG to think more about this -
- Do we continue to use ASCII only
- Do we define strings as UTF-8 from now on and leave the old ones as ASCII
- Do we make sure older names can be encoded in UTF-8 by defining a new TLV
or some other technique?

Thoughts?

Thanks!
Dhruv

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

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 17 Mar 2022 10:50:01 +0530

Hi Ramon,

On Mon, Mar 14, 2022 at 2:31 PM Ramon Casellas <[email-masked]>
wrote:

> My only minor comment is that I was confused by the sentence “This
> document defines one mandatory TLV "VIRTUAL-NETWORK-TLV" and one
>
> I believe the intent is to state that the latter can be used (optional)
> but no further guidelines are given in this regard. It is slightly
> redundant but  it does not hurt I guess.
>
> Alternatively, it would be beneficial to state what other information can
> be provided in the VENDOR-INFORMATION-TLV (my personal opinion is to try to
> avoid those)
>
>
>

I think this could be more clearly stated as -

OLD

   o  VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor
      specific behavioral information, described in [RFC7470].

NEW
  This document defines one new mandatory TLV "VIRTUAL-NETWORK-TLV";
   apart from this TLV, the existing VENDOR-INFORMATION-TLV [RFC7470]
   can be optionally used as described below:

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

   o  VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor
      specific behavioral information, described in [RFC7470].
END

The VIRTUAL-NETWORK-TLV is used for VN Name only and any other
vendor-specific info goes in VENDOR-INFORMATION-TLV. Does this work for
you?

Thanks!
Dhruv

> *Sent:* lunes, 14 de marzo de 2022 9:40
> *To:* [email-masked]
> *Subject:* Re: [Pce] WGLC for draft-ietf-pce-vn-association-05
>
>
>
> Hi WG,
>
>
>

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 17 Mar 2022 10:50:09 +0530

Hi Gyan,

> Does this draft update RFC 8697 or any other PCEP RFC?
As the author of RFC 8697, I don't think a PCEP extension defining a new
association type needs to update RFC 8697. The idea of RFC 8697 was to
define just the object and let future extensions define association types
as done by RFC  8745, 8800, 9005, 9059 (none of them update RFC 8697).

Thanks!
Dhruv

---

From: "Ramon Casellas" <[email-masked]>
Date: Thu, 17 Mar 2022 07:25:03 +0100

From: Dhruv Dhody <[email-masked]> 

Hi Ramon,

OLD

NEW

END        

The VIRTUAL-NETWORK-TLV is used for VN Name only and any other vendor-specific info goes in VENDOR-INFORMATION-TLV. Does this work for you? 

Hi Dhruv, all

Almost there :) -- I also noticed that you also changed Identifier -> Name, I guess that’s from another comment –

IMHO,  

*	now the text seems to say: “the existing tlv can be used  as described below : “ and one of the two bullets still relates to the new VN_TLV. Maybe adding a “jointly”
*	the two references to RFC7470 are IMHO slightly redundant

NEW NEW  OPTION 1 

   This document defines one new mandatory TLV "VIRTUAL-NETWORK-TLV”.
   Optionally, the new TLV can be jointly used with the existing 

   VENDOR-INFORMATION-TLV [RFC7470] as described below:

END        

(the “, described in [RFC7470].” could be suppressed)

Personally, I would simplify it as follows:

NEW NEW OPTION 2

  This document defines one new mandatory TLV "VIRTUAL-NETWORK-TLV", 
  used to communicate the VN Name. Note that the existing VENDOR-INFORMATION-TLV 

  can be optionally used to communicate arbitrary vendor specific behavioral 

  information, as described in [RFC7470].

END        

That said, it is quite minor, the point was avoiding the confusion that the draft defined the vendor tlv, I am ok with any wording

Thanks and best regards

Ramon

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 17 Mar 2022 12:18:16 +0530

Hi Ramon,

That works too, I would let the editors take the final call.

Thanks!
Dhruv

On Thu, Mar 17, 2022 at 11:55 AM Ramon Casellas <[email-masked]>
wrote:

>
>
>
>
> *From:* Dhruv Dhody <[email-masked]>
>
>
>
> Hi Ramon,
>
>
>
> Almost there :) -- I also noticed that you also changed Identifier ->
> Name, I guess that’s from another comment –
>
>
>
> IMHO,
>
>    - now the text seems to say: “the existing tlv can be used  as
>    described below : “ and one of the two bullets still relates to the new
>    VN_TLV. Maybe adding a “jointly”
>    - the two references to RFC7470 are IMHO slightly redundant
>
>
>
> NEW NEW  OPTION 1
>
> That said, it is quite minor, the point was avoiding the confusion that
> the draft defined the vendor tlv, I am ok with any wording
>
>
>
> Thanks and best regards
>
> Ramon

---

From: <[email-masked]>
Date: Thu, 17 Mar 2022 16:24:25 +0800 (CST)

Hi WG,

I read the draft and support publication.2022-03-17

Best Regards,
Ran
-----------------------------------------------------------------------------------------------------------
On Tue, Feb 22, 2022 at 7:19 AM Dhruv Dhody <[email-masked]> wrote:
Hi WG,

This email starts a 3-weeks working group last call for draft-ietf-pce-vn-association-05 [1] to accommodate the upcoming draft submission deadline.

Thanks,
Dhruv & Julien

Gyan Mishra
Network Solutions Architect
Email [email-masked]
M 301 502-1347

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 17 Mar 2022 19:18:39 -0000

Hi Dhruv,

I agree: this is a wider issue than just this draft. And I think it was discussed way back for some early part of the PCEP work, but I really can’t recall how or what the conclusions were.

The IETF has a Directorate for Internationalisation (https://datatracker.ietf.org/group/i18ndir/about/) and they should be able to help. Once upon a time I would have said, “Let’s meet up with a couple of them over coffee at the IETF and see if we can understand the problem space and scope. But we have a new normal, so probably the thing to do is ask the Directorate if they could supply one or two people to work with us on this and then set up a call after the IETF and after we have all got over the zoom-lag. 

At the moment I don’t even know what questions we should be asking each other!

A first step might be to collect all of the free-form text strings currently in PCEP and list out how they are used. Then we can have a starting point for a conversation.

Cheers,

Adrian

From: Dhruv Dhody <[email-masked]> 
Sent: 17 March 2022 05:20
To: Adrian Farrel <[email-masked]>
Cc: [email-masked]; [email-masked]; pce-chairs <[email-masked]>
Subject: ASCII in PCEP (WAS - Re: [Pce] WGLC for draft-ietf-pce-vn-association-05)

Hi Adrian, WG,

 

4.

Why is ASCII acceptable?

---

In the past, we had limited to ASCII, see SYMBOLIC-PATH-NAME TLV (RFC 8231). 

I see a recent discussion (but not sure if it is resolved yet) for the spring SR policy draft related to the same topic -  https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ballot/ (search for ASCII)

- Do we make sure older names can be encoded in UTF-8 by defining a new TLV or some other technique? 

Thoughts? 

Thanks! 

Dhruv

Hi WG,

Thanks,
Dhruv & Julien

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 18 Mar 2022 11:03:43 +0530

Hi,

A quick glance in all our RFC and WG I-Ds, there are not many strings in
PCEP, I found -

Strings in PCEP

This page documents all the strings in the published RFCs as well as WG
documents. The aim is to further decide if they need to be converted to
UTF-8 to allow Internationalisation
<https://datatracker.ietf.org/group/i18ndir/about/>
DocumentObject/TLVFormatRemarks
RFC8231 <https://datatracker.ietf.org/doc/html/rfc8231> SYMBOLIC-PATH-NAME
TLV printable ASCII
draft-ietf-pce-vn-association
<https://datatracker.ietf.org/doc/draft-ietf-pce-vn-association/>
VIRTUAL-NETWORK-TLV printable ASCII
draft-ietf-pce-segment-routing-policy-cp
<https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/>
SRPOLICY-POL-NAME
TLV, SRPOLICY-CPATH-NAME TLV printable ASCII This needs to be as per
draft-ietf-spring-segment-routing-policy
<https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/>

Maintained at - https://notes.ietf.org/strings-in-pcep?view ; feel free to
add if I missed something!

Regards,
Dhruv

On Fri, Mar 18, 2022 at 12:48 AM Adrian Farrel <[email-masked]> wrote:

> Hi Dhruv,
>
>
>
> I agree: this is a wider issue than just this draft. And I think it was
> discussed way back for some early part of the PCEP work, but I really can’t
> recall how or what the conclusions were.
>
>
>
> The IETF has a Directorate for Internationalisation (
> https://datatracker.ietf.org/group/i18ndir/about/) and they should be
> able to help. Once upon a time I would have said, “Let’s meet up with a
> couple of them over coffee at the IETF and see if we can understand the
> problem space and scope. But we have a new normal, so probably the thing to
> do is ask the Directorate if they could supply one or two people to work
> with us on this and then set up a call after the IETF and after we have all
> got over the zoom-lag.
>
>
>
> A first step might be to collect all of the free-form text strings
> currently in PCEP and list out how they are used. Then we can have a
> starting point for a conversation.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *Sent:* 17 March 2022 05:20
> *To:* Adrian Farrel <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; pce-chairs <
> [email-masked]>
> *Subject:* ASCII in PCEP (WAS - Re: [Pce] WGLC for
> draft-ietf-pce-vn-association-05)
>
>
>
> Hi Adrian, WG,
>
>
>

---

From: Ketan Talaulikar <[email-masked]>
Date: Fri, 18 Mar 2022 11:26:25 +0530

Hi Dhruv/Adrian,

As someone who was involved in this debate recently with the IESG, I would
like to share my input on this topic.

I am in favor of internationalization. From an implementor's perspective,
the key is that we bring this early in the document lifecycle - ideally WG
adoption or whenever a new TLV is introduced. Making changes later once we
have implementations shipping/deployed can be problematic - especially for
"on-the-wire" parts. I would urge caution in changing these things "late"
in the document cycle.

Thanks,
Ketan

On Fri, Mar 18, 2022 at 11:05 AM Dhruv Dhody <[email-masked]> wrote:

> <https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/> SRPOLICY-POL-NAME
> Maintained at - https://notes.ietf.org/strings-in-pcep?view ; feel free
> to add if I missed something!
>
> Regards,
> Dhruv
>

---

From: Ketan Talaulikar <[email-masked]>
Date: Fri, 18 Mar 2022 11:27:15 +0530

Just to add ... another checkpoint would be codepoint allocation.

Thanks,
Ketan

---

From: <[email-masked]>
Date: Fri, 18 Mar 2022 15:06:10 +0100

Hi all,

This LC has ended. Thanks to all the reviewers for sharing their
feedback.

@Authors: please, address the received comments and update the I-D
accordingly.

Cheers,

Dhruv & Julien

On 22/02/2022 13:32, Dhruv Dhody wrote:

Looks like
the chairs had a "collision" in sending out the WGLC
notice! Apologies! :)

The only parameter that was
different was when the WGLC ends, and let's pick the
larger of the two dates i.e.  WGLC will end on March 16,
2022.

Thanks!

Dhruv

On Tue, Feb 22, 2022 at 5:48
PM Dhruv Dhody <[email-masked]> wrote:

Hi WG,

This email starts a 3-weeks working group last call for
draft-ietf-pce-vn-association-05 [1] 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.

Thanks,

Dhruv & Julien

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 18 Mar 2022 13:10:26 -0400

Hi Dhruv

Makes sense.

Thanks

Gyan

On Thu, Mar 17, 2022 at 1:20 AM Dhruv Dhody <[email-masked]> wrote:

>>> We inform you that your identification data and the data contained in
>>> the emails and attached files can be incorporated into our databases, in
>>> order to maintain professional and / or commercial relationships, and that
>>> it will be preserved throughout the relationship. According to the current
>>> *A/c:* [email-masked]; [email-masked]; pce-chairs
>>> <[email-masked]>

*Gyan Mishra*

*M 301 502-1347*