Thanks a lot Xiao for review and great comments.
Updated version submitted.
Regards,
Samuel
From: xiao.m...@zte.com.cn <xiao.m...@zte.com.cn>
Sent: Wednesday, August 14, 2024 3:21 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
HI Samuel,
Yes, the new text you proposed looks good to me.
Thank you for addressing all my comments.
Cheers,
Xiao Min
Original
From: SamuelSidor(ssidor) <ssi...@cisco.com<mailto:ssi...@cisco.com>>
To: 肖敏10093570;
Cc:
draft-ietf-pce-stateful-pce-vendor....@ietf.org<mailto:draft-ietf-pce-stateful-pce-vendor....@ietf.org>
<draft-ietf-pce-stateful-pce-vendor....@ietf.org<mailto:draft-ietf-pce-stateful-pce-vendor....@ietf.org>>;pce@ietf.org
<pce@ietf.org<mailto:pce@ietf.org>>;ops-...@ietf.org
<ops-...@ietf.org<mailto:ops-...@ietf.org>>;
Date: 2024年08月13日 19:40
Subject: RE: Opsdir early review of draft-ietf-pce-stateful-pce-vendor-04
Hi Xiao,
Would adding text like this at then end of section 4.6 address your remaining
comments?
“Section 6.6 of RFC7470 describes congestion mitigation methods for a PCC for
Stateless PCEP messages. A similar approach SHOULD be considered for Stateful
PCEP messages and for a PCE.
Encoding optimization for the Vendor Information Object, for example, in case
of the object with the same content encoded for multiple LSPs, is considered
out of the scope of this document and may be proposed in the future as a
separate document applicable to other PCEP objects.”
Would that work for you?
Thanks,
Samuel
From: xiao.m...@zte.com.cn<mailto:xiao.m...@zte.com.cn>
<xiao.m...@zte.com.cn<mailto:xiao.m...@zte.com.cn>>
Sent: Tuesday, August 13, 2024 9:38 AM
To: Samuel Sidor (ssidor) <ssi...@cisco.com<mailto:ssi...@cisco.com>>
Cc:
draft-ietf-pce-stateful-pce-vendor....@ietf.org<mailto:draft-ietf-pce-stateful-pce-vendor....@ietf.org>;
pce@ietf.org<mailto:pce@ietf.org>; ops-...@ietf.org<mailto:ops-...@ietf.org>
Subject: Re: Opsdir early review of draft-ietf-pce-stateful-pce-vendor-04
Hi Samuel,
Thanks for the new version and the clear responses.
Please see inline.
Original
From: SamuelSidor(ssidor) <ssi...@cisco.com<mailto:ssi...@cisco.com>>
To: 肖敏10093570;
Cc:
draft-ietf-pce-stateful-pce-vendor....@ietf.org<mailto:draft-ietf-pce-stateful-pce-vendor....@ietf.org>
<draft-ietf-pce-stateful-pce-vendor....@ietf.org<mailto:draft-ietf-pce-stateful-pce-vendor....@ietf.org>>;pce@ietf.org
<pce@ietf.org<mailto:pce@ietf.org>>;ops-...@ietf.org
<ops-...@ietf.org<mailto: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<mailto:xiao.m...@zte.com.cn>
<xiao.m...@zte.com.cn<mailto:xiao.m...@zte.com.cn>>
Sent: Monday, August 12, 2024 8:51 AM
To: Samuel Sidor (ssidor) <ssi...@cisco.com<mailto:ssi...@cisco.com>>
Cc:
draft-ietf-pce-stateful-pce-vendor....@ietf.org<mailto:draft-ietf-pce-stateful-pce-vendor....@ietf.org>;
pce@ietf.org<mailto:pce@ietf.org>; ops-...@ietf.org<mailto: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<mailto:ssi...@cisco.com>>
To: 肖敏10093570;
Cc:
draft-ietf-pce-stateful-pce-vendor....@ietf.org<mailto:draft-ietf-pce-stateful-pce-vendor....@ietf.org>
<draft-ietf-pce-stateful-pce-vendor....@ietf.org<mailto:draft-ietf-pce-stateful-pce-vendor....@ietf.org>>;pce@ietf.org
<pce@ietf.org<mailto:pce@ietf.org>>;ops-...@ietf.org
<ops-...@ietf.org<mailto: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<mailto:nore...@ietf.org>>
Sent: Tuesday, August 6, 2024 9:42 AM
To: ops-...@ietf.org<mailto:ops-...@ietf.org>
Cc:
draft-ietf-pce-stateful-pce-vendor....@ietf.org<mailto:draft-ietf-pce-stateful-pce-vendor....@ietf.org>;
pce@ietf.org<mailto: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.
--- Begin Message ---
A new version of Internet-Draft draft-ietf-pce-stateful-pce-vendor-05.txt has
been successfully submitted by Samuel Sidor and posted to the
IETF repository.
Name: draft-ietf-pce-stateful-pce-vendor
Revision: 05
Title: Conveying Vendor-Specific Information in the Path Computation Element
(PCE) Communication Protocol (PCEP) extensions for Stateful PCE.
Date: 2024-08-14
Group: pce
Pages: 12
URL:
https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-05.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-vendor/
HTML:
https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-05.html
HTMLized:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-pce-vendor
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-stateful-pce-vendor-05
Abstract:
A Stateful Path Computation Element (PCE) maintains information on
the current network state, including computed Label Switched Path
(LSPs), reserved resources within the network, and the pending path
computation requests. This information may then be considered when
computing new traffic engineered LSPs, and for any associated and
dependent LSPs, received from a Path Computation Client (PCC).
RFC 7470 defines a facility to carry vendor-specific information in
stateless Path Computation Element Communication Protocol (PCEP).
This document extends this capability for the Stateful PCEP messages.
The IETF Secretariat
--- End Message ---
_______________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
