Re: [Pce] IPR Poll for draft-li-pce-pcep-pmtu-05

[Pengshuping (Peng Shuping)]

Hi Hari,

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

Best Regards,
Shuping



From: Hariharan Ananthakrishnan [mailto:h...@netflix.com]
Sent: Tuesday, March 29, 2022 5:32 AM
To: Pengshuping (Peng Shuping) ; 
luc-fabrice.ndi...@mtn.com; Chengli (Cheng Li) ; 
hanliu...@chinamobile.com
Cc: pce@ietf.org
Subject: IPR Poll for draft-li-pce-pcep-pmtu-05


Hi Authors,

In preparation for WG adoption on this draft, I'd like all

authors and contributors to confirm on the list that they are in compliance

with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.



I am aware of the IPR applicable to this draft, and it has already been

disclosed to the IETF.



I am aware of IPR applicable to this draft, but that has not yet been

disclosed to the IETF. I will work to ensure that it will be disclosed in a

timely manner.



Thanks,

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

Re: [Pce] IPR Poll for draft-li-pce-pcep-pmtu-05

[Luc-Fabrice Ndifor Ngwa [ MTN Cameroon ]]

Hi Hari,
Trust this mail finds you well.

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules


​Warm regards,
Luc-Fabrice

Ndifor
Specialist - IP Access and Data center
luc-fabrice.ndi...@mtn.com
T +237 677 55 02 13
Head Office: 360, Rue Drouot
​P.O. Box 15 574 Douala, Cameroon
T +237 679 00 90 90
 | mtn.cm
This email is confidential. If you have received it in error, you are on notice 
of its status. Please notify ​the ​​sender immediately by
​reply email and then delete this message from your system. Please do not copy 
it ​or use it for any purpose or disclose its content
​to any other person as to do so could be a breach of ​confidentiality.
​
 Please be informed that no employee or agent is authorized to conclude any 
legally binding agreement ​on behalf of MTN Cameroon
​via email. This can be only done if the email is confirmed explicitly in 
writing ​by an MTN Cameroon authorized officer. In no event
​will this email or its content be construed as a written ​approval.
From: Hariharan Ananthakrishnan 
Sent: Monday, March 28, 2022 10:32 PM
To: Pengshuping (Peng Shuping) ; Luc-Fabrice Ndifor 
Ngwa [ MTN Cameroon ] ; Chengli (Cheng Li) 
; hanliu...@chinamobile.com
Cc: pce@ietf.org
Subject: IPR Poll for draft-li-pce-pcep-pmtu-05


Hi Authors,

In preparation for WG adoption on this draft, I'd like all

authors and contributors to confirm on the list that they are in compliance

with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.



I am aware of the IPR applicable to this draft, and it has already been

disclosed to the IETF.



I am aware of IPR applicable to this draft, but that has not yet been

disclosed to the IETF. I will work to ensure that it will be disclosed in a

timely manner.



Thanks,

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

Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

[Gyan Mishra]

Hi Dhruv

I reviewed the draft and support WG adoption.

Should this draft be adopted by the PCE WG?

Yes

Please state your reasons - Why / Why not?

This documents PCEP PMTU extension is valuable for any operator deployments
of SR-MPLS or SRv6 and/or uses SR-TE and want to ensure that fragmentation
does not occur along the stateful path instantiated.

What needs to be fixed before or after adoption?

The document well written and to the point and is ready for adoption

Are you willing to work on this draft?

Yes I would be happy to collaborate on the draft

Review comments should be posted to the list.

Few comments for the authors below:

It maybe worthwhile to mention PMTUD path MTU discovery which allows a TCP
session to dynamically adjust the MSS for incoming and outgoing MSS.  As
this document utilizes PMTU which is based on the PMTUD concept which is
being carried in a new metric field in the PCEP report message I think for
clarity it would.

BGP uses TCP and by default most all vendor implementations have PMTUD
enabled by default on all BGP sessions.  Maybe worthwhile mentioning.

In the abstract I don’t understand this sentence.

Since the SR does not require signaling, the path maximum
transmission unit (MTU) information for SR path is not available.


I understand SR eliminates the control plane signaling for label
distribution LDP which is now via IGP extension, but how does that make it
so the SR MTU information is not available.  Directed LDP is for adjacency
nodes or targeted LDP for session protection for non directly connected
nodes.

RFC 5036 LDP does not support signaling for MTU.

RFC 7552 LDP updates for IPv6 also does not support signaling for MTU.

