Hi Sandy,
Appreciate the work put into this document.I approve its publication as RFC.
Best Regards,
Ran
Original
From: KetanTalaulikar <ketant.i...@gmail.com>
To: Dongjie (Jimmy) <jie.d...@huawei.com>;
Cc: Sandy Ginoza <sgin...@staff.rfc-editor.org>;RFC Editor
<rfc-edi...@rfc-editor.org>;Wanghaibo (Rainsword)
<rainsword.w...@huawei.com>;Hantao(hantao,Datacom)
<han...@huawei.com>;陈然00080434;idr-...@ietf.org
<idr-...@ietf.org>;idr-cha...@ietf.org <idr-cha...@ietf.org>;sha...@ndzh.com
<sha...@ndzh.com>;John Scudder <j...@juniper.net>;auth48archive@rfc-editor.org
<auth48archive@rfc-editor.org>;
Date: 2025年05月22日 16:07
Subject: Re: AUTH48: RFC-to-be 9723 <draft-ietf-idr-cpr-08> for your review
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
