Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03

[Jeff Tantsura]

+1

Regards,
Jeff

> On Feb 22, 2021, at 14:13, Stone, Andrew (Nokia - CA/Ottawa) 
>  wrote:
> 
> +1 thanks Julien, also support the document. 
> 
> Did not recognize that binding label and path segment we're requesting bits 
> as well. Seems like this draft is pre-empting the inevitable exhaustion at a 
> good time. 
> 
> Thanks
> Andrew
> 
> 
> On 2021-02-19, 11:05 AM, "Pce on behalf of Adrian Farrel" 
>  wrote:
> 
>Ah, that's useful. Thanks Julien.
> 
>Makes this work more pressing.
> 
>Informative references to those two drafts would help focus the reviewer's 
> mind and might be handy when this draft overtakes those other two documents 
> and goes to the IESG.
> 
>Cheers,
>Adrian
> 
>-Original Message-
>From: julien.meu...@orange.com  
>Sent: 19 February 2021 14:38
>To: adr...@olddog.co.uk
>Cc: pce@ietf.org
>Subject: Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03
> 
>Hi Adrian,
> 
>Thank you for your feedback.
> 
>If evidence is needed, how about binding label?
>
> https://tools.ietf.org/html/draft-ietf-pce-binding-label-sid-06#section-11.2
>Note it's also reused in
>https://tools.ietf.org/html/draft-ietf-pce-sr-path-segment-03#section-4.2
> 
>Have a nice week-end,
> 
>Julien
> 
> 
>>On 18/02/2021 16:57, Adrian Farrel wrote:
>> Thanks to the authors for cleaning this up a lot since last time.
>> 
>> I don't object to adoption. Would be nice to have evidence of someone
>> needing a bit now, but by the time this becomes an RFC it is reasonably
>> possible.
>> 
>> Adrian
>> 
>> -Original Message-
>> From: Pce  On Behalf Of Dhruv Dhody
>> Sent: 01 February 2021 17:48
>> 
>> Hi WG,
>> 
>> This email begins the WG adoption poll for draft-xiong-pce-lsp-flag-03.
>> 
>> https://datatracker.ietf.org/doc/html/draft-xiong-pce-lsp-flag-03
>> 
>> This is a small draft that extends the flags in the LSP Objects by
>> defining a new LSP-EXTENDED-FLAG TLV. Note that the existing
>> sub-registry "LSP Object Flag Field" is almost fully assigned.
>> 
>> https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-object-flag-field
>> 
>> Should this draft be adopted by the PCE WG? Please state your reasons
>> - Why / Why not? What needs to be fixed before or after adoption? Are
>> you willing to work on this draft? Review comments should be posted to
>> the list.
>> 
>> Please respond by Monday 15th Feb.
>> 
>> Thanks!
>> Dhruv & Julien
>> 
>> ___
>> Pce mailing list
>> Pce@ietf.org
>> https://www.ietf.org/mailman/listinfo/pce
>> 
>> ___
>> Pce mailing list
>> Pce@ietf.org
>> https://www.ietf.org/mailman/listinfo/pce
>> 
> 
> 
>
> _
> 
>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.
> 
>___
>Pce mailing list
>Pce@ietf.org
>https://www.ietf.org/mailman/listinfo/pce
> 
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03

[Stone, Andrew (Nokia - CA/Ottawa)]

+1 thanks Julien, also support the document. 

Did not recognize that binding label and path segment we're requesting bits as 
well. Seems like this draft is pre-empting the inevitable exhaustion at a good 
time. 

Thanks
Andrew


On 2021-02-19, 11:05 AM, "Pce on behalf of Adrian Farrel" 
 wrote:

Ah, that's useful. Thanks Julien.

Makes this work more pressing.

Informative references to those two drafts would help focus the reviewer's 
mind and might be handy when this draft overtakes those other two documents and 
goes to the IESG.

Cheers,
Adrian

-Original Message-
From: julien.meu...@orange.com  
Sent: 19 February 2021 14:38
To: adr...@olddog.co.uk
Cc: pce@ietf.org
Subject: Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03

Hi Adrian,

Thank you for your feedback.

