Hi Sandy, All the changes look good to me, thanks. I approve its publication as RFC.
Best regards, Jie > -----Original Message----- > From: Sandy Ginoza <sgin...@staff.rfc-editor.org> > Sent: Thursday, May 22, 2025 1:49 AM > To: Dongjie (Jimmy) <jie.dong=40huawei....@dmarc.ietf.org> > Cc: RFC Editor <rfc-edi...@rfc-editor.org>; Wanghaibo (Rainsword) > <rainsword.w...@huawei.com>; ketant.i...@gmail.com; > Hantao(hantao,Datacom) <han...@huawei.com>; chen....@zte.com.cn; > idr-...@ietf.org; idr-cha...@ietf.org; sha...@ndzh.com; John Scudder > <j...@juniper.net>; auth48archive@rfc-editor.org > Subject: Re: AUTH48: RFC-to-be 9723 <draft-ietf-idr-cpr-08> for your review > > Hi Dongjie, > > Thank you for your reply. We have updated the document as described below > and posted the files here: > https://www.rfc-editor.org/authors/rfc9723.txt > https://www.rfc-editor.org/authors/rfc9723.pdf > https://www.rfc-editor.org/authors/rfc9723.html > https://www.rfc-editor.org/authors/rfc9723.xml > > AUTH48 diffs: > https://www.rfc-editor.org/authors/rfc9723-auth48diff.html > https://www.rfc-editor.org/authors/rfc9723-auth48rfcdiff.html (side by > side) > > Comprehensive diffs: > https://www.rfc-editor.org/authors/rfc9723-diff.html > https://www.rfc-editor.org/authors/rfc9723-rfcdiff.html (side by side) > > Please review and let us know if any additional updates are needed or if you > approve the RFC for publication. > > Thank you, > RFC Editor/sg > > > > On May 14, 2025, at 7:54 AM, Dongjie (Jimmy) > <jie.dong=40huawei....@dmarc.ietf.org> wrote: > > > > Hi RFC Editor, > > > > Thanks for this mail. Please find my replies inline. > > > > > >> -----Original Message----- > >> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> > >> Sent: Tuesday, May 13, 2025 4:41 AM > >> To: Wanghaibo (Rainsword) <rainsword.w...@huawei.com>; Dongjie > >> (Jimmy) <jie.d...@huawei.com>; ketant.i...@gmail.com; > >> Hantao(hantao,Datacom) <han...@huawei.com>; chen....@zte.com.cn > >> Cc: rfc-edi...@rfc-editor.org; idr-...@ietf.org; idr-cha...@ietf.org; > >> sha...@ndzh.com; j...@juniper.net; auth48archive@rfc-editor.org > >> Subject: Re: AUTH48: RFC-to-be 9723 <draft-ietf-idr-cpr-08> 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 insert any keywords (beyond those that appear > >> in the title) for use on https://www.rfc-editor.org/search. --> > > > > Please add: intent-aware routing as keyword. > > > > > >> > >> 2) <!-- [rfced] RFC 8277 doesn't appear to use the term "BGP Labeled > Unicast" > >> or "BGP-LU." For clarity, may we add text to draw a more clear > >> connection, for example, "the mechanism described in RFC 8277 is > >> referred to BGP-LU although that term does not actually appear in the > document." > >> > >> Original: > >> The inter-domain path can be established using either Multi-Protocol > >> Label Switching (MPLS) or IP data plane. In MPLS-based networks, the > >> usual inter-domain approach is to establish an end-to-end Label- > >> Switched Path (LSP) based on the BGP Labeled Unicast (BGP-LU) > >> mechanism as defined in [RFC8277]. > >> --> > >> > > > > Thanks for catching this. Maybe the second sentence could be rephrased as: > > > > New: > > In MPLS-based networks, the usual inter-domain approach is to establish > an end-to-end Label-Switched Path (LSP) based on the mechanism as defined > in [RFC8277] (which is usually referred to as BGP-LU). > > > >> > >> 3) <!-- [rfced] Would it be correct to change "and" to "whereby"? > >> > >> Original: > >> One way to achieve this is by splitting the base SRv6 locator of the > >> node into N sub-locators, and these sub-locators are Colored Prefixes > >> associated with different intents. > >> --> > > > > Yes, that change looks good. > > > >> > >> > >> 4) <!-- [rfced] RFC 2545 does not contain the term "IPv6 unicast > >> Address Family/Subsequent Address Family (AFI/SAFI = 2/1)", "AFI", or > >> "SAFI". We see one instance of "Address Family" and a couple instances of > "unicast address". > >> Please consider how the text and citation can be clarified. > >> > >> In a multi-AS IPv6 network, the IPv6 unicast Address Family/ > >> Subsequent Address Family (AFI/SAFI = 2/1) [RFC2545] is used for the > >> advertisement of the Colored Prefix routes. > >> --> > > > > The IPv6 unicast AFI/SAFI is the combination of AFI =2 for IPv6 and SAFI = 1 > (allocated by IANA) for unicast forwarding, and the mechanism for IPv6 unicast > routing is specified in RFC 2545. It is an relatively old RFC and there is no > IANA > considerations section. > > > > How about rephrasing the text as: > > > > New: > > > > In a multi-AS IPv6 network, the mechanism for IPv6 unicast routing as > defined in [RFC2545] is used for the advertisement of the Colored Prefix > routes, > in which the Address Family/Subsequent Address Family (AFI/SAFI = 2/1) is > used. > > > > > >> > >> 5) <!-- [rfced] In the bulleted list, is it correct for SRv6 to be > >> listed twice? Also, adding conjunctions may improve clarity regarding > >> how the mechanisms are related. Is the path built with a combination > >> of the bulleted items or only one of the individual items? > >> > >> Original: > >> The intra-domain color-aware path could > >> be built with any of the following mechanisms: > >> > >> * SRv6 or SR-MPLS Policy > >> > >> * SRv6 or SR-MPLS Flex-Algo > >> > >> * RSVP-TE > >> > >> Perhaps (a combination): > >> The intra-domain color-aware path could > >> be built with any of the following mechanisms: > >> > >> * SRv6 or SR-MPLS Policy, and > >> * SRv6 or SR-MPLS Flex-Algo, and > >> * RSVP-TE. > > > > The first bullet means "SRv6 Policy or SR-MPLS policy", and the second > > bullet > means "SRv6 Flex-algo or SR-MPLS Flex-Algo". Maybe a better approach is to > list each of them separately. > > > > New: > > The intra-domain color-aware path could be built with any of the > following mechanisms: > > * SRv6 Policy > > * SR-MPLS Policy > > * SRv6 Flex-Algo > > * SR-MPLS Flex-Algo > > * RSVP-TE > > > > > >> > >> Perhaps (a single item): > >> The intra-domain color-aware path could > >> be built with any of the following mechanisms: > >> > >> * SRv6, > >> * SR-MPLS Policy, > >> * SR-MPLS Flex-Algo, or > >> * RSVP-TE. > >> --> > >> > >> > >> 6) <!-- [rfced] "which makes them belonging" is unclear. We have > >> updated the text as shown below. > >> > >> Original: > >> The CPR mechanism can be used in network scenarios where multiple > >> inter-connected ASes belong to the same operator, or there is an > >> operational trust model between the ASes of different operators which > >> makes them belonging to the same trusted domain (in the sense used by > >> Section 8 of [RFC8402]). > >> > >> Current: > >> The CPR mechanism can be used in network scenarios where multiple > >> inter-connected ASes belong to the same operator, or where there is > >> an operational trust model between the ASes of different operators > >> which means they belong to the same trusted domain (in the sense used > >> by Section 8 of [RFC8402]). > >> --> > > > > The updated text looks good, thanks. > > > > > >> > >> 7) <!-- [rfced] What spans across multiple ASes? Is it the SR Policy > >> or the tunnel? > >> > >> Original: > >> As described in section 5 of > >> [I-D.hr-spring-intentaware-routing-using-color], the inter-domain > >> intent-aware routing may be achieved with a logical tunnel created by > >> an SR Policy across multiple ASes, and service traffic with specific > >> intent can be steered to the inter-domain SR Policy based on the > >> intent signaled by Color Extended Community. > >> > >> Perhaps: > >> As described in Section 5 of > >> [INTENTAWARE], the inter-domain > >> intent-aware routing may be achieved with a logical tunnel created by > >> an SR Policy that applies to multiple ASes. In addition, service > >> traffic with a specific intent can be steered to the inter-domain > >> SR Policy based on the intent signaled by Color Extended Community. > >> --> > > > > It should be the tunnel which spans across multiple ASes. The updated text > looks good. > > > > > >> > >> 8) <!-- [rfced] Is seems as though there may be words missing in the > following. > >> What can "fall back"? > >> > >> Original: > >> This allows the CPR routes to be resolved to > >> intent-aware intra-domain paths in any autonomous systems that > >> support the CPR mechanism, while can fall back to resolve over best- > >> effort intra-domain path in the legacy autonomous systems. > > > > It is the CPR route which can fall back to resolve over best-effort > intra-domain path. > > > > New: > > > > ...while the CPR routes can fall back to resolve over best-effort > > intra-domain > paths in the legacy autonomous systems. > > > > > > > >> --> > >> > >> > >> 9) <!-- [rfced] Throughout the text, the following terminology > >> appears to be used inconsistently. Please review. > >> > >> a) Colored Prefix vs Colored prefixes vs colored prefix > >> > >> We updated to use the form on the left. Please let us know if any > >> updates are needed. > >> > >> In addition, please consider whether the capitalization of "Colored > >> locator prefixes" is correct. > > > > Please use "Colored Prefix", or "Colored Prefixes" for plural. > > > > > >> > >> > >> b) Please review the use of the following and let us know how/if they > >> may be updated for consistency. > >> > >> color extended community vs Color Extended Community > > > > Please use the latter one, thanks. > > > > > >> > >> --> > >> > >> > >> 10) <!-- [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. > >> > >> Note that our script did not flag any words in particular, but this > >> should still be reviewed as a best practice. > > > > After checking I believe the current text is OK in this aspect. > > > > Many thanks, > > Jie > > > >> --> > >> > >> > >> Thank you. > >> > >> RFC Editor > >> > >> > >> > >> On May 12, 2025, at 1:38 PM, rfc-edi...@rfc-editor.org wrote: > >> > >> *****IMPORTANT***** > >> > >> Updated 2025/05/12 > >> > >> 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-4Q9l2USx > >> IAe6P > >> 8O4Zc > >> > >> * 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/rfc9723.xml > >> https://www.rfc-editor.org/authors/rfc9723.html > >> https://www.rfc-editor.org/authors/rfc9723.pdf > >> https://www.rfc-editor.org/authors/rfc9723.txt > >> > >> Diff file of the text: > >> https://www.rfc-editor.org/authors/rfc9723-diff.html > >> https://www.rfc-editor.org/authors/rfc9723-rfcdiff.html (side by > >> side) > >> > >> Diff of the XML: > >> https://www.rfc-editor.org/authors/rfc9723-xmldiff1.html > >> > >> > >> Tracking progress > >> ----------------- > >> > >> The details of the AUTH48 status of your document are here: > >> https://www.rfc-editor.org/auth48/rfc9723 > >> > >> Please let us know if you have any questions. > >> > >> Thank you for your cooperation, > >> > >> RFC Editor > >> > >> -------------------------------------- > >> RFC 9723 (draft-ietf-idr-cpr-08) > >> > >> Title : BGP Colored Prefix Routing (CPR) for SRv6 based > Services > >> Author(s) : H. Wang, J. Dong, K. Talaulikar, T. Han, R. Chen > >> WG Chair(s) : Susan Hares, Keyur Patel, Jeffrey Haas > >> > >> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de > >> Velde > >> > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
