Hi Marina,
Thanks a lot, for comments. Please see inline <S>.
Regards,
Samuel
From: Marina Fizgeer <marina.fizg...@rbbn.com>
Sent: Tuesday, December 17, 2024 9:33 AM
To: Aijun Wang <wangai...@tsinghua.org.cn>; 'Dhruv Dhody'
<d...@dhruvdhody.com>; pce@ietf.org
Cc: 'pce-chairs' <pce-cha...@ietf.org>; draft-ietf-pce-sid-a...@ietf.org
Subject: RE: [EXTERNAL] [Pce] 答复: WGLC for draft-ietf-pce-sid-algo-15
Hi, all,
I have also some comments about this draft.
I read this document.
What is missing, from my point of view, is the description of use of new flag
in ERO sub object and LSPA object related to different message types.
For example, PCInit, report. Is it MUST to include it in report if it was in
initiate? Is it needed in initiated? At all, do we need it in report/reply, if
it was even in request?
As I understand, the main flow, described in this document is request-reply,
and not related to PCE initiated LSPs.
I think it would be useful to give a list of messages, where the new flag and
information can be and shall be used. And describe when it is optional, when it
is Must (and what to do if it is missed)
<S> Main flow in the document is really PCRpt-PCUpd, but extensions are
applicable to PCE initiated policies as well. We can add statement to sections
4.1 and 4.2 to indicate that PCC MUST reflect TLV received from PCUpd and
PCInitiate in the PCRpt and that PCE MUST reflect value received from PCRpt in
PCUpd message. I’ll discuss with other co-authors to see what will the best way
to specify it (to make sure that it does not conflict with other existing
statements).
In additional small notes:
1.
In this document:
The code point for the TLV type is 66. The TLV length is 4 octets.
The 32-bit value is formatted as follows.
The common practices in other documents to write:
Type: Extended Association ID TLV, type = 31.
Length: Either 8 or 20, …..
<S> For the format of specifying TLV type and length – at least RFCs for PCEP
SR and SRv6 extensions, which are describing SR-ERO sub object seems to be
following format used in this document, see:
https://www.rfc-editor.org/rfc/rfc8664.html#name-the-sr-pce-capability-sub-t
“The codepoint for the TLV type is 26. The TLV length is 4 octets.”
Or
https://www.rfc-editor.org/rfc/rfc9603.html#section-4.1.1
“The code point for the TLV type is 27, and the format…
2. In 3.5 Extensions to METRIC Object
2.1 The METRIC object is defined in Section 7.8 of [RFC5440]
Link to RFC is not so good, may be the better is to put link to this
specific section
<S> Ack, I’ll update it.
2.2 Metric values shall be as in RFC5440:
T = 22: Path Min Delay metric
And not:
T:22: Path Min Delay metric
<S> Ack, I’ll update it.
[Logo]<https://ribboncommunications.com/>
Marina Fizgeer
Sr. Manager, Systems Architecture | Ribbon
M +972.544860016
Petah Tikva, Israel
[Banner]<https://ribboncommunications.com/?_gl=1*6qlbuc*_gcl_au*MjA3NzE5OTk5NC4xNzI4NDE0NDY4*_ga*NTIxNzg1MDgxLjE3Mjg0MTQ0NjM.*_ga_VCEZ9Q3S3Y*MTcyODQ1MjEzMC4yLjEuMTcyODQ1MjE4OS4xLjAuMTA4NjExNTU4>
From: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>
Sent: Tuesday, December 17, 2024 09:48
To: 'Dhruv Dhody' <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>>;
pce@ietf.org<mailto:pce@ietf.org>
Cc: 'pce-chairs' <pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>>;
draft-ietf-pce-sid-a...@ietf.org<mailto:draft-ietf-pce-sid-a...@ietf.org>
Subject: [EXTERNAL] [Pce] 答复: WGLC for draft-ietf-pce-sid-algo-15
Hi, All:
I have review the document and has the following comments:
Although I think the document has already defined the related extension for the
information exchange between PCE and PCC, It’s bit harder for the reader to get
the reason behind this.
1. For example, in the introduction part, one sentence say: “While this
information is available on the PCE, there is no method of conveying this
information to the headend router. “
From my POV, the headend router can get such information from the IGP protocol,
why it is necessary to get such information from the PCE?
2. And again, it says: ”In addition, in the case of multiple (redundant)
PCEs, when the headend receives a path from the primary PCE, it needs to be
able to report the complete path information - including the SR-Algorithm -
to the backup PCE so that in HA scenarios”
From my POV, why the multiple(redundant)PCEs can’t exchange such information
themselves?
3. And, for the following rest part of introduction section, there is no
clear logic for the newly extended TLV and their purposes, or the remaining
part doesn’t cover all the extensions that described in the following sections.
4. And finally, I am wondering is there any other TLV/Sub-TLV that needs to
be synchronized between the PCE/PCC to make the final optimal path can be
calculated in each of them? The draft just enumerate them, but doesn’t’ explain
whether it covers all of them.
Then, I suggest the authors revisit the introduction part of this document, and
rewrite it to assure the reader the necessary of this document, and also its
enough coverage.
Maybe I miss something, if so, please forgive me.
Best Regards
Aijun Wang
China Telecom
发件人: forwardingalgori...@ietf.org<mailto:forwardingalgori...@ietf.org>
[mailto:forwardingalgori...@ietf.org] 代表 Dhruv Dhody
发送时间: 2024年12月6日 3:02
收件人: pce@ietf.org<mailto:pce@ietf.org>
抄送: pce-chairs <pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>>;
draft-ietf-pce-sid-a...@ietf.org<mailto:draft-ietf-pce-sid-a...@ietf.org>
主题: [Pce] WGLC for draft-ietf-pce-sid-algo-15
Hi WG,
This email starts a 3-weeks working group last call for
draft-ietf-pce-sid-algo-15.
https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/
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 Friday 27 Dec 2024.
A general reminder to the WG to be more vocal during the last-call/adoption.
Thanks,
Dhruv & Julien
Disclaimer
This e-mail together with any attachments may contain information of Ribbon
Communications Inc. and its Affiliates that is confidential and/or proprietary
for the sole use of the intended recipient. Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly
prohibited. If you are not the intended recipient, please notify the sender
immediately and then delete all copies, including any attachments.
_______________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
