Hi Samuel,
Thanks for the new version and the clear responses.
Please see inline.
Original
From: SamuelSidor(ssidor) <ssi...@cisco.com>
To: 肖敏10093570;
Cc: draft-ietf-pce-stateful-pce-vendor....@ietf.org
<draft-ietf-pce-stateful-pce-vendor....@ietf.org>;pce@ietf.org
<pce@ietf.org>;ops-...@ietf.org <ops-...@ietf.org>;
Date: 2024年08月12日 15:41
Subject: RE: Opsdir early review of draft-ietf-pce-stateful-pce-vendor-04
Hi Xiao,
Sorry for delay, most of issues/comments should be fixed in attached version.
Please see responses for remaining issues/comments:
Your comment:
" Section 3, my first feeling is that this section should list all Stateful
PCEP objects in which the Vendor Information TLV may be contained, however
after checking Section 3 of RFC 7470, I found it says "Further specifications
are needed to define the position and meaning of the Vendor Information TLV for
specific PCEP objects". Then I think this section should either define the
Vendor Information TLV for each Stateful PCEP object or state something like
what's said in Section 3 of RFC 7470"
Response:
This draft is only about carrying the <VENDOR-INFORMATION> object in stateful
PCEP messages, it does not make any changes to VENDOR-INFORMATION-TLV
processing, where RFC 7470 continues to apply. The draft is even explicitly
inheriting all rules from Section 3 of RFC 7470 (see: "All the procedures are
as per section 3 of [RFC7470].")
[XM]>>> OK, that's fine.
Your comment:
" Section 4.6, compared to what's said in Section 6.6 of RFC 7470, it seems
what's said here is a little bit too simple."
Response:
Based on Section 4 of this draft, all manageability requirements and
considerations are inherited from RFC7470 (and from other RFCs), including that
longer text from Section 6.6. Are you missing any specific recommendation?
[XM]>>> In Section 6.6 of RFC 7470, it seems that the provided mitigation
method covers only the direction from PCC to PCE, then how about from PCE to
PCC?
Your comment:
"Considering that multiple Vendor Information Objects/TLVs of multiple LSPs can
be carried in the Stateful PCEP messages, it can be imagined that in some cases
the amount of Vendor Information would become too huge to be processed by the
receiver timely. In other words, some kind of congestion may happen due to the
added Vendor Information. So it's helpful to the reader/implementer if some
mitigation method can be provided here."
Response:
There is no change against RFC7470, where multiple requests with Vendor
Information object could be also included in single PCReq message. Individual
vendors are not exposing structure of their Vendor Information Objects, so it
is not expected (or it will really rare) that some specific implementation will
include Vendor Information Object from different vendor. Section 6.1 of RFC7470
(which is inherited by this draft) is also proposing that inclusion of vendor
specific information may be configurable, so it can be disabled if not really
needed (e.g. if vendor of PCC and PCE are not same and including vendor
specific information is useless). There was also recent discussion about
potentially optimizing encoding of Vendor Information object, but conclusion
seems to be that if any optimization needs to be done, then it should be
generic optimization applicable to other PCEP objects, which is out of scope of
this draft.
[XM]>>> Thank you for the detailed explanation. If appropriate, some text on
potential out-of-scope optimization can be added here, it's up to you. :-)
Cheers,
Xiao Min
Thanks a lot,
Samuel
From: xiao.m...@zte.com.cn <xiao.m...@zte.com.cn>
Sent: Monday, August 12, 2024 8:51 AM
To: Samuel Sidor (ssidor) <ssi...@cisco.com>
Cc: draft-ietf-pce-stateful-pce-vendor....@ietf.org; pce@ietf.org;
ops-...@ietf.org
Subject: Re: Opsdir early review of draft-ietf-pce-stateful-pce-vendor-04
OK, no problem. :-)
Looking forward to your new version and more discussion if needed.
Cheers,
Xiao Min
Original
From: SamuelSidor(ssidor) <ssi...@cisco.com>
To: 肖敏10093570;
Cc: draft-ietf-pce-stateful-pce-vendor....@ietf.org
<draft-ietf-pce-stateful-pce-vendor....@ietf.org>;pce@ietf.org
<pce@ietf.org>;ops-...@ietf.org <ops-...@ietf.org>;
Date: 2024年08月07日 20:40
Subject: RE: Opsdir early review of draft-ietf-pce-stateful-pce-vendor-04
Thanks a lot Xiao for review and comments.
We are discussing changes required to the draft with co-authors. We will get
back to you soon.
Regards,
Samuel
-----Original Message-----
From: Xiao Min via Datatracker <nore...@ietf.org>
Sent: Tuesday, August 6, 2024 9:42 AM
To: ops-...@ietf.org
Cc: draft-ietf-pce-stateful-pce-vendor....@ietf.org; pce@ietf.org
Subject: Opsdir early review of draft-ietf-pce-stateful-pce-vendor-04
Reviewer: Xiao Min
Review result: Has Issues
Summary: I've reviewed this document and I believe this document is on the
right track. I have no major concern but several minor ones. Besides, there are
a number of nits and ungrammatical sentences, I'm also not good at this, so
just to name a few.
Major issues: None.
Minor issues: As below.
Section 2, it says "Different instances of the object can have different
Enterprise Numbers". I believe a normative language is more suitable than
*can*, MUST or MAY? It's supposed to be MAY. Section 3, my first feeling is
that this section should list all Stateful PCEP objects in which the Vendor
Information TLV may be contained, however after checking Section 3 of RFC 7470,
I found it says "Further specifications are needed to define the position and
meaning of the Vendor Information TLV for specific PCEP objects". Then I think
this section should either define the Vendor Information TLV for each Stateful
PCEP object or state something like what's said in Section 3 of RFC 7470.
Section 4.2, it says "Any standard YANG module will not include details of
vendor-specific information", and then it provides a suggestion on how the
standard YANG module MAY be extended. I assume the mentioned extension applies
only to a proprietary YANG module, if that's the case, then I don't see much
value to mention the extension. Section 4.6, compared to what's said in Section
6.6 of RFC 7470, it seems what's said here is a little bit too simple.
Considering that multiple Vendor Information Objects/TLVs of multiple LSPs can
be carried in the Stateful PCEP messages, it can be imagined that in some cases
the amount of Vendor Information would become too huge to be processed by the
receiver timely. In other words, some kind of congestion may happen due to the
added Vendor Information. So it's helpful to the reader/implementer if some
mitigation method can be provided here.
Nits/editorial comments: As below.
Abstract Section, s/may then be/may be then.
Section 1, s/(LSP-DB)/(LSP-DB)); s/added new messages in PCEP/add new messages
to PCEP; s/[RFC7470] defined/[RFC7470] defines; s/It also defined/It also
defines; s/to also include/to include. Section 2, s/be used on a single PCRpt
message/be contained in a single PCRpt message. Section 3, SRP needs expansion
in first use; s/All the procedures as per/All the procedures are as per;
s/defines the Enterprise Numbers are allocated by IANA/defines the Enterprise
Numbers allocated by IANA; s/clarifies that the IANA registry described
is/clarifies that what the IANA registry describes is. Section 4.4, s/Verify
Correct Operations/Verifying Correct Operations. Section 7, s/PCEP also
support/PCEP also supports.
_______________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
