Hi Alanna, I approve the publication of this document.
Best Regards, Zhenbin (Robin) 发件人: Quintin Zhao <quintinz...@gmail.com> 发送时间: 2024年11月28日 12:50 收件人: Dhruv Dhody <dhruv.i...@gmail.com> 抄送: Boris Hassanov <bhassa...@yahoo.com>; Lizhenbin <lizhen...@huawei.com>; kin...@tencent.com; rfc-edi...@rfc-editor.org; teas-...@ietf.org; teas-cha...@ietf.org; vishnupa...@gmail.com; james.n.guich...@futurewei.com; auth48archive@rfc-editor.org; Alanna Paloma <apal...@amsl.com> 主题: Re: AUTH48: RFC-to-be 9689 <draft-ietf-teas-pcecc-use-cases-18> for your review Hello Alanna, Please update my affiliation information in the document as below: Quintin Zhao Etheric Networks 1009 S Claremont St<https://www.google.com/maps/search/1009+S+Claremont+St.+%0D%0A%C2%A0+%C2%A0San+Mateo,+CA+94402+%0D%0A%C2%A0+%C2%A0United+States+of+America?entry=gmail&source=g> San Mateo, CA 9440<https://www.google.com/maps/search/1009+S+Claremont+St.+%0D%0A%C2%A0+%C2%A0San+Mateo,+CA+94402+%0D%0A%C2%A0+%C2%A0United+States+of+America?entry=gmail&source=g>2 United States of Americ<https://www.google.com/maps/search/1009+S+Claremont+St.+%0D%0A%C2%A0+%C2%A0San+Mateo,+CA+94402+%0D%0A%C2%A0+%C2%A0United+States+of+America?entry=gmail&source=g>a Email: quintinz...@gmail.com<mailto: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<mailto:dhruv.i...@gmail.com>> wrote: >>>> >>>> Hi, >>>> >>>> On Mon, Nov 18, 2024 at 11:09 PM >>>> <rfc-edi...@rfc-editor.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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
