Hi Aijun,
Version 16 submitted.
- “Introduction” section re-worked
- Section with multiple RFCs moved to section 4
- Based on discussion with other co-authors, we don’t see many things
to be mentioned in “Overall Procedures Description” as drafts is not
introducing any new messages and it is practically just extending existing PCEP
objects. We instead added overview of extensions to introduction section.
- Comments from other WG members and co-authors were addressed.
I hope that will make it more readable for you as well.
Regards,
Samuel
From: Samuel Sidor (ssidor) <ssi...@cisco.com>
Sent: Wednesday, December 18, 2024 1:50 PM
To: Aijun Wang <wangai...@tsinghua.org.cn>; 'Dhruv Dhody' <d...@dhruvdhody.com>
Cc: 'pce-chairs' <pce-cha...@ietf.org>; draft-ietf-pce-sid-a...@ietf.org;
pce@ietf.org
Subject: RE: [Pce] WGLC for draft-ietf-pce-sid-algo-15
Thanks Aijun,
We are discussing updated version of the draft with other co-authors (mostly
with updated Introduction section, comments from Marina and also adding small
clarification about RRO object). I’ll send it here as well after finishing that
discussion. It should solve 1) and 2) from your list bellow. I’ll discuss 3)
with them as well, but I’m fine with adding “Overview” or “Overall Procedures
Description” section.
For 4) – I prefer current approach, where format of PCEP objects/TLVs, which
are introduced or extended are defined in dedicated sections and separated from
operations – so same approach as was already used in RFCs, which this drafts is
related to like RFC8664 or RFC9603 (see sections “Object Formats” and
“Procedures”), but in a lot of other PCEP RFCs as well – e.g. RFC8745, RFC8934,
RFC9059.
Operations described in the drafts are often impacting multiple objects/TLVs
(e.g. capability and object, which can be included only if capability is set)
and then it is difficult to include it into proper sections – often resulting
in duplicate statements. But I’ll keep chairs, co-authors and other WG members
to express their preference.
Thanks,
Samuel
From: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>
Sent: Wednesday, December 18, 2024 7:16 AM
To: Samuel Sidor (ssidor) <ssi...@cisco.com<mailto:ssi...@cisco.com>>; '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: 答复: [Pce] WGLC for draft-ietf-pce-sid-algo-15
Hi, Samuel:
From your responses to me and to Marina, I recommend the authors of draft to do
the following updates:
1) Rewrite the section 1 “Introduction” part, to state clear the necessary
of this document, and its applied scenarios.
2) As you suggested, “some details can be removed from introduction (e.g.
pointer to specific RFCs)”.
3) Add one new segment before “section 3”, as, for example, the “Overall
Procedures Description”?, let reader to know where(for example, in which PCEP
message etc.) to encapsulate these newly defined objects.
4) Rewrite the section 4 “Operation”. As you said, “section 4 is explaining
how to use them”, is it better to merge it together with section 3(it will be
more easier to use when comparing with its original definition)
After accomplishing the above updates, I think the document will be more
readable.
Best Regards
Aijun Wang
China Telecom
发件人: Samuel Sidor (ssidor) [mailto:ssi...@cisco.com]
发送时间: 2024年12月17日 17:01
收件人: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>;
'Dhruv Dhody' <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>>;
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>
主题: RE: [Pce] WGLC for draft-ietf-pce-sid-algo-15
Hi Aijun,
Please see inline <S>.
Thanks,
Samuel
From: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>
Sent: Tuesday, December 17, 2024 8:48 AM
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: 答复: [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?
<S> There may be multiple reasons, but one obvious example is inter-area path
computed by PCE and there is high chance that headend will see only topology
from local IGP instance.
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?
<S> PCEs can exchange such information between themselves, but existing
standard synchronization mechanisms like one defined in
draft-ietf-pce-state-sync also relies on forwarding PCRpt messages, so same
extension is still required anyway (and not all vendors implemented such
extension).
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.
<S> Can you point to specific parts of introduction section? What I can see in
introduction:
- Initial 2 sections talking about SR-algorithm in ERO
- 1 section talking about SR-algorithm constraint
- 1 section describing where definition and valid values of
SR-algorithms can be found
- 1 section talking about capabilities
- 1 section talking again about SR-algorithm constraint (this can be
potentially merged with previous statement talking about constraint)
Where PCEP extensions described in the document are:
- Section 3.1 – capabilities
- Sections 3.2 and 3.3 - SR-algorithm in ERO
- Section 3.4 – SR-algorithm constraint
- Section 3.5 – New metric values required to provide parity with IGP
metric types for Flex-algo
But I agree that maybe some details can be removed from introduction (e.g.
pointer to specific RFCs) and we can add more details about purpose.
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.
<S> Section 3 is describing PCEP extensions (enumerating them) and section 4 is
explaining how to use them. Please check it. If you are referring to Flex-algo
path-computation and TLVs/sub-TLVs used for advertising Flex-algo definition
and its content, then those are learned from IGP/BGP-LS and used in the
path-computation (out of scope of this document), but PCEP is used just for
encoding computed path (and accumulated metric).
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.
<S> At least my interpretation is that section is called “Introduction” because
its main goal is set the context and not to provide summary of changes and how
to use them, but I’ll think about re-phrasing it a bit.
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
--- Begin Message ---
A new version of Internet-Draft draft-ietf-pce-sid-algo-16.txt has been
successfully submitted by Samuel Sidor and posted to the
IETF repository.
Name: draft-ietf-pce-sid-algo
Revision: 16
Title: Carrying SR-Algorithm Information in PCE-based Networks.
Date: 2024-12-20
Group: pce
Pages: 23
URL: https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-16.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-pce-sid-algo/
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-pce-sid-algo
Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-sid-algo-16
Abstract:
The SR-Algorithm associated with a Segment-ID (SID) defines the path
computation algorithm used by Interior Gateway Protocols (IGPs).
This information is available to controllers, such as the Path
Computation Element (PCE), via topology learning. This document
proposes an approach for informing headend routers regarding the SR-
Algorithm associated with each SID used in PCE-computed paths, as
well as signaling a specific SR-Algorithm as a constraint to the PCE.
The IETF Secretariat
--- End Message ---
_______________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