If evidence is needed, how about binding label?
https://tools.ietf.org/html/draft-ietf-pce-binding-label-sid-06#section-11.2
Note it's also reused in
https://tools.ietf.org/html/draft-ietf-pce-sr-path-segment-03#section-4.2

Have a nice week-end,

Julien


On 18/02/2021 16:57, Adrian Farrel wrote:
> Thanks to the authors for cleaning this up a lot since last time.
>
> I don't object to adoption. Would be nice to have evidence of someone
> needing a bit now, but by the time this becomes an RFC it is reasonably
> possible.
>
> Adrian
>
> -Original Message-
> From: Pce  On Behalf Of Dhruv Dhody
> Sent: 01 February 2021 17:48
>
> Hi WG,
>
> This email begins the WG adoption poll for draft-xiong-pce-lsp-flag-03.
>
> https://datatracker.ietf.org/doc/html/draft-xiong-pce-lsp-flag-03
>
> This is a small draft that extends the flags in the LSP Objects by
> defining a new LSP-EXTENDED-FLAG TLV. Note that the existing
> sub-registry "LSP Object Flag Field" is almost fully assigned.
>
> https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-object-flag-field
>
> Should this draft be adopted by the PCE WG? Please state your reasons
> - Why / Why not? What needs to be fixed before or after adoption? Are
> you willing to work on this draft? Review comments should be posted to
> the list.
>
> Please respond by Monday 15th Feb.
>
> Thanks!
> Dhruv & Julien
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>



_

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.

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-association-bidir-12: (with COMMENT)

[Alvaro Retana]

Rakesh:

Hi!

This new text works for me.

Thanks!

Alvaro.

On February 19, 2021 at 4:39:48 PM, Rakesh Gandhi (rgandhi) (
rgan...@cisco.com) wrote:

Thank you Alvaro for the review comments.



We have added a Section 3.5 - Operational Considerations in the new
revision to address the comment.



URL:
https://www.ietf.org/archive/id/draft-ietf-pce-association-bidir-13.txt
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-bidir-13



Please advise your feedback on this.



Thanks,

Rakesh





*From: *Pce  on behalf of Alvaro Retana via
Datatracker 
*Date: *Tuesday, February 16, 2021 at 8:37 AM
*To: *The IESG 
*Cc: *draft-ietf-pce-association-bi...@ietf.org <
draft-ietf-pce-association-bi...@ietf.org>, pce@ietf.org ,
pce-cha...@ietf.org 
*Subject: *[Pce] Alvaro Retana's No Objection on
draft-ietf-pce-association-bidir-12: (with COMMENT)

Alvaro Retana has entered the following ballot position for
draft-ietf-pce-association-bidir-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-association-bidir/



--
COMMENT:
--

This document defines extensions that can be used in different modes of
operation (§3.4).  However, there is no operational guidance related to the
advantages/disadvantages or considerations of using each of them.  Are there
cases (beyond implementation support) when one mode could be preferred?  If
all
modes are supported, how should an operator choose?

I believe that the specification is incomplete without this type of
guidance,
but I am not making this point a DISCUSS hoping that it will be easy for the
authors to address.



___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Implementation option of draft-ietf-pce-stateful-interdomain-01.txt

[olivier.dugeon]

Dear all,

According to the remark about implementation we got during the WG call
for adoption, we would start a new thread to discuss this point.
The goal isto prepare the discussion for next IETF meeting and reach a
consensusin order to edit revision 2 of the draft.

The stitching label principle requires at least a certain number of
modifications in the current PCEP version:

 a) A new PCE Capability to announce the inter-domain behaviour
 b) A new PCE Association Group to associate the local paths identifier
    to the inter-domain identifier
 c) new PCEP Errors to manage the Stitching Label exchange
 d) A mechanism to convey the Stitching Label

