Dear editors,
I have resolved all the questions inline with your email starting with
"weiyh>>>", I appreciate your further comments.
In adition, I believe in "5.10. In-Band Reachability of Nodes",
"-- the spine nodes in Figure 9 -- " SHOULD BE "-- the spine nodes in Figure
11 -- "
Thank you!
Best Regards,
Yuehua Wei
Original
From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>
To: 魏月华00019655;张征00007940;f...@yandex-team.ru
<f...@yandex-team.ru>;pthub...@cisco.com <pthub...@cisco.com>;p...@juniper.net
<p...@juniper.net>;
Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>;rift-...@ietf.org
<rift-...@ietf.org>;rift-cha...@ietf.org
<rift-cha...@ietf.org>;zzh...@juniper.net
<zzh...@juniper.net>;james.n.guich...@futurewei.com
<james.n.guich...@futurewei.com>;auth48archive@rfc-editor.org
<auth48archive@rfc-editor.org>;
Date: 2024年12月12日 08:21
Subject: Re: AUTH48: RFC-to-be 9696 <draft-ietf-rift-applicability-17> for your
review
Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the XML file.
1) <!-- [rfced] Please note that the title of the document has been updated to
expand "RIFT" per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please
review.
Original:
RIFT Applicability and Operational Considerations
Current:
Routing in Fat Trees (RIFT) Applicability and Operational Considerations
-->
weiyh>>>Good!
2) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
weiyh>>>no more keywords.
3) <!-- [rfced] To avoid repetition and make the text more concise, we have
updated the following sentences in Section 2. Please let us know any
objections.
Original:
This document uses the terminology of RIFT [RIFT]. The most
frequently used terminologies defined in RIFT are listed here. These terms
are consistent with definition in RIFT [RIFT]
Current:
This document uses the terminology defined in [RIFT]. The most
frequently used terms and their definitions from that document are listed
here.
-->
weiyh>>>no objections.
4) <!-- [rfced] What is "vice versa" referring to in this sentence?
Original:
If links in a Clos are considered as either being all directed
towards the top or vice versa, each of such two graphs is a DAG.
Perhaps:
If links in a Clos are considered as either being all directed
towards the top or bottom, each of such two graphs is a DAG.
-->
weiyh>>>no objections.
5) <!-- [rfced] We are unable to verify if the term "homonym" is used correctly
in [FATTREE]. May we rephrase the following sentence for accuracy?
Original:
Clos [CLOS] topologies (called commonly a fat tree/network in modern
IP fabric considerations as homonym to the original definition of the
term Fat Tree [FATTREE]) have gained prominence in today's
networking, primarily as a result of the paradigm shift towards a
centralized data-center based architecture that deliver a majority of
computation and storage services.
Perhaps:
Clos [CLOS] topologies (commonly called a Fat Tree/network in modern
IP fabric considerations as a similar term for the original definition of the
term Fat Tree [FATTREE]) have gained prominence in today's
networking, primarily as a result of the paradigm shift towards a
centralized data-center-based architecture that delivers a majority of
computation and storage services.
-->
weiyh>>>no objections.
6) <!-- [rfced] May we specify "link-state" and "distance-vector" for clarity in
the following instances?
Original:
RIFT combines the advantage of both link-state and distance-vector...
RIFT also eliminates major disadvantages of link-state and distance-vector
with...
Perhaps:
RIFT combines the advantages of both link-state and distance-vector
protocols...
RIFT also eliminates major disadvantages of link-state and distance-vector
protocols...
-->
weiyh>>>no objections.
7) <!-- [rfced] Some author comments are present in the XML. Please confirm that
no updates related to these comments are outstanding. Note that the
comments will be deleted prior to publication.
-->
weiyh>>>confirmed.
8) <!-- [rfced] May we update the following sentence for clarity? Additionally,
should "employed" be updated to "deployed"? We note that this is the only
instance of "employed" that appears in the document.
Original:
A full-mesh connectivity between nodes on the same level can be
employed and that allows N-SPF to provide for any node losing all its
northbound adjacencies (as long as any of the other nodes in the
level are northbound connected) to still participate in northbound
forwarding.
Perhaps:
A full-mesh connectivity between nodes on the same level can be
deployed, which allows North SPF (N-SPF) to provide for any node losing all
its
northbound adjacencies (as long as any of the other nodes in the
level are northbound connected) and still participate in northbound
forwarding.
-->
weiyh>>>Yes, "deployed" is better.
9) <!-- [rfced] Should "Link State" be specified as "link-state protocols" here?
Original:
In that case, RIFT operates very much like RPL [RFC6550], but using
Link State for southbound routes (downwards in RPL's terms).
Perhaps:
In that case, RIFT operates very much like RPL [RFC6550], but uses
link-state protocols for southbound routes (downwards in RPL's terms).
-->
weiyh>>>if "link-state" is too brief, maybe say, "but uses link-state
information for southbound routes (downwards in RPL's terms)."
10) <!-- [rfced] May we rephrase the following sentence for ease of the reader?
Original:
RIFT is suited for applying in data center (DC) IP fabrics underlay
routing, vast majority of which seem to be currently (and for the foreseeable
future) Clos architectures.
Perhaps:
RIFT is suited for applying underlay routing in data center (DC) IP
fabrics, with the vast majority of these IP fabrics being Clos architectures
(and will be for the foreseeable future).
-->
weiyh>>>Good!
11) <!-- [rfced] To match [TR-384], may we update "leaf and spine fabric" to
"leaf-spine fabric"?
Original:
The two I/O modules are interconnected by a leaf and spine fabric [TR-384].
Perhaps:
The two I/O modules are interconnected by a leaf-spine fabric [TR-384].
-->
weiyh>>>since "spine-and-leaf" is widely used in this rfc, I'd prefer "The two
I/O modules are interconnected by a spine-and-leaf fabric [TR-384]."
12) <!-- [rfced] May we rephrase and break up the following sentence to
improve readability?
Original:
* RIFT reduces FIB size towards the bottom of the IP fabric where
most nodes reside and allows with that for cheaper hardware on the
edges and introduction of modern IP fabric architectures that
encompass e.g. server multi-homing.
Perhaps:
* RIFT reduces FIB size towards the bottom of the IP fabric where
most nodes reside. This allows for cheaper hardware on the
edges and introduction of modern IP fabric architectures that
encompass server multihoming and other mechanisms.
-->
weiyh>>>Good!
13) <!-- [rfced] We note that the following instances of text are repeated at
the end of Sections 5.1 and following Figure 4 in Section 5.2. Should the text
in Section 5.2 be removed to avoid repetition?
Original (Section 5.1):
In an equivalent fashion, as the result of the south
reflection between Spine121-Leaf121-Spine122 and Spine121-Leaf122-Spine122,
Spine121 and Spine 122 knows each other at level 1.
Original (Section 5.2):
As shown in Figure 4, as the result of the south
reflection between Spine121-Leaf121-Spine122 and Spine121-Leaf122-Spine122,
Spine121 and Spine 122 knows each other at level 1.
-->
weiyh>>>Good catch! I suggest to replace "as the result of the south reflection
between Spine121-Leaf121-Spine122 and Spine121-Leaf122-Spine122, Spine121 and
Spine 122 know each other at level 1" with "as the result of the south
reflection, Spine121 and Spine 122 know each other at level 1". Is it better?
14) <!-- [rfced] We have rephrased the following sentence and split it into two
for ease of the reader. Please let us know any objections.
Original:
Without disaggregation mechanism, when linkSL6 fails, the packet
from leaf121 to prefix122 will probably go up through linkSL5 to linkTS3 then
ago down through linkTS4 to linkSL8 to Leaf122 or go up through linkSL5 to
linkTS6 then go down through linkTS8 and linkSL8 to Leaf122 based on pure
default route.
Current:
Without disaggregation mechanisms, the packet from leaf121 to
prefix122 will probably go up through linkSL5 to linkTS3 when linkSL6
fails. Then, the packet will go down through linkTS4 to linkSL8 to Leaf122 or
go up through linkSL5 to linkTS6, then go down through linkTS8 and linkSL8 to
Leaf122 based on the pure default route.
-->
weiyh>>>no objections.
15) <!-- [rfced] Is "and when not" referring to ZTP configuring the network?
Original:
It is recommended to let ZTP configure the network, and when not, it
is recommended to configure the level of all the nodes to avoid an
undesirable
interaction between ZTP and the manual configuration.
Perhaps:
It is recommended to let ZTP configure the network, and when ZTP does
not configure the network, it is recommended to configure the level of all
the
nodes to avoid an undesirable interaction between ZTP and the manual
configuration.
-->
weiyh>>>Good!
16) <!-- [rfced] We note that Figures 8 and 9 have the same title of "Fallen
Spine". Is this intentional? If not, please let us know how we should
update to make these figures more distinct.
-->
weiyh>>>replace "Figure 9: Fallen Spine" with "Additional Cabling Constraint
Example"
17) <!--[rfced] To clarify the content found in RFC 8505, may we rephrase the
text around its citations as follows?
Original:
When using IPv6 [RFC8200], RIFT suggests to leverage [RFC8505] as the
IPv6 ND interaction between the mobile node and the leaf.
...
When using [RFC8505], the parallel registration of an
anycast address to multiple leaves is done with the same sequence
counter, whereas the sequence counter is incremented when the point
of attachment changes.
Perhaps:
When using IPv6 [RFC8200], RIFT suggests leveraging 6LoWPAN ND [RFC8505]
as the IPv6 ND interaction between the mobile node and the leaf.
...
When using 6LoWPAN ND [RFC8505], the parallel registration of an
anycast address to multiple leaves is done with the same sequence
counter, whereas the sequence counter is incremented when the point
of attachment changes.
-->
weiyh>>>Good!
18) <!-- [rfced] We are unable to parse the following sentence (specifically, we
are unable to determine what "or the must" means). May we rephrase as
follows for clarity and specify "Top-of-Fabric"?
Original:
It has no configuration (unless it is a Top-of-Fabric at the top of
the topology or the must operate in the topology as leaf and/or support
leaf-2-leaf procedures) and it will fully configure itself after being
attached to the topology.
Perhaps:
It has no configuration (unless it is a ToF node at the top of the
topology or if it must operate in the topology as a leaf and/or support
leaf-2-leaf procedures), and it will fully configure itself after being
attached to the topology.
-->
weiyh>>> "or the must" means “the node is a leaf_only node”，the rephrasing is
Good!
19) <!-- [rfced] May we rephrase the sentence below as follows (i.e., specify
"ToR" and update "start on" to "startup")?
Original:
Sometimes, people may prefer to disaggregate from ToR to servers
from start on, i.e. the servers have couple tens of routes in FIB from start
on beside default routes to avoid breakages at rack level.
Perhaps:
Sometimes people may prefer to disaggregate from ToR nodes to
servers from startup, i.e., the servers have multiple routes in the FIB from
startup other than default routes to avoid breakages at the rack level.
-->
weiyh>>>no objections.
20) <!-- [rfced] References
a) Please review the following reference. We have added the following URL:
https://www.iso.org/standard/30932.html and updated the title to reflect the
accurate title of this ISO/IEC standard. Please let us know if you have any
objections.
Original:
[ISO10589-Second-Edition]
International Organization for Standardization,
"Intermediate system to Intermediate system intra-domain
routing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473)", November
2002.
Current:
[ISO10589-Second-Edition]
ISO/IEC, "Information technology - Telecommunications and
information exchange between systems - Intermediate System
to Intermediate System intra-domain routeing information
exchange protocol for use in conjunction with the protocol
for providing the connectionless-mode network service (ISO
8473)", ISO/IEC 10589:2002, November 2002,
<https://www.iso.org/standard/30932.html>.
weiyh>>>no objections.
b) Please review the following reference. We found a URL
(https://www.broadband-forum.org/pdfs/tr-384-1-0-0.pdf) that matches the
information provided in this reference and updated the reference as
follows. Please let us know any objections.
Original:
[TR-384] Broadband Forum Technical Report, "TR-384 Cloud Central
Office Reference Architectural Framework", January 2018.
Current:
[TR-384] Broadband Forum Technical Report, "TR-384: Cloud Central
Office Reference Architectural Framework", TR-384, Issue
1, January 2018,
<https://www.broadband-forum.org/pdfs/tr-384-1-0-0.pdf>.
weiyh>>>no objections.
c) Please review the following reference. We found the following URL:
https://ieeexplore.ieee.org/document/6012836. We have added this URL to this
reference. Please let us know if you have any objections.
Original:
[CLOS] Yuan, X., "On Nonblocking Folded-Clos Networks in Computer
Communication Environments", IEEE International Parallel &
Distributed Processing Symposium, 2011.
Current:
[CLOS] Yuan, X., "On Nonblocking Folded-Clos Networks in Computer
Communication Environments", 2011 IEEE International
Parallel & Distributed Processing Symposium,
DOI 10.1109/IPDPS.2011.27, May 2011,
<https://ieeexplore.ieee.org/document/6012836>.
weiyh>>>no objections.
d) Please review. We found the following URL for this reference:
https://ieeexplore.ieee.org/document/6312192. We have added this URL to this
reference. Please let us know if you have any objections
Original:
[FATTREE] Leiserson, C. E., "Fat-Trees: Universal Networks for
Hardware-Efficient Supercomputing", 1985.
Current:
[FATTREE] Leiserson, C. E., "Fat-Trees: Universal Networks for
Hardware-Efficient Supercomputing", IEEE Transactions on
Computers, vol. C-34, no. 10, pp. 892-901,
DOI 10.1109/TC.1985.6312192, October 1985,
<https://ieeexplore.ieee.org/document/6312192>.
weiyh>>>no objections.
e) Please review. We found the following URL for this reference:
https://www.broadband-forum.org/download/af-pnni-0055.001.pdf. We have added
this URL to this reference. Additionally, please note that the original date
for this reference was 2003. We were unable to find a version of this
reference with that date. The version we found at the URL has a date of April
2002 and updated the reference as follows for consistency. Please let us know
if you have any objections.
Original:
[PNNI] ATM Forum Technical Committee, "Private Network-Network
Interface Specification, Version 1.1 (PNNI 1.1), af-pnni-
0055.002", 2003.
Current:
[PNNI] The ATM Forum Technical Committee, "Private Network-
Network Interface - Specification Version 1.1 - (PNNI
1.1)", af-pnni-0055.001, April 2002,
<https://www.broadband-forum.org/download/af-pnni-
0055.001.pdf>.
-->
weiyh>>>no objections.
21) <!-- [rfced] The following terminology appears to be used inconsistently.
Please let us know how we should update for consistency.
North Prefix TIE vs. Prefix North TIE
South Prefix TIE vs. South North TIE -->
Prefix South TIE
weiyh>>> replace “South Prefix TIE”with "Prefix South TIE" ，and replace “North
Prefix TIE”with "Prefix North TIE"
22) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
For example, please consider whether the terms "black" and "natively".
In addition, please consider whether "traditional" should be updated for
clarity.
While the NIST website
<https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone. -->
weiyh>>>I'd prefer to keep "black" and "natively", and prefer to replace
"traditional" with "classical"
23) <!-- [rfced] FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Bidirectional Forwarding Detection (BFD)
Key Management Protocol (KMP)
Mobile Ad Hoc Network (MANET)
Optimized Link State Routing (OLSR)
Private Network-Network Interface (PNNI)
Routing Protocol for Low-Power and Lossy Networks (RPL)
-->
weiyh>>>no objections.
Thank you.
RFC Editor/mc/ap
On Dec 11, 2024, at 4:19 PM, rfc-edi...@rfc-editor.org wrote:
*****IMPORTANT*****
Updated 2024/12/11
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* rfc-edi...@rfc-editor.org (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* auth48archive@rfc-editor.org, which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
auth48archive@rfc-editor.org will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9696.xml
https://www.rfc-editor.org/authors/rfc9696.html
https://www.rfc-editor.org/authors/rfc9696.pdf
https://www.rfc-editor.org/authors/rfc9696.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9696-diff.html
https://www.rfc-editor.org/authors/rfc9696-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9696-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9696
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9696 (draft-ietf-rift-applicability-17)
Title : RIFT Applicability and Operational Considerations
Author(s) : Y. Wei, Z. Zhang, D. Afanasiev, P. Thubert, T. Przygienda
WG Chair(s) : Zhaohui (Jeffrey) Zhang, Jeff Tantsura
Area Director(s) : Jim Guichard, John Scudder, Gunter Van de Velde--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
