Just to keep mail thread updated – new version (08) with proposed version
submitted.
If more changes will be needed, we can still submit another one.
Regards,
Samuel
From: Samuel Sidor (ssidor) <ssidor=40cisco....@dmarc.ietf.org>
Sent: Tuesday, September 24, 2024 11:12 AM
To: Dhruv Dhody <d...@dhruvdhody.com>; Roman Danyliw <r...@cert.org>
Cc: pce@ietf.org; xiao.m...@zte.com.cn
Subject: [Pce] Re: AD Review of draft-ietf-pce-stateful-pce-vendor-07
Thanks Roman for review and thanks Dhruv for response.
Updated version attached.
Roman – please let me know if updated version satisfies all your comments, I
can submit it then.
Regards,
Samuel
From: Dhruv Dhody <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>>
Sent: Monday, September 23, 2024 11:01 AM
To: Roman Danyliw <r...@cert.org<mailto:r...@cert.org>>
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: [Pce] Re: AD Review of draft-ietf-pce-stateful-pce-vendor-07
Hi Roman,
Thanks for taking the responsible AD role for this I-D.
On Fri, Sep 20, 2024 at 7:56 PM Roman Danyliw
<r...@cert.org<mailto:r...@cert.org>> wrote:
Hi!
I performed an AD review of draft-ietf-pce-stateful-pce-vendor-07. To help
load balance AD document queues, I'll be taking over as responsible AD.
Thanks for this document. My feedback is below:
** Is there a reason why this document does not formally updated RFC8231 and
RFC8281 given the text in Section 2?
Dhruv: This is the case of "Extends" as per draft-kuehlewind-rswg-updates-tag.
Within PCE WG, we have not used "Updates" to mean "extends" and doing it now
will just create more confusion.
** Section 2. I’m not confident in my understanding of RFC5511 models. Where
is the reference or explanation of this value: <VENDOR-INFORMATION> in this
document?
Dhruv: That would be Vendor Information object from RFC 7470. This is
understandable to anyone with understanding of PCEP RBNF.
** Section 2. Consider provide specific section references when OLD/NEW text
is provided.
Dhruv: Thanks for these, makes sense to include section numbers!
<snip>
** Section 2. Per the definition of PCInitiate, RFC8281 included the text
“<Common Header> is defined in RFC 5440”. Should that be used here?
Dhruv: The <Common Header> is common to all PCEP messages and well understood.
In the case where we are simply extending the messages and the initial message
is specified in existing RFC, we have not used that text. For the sake of
uniformity, prefer to keep it that way.
** Section 4.2
Any
standard YANG module will not include details of vendor-specific
information.
What is a “standard” YANG module?
Dhruv: That would be to differentiate with vendor-specific YANG extensions. RFC
7470 uses similar phrasing.
** Section 4.6
Section 6.6 of [RFC7470] highlights how the presence of additional
vendor-specific information in PCEP messages may congest the
operations and how to detect and handle it. A similar approach
SHOULD be considered for Stateful PCEP messages and for a PCE.
What does it mean when an approach “SHOULD be considered”? SHOULD is already
conveying that this behavior is optional. Can the desired behavior please be
more tangibly described?
Dhruv: How about rephrasing this way -
This also applies to stateful PCEP messages as outlined
in Section 2. Specifically, a PCEP speaker SHOULD NOT
include vendor information in a stateful PCEP message
if it believes the recipient does not support that
information.
Authors, if you disagree, please feel free to jump in!
Thanks!
Dhruv (Document Shepherd)
Regards,
Roman
_______________________________________________
Pce mailing list -- pce@ietf.org<mailto:pce@ietf.org>
To unsubscribe send an email to pce-le...@ietf.org<mailto:pce-le...@ietf.org>
--- Begin Message ---
A new version of Internet-Draft draft-ietf-pce-stateful-pce-vendor-08.txt has
been successfully submitted by Samuel Sidor and posted to the
IETF repository.
Name: draft-ietf-pce-stateful-pce-vendor
Revision: 08
Title: Conveying Vendor-Specific Information in the Path Computation Element
(PCE) Communication Protocol (PCEP) extensions for Stateful PCE.
Date: 2024-09-26
Group: pce
Pages: 12
URL:
https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-08.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-08.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-08
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 PCE Communication Protocol (PCEP) messages.
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