If there is no other choice than to reuse existing PCEP Objects by
allocating new code points for modifications a-c,there is several
options for point d, which we have tried to list below:

 d1) Use ERO and RRO in conjunction to new Path Setup code points as
 described in version 01 of the draft. It is the simplest
 implementation but as mention by Dhruv, each time a new path
 enforcement appear, a new PST code point must be allocated.
 For example, when Segment Routing v6 will be standardized, we must
 allocate a new Stitching label PST code point for SRv6.
 d2) Use ERO and ERO in conjunction to a new flag in LSP. Simple as for d1,
 but need to use the LSP Extended Flag draft as all LSP flags have been
 already allocated.
 d3) Same as d2 but find another place for the flag e.g. SRP or LSPA Object.
 d4) Define a new PCEP sub-Objet TLV within the LSP Object to convey the
 stitching label. This is more independent but need extra parsing from
 an implementation point of view.

Please, give us your opinion about these different options and don't hesitate
to propose others.

Regards

Olivier on be-half of co-author's




_

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.

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Alvaro Retana's No Objection on draft-ietf-pce-pcep-extension-for-pce-controller-12: (with COMMENT)

[Alvaro Retana via Datatracker]

Alvaro Retana has entered the following ballot position for
draft-ietf-pce-pcep-extension-for-pce-controller-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/



--
COMMENT:
--

(0) The fact that the procedures (§5) are presented before introducing the
messages/objects (§6-7) makes reading this document harder and more complex
than it has to be.  Consider changing the order or at least adding forward
references in §5.

(1) §5.2:  Is there a reason for the messages from rfc8231 to be in parenthesis?

(2) §5.4:

   The PCECC-CAPABILITY sub-TLV SHOULD NOT be used without the
   corresponding Path Setup Type being listed in the PATH-SETUP-TYPE-
   CAPABILITY TLV.  If it is present without the corresponding Path
   Setup Type listed in the PATH-SETUP-TYPE-CAPABILITY TLV, it MUST be
   ignored.

When is it ok to use the PCECC-CAPABILITY sub-TLV without the corresponding
PST?  If the result is that it will be ignored, then I don't understand why the
use of both is not required.

(3) §5.5.1/§5.5.4: "ingress MAY further choose to deploy a data plane check
mechanism and report the status back to the PCE"  Is this (checking and
reporting) specified somewhere?  Because you're using normative language,
please add a reference.

A similar statement is made in §5.5.7: "ingress PCC MAY choose to apply any OAM
mechanism to check the status of LSP in the Data plane and MAY further send its
status in a PCRpt message to the PCE".

(4) §5.5.3: s/central controller instructions...is done/central controller
instructions...are done

(5) §5.5.8: "The PCC SHOULD allocate the Label and SHOULD report to the PCE
using the PCRpt message."   When is it ok for the PCC to not allocate and/or
report?  IOW, why are these actions only recommended and not required?  Note
that the very next paragraph requires the behavior.

(6) §7.3/§7.3.1:  In the out-label case, "it is mandatory to encode the
next-hop information".  Should this information point at a directly connected
IP address/interface, or can it point at a remote next-hop (which may be
resolved through a routing protocol)?  What if the expected conditions are not
met?



___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] I-D Action: draft-ietf-pce-stateful-interdomain-01.txt

[olivier.dugeon]

Dear all,

This new version includes remarks received during the WG call of adoption
with the exception on the modification about the implementation whichwill
be incorporated inversion 02 after discussion within the WG.

Regards

Olivier on be-half of co-author's


Le 22/02/2021 à 18:41, internet-dra...@ietf.org a écrit :
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Path Computation Element WG of the IETF.
>
> Title   : PCEP Extension for Stateful Inter-Domain Tunnels
> Authors : Olivier Dugeon
>   Julien Meuric
>   Young Lee
>   Daniele Ceccarelli
>   Filename: draft-ietf-pce-stateful-interdomain-01.txt
>   Pages   : 34
>   Date: 2021-02-22
>
> Abstract:
>This document specifies how to use a Backward Recursive or
>Hierarchical method to derive inter-domain paths in the context of
>stateful Path Computation Element (PCE).  The mechanism relies on the
>PCInitiate message to set up independent paths per domain.  Combining
>these different paths together enables them to be operated as end-to-
>end inter-domain paths, without the need for a signaling session
>between inter-domain border routers.  For this purpose, this document
>defines a new Stitching Label, new Path Setup Types, new Association
>Type, and a new PCEP communication Protocol (PCEP) Capability.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-interdomain/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-pce-stateful-interdomain-01
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-interdomain-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-interdomain-01
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
-- 
Orange logo 

 