RFC 3988 is an experimental extension to support signaling for MTU.

I see RFC 3988 as a informational reference.

I think it would be good to mention what I stated above related to LDP not
providing any signaling for MTU and RFC 3988 as its experimental and not
standard track also not implemented by all vendors.

Section 3.5 mentions that path MTU adjustment can be made for primary or
TI-LFA local protection path.

I would think this can be used for SR-TE protected path instantiated by
stateful PCE but not for local protection.

Also would this draft be applicable to Non SR MPLS and GMPLS LDP signaling
RFC 3988 is experimental only so MPLS and GMPLS as well have a gap for MTU
signaling.  I do see you stated in the introduction.  You may want to state
the gap that exists as RFC 3988 is experimental and now this solution fills
that gap as well.


Thanks

Gyan

On Mon, Mar 28, 2022 at 12:10 PM Dhruv Dhody  wrote:

> Hi WG,
>
> This email begins the WG adoption poll for draft-li-pce-pcep-pmtu-05.
>
> https://datatracker.ietf.org/doc/draft-li-pce-pcep-pmtu/
>
> 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 11th April 2022.
>
> Thanks!
> Dhruv & Julien
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

[Aijun Wang]

Hi, Dhruv:

I have read this document and support it adoption.

Some suggestions for the current contents are the followings:

1. The proposal in this draft is easy to understand, It is better to 
simplify the “Introduction” part.

2. There should be one section about “Procedures for the Path MTU 
calculation”, which can include the some contents in section 3.1, section 3.2, 
section 3.5

3. Section 3.3 and 3.4 should be put in one independent section, such as 
“Application of the Path MTU Metric”?

 

Best Regards

 

Aijun Wang

China Telecom

 

From: pce-boun...@ietf.org  On Behalf Of Dhruv Dhody
Sent: Tuesday, March 29, 2022 12:09 AM
To: pce@ietf.org
Cc: draft-li-pce-pcep-p...@ietf.org
Subject: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

 

Hi WG,

This email begins the WG adoption poll for draft-li-pce-pcep-pmtu-05.

 

https://datatracker.ietf.org/doc/draft-li-pce-pcep-pmtu/

 

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 11th April 2022.

Thanks!
Dhruv & Julien

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

Re: [Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

[Fangsheng]

I support the adoption. Passing PMTU through PCEP is a very important extension 
for SR TE LSP.

From: Dhruv Dhody [mailto:d...@dhruvdhody.com]
Sent: Tuesday, March 29, 2022 12:09 AM
To: pce@ietf.org
Cc: draft-li-pce-pcep-p...@ietf.org
Subject: WG Adoption of draft-li-pce-pcep-pmtu-05

Hi WG,

This email begins the WG adoption poll for draft-li-pce-pcep-pmtu-05.

https://datatracker.ietf.org/doc/draft-li-pce-pcep-pmtu/

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 11th April 2022.

Thanks!
Dhruv & Julien
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IPR Poll for draft-li-pce-pcep-pmtu-05

[韩柳燕]

Dear Hari,

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

Thank you.

Best regards,
Liuyan


2022-03-29 



-
韩柳燕 / Han Liuyan
中国移动通信研究院 网络技术研究所 / China Mobile Research Institute
地址: 北京市西城区宣武门西大街32号创新大厦,100053
电话: 010-15801696688-33076
传真：010-63601087
手机: 15810339103
Email: hanliu...@chinamobile.com
- 



发件人： Hariharan Ananthakrishnan 
发送时间： 2022-03-29  05:37:14 
收件人： pengshuping; luc-fabrice.ndifor; c.l; hanliuyan 
抄送： pce 
主题： IPR Poll for draft-li-pce-pcep-pmtu-05 
 
Hi Authors,
In preparation for WG adoption on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.
Please respond (copying the mailing list) to say one of:
I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

I am aware of the IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

Thanks,
- Hari
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Yangdoctors early review of draft-ietf-pce-pcep-yang-18

[Mahesh Jethanandani via Datatracker]

Reviewer: Mahesh Jethanandani
Review result: On the Right Track

I am not an expert in PCEP. This review is looking at the draft from a YANG
perspective. With that said, I am continuing to mark it as “On the Right Track”
because of some of the points discussed below.

Summary:

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 data and state data.

Comments:

General

- Thanks for acknowledging me in the Acknowledgement section, but you have my
last name wrong :-). Dhruv, are you thinking of the famous lawyer by that name??

