Dear editor I reviewed the changes and I approve the publication.
Nit: in the change under fig 4, I'd add "via leaf 122" to clarify how the reflection happens. Many thanks Pascal Le dim. 12 janv. 2025, 07:01, <wei.yue...@zte.com.cn> a écrit : > Hi Madison and Pascal, > Pascal's email changed, so I forward this email to > pascal.thub...@gmail.com. > Thank you! > > *Best Regards,* > > *Yuehua Wei* > > M: +86 13851460269 E: wei.yue...@zte.com.cn > Original > *From: *MadisonChurch <mchu...@staff.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 Editor <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 Guichard < > james.n.guich...@futurewei.com>;auth48archive@rfc-ed < > auth48archive@rfc-editor.org>;Madison Church <mchu...@staff.rfc-editor.org > >; > *Date: * 2025年01月10日 03:58 > *Subject: **Re: AUTH48: RFC-to-be 9696 <draft-ietf-rift-applicability-17> > for your review* > Hi Dmitry, Pascal, and Tony, > > > [Note that this email is coming to you from a new email address on our end.] > > > This is another friendly reminder that we have yet to hear back from of you > regarding this document’s readiness for publication. > > > Please review the document carefully to ensure satisfaction as we do not make > changes once it has been published as an RFC. Contact us with any further > updates or with your approval of the document in its current form. We will > await approvals from each author prior to moving forward in the publication > process. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9696.txt > https://www.rfc-editor.org/authors/rfc9696.pdf > https://www.rfc-editor.org/authors/rfc9696.html > https://www.rfc-editor.org/authors/rfc9696.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9696-diff.html > https://www.rfc-editor.org/authors/rfc9696-rfcdiff.html > https://www.rfc-editor.org/authors/rfc9696-auth48diff.html > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9696 > > Thank you, > RFC Editor/mc > > > On Jan 2, 2025, at 9:03 AM, Madison Church <mchu...@amsl.com> wrote: > > > > Hi Authors, > > > > > This is a friendly reminder that we have yet to hear back from some of you > > regarding this document’s readiness for publication. We await approvals > > from Dmitry, Pascal, and Tony. > > > > > Please review the document carefully to ensure satisfaction as we do not > > make changes once it has been published as an RFC. Contact us with any > > further updates or with your approval of the document in its current form. > > We will await approvals from each author prior to moving forward in the > > publication process. > > > > The files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9696.txt > > https://www.rfc-editor.org/authors/rfc9696.pdf > > https://www.rfc-editor.org/authors/rfc9696.html > > https://www.rfc-editor.org/authors/rfc9696.xml > > > > The relevant diff files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9696-diff.html > > https://www.rfc-editor.org/authors/rfc9696-rfcdiff.html > > https://www.rfc-editor.org/authors/rfc9696-auth48diff.html > > > > For the AUTH48 status of this document, please see: > > https://www.rfc-editor.org/auth48/rfc9696 > > > > Thank you, > > RFC Editor/mc > > > >> On Dec 20, 2024, at 10:12 AM, Madison Church <mchu...@amsl.com> wrote: > >> > >> Hi Yuehua, > >> > > >> Thank you for your reply! We have marked your approval on the AUTH48 > >> status page (see > https://www.rfc-editor.org/auth48/rfc9696). > >> > >> Once we receive approvals from Dmitry, Pascal, and Tony, we will move this > >> document forward in the publication process. > > >> > >> Thank you! > >> RFC Editor/mc > >> > >>> On Dec 19, 2024, at 7:00 PM, wei.yue...@zte.com.cn wrote: > >>> > >>> Hi Madison, > >>> Thank you. > > >>> I have reviewed the whole draft and I approve the publication as the > >>> editor. > >>> > >>> Best Regards, > >>> Yuehua Wei > >>> > >>> Original > >>> From: MadisonChurch <mchu...@amsl.com> > >>> 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 Editor <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 Guichard < > james.n.guich...@futurewei.com>;auth48archive@rfc-ed < > auth48archive@rfc-editor.org>; > >>> Date: 2024年12月18日 23:33 > > >>> Subject: Re: AUTH48: RFC-to-be 9696 <draft-ietf-rift-applicability-17> > >>> for your review > >>> Hi Authors, > >>> > > >>> Zheng - We have noted your approval on the AUTH48 status page (please see > https://www.rfc-editor.org/auth48/rfc9696). > >>> > > >>> Yuehua - Thank you for your quick reply! We have updated the document to > >>> reflect your proposed change in the updated files below. > >>> > > >>> Please review the document carefully to ensure satisfaction as we do not > >>> make changes once it has been published as an RFC. Contact us with any > >>> further updates or with your approval of the document in its current > >>> form. We will await approvals from each author prior to moving forward in > >>> the publication process. > >>> > >>> The files have been posted here (please refresh): > >>> https://www.rfc-editor.org/authors/rfc9696.txt > >>> https://www.rfc-editor.org/authors/rfc9696.pdf > >>> https://www.rfc-editor.org/authors/rfc9696.html > >>> https://www.rfc-editor.org/authors/rfc9696.xml > >>> > >>> The relevant diff files have been posted here (please refresh): > >>> https://www.rfc-editor.org/authors/rfc9696-diff.html > >>> https://www.rfc-editor.org/authors/rfc9696-rfcdiff.html > >>> https://www.rfc-editor.org/authors/rfc9696-auth48diff.html > >>> > >>> For the AUTH48 status of this document, please see: > >>> https://www.rfc-editor.org/auth48/rfc9696 > >>> > >>> Thank you, > >>> RFC Editor/mc > >>> > >>>> On Dec 17, 2024, at 7:35 PM, <wei.yue...@zte.com.cn> < > wei.yue...@zte.com.cn> wrote: > >>>> > >>>> Hi Madison, > >>>> Thank you very much for such a quick revision. > >>>> Everything looks perfect except one minor flaw: > >>>> > >>>> ORIGINAL: > >>>> 4.2.4. Reachability of Internal Nodes in the Fabric > >>>> Under normal operating conditions this can be easily achieved by > >>>> injecting the node's loopback address into North and South Prefix > >>>> TIEs or other implementation specific mechanisms. > >>>> CURRENT: > >>>> 4.2.4. Reachability of Internal Nodes in the Fabric > >>>> Under normal operating conditions, this can be easily achieved by > >>>> injecting the node's loopback address into North and Prefix South > >>>> TIEs or other implementation-specific mechanisms. > >>>> PROPOSE: > >>>> Under normal operating conditions, this can be easily achieved by > >>>> injecting the node's loopback address into Prefix North TIEs and Prefix > >>>> South > > >>>> TIEs or other implementation-specific mechanisms. > >>>> > >>>> Best Regards, > >>>> Yuehua Wei > >>>> M: +86 13851460269 E: wei.yue...@zte.com.cn > >>>> > >>>> Original > >>>> From: MadisonChurch <mchu...@amsl.com> > >>>> 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 Editor <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 Guichard < > james.n.guich...@futurewei.com>;auth48archive@rfc-ed < > auth48archive@rfc-editor.org>; > >>>> Date: 2024年12月18日 06:27 > > >>>> Subject: Re: AUTH48: RFC-to-be 9696 <draft-ietf-rift-applicability-17> > >>>> for your review > >>>> Hi Yuehua, > >>>> > > >>>> Thank you for your reply! We have updated the document accordingly and > >>>> all of our questions have been addressed. > >>>> > > >>>> Please review the document carefully to ensure satisfaction as we do not > >>>> make changes once it has been published as an RFC. Contact us with any > >>>> further updates or with your approval of the document in its current > >>>> form. We will await approvals from each author prior to moving forward > >>>> in the publication process. > >>>> > >>>> The files have been posted here (please refresh): > >>>> https://www.rfc-editor.org/authors/rfc9696.txt > >>>> https://www.rfc-editor.org/authors/rfc9696.pdf > >>>> https://www.rfc-editor.org/authors/rfc9696.html > >>>> https://www.rfc-editor.org/authors/rfc9696.xml > >>>> > >>>> The relevant diff files have been posted here (please refresh): > >>>> https://www.rfc-editor.org/authors/rfc9696-diff.html (comprehensive > >>>> diff) > > >>>> https://www.rfc-editor.org/authors/rfc9696-rfcdiff.html > (side-by-side diff) > >>>> https://www.rfc-editor.org/authors/rfc9696-auth48diff.html > (diff showing AUTH48 changes) > >>>> > >>>> For the AUTH48 status of this document, please see: > >>>> https://www.rfc-editor.org/auth48/rfc9696 > >>>> > >>>> Thank you! > >>>> RFC Editor/mc > >>>> > >>>>> On Dec 17, 2024, at 1:37 AM, wei.yue...@zte.com.cn wrote: > >>>>> > >>>>> 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