Olivier Dugeon
Orange Expert, Future Networks
Open Source Referent
Orange/IMT/OLN/WTC/IEE/iTeQ

 

fixe : +33 2 96 07 28 80
mobile : +33 6 82 90 37 85
olivier.dug...@orange.com 


_

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.

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] I-D Action: draft-ietf-pce-stateful-interdomain-01.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element WG of the IETF.

Title   : PCEP Extension for Stateful Inter-Domain Tunnels
Authors : Olivier Dugeon
  Julien Meuric
  Young Lee
  Daniele Ceccarelli
Filename: draft-ietf-pce-stateful-interdomain-01.txt
Pages   : 34
Date: 2021-02-22

Abstract:
   This document specifies how to use a Backward Recursive or
   Hierarchical method to derive inter-domain paths in the context of
   stateful Path Computation Element (PCE).  The mechanism relies on the
   PCInitiate message to set up independent paths per domain.  Combining
   these different paths together enables them to be operated as end-to-
   end inter-domain paths, without the need for a signaling session
   between inter-domain border routers.  For this purpose, this document
   defines a new Stitching Label, new Path Setup Types, new Association
   Type, and a new PCEP communication Protocol (PCEP) Capability.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-interdomain/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-stateful-interdomain-01
https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-interdomain-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-interdomain-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] I-D Action: draft-ietf-pce-flexible-grid-05.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element WG of the IETF.

Title   : PCEP Extension for Flexible Grid Networks
Authors : Young Lee
  Haomian Zheng
  Ramon Casellas
  Ricard Vilalta
  Daniele Ceccarelli
  Francesco Lazzeri
Filename: draft-ietf-pce-flexible-grid-05.txt
Pages   : 19
Date: 2021-02-22

Abstract:
   This document provides the Path Computation Element Communication
   Protocol (PCEP) extensions for the support of Routing and Spectrum
   Assignment (RSA) in Flexible Grid networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-flexible-grid/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-flexible-grid-05
https://datatracker.ietf.org/doc/html/draft-ietf-pce-flexible-grid-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-flexible-grid-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] I-D Action: draft-ietf-pce-pcep-yang-16.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element WG of the IETF.

Title   : A YANG Data Model for Path Computation Element 
Communications Protocol (PCEP)
Authors : Dhruv Dhody
  Jonathan Hardwick
  Vishnu Pavan Beeram
  Jeff Tantsura
Filename: draft-ietf-pce-pcep-yang-16.txt
Pages   : 112
Date: 2021-02-22

Abstract:
   This document defines a YANG data model for the management of Path
   Computation Element communications Protocol (PCEP) for communications
   between a Path Computation Client (PCC) and a Path Computation
   Element (PCE), or between two PCEs.  The data model includes
   configuration and state data.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-16
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-yang-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-yang-16


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Éric Vyncke's No Objection on draft-ietf-pce-association-bidir-12: (with COMMENT)

[Eric Vyncke (evyncke)]

Thank you Rakesh for your reply and the updated text

-éric


From: "Rakesh Gandhi (rgandhi)" 
Date: Friday, 19 February 2021 at 22:36
To: Eric Vyncke , The IESG 
Cc: "draft-ietf-pce-association-bi...@ietf.org" 
, "pce@ietf.org" , 
"pce-cha...@ietf.org" 
Subject: Re: [Pce] Éric Vyncke's No Objection on 
draft-ietf-pce-association-bidir-12: (with COMMENT)

Thank you Eric for the review comments.

We have posted a new revision that address the comments:
URL:
https://www.ietf.org/archive/id/draft-ietf-pce-association-bidir-13.txt
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-bidir-13

Please see inline with …

From: Pce  on behalf of Éric Vyncke via Datatracker 

Date: Monday, February 15, 2021 at 6:18 AM
To: The IESG 
Cc: draft-ietf-pce-association-bi...@ietf.org 
, pce@ietf.org , 
pce-cha...@ietf.org 
Subject: [Pce] Éric Vyncke's No Objection on 
draft-ietf-pce-association-bidir-12: (with COMMENT)
Éric Vyncke has entered the following ballot position for
draft-ietf-pce-association-bidir-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-association-bidir/



