Hi Sandy, All modifications are satisfactory. Thanks for your work. I approve its publication as an RFC.
Regards, Haibo |-----Original Message----- |From: Hantao(hantao,Datacom) <han...@huawei.com> |Sent: Thursday, May 22, 2025 5:43 PM |To: Dongjie (Jimmy) <jie.dong=40huawei....@dmarc.ietf.org>; Sandy Ginoza |<sgin...@staff.rfc-editor.org> |Cc: RFC Editor <rfc-edi...@rfc-editor.org>; Wanghaibo (Rainsword) |<rainsword.w...@huawei.com>; ketant.i...@gmail.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: 答复: AUTH48: RFC-to-be 9723 <draft-ietf-idr-cpr-08> for your review | | |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
