Hi Sandy, Thanks for your work on this document. Please also mark my approval for publication.
Thanks, Ketan On Thu, May 22, 2025 at 12:43 PM Dongjie (Jimmy) <jie.d...@huawei.com> wrote: > 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