--
COMMENT:
--

Thank you for the work put into this document. I must admit that this document
was too deep in PCE for a full review of mine, I am trusting my routing AD
peers for this review.

Please find below some non-blocking COMMENT points (but replies would be
appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==
-- Section 3 --
Figure 2, should there be a LSP2 label on the link between C and F (as well as
between E and B) ? At the risk of overloading the figure though...

 I tried to add these two lines but the figure looked cumbersome. Looking 
at the Figure 2 in the draft as is, it seems ok to me.

-- Section 3.1.1 --
Suggest to mention that the topology of figure 1 is reused.

 Added the sentence.

== NITS ==

-- Section 1 --
Is "Path Control Element (PCE)" correct or is it "Path Computation Element
(PCE) " (per RFC Editor abbreviation list) ?

 Fixed.

Thanks,
Rakesh






___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Early code point allocation for draft-ietf-pce-segment-routing-policy-cp

[tom petch]

From: Pce  on behalf of tom petch 
Sent: 20 February 2021 12:33

From: Pce  on behalf of tom petch 
Sent: 19 February 2021 12:30

From: julien.meu...@orange.com 
Sent: 18 February 2021 10:35

Hi Tom,

Thank you for your valuable feedback.



The more I look, the less I like it.

This I-D asks for an error code for missing mandatory TLV, a category which PCE 
has defined  as Error-Type 6 and is referenced  by such as pce-vn-association.

Why does this I-D put missing mandatory TLV in a different Error-Type?

I will raise some more issues next week.


Next week and I like this I-D even less.

The I-D says repeatedly that only one instance of a particular TLV is allowed 
and others must be ignored.  Where the TLV is optional, this may make sense but 
where it is mandatory and forms part of the identifier then I think this wrong. 
 The sender is in effect saying I am confused about which association I am 
referring to (as indicated by including more than one).  That should be an 
error IMHO.

In passing I find the error messages poor.  I was looking at 
draft-ietf-pce-associated-bidirectional-lsp
and thinking how clear and easy to understand those error messages are, which I 
would not say of this I-D; the authors should look and learn.

A more significant problem is the identification of policy.  I assume that when 
this I-D talks of policy then it means SR policy.  (Sometimes it says so, 
sometimes it does not - needs fixing.)  This I-D says that a policy identifier 
consists of color, endpoint and optionally name.  

This raises a number of issues.  I raised earlier the point that an optional 
label as part of an identifier is a good candidate for erroneous 
implementations.  In fact it is more challenging than that.  The topic of 
optional keys came up in the development of YANG, were considered and rejected. 
 I forget the reasoning, whether they led to logical impossibilities or were 
too error-prone to implement or what, but they are not allowed.  So you cannot 
model in YANG anything with an optional key which is what this I-D seems to 
propose.

Separately, this I-D seems to contradict 
draft-ietf-spring-segment-routing-policy
which is clear that an SR policy is identified by the tuple  which is not what this I-D says (and which, in passing,  can be 
modelled in YANG).  Yes this PCE I-D mentions the context of headend but does 
not say where that should be inferred from to form the unique SR Policy 
identifier.

As you may infer, I do not see this I-D as fit for an early IANA allocation.

Tom Petch


Some of the issues you point out are easy to address and we've already
requested the authors to revise the I-D accordingly. To fully resolve
your concern, could you please point any other specific parts where you
feel you have to "interpret the words the way you think they should have
been"? If you even have some text to suggest, that could smoothly ease
the update.


At a first glance,

s.7.1
RFC8697 names three  columns for the registry; those names do not appear here.

The new association type is given a different identifier in different places.  
The preferred identifier needs to be nailed down since it is going into IANA 
forthwith and will be confusing to change thereafter.

s.7.2
This requests new error values  under Association Error  and specifies a Type 
of 29.  RFC8697 specifies a Type of 26 (29 is Path Computation Failure).

'Conflicting SRAG TLV' I find rather vague; conflicting with what?  Likewise 
'Multiple SRPAG from one LSP'

s.7.3
This document defines five new TLVs
That is TBD3, TBD4, TBD11, TBD5 and 

RFC8697 specifies the names of the fields in the registry,  Those names are not 
used here.

s.3.2
'as of the time of writing' will change its meaning as the I-D progresses; date 
needed

s.4.1
'is only meant to be used'
MUST NOT, SHOULD NOT, .?

'Policy Identifiers uniquely identify..
Policy Identifiers consist of Color.. Endpoint, optionally the policy hame.
So if one is Color red, Endpoint NY no policy name
and then one is requested for
Color red, Endpoint NY, policy name standby
that is a different triplet and so valid.  Mmm. I can see that being 
mis-implemented

s.4.2

'is meant to strictly correspond'
MUST, SHOULD, ?

s.5
This document specifies four new TLVs...
These five TLVs .

These five TLVs encode the Policy Identifiers, SR Policy name, Candidate path 
identifiers, candidate path name and Candidate path preference..
That is five TLV. Wrong! That is four TLV and something completely different.


When any of the mandatory TLVs
Only one TLV is listed as mandatory SRPOLICY-CPATH-ID.

s.5
At most only one .. can be carried
and then goes on to describe the carriage of  more than one;
'Only one ... SHOULD be present in a ... (whatever identifier you fix on) 
message.  If more than one is present, only the first is processed and 
subsequent ones are silently discarded.

A Normative Reference to an unadopted I-D that expires next week is not a good 
look:-)

