Hi Jeff, Thank you for your attention during AUTH48 - it’s greatly appreciated.
RFC Editor/sg > On May 22, 2025, at 6:16 AM, Jeffrey Haas <jh...@pfrc.org> wrote: > > Note from this IDR chair: The changes to date continue to reflect the WG's > intent for the document. Thanks for adding to the quality of the document. > > -- Jeff > > >> On May 22, 2025, at 8:59 AM, Sandy Ginoza <sgin...@staff.rfc-editor.org> >> wrote: >> >> Authors, >> >> Thank you for your reviews. We have noted approvals from the following >> authors on the AUTH48 page <https://www.rfc-editor.org/auth48/rfc9723>: >> >> Jie Dong >> Ketan Talaulikar >> Tao Han >> Ran Chen >> >> We will wait for input from Haibo Wang before continuing with the process. >> >> Thank you, >> RFC Editor/sg >> >>> On May 22, 2025, at 2:43 AM, Hantao(hantao,Datacom) <han...@huawei.com> >>> wrote: >>> >>> >>> Hi Sandy, >>> >>> Thanks for your work on this document. I also approve its publication as >>> RFC. >>> >>> Best regards, >>> Tao >>> >>> -----邮件原件----- >>> 发件人: Dongjie (Jimmy) <jie.dong=40huawei....@dmarc.ietf.org> >>> 发送时间: 2025年5月22日 15:14 >>> 收件人: Sandy Ginoza <sgin...@staff.rfc-editor.org> >>> 抄送: 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 >>> 主题: RE: AUTH48: RFC-to-be 9723 <draft-ietf-idr-cpr-08> for your review >>> >>> 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-4Q9l2U >>>>>> Sx >>>>>> 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
