Hi Sue,
Thanks for your review.
On Fri, May 24, 2024 at 12:32 AM Susan Hares via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Susan Hares
Review result: Ready with Issues
GEN-ART review
Status: Ready with Issues
Type of issues: Technical issues + Editorial issues
General Comment: The authors should be commended for undertaking the
massive challenge of collecing the use cases for a PCE as a Central Controller.
This work will help guide future PCE work and interactions with other protocols.
🙏
Summary of technical issues:
1. BGP interactions are skipped in this document except for section 3.5
Section 3.5 does not clearly indicate the BGP Peer relationships with the RR.
Interactions of the PCE with the BGP Flow specification should be consider in
the PCE discussion for IP Native, SFC, SR, and Best Effor tPaths.
Dhruv: I have added some text. Also added a disclaimer - "It is interesting to note that some of the use cases listed can also be supported via BGP instead of PCEP. However, within the scope of this document, the focus is on the use of PCEP."
2. SRPM calculations to calculate Active Policy from a set of Candidate SR
Policy is not clearly mentioned
Dhruv: Added "<t>Note that an SR Policy can be associated with multiple candidate paths. A candidate path is selected when it is valid and it is determined to be the best path of the SR Policy as described in <xref target="RFC9256"/>.</t>"
3. Clear delination of which forwarding is being used IP native, IP native
over MPLS, SR-MPLS, or SRv6
is critical at each section. See editorial issues for the issues I found.
Dhruv: The text has been updated, thanks for pointing out.
4. The inclusion of individual drafts in the informative text is beneficial,
but
care must be taken to indicate whether the PCE WG is going to adopt any
particular solution.
Dhruv: Some of them are in the adoption queue but that does not guarantee they would gain consensus. I have made updates and made sure that those references remain informative-useful-pointers without claiming to be definitive extensions.
Editorial
1. Abstract, general comment
The abstract is 3 paragraphs which is 1 paragraph longer than normal.
The authors might look at shortening this abstract.
Dhruv: It borrows the structure from the related RFCs 8283 and 9050. I prefer keeping it in the same framing if that's okay.
2. Abstract, paragraph 2,
Issue: English Grammar, clarity
Old text: /
SDN has much broader applicability than signal MPLS traffic-
engineered (TE) paths and the PCE may be used to determine paths in a
range of use cases including static Label Switched Paths (LSPs),
Segment Routing (SR), Service Function Chaining (SFC), and most forms
of a routed or switched network. /
New text: /
SDN has much broader applicability than just signaling MPLS traffic-
engineered (TE) paths. The PCE functions may be used to determine paths
in a range of use cases including static Label Switched Paths (LSPs),
Segment Routing (SR), Service Function Chaining (SFC), and most forms
of a routed or switched network. /
Dhruv: I aligned it to RFC8283.
3. introduction, paragraph 1
Issue: Grammar, clarity.
Old text: / The role and function of PCE have grown to cover several
other uses (such as GMPLS [RFC7025], Multicast), and to allow
delegated stateful control [RFC8231] and PCE-initiated use of network
resources [RFC8281]./
Old text: / The role and function of PCE have grown to cover several
other uses (such as GMPLS [RFC7025] or Multicast), and to allow
delegated stateful control [RFC8231] and PCE-initiated use of network
resources [RFC8281]./
Ack
4. Terminology:
I suggest you add the following definitions to aid readability.
Centralized Controller, BGP-LS [RFC9952], SR, Failure recovery, node-SID,
Adj-SID, LSP PST, SRGB, SRLB, failure recovery,
Dhruv: I have added a few of these.
5. Title in 3.1
old title:/ PCEEC for Label Management/
New title:/ PCE for MPLS Label Management/
Ack
6. section 3.1, paragraph 3,
Why: Need reference for BGP-LS
old text:/
The full SRGB/SRLB of a node could be learned via existing
IGP or BGP-LS mechanisms too./
New text:/
The full SRGB/SRLB of a node could also be learned via existing
IGP or BGP-LS [RFC9552] mechanisms./
Ack
7. section 3.2, paragraph 1.
Why: provide reference to Segment routing the first time used.
old text:/Segment Routing (SR) leverages the source routing paradigm./
New text:/Segment Routing (SR) [RFC8402] leverages the source routing paradigm.
/
Ack
8. section 3.2 paragraph 2,
issue: Missing reference to inter-domain. SR and the rest of the document
mentions inter-domain. It should be added here for clarity.
Old text:/
A database of segments can be distributed
through the network using a routing protocol (such as IS-IS or OSPF)
or by any other means. PCEP (and PCECC) could also be one of them./
new text: / A database of segments can be distributed
through the network using a intra-domain routing protocol (such as IS-IS or
OSPF) or an inter-domain protocol (BGP), or by any other means. PCEP (and
PCECC) c ould also be one of other protocols. /
Ack, with slight modification.
8. section 3.2 paragraph 4,
issue: no references for SR-TE. Which specificaion do you mean?
old text:/[RFC8355] identifies various protection and resiliency usecases for
SR. Path protection lets the ingress node be in charge of the
failure recovery (used for SR-TE)./
Used RFC 8664.
9. section 3.2.1, title and text
issue: The text taughts about label allocation and adds at the end
-15-text: /The forwarding behaviour and the end result are similar to IGP-based
Adj-
SID allocation and usage in SR./
If you are allocating SID for SR-MPLS and SRv6, this section has confusing
text. I suggest you rework to either be SR-MPLS and SRv6.
If this is not your intent, rename the title to PCEE SID Allocation for
SR-MPLS.
Ack, updated the title.
10. section 3.2.2 - description of packets, title.
Issue: What do you mean by "top of the packet"? Does this fit SR-MPLS and
SRv6?
Old text-1:/ The ingress router
of the forwarding path needs to encapsulate the destination Node-SID
on top of the packet. /
old-text-2:/
R1 may send a packet to R8 simply by pushing an SR label with segment
{1008} (Node-SID for R8). /
If you are just doing SR-MPLS, then change both the text and the title.
Ack, updated text/title.
11. section 3.2.3, paragraph 1, sentence 3 - run-on sentence
Grammar: Run on sentence. A semi-colon mans the two half of the sentence are
equal.
"hence" gives a conclusion which means the two halfs of the sentence are not
equal. If __-, hence ___.
Old text:/ The header has all necessary information so that, the
packets can be guided from the ingress node to the egress node of the
path; hence, there is no need for any signalling protocol. /
New text:/The header has all necessary information so that the
packets can be guided from the ingress node to the egress node of the
path. Hence, there is no need for any signalling protocol. /
[professor hat on]: (explanation) Grammar rules suggest the
removal of the semi-colon and addition of a period. This creates two clear
sentences linked together with hence. [professor hat off]
Ack.
12. section 3.2.2, paragraph 3
issue: Support in 3.2.1 for the allocations for SRv6 is weak
Current text:/
To achieve this, the PCECC first allocates and distributes SIDs as
described in Section 3.2.1. [RFC8664] describes the mechanism for a
PCE to compute, update, or initiate SR-TE paths./
What: SRv6 is included in [RFC8664]? if you decide to make 3.2.1 only
SR-MPLS, you will need to change this section.
Ack, made the text about SR-MPLS
13. section 3.2.3.1, paragraph 6
Issue: reference clarity and sentence clarity.
current text:/ The procedure:
PCECC allocates Node-SIDs and Adj-SIDs as described in Section 3.1
for all nodes and links./
New text:/
The procedure:
PCECC allocates Node-SIDs and Adj-SIDs using the mechanism described
in Section 3.2.1 for all nodes and links./
Problem: Allocations of Node-SIDs and Adj-SIDs are described in section 3.2.1.
If this is the correction section then the new text above fits.
If it is not, please rework the sentence.
Ack
14. Section 3.2.3.1, list of policies:
Issue: The calculation of the active SR Policy from a set of
SR Candidate policies is missing. (technical or editorial)
Current Text:/
PCECC will form both SR Policies POL1 and POL2.
PCECC will send both POL1 and POl2 to R1 via PCEP.
PCECC optionally can allocate BSIDs for the SR Policies.
/
Dhruv: I have added this text at the end "<t>Note that an SR Policy can be associated with multiple candidate paths. A candidate path is selected when it is valid and it is determined to be the best path of the SR Policy as described in <xref target="RFC9256"/>.</t>"
15. Section 3.2.4
issue: State "will be" for an individual drafts
Current text: /PCECC PCEP extensions
for SRv6 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] will be
used for that./
Possible text: / An example of how PCECC PCEP extensions could be
extended for SRv6 is in:
[I-D.dhody-pce-pcep-extension-pce-controller-srv6]./
Ack
16. section 3.4, paragraph 3
issue: draft-ietf-idr-mpls-seamless-mpls is a "dead" document.
What to do: Check with MPLS WG to see what is replacing this document.
It is still the best informative reference for seamless MPLS
17. section 3.5, BGP reference
old text:/ * Since PCECC needs to know the topology of both domains AS1 and
AS2, PCECC can utilize the BGP-LS peering with routers (or RRs) in
both domains./
New text:/ * Since PCECC needs to know the topology of both domains AS1 and
AS2, PCECC can utilize the BGP-LS peering with BGP routers (or RRs) in
both domains./
Ack
18. section 3.5
issue: Clarity of what is done for SRv 6, paragraph 8, bullet 4
old text:/
* PCECC will send PCInitiate message [RFC8281] towards the ingress
router R1 (PCC) in AS1 and receive the PCRpt message [RFC8231]
back from it. If the PST is PCECC-SR, the PCECC will include the
SID stack as per [RFC8664]. Optionally, a binding SID or BGP
Peering-SID [RFC9087] can also be included on the AS boundary.
The backup SID stack can be installed at ingress R1 but more
importantly, each node along the SR path could also do the local
protection just based on the top segment. If the PST is PCECC
(basic), when the PCECC will assign labels along the calculated
paths (R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3); and set up the path
by sending central controller instructions in PCEP message to each
node along the path of the LSPs as per [RFC9050]. Then PCECC will
send a PCUpd message to the ingress R1 router with information
about new LSPs and R1 will respond by PCRpt with LSP(s) status./
Suggested change:/
* PCECC will send PCInitiate message [RFC8281] towards the ingress
router R1 (PCC) in AS1 and receive the PCRpt message [RFC8231]
back from it.
* If the PST is PCECC-SR, the PCECC will include the
SID stack as per [RFC8664]. Optionally, a binding SID or BGP
Peering-SID [RFC9087] can also be included on the AS boundary.
The backup SID stack can be installed at ingress R1 but more
importantly, each node along the SR path could also do the
local protection just based on the top segment.
* If the PST is PCECC (basic), the PCECC assigns labels
along the calculated paths (R1-ASBR1-ASBR3-R3,
R1-ASBR5-ASBR6-R3) and sets up the path by sending central
controller instructions in PCEP message to each node along
the path of the LSPs as per [RFC9050]. After these steps,
the PCECC will send
a PCUpd message to the ingress R1 router with information
about new LSPs and R1 will respond by PCRpt with LSP(s) status./
Ack
19. Section 3.6.1, step 2 sentence.
Issue: Grammar - spacing and period in the sentence.
old text:/ Step 2: When R2 receives the packet with label 9000, it will
forward it to R4 by swapping label 9000 to 9001 and at the same
time, it will replicate the packet and swap the label 9000 to
9002 and forward it to R5/
New text:/Step 2: When R2 receives the packet with label 9000, it will
forward it to R4 by swapping label 9000 to 9001 and at the same
time, it will replicate the packet and swap the label 9000 to
9002 and forward it to R5./
Ack
20. Section 3.7, paragraph 1, sentence 2
Old text: It applies in many scenarios including MPLS
traffic engineering (where it determines what traffic is forwarded
into which LSPs); segment routing (where it is used to select which
set of forwarding instructions (SIDs) to add to a packet); SFC (where
it indicates how a packet should be forwarded across which service
function path )./
New text: It applies in many scenarios including the following:
a) MPLS traffic engineering (where it determines what traffic
is forwarded into which LSPs),
b) segment routing (where it is used to select which
set of forwarding instructions (SIDs) to add to a packet),
c) SFC (where it indicates how a packet should be forwarded
across which service function path ). /
Ack
21. Section 3.8 + 3.9 - missing content for Flow filters - BGP Flow
Specification + configured
The technical issue about SFC flow classification via
configured filters or BGP Flow Specification filters could be resolved
in this section.
Similarly, the Flow specification filters might be mentioned in section 3.9.
It would be good to know how to combine PCECC and these other common functions.
Dhruv: Added this text in 3.7 - "<t>The description of traffic flows by the combination of multiple Flow Specification components and their dissemination as traffic flow specifications (Flow Specifications) is described for BGP in <xref target="RFC8955"/>". When a PCECC is used to initiate tunnels (such as TE-LSPs or SR paths) using PCEP, it is important that the head end of the tunnels understands what traffic to place on each tunnel. <xref target="RFC9168"/> specifies a set of extensions to PCEP to support the dissemination of Flow Specification components where the instructions are passed from the PCECC to the routers using PCEP.</t>"
Added a reference to Section 3.7 in Section 3.8.
I did not make a change in Section 3.9 as the text in Section 3.7 applies to all path setup types including Native-IP.
22. informative references
The AD and Shephed should evaluate the use of:
1) individual drafts - as indicating a direction for PCE or just an example,
2) draft-ietf-mpls-seamless-mpls - as it is a IESG dead draft
Dhruv: Not directed towards the authors but I made text changes for 1) and 2) has been informatively referenced before and is still the best reference for seamless MPLS.
23. Appendix A.
Do the proposed phases for MapReduce-Hadoop align with PCE milestones and plans?
Dhruv: There are no changes in the protocol required it is an applicability statement or use case in a new environment where PCEP is not typically used.
Thanks,
Dhruv
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