Like I said, 

Re: [Pce] Early code point allocation for draft-ietf-pce-segment-routing-policy-cp

[Mike Koldychev (mkoldych)]

Hi Tom,

Thanks a lot for your review, the -03 version should address your prior 
comments. Please log any new comments against the -03 version.

Thanks,
Mike.

-Original Message-
From: Pce  On Behalf Of tom petch
Sent: Saturday, February 20, 2021 7:33 AM
To: julien.meu...@orange.com
Cc: pce@ietf.org
Subject: Re: [Pce] Early code point allocation for 
draft-ietf-pce-segment-routing-policy-cp

From: Pce  on behalf of tom petch 
Sent: 19 February 2021 12:30
To: julien.meu...@orange.com
Cc: pce@ietf.org
Subject: Re: [Pce] Early code point allocation for 
draft-ietf-pce-segment-routing-policy-cp

From: julien.meu...@orange.com 
Sent: 18 February 2021 10:35

Hi Tom,

Thank you for your valuable feedback.



The more I look, the less I like it.

This I-D asks for an error code for missing mandatory TLV, a category which PCE 
has defined  as Error-Type 6 and is referenced  by such as pce-vn-association.

Why does this I-D put missing mandatory TLV in a different Error-Type?

I will raise some more issues next week.

Tom Petch


Some of the issues you point out are easy to address and we've already 
requested the authors to revise the I-D accordingly. To fully resolve your 
concern, could you please point any other specific parts where you feel you 
have to "interpret the words the way you think they should have been"? If you 
even have some text to suggest, that could smoothly ease the update.


At a first glance,

s.7.1
RFC8697 names three  columns for the registry; those names do not appear here.

The new association type is given a different identifier in different places.  
The preferred identifier needs to be nailed down since it is going into IANA 
forthwith and will be confusing to change thereafter.

s.7.2
This requests new error values  under Association Error  and specifies a Type 
of 29.  RFC8697 specifies a Type of 26 (29 is Path Computation Failure).

'Conflicting SRAG TLV' I find rather vague; conflicting with what?  Likewise 
'Multiple SRPAG from one LSP'

s.7.3
This document defines five new TLVs
That is TBD3, TBD4, TBD11, TBD5 and 

RFC8697 specifies the names of the fields in the registry,  Those names are not 
used here.

s.3.2
'as of the time of writing' will change its meaning as the I-D progresses; date 
needed

s.4.1
'is only meant to be used'
MUST NOT, SHOULD NOT, .?

'Policy Identifiers uniquely identify..
Policy Identifiers consist of Color.. Endpoint, optionally the policy hame.
So if one is Color red, Endpoint NY no policy name and then one is requested 
for Color red, Endpoint NY, policy name standby that is a different triplet and 
so valid.  Mmm. I can see that being mis-implemented

