Hi Ben,
Thank you very much for your further valuable comments and suggestions.
They should have been addressed in version 24 uploaded. Inline below are my
explanations.
Best Regards,
Huaimo
________________________________
From: Benjamin Kaduk via Datatracker <[email protected]>
Sent: Thursday, August 6, 2020 10:24 PM
To: The IESG <[email protected]>
Cc: [email protected]
<[email protected]>; [email protected]
<[email protected]>; [email protected] <[email protected]>; Adrian Farrel
<[email protected]>; [email protected] <[email protected]>
Subject: Benjamin Kaduk's Discuss on
draft-ietf-pce-stateful-pce-lsp-scheduling-22: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-pce-stateful-pce-lsp-scheduling-22: Discuss
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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C77e5a8e196f9405b19f808d83a78f6f4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637323638504477582&sdata=Qbc5Va%2BmQottFqMBHI6%2BycUle3BhkWfxushrS3qFvQ8%3D&reserved=0
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-pce-stateful-pce-lsp-scheduling%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7C77e5a8e196f9405b19f808d83a78f6f4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637323638504477582&sdata=My4fM%2BqPZCPeYIRAFragD9ZRgy40vAkIguq474QA5Nk%3D&reserved=0
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Thanks for addressing my first two discuss points from the -19; it looks
like the last one is still remaining (please note that I had a typo in my
original ballot on the -19, referring to a section 3.3 when 7.3.3 was intended):
Section 6.6 refers to the "LSP-ERROR-CODE TLV (Section 7.3.3) which is
not defined in this document, rather, the reference should be to ยง 7.3.3
of RFC 8231.
[HC]: We have changed it to "Section 7.3.3 of [RFC8231]" as you suggested
(in version 23).
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
I have some new comments after reviewing the diff from -19 to -22.
(Signs indicate that processing of my previous comments is still
underway; if there's a need to refer to them they are available in the
email archives and in the 'history' tab for the document in the
datatracker.)
Section 4.1
For a scheduled LSP crossing multiple domains from an ingress domain
to an egress domain. There is a PCE responsible for each of these
domains. The PCE for the ingress domain is called ingress PCE. The
PCE for the egress domain is called egress PCE. The state of the LSP
MUST be synchronized among these PCEs. After a path for the LSP is
computed, a PCRpt message with the scheduled LSP information MUST be
sent to every PCE along the path from the ingress PCE to the egress
PCE. After receiving the PCRpt message, the PCE MUST update its
SLSP-DB according to the scheduled LSP information. The ingress PCE
acting as a PCC sends its next hop PCE the PCRpt message. After
receiving the PCRpt message, the next hop PCE acting as a PCC sends
its next hop PCE the PCRpt message. This continues until the egress
PCE receives the PCRpt message.
A bunch of nits here. How about
% Additional requirements apply when a scheduled LSP crosses multiple
% domains, from an ingress domain to an egress domain. There is a PCE
% responsible for each of these domains. The PCE for the ingress
% domain is called the ingress PCE. The PCE for the egress domain is
% called the egress PCE. The state of the LSP MUST be synchronized
% among all PCEs along the path. To achieve this, after a path for the
% LSP is computed, a PCRpt message with the scheduled LSP information
% MUST be sent to every PCE along the path from the ingress PCE to the
% egress PCE. After receiving the PCRpt message, each PCE MUST update
% its SLSP-DB according to the scheduled LSP information. The ingress
% PCE acting as a PCC sends its next hop PCE the PCRpt message. After
% receiving the PCRpt message, the next hop PCE acting as a PCC sends
% its next hop PCE the PCRpt message. This continues until the egress
% PCE receives the PCRpt message.
[HC]: The paragraph has been changed to talk about synchronization
among the PCEs in one domain as suggested (in version 23).
Section 4.3
o The stateful PCE MUST update its local scheduled LSP-DB and
scheduled TED with the scheduled LSP. Besides, it MUST send a
PCRpt message with the scheduled LSP to its next hop PCE along the
path of the LSP, so as to achieve the scheduling traffic
engineering information synchronization.
nit: I think s/Besides/Additionally/
[HC]: We have changed it to Additionally in version 24.
Section 5.1
During a PCEP session has been established, a PCC and a PCE indicates
its ability to support LSP scheduling during the PCEP session
establishment phase. [...]
Some nits here; maybe:
% During the PCE session establishment phase, a PCC and PCE indicate
% their ability to support LSC scheduling. [...]
[HC]: We have rephrased the text accordingly in version 24.
Section 5.2
Only one SCHED-LSP-ATTRIBUTE TLV SHOULD be present in the LSP object.
In case more than one SCHED-LSP-ATTRIBUTE TLV is found, the first
instance is processed and others ignored. The SCHED-PD-LSP-ATTRIBUTE
TLV is the same as the SCHED-LSP-ATTRIBUTE TLV regarding to its
presence in the LSP object.
The new text here has changed what I interpret it to mean.
I interpret the text in the -22 as allowing for an LSP that includes one
SCHED-LSP-ATTRIBUTE and one SCHED-PD-LSP-ATTRIBUTE TLV in the same LSP,
whereas the text from the -19 seemed to indicate that if (e.g.) I had a
periodic scheduling TLV then the regular SCHED-LSP-ATTRIBUTE was
forbidden. After just a cursory amount of thought, it seems like there
is not a useful way to interpret both TLVs at the same time, which would
make this text change a regression, but I may be missing something.
[HC]: These two TLVs MUST NOT be for the same LSP. We have added the
text to explain this and rephrased the related text (in version 24).
Section 5.2.2
STATEFUL-PCE-CAPABILITY TLV carried in open message. If the TLV is
received by a peer when both bits were not set, the peer MUST ignore
the TLV and generate a PCEP Error (PCErr) with a PCEP-ERROR object
having Error-type = 4 (Not supported object) and Error-value = 4
(Unsupported parameter).
(nit) English has this unfortunate property where the "not set" in "both
bits were not set" can be interpreted as a synonym for "unset", which
would make "both bits were not set" mean that this is describing the
case where B=0 and PD=0. What we actually mean is "anything other than
(B=1,PD=1)", which might be expressed as "If the TLV is received by a
peer when either (or both) bit is not set".
[HC]: We have changed it accordingly (in version 24).
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
