Hi Haomian,
Thanks for prompting for comments and opinions.
I have read the latest version (-17) and have some thoughts. In
principle, this seems like a reasonable requirement and a neat solution.
It is a somewhat complicated use case that depends on the desire to
support various restoration schemes, but these are realistic in a high
function network, and I think it is worthwhile to facilitate them with a
PCE.
Cheers,
Adrian
= Minor =
The re-optimization example in Figure 1 is not convincing for two
reasons:
1. The more optimal LSP (LSP2) has more hops than the original LSP
(LSP0)
2. There are no shared resources between the original and optimised
LSPs.
But the use cases are convincing (it is just the example that isn't).
I suggest that you use something like ...
+------+ +------+ +------+
| N1 +----------+ N2 +-----X----+ N3 |
+--+---+ +---+--+ +---+--+
| | |
| +-----+ |
| | |
| +--+---+ |
| + N4 + |
| +---+--+ |
| | |
| +--+ |
| | |
| +------+ +----+-+ |
+-----+ N5 +----------+ N6 +-----+
+------+ +------+
Figure 1: Figure 1: A Single Domain Example
LSP0 (existing): N1-N2-N3.
LSP1 (restoration): N1-N2-N4-N6-N3.
LSP2 (re-optimization): N1-N5-N6-N3.
And that you talk about:
- LSP0 fails and is restored to LSP1 (shared resources on N1-N2)
- LSP1 is re-optimised to LSP2 (share resources on N6-N3)
---
The text around Figure 2 is clear (to me), but Figure 2 itself is very
unclear. It seems that (possibly) ... represents an LSP in the higher
layer, while --- represents a link in either layer. Thus, there is no
link H2-H2 or H2-H5.
I might be inclined to draw the network without the LSPs. As this...
----- ----- ----- ----- -----
| LSR |--| LSR | | LSR |--| LSR |--| LSR |
| H1 | | H2 | | H3 | | H4 | | H5 |
----- -----\ ----- ----- /-----
\ | /
\ | /
\ | /
\ ----- ----- /
| LSR |--| LSR | /
| L1 | | L2 | /
----- ----- /
| | /
| | /
----- ----- /
| LSR |--| LSR |/
| L3 | | L4 |
----- -----
Or possibly it just needs a key to explain the notation.
---
3.1 has "A sharing group should have multiple LSPs."
While I see the point of this, I don't think it needs to be said.
- When you request the first LSP, the group will have only one LSP.
- You have used lower case "should", so it is just advice.
---
3.1 has...
The number of LSPs and
the criteria for how LSPs share among each other are dependent on
local policy.
But I don't find this mentioned in section 5, and I would like to
understand whether this needs to be consistent across all cooperating
PCE, or even across all PCCs that might add LSPs to the group.
---
3.2
The PCEP Resource Sharing group MAY carry the following TLV. It MAY
be carried within a PCReq message from the network element (or other
PCCs) so as to indicate the desired resource sharing requirements to
be applied by the stateful PCE during path computation.
There's something wrong here.
- TLVs are carried in objects. In 3.3 we learn that the TLV can be
included in the Association Group Object.
- What is the PCEP Resource Sharing group?
- Surely all PCReq messages come from PCCs or PCEs.
---
7.2
I think you need to ask IANA to create a new registry for the bit flags.
Compare with other TLV flags fields.
= Nits =
idnits shows some issues with references:
- RFC 7399 is missing
- RFC 8751 is missing
- TBD2 in the figure in Section 3.2 should not appear in square brackets
---
Title
OLD
Path Computation Element Protocol
NEW
Path Computation Element Communication Protocol
END
---
All the figures name themselves twice. I think this is because the text
has the figure numbers, and XML is also adding them.
---
Final paragraph on page 3 is pissing a concluding period.
---
1.
s/The current protocol supporting the/The protocol that supports/
OLD
i.e. PCE Protocol (PCEP)
NEW
i.e., the Path Computation Element Communication Protocol (PCEP)
END
---
1.
OLD
Request (PCReq) message sent from a PCC to the PCE. To support this
type of resource sharing, a PCC needs to ask a PCE to compute a new
NEW
Request (PCReq) message sent from a PCC to the PCE.
To support resource sharing, a PCC needs to ask a PCE to compute a
new
END
---
1.
You have "smart quotes" after...
It is worth noting
---
1.
s/draft/document/
---
1.
OLD
Current PCEP specifications do not provide such function. More
specifically, this document
NEW
This document
END
---
The first para of page 6
- has smart quotes
- s/PCInitiate of RSVP/PCInitiate or RSVP-TE/
--
2.3 second line has smart quotes.
2.3 final paragraph uses smart quotes and a smart apostrophe.
---
2.3
Need to expand H-PCE on first use.
---
Figure 3 looks a bit messy. Perhaps....
+-------+
/| P-PCE |\
/ +---+---+ \
/ | \
/ | \
/ | \
/ | \
/ | \
/ | \
+------+ +---+--+ +------+
|C-PCE1| |C-PCE2| |C-PCE3|
+------+ +------+ +------+
/ | \
--------------- ------------------------- ------------
/ \ / \ / \
| +---+ +---+ | | +---+ +---+ +---+ | | +---+ +---+ |
| | A +---+ B +-+--+---+ D +---+ E +---+ H +---+--+-+ J +---+ L | |
| +---+ +---+ | | +---+ +---+ +---+ | | +---+ +---+ |
| \ | | / \ | | / |
| \ | | / \ | | / |
| \ | | / \ | | / |
| \+---+ | | +---+/ \| | +---+/ |
| | C +-+--+---+ G | +--+-+ K | |
\ +---+/ \ +---+ / \+---+ /
-------------- -------------------------- -------------
-----Original Message-----
From: Zhenghaomian <zhenghaomian=40huawei....@dmarc.ietf.org>
Sent: 13 January 2025 09:06
To: pce@ietf.org
Cc: pce-cha...@ietf.org
Subject: [Pce] 回复: I-D Action: draft-zhang-pce-resource-sharing-17.txt
Dear PCE Working Group,
This is a draft we having been working for years, and refreshed recently for
the resource sharing considerations in the path computation. We re-activate the
work given that there are more concerns on the reliability of the connection
together with the resource utility in the management. We look forward to see
the interests from WG experts and it would be greatly appreciated if you can
review and provide comments, thanks.
Best wishes,
Haomian
-----邮件原件-----
发件人: internet-dra...@ietf.org <internet-dra...@ietf.org>
发送时间: 2025年1月13日 16:57
收件人: i-d-annou...@ietf.org
主题: I-D Action: draft-zhang-pce-resource-sharing-17.txt
Internet-Draft draft-zhang-pce-resource-sharing-17.txt is now available.
Title: Extensions to the Path Computation Element Protocol (PCEP) to
Support Resource Sharing-based Path Computation
Authors: Xian Zhang
Haomian Zheng
Oscar Gonzales de Dios
Victor Lopez
Yunbin Xu
Name: draft-zhang-pce-resource-sharing-17.txt
Pages: 18
Dates: 2025-01-13
Abstract:
Resource sharing in a network means two or more Label Switched Paths
(LSPs) use common pieces of resource along their paths. This can
help save network resources and is useful in scenarios such as LSP
recovery or when two LSPs do not need to be active at the same time.
A Path Computation Element (PCE) is responsible for path computation
with such requirement.
Existing extensions to the Path Computation Element Protocol (PCEP)
allow one path computation request for an LSP to be associated with
other (existing) LSPs through the use of the PCEP Association Object.
This document extends PCEP in order to support resource-sharing-based
path computation as another use of the Association Object to enable
better efficiency in the computation and in the resultant paths and
network resource usage.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-zhang-pce-resource-sharing/
There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-zhang-pce-resource-sharing-17
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-zhang-pce-resource-sharing-17
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
I-D-Announce mailing list -- i-d-annou...@ietf.org To unsubscribe send an email
to i-d-announce-le...@ietf.org
_______________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
_______________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