s.4.2

'is meant to strictly correspond'
MUST, SHOULD, ?

s.5
This document specifies four new TLVs...
These five TLVs .

These five TLVs encode the Policy Identifiers, SR Policy name, Candidate path 
identifiers, candidate path name and Candidate path preference..
That is five TLV. Wrong! That is four TLV and something completely different.


When any of the mandatory TLVs
Only one TLV is listed as mandatory SRPOLICY-CPATH-ID.

s.5
At most only one .. can be carried
and then goes on to describe the carriage of  more than one; 'Only one ... 
SHOULD be present in a ... (whatever identifier you fix on) message.  If more 
than one is present, only the first is processed and subsequent ones are 
silently discarded.

A Normative Reference to an unadopted I-D that expires next week is not a good 
look:-)

Like I said, the word that came to my mind was 'sloppy':-(

Tom Petch

Thanks,

Dhruv & Julien


On 17/02/2021 12:46, tom petch wrote:
> 
> 
> I am sure that IANA will cope because they always do, but it will be by 
> reading between the lines, applying intelligence to what the authors may have 
> meant, and so on.  Editorially this is a poor I-D (as yet), and that quality 
> verges on the technical aspects.
>
> Thus 7.3 says the I-D defines five new TLV and lists four; this also occurs 
> in the body of the I-D.  A reader might also notice the absence of TBD2 and 
> wonder.
>
> Or the new Association.  Thus needs an identifier.  Trouble is, the I-D uses 
> (at least) three different ones; this looseness of terminology can lead to 
> problems down the line.  (MPLS I see as a classic in how not to specify IANA 
> registries and I see this heading the same way).
>
> Likewise the identifiers used in s.7 do not match those in current use, a 
> good way of storing up future trouble.
>
> Is the specification adequate?  Only if you do not take it literally and 
> interpret the words the way you think they should have been.
>
> Tom Petch
>


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

___
Pce mailing list
Pce@ietf.org

Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03

[Dhruv Dhody]

Hi WG,

Thanks to all who responded to the adoption poll. We have support to
adopt this as a WG item. Please continue to provide your comments as
the document moves through the WG process.

Authors, please post a -00 version
'draft-ietf-pce-lsp-extended-flags-00' with only the name/date change,
and be sure to set the "replaces" option during submission ("extended"
is added in the file name for clarity).

Please post the -01 version that handles the comments received during
the adoption call as well.

Thanks!
PCE Chairs

On Tue, Feb 16, 2021 at 4:58 PM Dhruv Dhody  wrote:
>
> Hi WG,
>
> We *need* to hear from more of you before taking a call on adoption. It is a 
> straightforward "house-keeping" document, but we need to see explicit 
> expressions of support (and comments).
>
> We are extending the call till Friday, Feb 19th. Please respond with your 
> support (or not) for this adoption.
>
> Regards,
> Dhruv & Julien
>
> On Mon, Feb 1, 2021 at 11:17 PM Dhruv Dhody  wrote:
>>
>> Hi WG,
>>
>> This email begins the WG adoption poll for draft-xiong-pce-lsp-flag-03.
>>
>> https://datatracker.ietf.org/doc/html/draft-xiong-pce-lsp-flag-03
>>
>> This is a small draft that extends the flags in the LSP Objects by
>> defining a new LSP-EXTENDED-FLAG TLV. Note that the existing
>> sub-registry "LSP Object Flag Field" is almost fully assigned.
>>
>> https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-object-flag-field
>>
>> Should this draft be adopted by the PCE WG? Please state your reasons
>> - Why / Why not? What needs to be fixed before or after adoption? Are
>> you willing to work on this draft? Review comments should be posted to
>> the list.
>>
>> Please respond by Monday 15th Feb.
>>
>> Thanks!
>> Dhruv & Julien

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03

[xiong.quan]

Hi Dhruv,






Thanks for your suggestion! I agree with you to cite the 
draft-peng-pce-entropy-label-position as an example.


But I am not sure about the two wg drafts including 
draft-ietf-pce-binding-label-sid-06 and draft-ietf-pce-sr-path-segment-03. As 
far as I know, the last unassigned bit in LSP object is bit 0. It is not enough 
for the two drafts.






Regards,


Quan











原始邮件



发件人：DhruvDhody
收件人：熊泉00091065;
抄送人：pce@ietf.org;
日 期 ：2021年02月22日 11:48
主 题 ：Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03


Hi Quan,
 
To clarify,
 
- draft-ietf-pce-binding-label-sid is asking for the allocation in the
existing LSP Object Flag Field, after this allocation, there won't be
any flags left.
- as an example of usage of the new LSP-EXTENDED-FLAG TLV, you should
site draft-peng-pce-entropy-label-position!
 
Hope this helps you with the text in your draft!
 
Thanks!
Dhruv
 
On Mon, Feb 22, 2021 at 7:06 AM  wrote:
> 
> Hi  Adrian and Julien,
> 
> 
> Many thanks for your suggestions!
> 
> I fully agree with you. The two wg drafts could be viewed as two 
> implementations to use the flag carried in LSP-EXTENDED-FLAG TLV.
> 
> I will add informative references to those two drafts if necessary.  And I 
> also suggest those two drafts could add references to the 
> draft-xiong-pce-lsp-flag.
> 
> 
> Regards,
> 
> Quan
> 
> 
> >Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03
> 
> Adrian Farrel  Fri, 19 February 2021 16:05 UTCShow header
> 
> >Ah, that's useful. Thanks Julien.
> 
> >Makes this work more pressing.
> 
> >Informative references to those two drafts would help focus the reviewer's 
> >mind and might be handy when this draft overtakes those other two documents 
> >and goes to the IESG.
> 
> >Cheers,
> >Adrian
> 
> -Original Message-
> From: julien.meu...@orange.com  Sent: 19 February 
> 2021 14:38
> To: adr...@olddog.co.ukcc: pce@ietf.orgSubject: Re: [Pce] Adoption of 
> draft-xiong-pce-lsp-flag-03
> 
> >Hi Adrian,
> 
> >Thank you for your feedback.
> 
> >If evidence is needed, how about binding 
> >label?https://tools.ietf.org/html/draft-ietf-pce-binding-label-sid-06#section-11.2Note
> > it's also reused 
> >inhttps://tools.ietf.org/html/draft-ietf-pce-sr-path-segment-03#section-4.2Have
> > a nice week-end,
> 
> >Julien
> 
> 
> On 18/02/2021 16:57, Adrian Farrel wrote:
> > Thanks to the authors for cleaning this up a lot since last time.
> > 
> > I don't object to adoption. Would be nice to have evidence of someone
> > needing a bit now, but by the time this becomes an RFC it is reasonably
> > possible.
> > 
> > Adrian
> > 
> > -Original Message-
> > From: Pce  On Behalf Of Dhruv Dhody
> > Sent: 01 February 2021 17:48
> > 
> > Hi WG,
> > 
> > This email begins the WG adoption poll for draft-xiong-pce-lsp-flag-03.
> > 
> > https://datatracker.ietf.org/doc/html/draft-xiong-pce-lsp-flag-03> 
> > This is a small draft that extends the flags in the LSP Objects by
> > defining a new LSP-EXTENDED-FLAG TLV. Note that the existing
> > sub-registry "LSP Object Flag Field" is almost fully assigned.
> > 
> > https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-object-flag-field> 
> > Should this draft be adopted by the PCE WG? Please state your reasons
> > - Why / Why not? What needs to be fixed before or after adoption? Are
> > you willing to work on this draft? Review comments should be posted to
> > the list.
> > 
> > Please respond by Monday 15th Feb.
> > 
> > Thanks!
> > Dhruv & Julien
> > 
> > ___
> > Pce mailing list
> > Pce@ietf.org> https://www.ietf.org/mailman/listinfo/pce> 
> > ___
> > Pce mailing list
> > Pce@ietf.org> https://www.ietf.org/mailman/listinfo/pce> 
> 
> 
> _
> 
> 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.
> 
> 
> 
> 
> 
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
 
___
Pce mailing list