Hi Quintin, Thank you for your reply. We have updated your email address and noted your approval.
The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9689.xml https://www.rfc-editor.org/authors/rfc9689.txt https://www.rfc-editor.org/authors/rfc9689.html https://www.rfc-editor.org/authors/rfc9689.pdf The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc9689-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9689-auth48diff.html (AUTH48 changes) https://www.rfc-editor.org/authors/rfc9689-lastdiff.html (last version to this one) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9689 We will await approvals from Robin and King prior to moving forward with the publication process. Best regards, RFC Editor/ap > On Nov 27, 2024, at 8:49 PM, Quintin Zhao <quintinz...@gmail.com> wrote: > > > Hello Alanna, > > Please update my affiliation information in the document as below: > > Quintin Zhao > Etheric Networks > 1009 S Claremont St > San Mateo, CA 94402 > United States of America > Email: quintinz...@gmail.com > > Also I approve the publication of this document. > > Thanks, > Quintin > > > > All - We have updated the Contributors section accordingly. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9689.xml > https://www.rfc-editor.org/authors/rfc9689.txt > https://www.rfc-editor.org/authors/rfc9689.html > https://www.rfc-editor.org/authors/rfc9689.pdf > > The relevant diff files have been posted here: > https://www.rfc-editor.org/authors/rfc9689-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9689-auth48diff.html (AUTH48 changes) > https://www.rfc-editor.org/authors/rfc9689-lastdiff.html (last version to > this one) > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9689 > > Once we receive approvals from Robin, Quintin, and King, we will move this > document forward in the publication process > > Thank you, > RFC Editor/ > > > > We have updated your affiliation and noted your approval on the AUTH48 > > status page: > > https://www.rfc-editor.org/auth48/rfc9689 > > > > The files have been posted here (please refresh): > > https://www.rfc-editor.org/authors/rfc9689.xml > > https://www.rfc-editor.org/authors/rfc9689.txt > > https://www.rfc-editor.org/authors/rfc9689.html > > https://www.rfc-editor.org/authors/rfc9689.pdf > > > > The relevant diff files have been posted here: > > https://www.rfc-editor.org/authors/rfc9689-diff.html (comprehensive diff) > > https://www.rfc-editor.org/authors/rfc9689-auth48diff.html (AUTH48 changes) > > https://www.rfc-editor.org/authors/rfc9689-lastdiff.html (last version to > > this one) > > > > We will await word from you regarding updates to the Contributors section. > > > > Thank you, > > RFC Editor/ap > >> > >>> Please review the document carefully and contact us with any further > >>> updates. Note that we do not make changes once a document is published > >>> as an RFC. > >>> > >>> We will await approvals from each party listed on the AUTH48 status page > >>> below prior to moving this document forward in the publication process. > >>> > >>> For the AUTH48 status of this document, please see: > >>> https://www.rfc-editor.org/auth48/rfc9689 > >>> > >>> Thank you, > >>> RFC Editor/ap > >>> > >>>> On Nov 21, 2024, at 6:17 AM, Dhruv Dhody <dhruv.i...@gmail.com> wrote: > >>>> > >>>> Hi, > >>>> > >>>> On Mon, Nov 18, 2024 at 11:09 PM <rfc-edi...@rfc-editor.org> wrote: > >>>> Authors, > >>>> > >>>> While reviewing this document during AUTH48, please resolve (as > >>>> necessary) the following questions, which are also in the XML file. > >>>> > >>>> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in > >>>> the title) for use on https://www.rfc-editor.org/search. --> > >>>> > >>>> > >>>> Dhruv: SDN > >>>> > >>>> > >>>> 2) <!--[rfced] The text below suggests that RFC 8283 (rather than a > >>>> person) > >>>> can "assume" something. Since we try to avoid the personification of > >>>> RFCs, > >>>> may we rephrase the text as shown below for clarity? > >>>> > >>>> Original: > >>>> [RFC8283] introduces the architecture for the PCE as a central > >>>> controller as an extension to the architecture described in [RFC4655] > >>>> and assumes the continued use of PCEP as the protocol used between > >>>> the PCE and PCC. > >>>> > >>>> Perhaps: > >>>> [RFC8283] introduces the architecture for the PCE as a central > >>>> controller and as an extension to the architecture described in > >>>> [RFC4655]. > >>>> It is assumed that PCEP continues to be used as the protocol between > >>>> the PCE and PCC. > >>>> --> > >>>> > >>>> > >>>> Dhruv: The text is coming from RFC 8283 itself. > >>>> > >>>> Maybe I can suggest a different tact - > >>>> > >>>> [RFC8283] outlines the architecture for the PCE as a central controller, > >>>> extending the framework described in [RFC4655], and demonstrates how > >>>> PCEP can serve as a general southbound control protocol between the PCE > >>>> and PCC. > >>>> > >>>> 3) <!--[rfced] FYI - We have ordered the list of terms in Section 2 > >>>> alphabetically. > >>>> Please let us know of any objections. > >>>> --> > >>>> > >>>> > >>>> Dhruv: No objection > >>>> > >>>> > >>>> 4) <!--[rfced] FYI - We have updated the text below for clarity. Please > >>>> review and let us know if this has changed the intended meaning. > >>>> > >>>> Original: > >>>> > >>>> Further, there have been proposals for a global label range in MPLS, > >>>> the PCECC architecture could be used as a means to learn the label > >>>> space of nodes, and could also be used to determine and provision the > >>>> global label range. > >>>> > >>>> Current: > >>>> > >>>> Further, there have been proposals for a global label range in MPLS > >>>> as well as PCECC architecture being used as a means to learn the > >>>> label > >>>> space of nodes and being used to determine and provision the global > >>>> label range. > >>>> --> > >>>> > >>>> > >>>> Dhruv: How is this -> > >>>> > >>>> Further, there have been proposals for a global label range in MPLS > >>>> as well as the use of PCECC architecture to learn the label > >>>> space of each node to determine and provision the global > >>>> label range. > >>>> > >>>> 5) <!-- [rfced] Should an introductory sentence be added to the list > >>>> that appears > >>>> after Figure 1 to provide context for the proceeding text? > >>>> > >>>> Original: > >>>> > >>>> Figure 1: PCECC for MPLS Label Management > >>>> > >>>> * As shown in Figure 1, PCC will advertise the PCECC capability to > >>>> the PCE central controller (PCECC) [RFC9050]. > >>>> > >>>> * The PCECC could also learn the label range set aside by the PCC > >>>> (via [I-D.li-pce-controlled-id-space]). > >>>> > >>>> Perhaps: > >>>> > >>>> Figure 1: PCECC for MPLS Label Management > >>>> > >>>> As shown in Figure 1: > >>>> > >>>> * PCC will advertise the PCECC capability to > >>>> the PCE central controller (PCECC) [RFC9050]. > >>>> > >>>> * The PCECC could also learn the label range set aside by the > >>>> PCC > >>>> (via [I-D.li-pce-controlled-id-space]). > >>>> --> > >>>> > >>>> > >>>> Dhruv: Yes, it makes sense! > >>>> > >>>> > >>>> 6) <!-- [rfced] Section 3.2.2 begins with the text below; how may we > >>>> rephrase to > >>>> clarify what "this use case" refers to? > >>>> > >>>> Original: > >>>> > >>>> 3.2.2. PCECC for SR-MPLS Best Effort (BE) Path > >>>> > >>>> In this use case, the PCECC needs to allocate the Node-SID (without > >>>> calculating the explicit path for the SR path). > >>>> > >>>> Perhaps: > >>>> > >>>> 3.2.2. PCECC for SR-MPLS Best Effort (BE) Path > >>>> > >>>> When using PCECC for SR-MPLS Best Effort (BE) Paths, the PCECC > >>>> needs to > >>>> allocate the Node-SID (without calculating the explicit path for > >>>> the SR path). > >>>> --> > >>>> > >>>> > >>>> Dhruv: Happy with your suggestion. > >>>> > >>>> > >>>> 7) <!-- [rfced] For clarity, can "w/ECMP" be updated to "with ECMP" in > >>>> the text > >>>> below? > >>>> > >>>> Original: > >>>> > >>>> Due to the possibility of having many Segment Lists in the same > >>>> Candidate Path of each POL1/POL2, PCECC could provision more paths > >>>> towards R8 and traffic will be balanced either as ECMP or as w/ECMP. > >>>> > >>>> Perhaps: > >>>> > >>>> Due to the possibility of having many segment lists in the same > >>>> candidate path of each POL1/POL2, the PCECC could provision more > >>>> paths > >>>> towards R8 and traffic will be balanced either as ECMP or as with > >>>> ECMP. > >>>> --> > >>>> > >>>> > >>>> Dhruv: No, it refers to weighted ECMP. Thus it is better to use > >>>> "weighted-ECMP (W-ECMP)" instead of w/ECMP. > >>>> > >>>> 8) <!--[rfced] FYI - We have slightly adjusted the spacing and formatting > >>>> of the ASCII artwork in Figure 6 as it exceeded the 72-character limit. > >>>> Please review and let us know if any further changes are necessary. --> > >>>> > >>>> > >>>> Dhruv: Looks good! > >>>> > >>>> > >>>> 9) <!-- [rfced] We have removed the parentheses around "Virtual Private > >>>> LAN > >>>> Services (VPLS)" in the text below. Please review and let us know if this > >>>> changed the intended meaning of the text. > >>>> > >>>> Original: > >>>> > >>>> Service deployment is made by means of Layer 2 Virtual Private > >>>> Networks (L2VPNs) (Virtual Private LAN Services (VPLS)), Layer 3 > >>>> Virtual Private Networks (L3VPNs) or Ethernet VPNs (EVPNs). > >>>> > >>>> Current: > >>>> > >>>> Service deployment is made by means of Layer 2 Virtual Private > >>>> Networks (L2VPNs), Virtual Private LAN Services (VPLSs), Layer 3 > >>>> Virtual Private Networks (L3VPNs), or Ethernet VPNs (EVPNs). > >>>> --> > >>>> > >>>> > >>>> Dhruv: The change makes sense! > >>>> > >>>> > >>>> 10) <!-- [rfced] To improve readability, may we update this this text > >>>> as follows? Additionally, should "HSI" be listed as an example > >>>> of high-speed data services? > >>>> > >>>> Original: > >>>> > >>>> * TE bandwidth (BW) management: Provide guaranteed BW for specific > >>>> services: High-Speed Data Service (HSI)), IPTV, etc., and provide > >>>> time-based BW reservation (BW on demand (BoD)) for other > >>>> services. > >>>> > >>>> Perhaps: > >>>> > >>>> * Manage TE bandwidth (BW) and provide guaranteed BW for specific > >>>> services (such as high-speed data services like High-Speed > >>>> Internet > >>>> (HSI), IPTV, etc.) and provide time-based BW reservation (such as > >>>> Bandwidth on Demand (BoD)) for other services. > >>>> --> > >>>> > >>>> > >>>> Dhruv: How about this - > >>>> > >>>> * Manage TE bandwidth (BW) by guaranteeing BW for specific > >>>> services (such as High-Speed Internet (HSI), IPTV, etc.) > >>>> and enabling time-based BW reservation (such as Bandwidth > >>>> on Demand (BoD)). > >>>> > >>>> 11) <!-- [rfced] FYI - We have broken up the sentence below to improve > >>>> readability. > >>>> Please review and let us know if any further updates are necessary. > >>>> > >>>> Original: > >>>> > >>>> If PST is PCECC (basic), then the PCECC > >>>> will assign labels along the calculated path and set up the path > >>>> by sending central controller instructions in a PCEP message to > >>>> each node along the path of the LSP as per [RFC9050] and then send > >>>> PCUpd message to the ingress AGG X router with information about > >>>> new LSP. > >>>> > >>>> Current: > >>>> > >>>> If the PST is a PCECC (basic), then the PCECC > >>>> will assign labels along the calculated path and set up the path > >>>> by sending central controller instructions in a PCEP message to > >>>> each node along the path of the LSP as per [RFC9050]. Then, the > >>>> PCECC will send a PCUpd message to the ingress AGG X router with > >>>> information about the new LSP. > >>>> --> > >>>> > >>>> > >>>> Dhruv: Happy with breaking it into two sentences. BUT, PCECC is one of > >>>> the path setup types (PST) and thus use of "PST is a PCECC (basic)" is > >>>> wrong, perhaps we can change that to - if the PST is "PCECC"? (this kind > >>>> of change has been made at multiple places). I also think we can remove > >>>> (basic) as that is not the term used in RFC9050. Thus for this paragraph > >>>> perhaps - > >>>> > >>>> If the PST is set to "PCECC" type, then the PCECC > >>>> will assign labels .... > >>>> > >>>> > >>>> 12) <!-- [rfced] To parallel the preceding sentence, may we update > >>>> "R1-R3 LSP2" > >>>> to be "LSP2 from R1 to R3"? > >>>> > >>>> Original: > >>>> > >>>> As per Figure 8, LSP1 from R1 to R3 goes via ASBR1 and ASBR3, and it > >>>> is the primary Inter-AS LSP. R1-R3 LSP2 that goes via ASBR5 and > >>>> ASBR6 are the backup ones. > >>>> > >>>> Perhaps: > >>>> > >>>> As per Figure 8, LSP1 from R1 to R3 goes via ASBR1 and ASBR3, and it > >>>> is the primary Inter-AS LSP. LSP2 from R1 to R3 that goes via ASBR5 > >>>> and > >>>> ASBR6 is the backup one. > >>>> --> > >>>> > >>>> > >>>> Dhruv: yes! > >>>> > >>>> > >>>> 13) <!-- [rfced] We have broken up the sentence below to improve > >>>> readability. > >>>> Please review and let us know if any further updates are necessary. > >>>> > >>>> Original: > >>>> > >>>> Then PCECC will calculate the optimal path based on Objective > >>>> Function > >>>> (OF) and given constraints (i.e. path setup type, bandwidth > >>>> etc.), > >>>> including those from [RFC5376]: priority, AS sequence, preferred > >>>> ASBR, > >>>> disjoint paths, and protection type. > >>>> > >>>> Current: > >>>> > >>>> Then, the PCECC will calculate the optimal path based on > >>>> Objective Function > >>>> (OF) and given constraints (i.e., path setup type, bandwidth, > >>>> etc.). > >>>> These constraints include those from [RFC5376], such as priority, > >>>> AS sequence, preferred ASBR, disjoint paths, and protection type. > >>>> --> > >>>> > >>>> > >>>> Dhruv: Ok > >>>> > >>>> > >>>> 14) <!--[rfced] We note that Figure 9 abbreviates links as "L1", "L2", > >>>> etc., while > >>>> Figures 2, 3, 4, and 5 use "link1", "link2", etc. Should Figure 9 be > >>>> updated > >>>> to also use "link1", "link2", etc. to reflect the other figures in this > >>>> document? > >>>> --> > >>>> > >>>> > >>>> Dhruv: Make sense to be consistent. > >>>> > >>>> > >>>> 15) <!-- [rfced] We have updated the following text to make them complete > >>>> sentences. Please review and let us know if further updates are > >>>> necessary. > >>>> > >>>> a) Section 3.6.2: > >>>> Original: > >>>> > >>>> In this section, the end-to-end managed path protection service as > >>>> well as the local protection with the operation management in the > >>>> PCECC network for the P2MP/MP2MP LSP. > >>>> > >>>> Current: > >>>> > >>>> This section describes the end-to-end managed path protection > >>>> service as > >>>> well as the local protection with operation management in the > >>>> PCECC network for the P2MP/MP2MP LSP. > >>>> > >>>> b) Appendix A.4: > >>>> Original: > >>>> > >>>> In Hadoop (https://hadoop.apache.org/) 1.0 > >>>> architecture MapReduce operations on big data in the Hadoop > >>>> Distributed File System (HDFS), where NameNode knows about resources > >>>> of the cluster and where actual data (chunks) for a particular task > >>>> are located (which DataNode). > >>>> > >>>> Current: > >>>> > >>>> In Hadoop (https://hadoop.apache.org/) 1.0 architecture, MapReduce > >>>> operations occur on big data in the Hadoop Distributed File System > >>>> (HDFS), where > >>>> NameNode knows about resources of the cluster and where actual data > >>>> (chunks) for a particular task are located (which DataNode). > >>>> --> > >>>> > >>>> > >>>> Dhruv: Ok. > >>>> > >>>> > >>>> 16) <!-- [rfced] We note that "Flow Specification" occurs three times in > >>>> the > >>>> sentence below. For concision and clarity, may we update the sentence as > >>>> follows? > >>>> > >>>> Original: > >>>> > >>>> 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 > >>>> [RFC8955]. > >>>> > >>>> Perhaps: > >>>> > >>>> The description of traffic flows by the combination of multiple Flow > >>>> Specification components and their dissemination as traffic Flow > >>>> Specifications is described for BGP in [RFC8955]. > >>>> --> > >>>> > >>>> > >>>> Dhruv: Yes! > >>>> > >>>> > >>>> 17) <!-- [rfced] For clarity, what does "it" refer to in the bullets > >>>> below? Is > >>>> it the PCECC? > >>>> > >>>> Original (Section 3.7): > >>>> > >>>> Along with traffic classification, there are a few more questions > >>>> that need to be considered after path setup: > >>>> > >>>> * how to use it > >>>> > >>>> * Whether it is a virtual link > >>>> > >>>> * Whether to advertise it in the IGP as a virtual link > >>>> > >>>> * What bits of this information to signal to the tail end > >>>> > >>>> Perhaps: > >>>> > >>>> Along with traffic classification, there are a few more questions > >>>> about the PCECC that need to be considered after path setup: > >>>> > >>>> * how to use it, > >>>> > >>>> * whether it is a virtual link, > >>>> > >>>> * whether to advertise it in the IGP as a virtual link, and > >>>> > >>>> * what bits of this information to signal to the tail end. > >>>> --> > >>>> > >>>> > >>>> Dhruv: Maybe > >>>> > >>>> Along with traffic classification, there are a few more questions > >>>> about the tunnels setup by the PCECC that need to be considered: > >>>> > >>>> 18) <!-- [rfced] Would you like to add any additional text or a > >>>> definition to "SFC > >>>> Proxy handling" below, for consistency with the other bulleted items in > >>>> this list? > >>>> > >>>> Original: > >>>> > >>>> A possible mechanism could add support for SFC-based central control > >>>> instructions. PCECC will be able to instruct each SFF along the SFP. > >>>> > >>>> * Service Path Identifier (SPI): Uniquely identifies an SFP. > >>>> > >>>> * Service Index (SI): Provides location within the SFP. > >>>> > >>>> * SFC Proxy handling > >>>> --> > >>>> > >>>> > >>>> Dhruv: Maybe change to - "Provide SFC Proxy handling instruction." > >>>> > >>>> 19) <!-- [rfced] FYI - Since "BIER encapsulation" appeared twice in the > >>>> sentence > >>>> below, we removed the second instance and updated for conciseness. Please > >>>> review and let us know of any objections. > >>>> > >>>> Original: > >>>> > >>>> The PCECC could be used to program the BIER router with various > >>>> parameters > >>>> used in the BIER encapsulation such as BIER subdomain-ID, BFR-ID, > >>>> BIER > >>>> Encapsulation etc. for both node and adjacency. > >>>> > >>>> Current: > >>>> > >>>> The PCECC could be used to program the BIER router with various > >>>> parameters > >>>> used in the BIER encapsulation (such as BIER sub-domain-id, BFR-id, > >>>> etc.) > >>>> for both node and adjacency. > >>>> --> > >>>> > >>>> > >>>> Dhruv: Ok > >>>> > >>>> > >>>> 20) <!-- [rfced] Should "signalling" be moved before "protocols" in the > >>>> sentence below? > >>>> > >>>> Original: > >>>> > >>>> During the migration, the legacy nodes still need > >>>> to use the existing MPLS protocols signalling such as LDP and RSVP- > >>>> TE... > >>>> > >>>> Perhaps: > >>>> > >>>> During the migration, the legacy nodes still need > >>>> to use the existing MPLS signalling protocols such as LDP and RSVP- > >>>> TE... > >>>> --> > >>>> > >>>> > >>>> Dhruv: Yes! > >>>> > >>>> > >>>> 21) <!-- [rfced] We note that paths appear to be formatted differently > >>>> throughout > >>>> this document. Should they appear in quotation marks or without any > >>>> additional > >>>> text styling? > >>>> > >>>> Original (some examples): > >>>> > >>>> The traffic from R1 to R8 which fits color 200 will be steered to > >>>> POL2 > >>>> and follows the path: R1-link2-R2-link4-R5-R6-R8. > >>>> ... > >>>> In this step, we will > >>>> have two paths: R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3 > >>>> ... > >>>> * PCECC will provision each node along the path and assign incoming > >>>> and outgoing labels from R1 to R8 with the path as > >>>> "R1-link1-R2-link3-R4-link10-R3-link8-R8": > >>>> --> > >>>> > >>>> > >>>> Dhruv: Most important thing would be to be consistent and I guess > >>>> putting them in quotations seems like the right style. > >>>> > >>>> > >>>> 22) <!-- [rfced] Should spaces appear between values (90012,1002,90024, > >>>> etc.)? > >>>> > >>>> Original (some examples): > >>>> > >>>> * For the end-to-end protection, PCECC can provision the secondary > >>>> path (R1-link2-R2-link4-R5-R8): {90012,1002,90024,1005,1008}. > >>>> ... > >>>> As shown in Figure 3, R1 may send a packet to R8 by pushing an SR > >>>> header with segment list {1002, 9001, 1008}. > >>>> --> > >>>> > >>>> > >>>> Dhruv: For readability, adding space is a good option. > >>>> > >>>> > >>>> 23) <!-- [rfced] Terminology > >>>> > >>>> a) Should instances of "PCEP protocol" be updated to read simply > >>>> "PCEP" to avoid redundancy (if expanded, "PCEP protocol" would read "Path > >>>> Computation Element Communication Protocol protocol")? Please review and > >>>> let us know if any updates are needed. > >>>> > >>>> > >>>> Dhruv: Yes, please make that change! > >>>> > >>>> > >>>> b) We note use of the terms "PCE-based controller" and "PCE-based central > >>>> controller". Should these be updated to "PCECC"? > >>>> > >>>> Original (some examples): > >>>> > >>>> For this to work, the PCE-based controller will take responsibility > >>>> for managing some part of the MPLS label space for each of the > >>>> routers that it controls. > >>>> ... > >>>> A PCE-based central controller can consider the whole > >>>> network and all components of a service at once when planning how to > >>>> deliver the service. > >>>> > >>>> > >>>> Dhruv: That is a good idea, > >>>> > >>>> > >>>> c) FYI - The terms below have been updated to match how they appear in > >>>> RFCs > >>>> 8279 and 9262. Please review and let us know any objections. > >>>> > >>>> Original / Current: > >>>> > >>>> bitmask / BitMask > >>>> BFR-ID / BFR-id > >>>> subdomain-ID / sub-domain-id > >>>> BIER Encapsulation / BIER encapsulation > >>>> > >>>> > >>>> > >>>> Dhruv: No objection! > >>>> > >>>> d) We note the following differences in the use of the terms below. > >>>> Please > >>>> review and let us know how to update each item for consistency. > >>>> > >>>> headend v. head end > >>>> NODE 1 v. Node1 v. Node 3 (regarding spacing and capitalization) > >>>> --> > >>>> > >>>> > >>>> Dhruv: My pref is for - headend and Node1 > >>>> > >>>> > >>>> 24) <!-- [rfced] Abbreviations > >>>> > >>>> a) FYI - we have added expansions for "AS" and "ASBR" to the Terminology > >>>> section > >>>> to avoid awkward expansions in the body of the text. Please let us know > >>>> any > >>>> objections. > >>>> > >>>> > >>>> Dhruv: No objection! > >>>> > >>>> b) To match usage in RFC 5440, may we expand and update "TEDB" to > >>>> "Traffic > >>>> Engineering Database (TED)" ? > >>>> > >>>> Original: > >>>> * Since PCECC is aware of TEDB (TE state) and LSP-DB... > >>>> > >>>> Perhaps: > >>>> * Since PCECC is aware of Traffic Engineering Database (TED) (TE > >>>> state) > >>>> and LSP-DB... > >>>> > >>>> > >>>> Dhruv: ok! > >>>> > >>>> > >>>> c) How should "NBI" be expanded in the text below? > >>>> > >>>> Original: > >>>> * After the operator's application or service orchestrator creates a > >>>> request for tunnel creation of a specific service, PCECC will > >>>> receive that request via NBI (NBI type is implementation > >>>> dependent, it could be NETCONF/Yang, REST etc.). > >>>> > >>>> > >>>> > >>>> Dhruv: North Bound Interface > >>>> > >>>> d) We note two different expansions of "TE" in this document. Should > >>>> these > >>>> be updated for consistency? > >>>> > >>>> traffic-engineered (TE) > >>>> Traffic Engineering (TE) > >>>> > >>>> > >>>> > >>>> Dhruv: 2nd one! > >>>> > >>>> e) This document has mixed usage of the expanded and abbreviated forms > >>>> of the > >>>> following terms. After they are expanded upon first use, may we replace > >>>> all > >>>> instances thereafter with the abbreviated form (per guidance from the Web > >>>> Portion of the Style Guide at > >>>> <https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>)? > >>>> > >>>> Objective Function (OF) > >>>> bandwidth (BW) > >>>> Path Setup Type (PST) > >>>> Segment Routing (SR) > >>>> load balancing (LB) > >>>> Layer 3 VPN (L3VPN) > >>>> Ethernet VPN (EVPN) > >>>> > >>>> > >>>> Dhruv: yes! > >>>> > >>>> > >>>> f) FYI - We have updated the expansion for CCDR to match how it appears > >>>> in > >>>> RFC 8735. Please let us know any objections. > >>>> > >>>> Original: > >>>> Centrally Control Dynamic Routing (CCDR) > >>>> > >>>> Current: > >>>> Centralized Control Dynamic Routing (CCDR) > >>>> > >>>> > >>>> Dhruv: Thanks! > >>>> > >>>> > >>>> g) 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. > >>>> > >>>> Hierarchical PCE (H-PCE) > >>>> LSP Database (LSP-DB) (per RFC 8283) > >>>> Network Processing Unit (NPU) > >>>> Open vSwitch (OVS) > >>>> Provider Edge (PE) > >>>> Service Level Agreement (SLA) > >>>> Service Function Forwarder (SFF) > >>>> SR over MPLS (SR-MPLS) > >>>> SR over IPv6 (SRv6) > >>>> --> > >>>> > >>>> > >>>> > >>>> Dhruv: all good! > >>>> > >>>> 25) <!-- [rfced] FYI - There are several author comments in the XML > >>>> file. These have been > >>>> marked with [auth]. Please review these and let us know if any updates > >>>> are needed > >>>> based on those comments, as they will be removed before publication. > >>>> --> > >>>> > >>>> > >>>> Dhruv: please remove! > >>>> > >>>> > >>>> 26) <!-- [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. > >>>> > >>>> a) For example, please consider whether "native" should be updated in > >>>> the text > >>>> below: > >>>> > >>>> Original: > >>>> > >>>> Section 3.9. PCECC for Native IP > >>>> > >>>> Figure 12: PCECC for Native IP > >>>> > >>>> ...traffic engineering for native IP networks. [RFC8821] defines the > >>>> framework for CCDR traffic engineering within a Native IP network... > >>>> > >>>> > >>>> Dhruv: The term is coming from RFC 8821 and also used in another recent > >>>> IESG approved document - > >>>> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/, > >>>> please continue to use it. > >>>> > >>>> > >>>> b) In addition, please consider whether "tradition" 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. > >>>> > >>>> Original: > >>>> > >>>> The traditional IP-based multicast may not be appropriate because > >>>> it... > >>>> --> > >>>> > >>>> > >>>> Dhruv: conventional? > >>>> > >>>> > >>>> > >>>> Thanks! > >>>> Dhruv > >>>> > >>>> Thank you. > >>>> > >>>> RFC Editor/kf/ap > >>>> > >>>> > >>>> On Nov 18, 2024, at 9:38 AM, rfc-edi...@rfc-editor.org wrote: > >>>> > >>>> *****IMPORTANT***** > >>>> > >>>> Updated 2024/11/18 > >>>> > >>>> 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/rfc9689.xml > >>>> https://www.rfc-editor.org/authors/rfc9689.html > >>>> https://www.rfc-editor.org/authors/rfc9689.pdf > >>>> https://www.rfc-editor.org/authors/rfc9689.txt > >>>> > >>>> Diff file of the text: > >>>> https://www.rfc-editor.org/authors/rfc9689-diff.html > >>>> https://www.rfc-editor.org/authors/rfc9689-rfcdiff.html (side by > >>>> side) > >>>> > >>>> Diff of the XML: > >>>> https://www.rfc-editor.org/authors/rfc9689-xmldiff1.html > >>>> > >>>> > >>>> Tracking progress > >>>> ----------------- > >>>> > >>>> The details of the AUTH48 status of your document are here: > >>>> https://www.rfc-editor.org/auth48/rfc9689 > >>>> > >>>> Please let us know if you have any questions. > >>>> > >>>> Thank you for your cooperation, > >>>> > >>>> RFC Editor > >>>> > >>>> -------------------------------------- > >>>> RFC9689 (draft-ietf-teas-pcecc-use-cases-18) > >>>> > >>>> Title : Use Cases for a PCE as a Central Controller (PCECC) > >>>> Author(s) : Z. Li, D. Dhody, Q. Zhao, Z. Ke, B. Khasanov > >>>> WG Chair(s) : Oscar Gonzalez de Dios, Vishnu Pavan Beeram, Lou > >>>> Berger > >>>> > >>>> 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