- The module continues to make use of groupings. They are great if they are
being used in multiple places. But I seem to see single usage of groupings,
which makes the model hard to read. Please collapse all groupings that are used
only once into the module.

Section 4. Objectives

You state what I would consider obvious objectives of any YANG model. Are they
really necessary?

More curiously, what caught my attention was mapping to the MIB module. Other
than an index value, and some notifications that are supported in the MIB, I
did not see a wholesale effort to try to map to the MIB.

If such an effort is desired, and I believe operators would like it, please
capture that mapping as part of the description statement of the node.

Section 5. The Design of the PCEP Data Model.

Thank you for taking care of the following comment from the -08 review.

-- Begin comment from -08 
Thank you for first of all for creating an abridged version of the tree
diagram. What would really help to understand the design of the model would be
to place the full tree diagram at the end of the section, and move sections 5.3
to 5.7. directly under 5.1. Scrolling through pages of the full diagram to get
to the design sections is painful to read. -- End comment from -08 ---

- Some new observations. Generally, the principal we have tried to follow is
that the container is plural (domains), but the list is singular (domain). Same
for capabilities and capability, neighbor-domains and domains, path-keys and
part-key etc. You get the picture. Please address/fix them.

- Could the section numbers for Section 5 follow the hierarchy of the model
itself. For example, pcep consists of entity (Section 5.2), which consists of
peers (Section 5.2.1), which consists of sessions (Section 5.2.1.1) etc.

Section 5.2 The Entity.

- Does pcep have 'entity' and 'peers', and each entity have their own 'peers'?
I see 'peers' under both.

- You say that

   The PCEP yang module may contain status information for the local
   PCEP entity.

   The entity has an IP address (using ietf-inet-types [RFC6991]) and a
   "role" leaf (the local entity PCEP role) as mandatory.

If this is status information (ro), how is the IP address and role leaf
mandatory type being enforced?

- The following statement seems incomplete:

   The various information related to this entity such as its domain,
   capabilities etc.

This paragraph is difficult to read with too many "and" and "as wells". Can it
rewritten?

   There is a list for static peer configuration and operational state
   of all peers (i.e.static as well as discovered)("/pcep/entity/
   peers").  The list is used to enable remote PCE configuration at PCC
   (or PCE) and has the operational state of these peers as well as the
   remote PCE peer which were discovered and PCC peers that have
   initiated session.

And since I am not a PCEP expert, I am allowed to ask some dumb question. Are
all the peer nodes configurable? Including their IP addresses and their
capabilities?? I would have imagined that the peers are configured on the nodes
where they exist, and show up as operational data on this node.

Section 5.6 RPC

Does the rpc not have any output? Success or failure??

Section 6 The Design of PCEP Statistics Data Model.

- Why are stats a separate module? Can they not be part of the base model? If
the idea is that some implementations may not want to implement statistics,
then the model can carry a feature statement 'statistics-supported'.

- Almost all counters are numbers. Is the num- prefix needed for every counter
name?

Section 10. PCEP YANG Modules

I see that many of the points from the -08 review have been incorporated. Thank
you. I have removed those that I think were resolved. But there are still a
few, and I am adding new comments.

- The model defines a dizzying number of feature statements. Is there any
portion of the model that is truly common?

- The YANG module continues the use of single instances of grouping, e.g.
pce-scope. Please collapse the grouping.

- Some of the typedefs continue to reuse the parent name in the definitions.
E.g. 'pcep-oper-status' has oper-status as a prefix for each definition. They
could easily be shortened to 'up', 'd

[Pce] IPR Poll for draft-li-pce-pcep-pmtu-05

[Hariharan Ananthakrishnan]

Hi Authors,

In preparation for WG adoption on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

I am aware of the IPR applicable to this draft, and it has already been
disclosed to the IETF.

I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.

Thanks,
- Hari
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] The PCE WG has placed draft-li-pce-pcep-pmtu in state "Call For Adoption By WG Issued"

[IETF Secretariat]

The PCE WG has placed draft-li-pce-pcep-pmtu in state
Call For Adoption By WG Issued (entered by Dhruv Dhody)

The document is available at
https://datatracker.ietf.org/doc/draft-li-pce-pcep-pmtu/


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

[Pce] WG Adoption of draft-li-pce-pcep-pmtu-05

[Dhruv Dhody]

Hi WG,

This email begins the WG adoption poll for draft-li-pce-pcep-pmtu-05.

https://datatracker.ietf.org/doc/draft-li-pce-pcep-pmtu/

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 11th April 2022.

Thanks!
Dhruv & Julien
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce