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
-->


2) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->


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.
-->


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.
-->


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.
-->


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...
-->


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.
-->


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.
-->


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).
-->


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).
-->


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].
-->


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.
-->


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.
-->


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.
-->


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.
-->


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.
-->


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.    
-->   


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.
-->


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.
-->


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>.


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>.


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>.


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>.

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>.
-->


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 -->


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. -->


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)
-->


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

Reply via email to