Re: [auth48] AUTH48: RFC-to-be 9573 <draft-ietf-bess-mvpn-evpn-aggregation-label-14> for your review

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Lynne,

Sorry for not responding earlier.
I have been traveling for business and vacation but will prioritize this once I get back this Monday.

Thanks!
Jeffrey


Juniper Business Use Only

________________________________
From: Lynne Bartholomew <[e-mail]>
Sent: Friday, April 19, 2024 11:27:08 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; [e-mail] <[e-mail]>; Wen Lin <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; auth48archive <[e-mail]>
Subject: Re: AUTH48: RFC-to-be 9573 <draft-ietf-bess-mvpn-evpn-aggregation-label-14> for your review

[External Email. Be cautious of content]


We got a bounce message for Gunter.  Resending, using Gunter's Nokia address.

> On Apr 19, 2024, at 10:24 AM, Lynne Bartholomew <[e-mail]> wrote:
>
> Dear authors,
>
> We do not believe that we have heard from you regarding this document and the questions below.
>
> Please review this document and the questions, and let us know how the document should be updated.
>
> The files (links copied from the "Instructions for Completing AUTH48" email below) are here:
>
>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9573.xml__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAE5uRYcUg$
>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9573.html__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAEnGGzPLQ$
>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9573.pdf__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAEcBkHGwA$
>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9573.txt__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAFPilva1w$
>
> Diff file of the text:
>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9573-diff.html__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAFnA1YUOg$
>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9573-rfcdiff.html__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAFyS1WLKg$  (side by side)
>
> Diff of the XML:
>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9573-xmldiff1.html__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAEeGbfIgQ$
>
> The following files are provided to facilitate creation of your own diff files of the XML.
>
> Initial XMLv3 created using XMLv2 as input:
>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9573.original.v2v3.xml__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAH9F7BFTA$
>
> XMLv3 file that is a best effort to capture v3-related format updates only:
>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9573.form.xml__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAFZOXekkQ$
>
>
> Thank you!
>
> RFC Editor/lb
>
>
>> On Apr 10, 2024, at 3:46 PM, [e-mail] wrote:
>>
>> Authors,
>>
>> While reviewing this document during AUTH48, please resolve (as necessary)
>> the following questions, which are also in the XML file.
>>
>> 1) <!-- [rfced] Running (abbreviated) title (PDF output):  We changed
>> "mvpn-evpn-aggregation-label" to "MVPN/EVPN Aggregation Labels" so
>> that the title is more descriptive.  Please let us know any
>> objections.
>>
>> Original:
>> mvpn-evpn-aggregation-label
>>
>> Currently (PDF output):
>> MVPN/EVPN Aggregation Labels -->
>>
>>
>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
>> title) for use on <https://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAH6ZMPeqQ$ >. -->
>>
>>
>> 3) <!-- [rfced] Datatracker idnits yielded the following warning:
>>
>> (Using the creation date from RFC6514, updated by this document, for
>> RFC5378 checks: 2006-08-01)
>>
>> - The document seems to lack a disclaimer for pre-RFC5378 work, but may
>>  have content which was first submitted before 10 November 2008.  If you
>>  have contacted all the original authors and they are all willing to grant
>>  the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
>>  this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
>>  (See the Legal Provisions document at
>>  https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAHN4XexhQ$  for more information.)
>>
>> Please review, and advise. -->
>>
>>
>> 4) <!-- [rfced] We restructured Sections 1 and 2 of this document per
>> standard practice (e.g., RFCs 9251 and 9252, which are also part of
>> Cluster 448 (https://urldefense.com/v3/__https://www.rfc-editor.org/cluster_info.php?cid=C448__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAF5PH4-Rg$ ))
>> and per Section 4.8.1 ("Introduction Section") of RFC 7322
>> ("RFC Style Guide" - https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc7322__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAH72R48wg$ ).
>> Please let us know any concerns.
>>
>> Original:
>> 1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
>> 2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
>>  2.1.  Problem Description . . . . . . . . . . . . . . . . . . .   5
>>  2.2.  Proposed Solution . . . . . . . . . . . . . . . . . . . .   6
>>    2.2.1.  MP2MP Tunnels . . . . . . . . . . . . . . . . . . . .   8
>>    2.2.2.  Segmented Tunnels . . . . . . . . . . . . . . . . . .   8
>>    2.2.3.  Summary of Label Allocation Methods . . . . . . . . .  10
>> 3.  Specification . . . . . . . . . . . . . . . . . . . . . . . .  11
>> ...
>>
>> Currently:
>> 1.  Introduction
>>  1.1.  Requirements Language
>>  1.2.  Terminology
>> 2.  Problem Description
>> 3.  Proposed Solutions
>>  3.1.  MP2MP Tunnels
>>  3.2.  Segmented Tunnels
>>  3.3.  Summary of Label Allocation Methods
>> 4.  Specification
>> ... -->
>>
>>
>> 5) <!-- [rfced] Terminology section:
>>
>> a) For ease of the reader, we defined "A-D" as "Auto-Discovery" per
>> RFC 6514 (but initial-capitalized, per other definitions in this
>> document).  Please let us know any concerns.
>>
>> Original:
>> *  IMET [RFC7432]: Inclusive Multicast Ethernet Tag route.  An EVPN
>>   specific name for I-PMSI A-D route.
>>
>> Currently:
>> IMET [RFC7432]:  Inclusive Multicast Ethernet Tag.  An EVPN-
>>   specific name for an I-PMSI Auto-Discovery (A-D) route.
>>
>> b) We changed "PMXI" to "PMSI", as we could not find "PMXI" elsewhere
>> in this document or in any published RFC.  Also, we changed
>> "an BGP... routes" to "a BGP... route".  Please let us know any
>> concerns.
>>
>> Original:
>> *  PTA [RFC6514]: PMSI Tunnel Attribute.  A BGP attribute that may be
>>   attached to an BGP-MVPN/EVPN x-PMXI A-D routes.
>>
>> Currently:
>> PTA [RFC6514]:  PMSI Tunnel Attribute.  A BGP attribute that may be
>>   attached to a BGP-MVPN/EVPN x-PMSI A-D route. -->
>>
>>
>> 6) <!-- [rfced] "Problem Description" section:  Please confirm that
>> "the VRF/BD label case above" should not instead be "the VPN/BD label
>> case above".  We ask because we see "VPN/BD" used in the first
>> paragraph of this section and elsewhere in this document, but we do
>> not see any other instances of "VRF/BD" in this document.
>>
>> Original:
>> From the
>> receiving PE's point of view, the ESI label is (upstream-)assigned
>> from the source PE's label space, so the receiving PE needs to
>> maintain context-specific label tables, one for each source PE, just
>> like the VRF/BD label case above. -->
>>
>>
>> 7) <!-- [rfced] "Proposed Solutions" section:  Please confirm that
>> "Access Circuits" and not "Attachment Circuits" is correct here.
>>
>> Original:
>> A PE that is
>> attached (via L3VPN VRF interfaces or EVPN Access Circuits) would
>> know by provisioning which label from the DCB corresponds to which of
>> its locally attached VPNs, BDs, or ESes. -->
>>
>>
>> 8) <!-- [rfced] "Proposed Solutions" section:  This sentence does not
>> parse.  It appears that some words are missing.  Please clarify
>> "and they are all provisioned that label".
>>
>> Also, should "[1000, 2000]" be "[1000~2000]" per other block ranges
>> listed in this document?
>>
>> Original:
>> For example, all PEs could reserve a DCB [1000, 2000] and they are
>> all provisioned that label 1000 maps to VPN 0, 1001 to VPN 1, and so
>> forth.
>>
>> Possibly:
>> For example, all PEs could reserve a DCB [1000~2000], and they
>> could all be provisioned such that label 1000 maps to VPN 0, 1001 to
>> VPN 1, and so forth. -->
>>
>>
>> 9) <!-- [rfced] "Proposed Solutions" section:  Is "domain" always
>> loosely defined, or does this statement only apply to this document?
>>
>> Original:
>> The definition of "domain" is loose - it simply includes all the
>> routers that share the same DCB.  In this document, it only needs to
>> include all PEs of an MVPN/EVPN network.
>>
>> Possibly:
>> In this document, "domain" is defined loosely; it simply includes
>> all the routers that share the same DCB, and it only needs to
>> include all PEs of an MVPN/EVPN. -->
>>
>>
>> 10) <!-- [rfced] "Proposed Solutions" section:  Please confirm that
>> "P routers" and not "PE routers" is intended here.  (We also ask
>> because we do not see "P router" or "P routers" used anywhere else
>> in Cluster 448 (https://urldefense.com/v3/__https://www.rfc-editor.org/cluster_info.php?cid=C448__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAF5PH4-Rg$ ).
>>
>> Original:
>> Therefore, it is
>> better to not include internal P routers in the "domain". -->
>>
>>
>> 11) <!-- [rfced] "Proposed Solution" section:  Does "independent of each
>> PE" refer to allocation, as used elsewhere in this document (in which
>> case it should be "independently of each PE"), or does it refer to
>> label spaces that are independent of each PE (in which case this text
>> should be rephrased)?  Please clarify.
>>
>> Original:
>> In this
>> case, it may be necessary to allocate those labels from one or a few
>> separate context-specific label spaces independent of each PE. -->
>>
>>
>> 12) <!-- [rfced] "Proposed Solutions" section:  As it appears that "them"
>> in this sentence refers to "a label", we changed "them" to "the
>> label".  We also changed "from a context-specific label spaces" to
>> "from a context-specific label space".  If these updates are
>> incorrect, please provide text that clarifies the singular versus the
>> plural.
>>
>> Original:
>> Allocating a label from the DCB or from a context-specific
>> label spaces and communicating them to all PEs is not different from
>> allocating VNIs, and is feasible especially with controllers.
>>
>> Currently:
>> Allocating a label from the DCB or from a context-specific
>> label space and communicating the label to all PEs is not different
>> from allocating VNIs and is especially feasible with controllers. -->
>>
>>
>> 13) <!-- [rfced] "MP2MP Tunnels" section:  We found this sentence
>> confusing, because the "Problem Description" section appears to
>> discuss more than one problem ("This is an evident scaling problem",
>> "this problem has not surfaced", "A similar problem also exists").
>> Which problem is referred to here?  Please provide clarifying text.
>>
>> Original:
>> MP2MP tunnels present the same problem (Section 2.1) that can be
>> solved the same way (Section 2.2), with the following additional
>> requirement. -->
>>
>>
>> 14) <!-- [rfced] "MP2MP Tunnels" section:  Section 3.2.2.1 of RFC 7582
>> appears to use a "MUST" when discussing this topic, as opposed to the
>> "may" as used in this sentence.  Will this distinction be clear to
>> readers?
>>
>> Original:
>> Per RFC 7582 ("MVPN: Using Bidirectional P-tunnels"), when MP2MP
>> tunnels are used for MVPN, the root of the MP2MP tunnel may need to
>> allocate and advertise "PE Distinguisher Labels" (section 4 of
>> [RFC6513]. -->
>>
>>
>> 15) <!-- [rfced] "Selective Tunnels" section:  We could not parse this
>> sentence.  To what do "that" and "PE's" refer - a block, a label, or
>> something else?
>>
>> Original:
>> To address
>> this problem, all PEs can be assigned disjoint label blocks in those
>> few context-specific label spaces, and each will independently
>> allocate labels for segmented S-PMSI from its assigned label block
>> that is different from any other PE's.
>>
>> Possibly:
>> To address
>> this problem, all PEs can be assigned their own disjoint label
>> blocks in those few context-specific label spaces; each PE will
>> independently allocate labels for a segmented S-PMSI from its own
>> assigned label block. -->
>>
>>
>> 16) <!-- [rfced] "Specification" section:  The meaning and purpose of
>> this section title are unclear.  Would "Specifications" be clearer,
>> or perhaps something more descriptive (e.g., "New Extended Community
>> and Related Procedures", assuming that this title would be accurate)?
>>
>> Original:
>> 3.  Specification -->
>>
>>
>> 17) <!-- [rfced] "Context-Specific Label Space ID Extended Community"
>> section:  Please clarify the meaning of "most significant 20-bit".
>> Does it mean "most significant 20 bits", "most significant 20-bit
>> portion", or something else?  Is this related to Erratum ID 5554
>> for RFC 7432 (https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid5554)?__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAGj4lsMQg$
>>
>> Original:
>> *  ID-Value: A 4-octet field that specifies the value of Label Space
>>   ID.  When it is a label (with ID-Type 0), the most significant
>>   20-bit is set to the label value. -->
>>
>>
>> 18) <!-- [rfced] "Context-Specific Label Space ID Extended Community"
>> section:  We see one instance each of "carry a DCB-flag" and "carries
>> the DCB-flag" in the "Procedures" section.  However, we do not see
>> any instances of "has DCB-flag attached" or "DCB-flag attached"
>> elsewhere in this document.  To avoid confusion, we suggest either
>> removing the quotes in this sentence or rephrasing the text.
>>
>> Original:
>> In the remainder of the document, when we say a BGP-MVPN/EVPN A-D
>> route "carries DCB-flag" or "has DCB-flag attached" we mean the
>> following:
>>
>> Possibly:
>> In the remainder of this document, when we say that a BGP-MVPN/EVPN
>> A-D route carries a DCB-flag or has a DCB-flag attached to it, we
>> mean the following: -->
>>
>>
>> 19) <!-- [rfced] "Procedures" section:  This sentence did not parse.  We
>> updated it as noted below.  If this is incorrect, please provide
>> clarifying text.
>>
>> Original:
>> The protocol and procedures specified in this section MAY be used
>> when BIER, or P2MP/MP2MP tunnel aggregation is used for MVPN/EVPN, or
>> BIER/P2MP/MP2MP tunnels are used with EVPN multi-homing.
>>
>> Suggested:
>> The protocol and procedures specified in this section MAY be used
>> when BIER or P2MP/MP2MP tunnel aggregation is used for an MVPN/EVPN
>> or when BIER/P2MP/MP2MP tunnels are used with EVPN multihoming. -->
>>
>>
>> 20) <!-- [rfced] "Procedures" section:  As it appears that "both" refers
>> to the DCB-flag and the Context-Specific Label Space ID EC and not
>> to the x-PMSI/IMET route, we changed "both carry" to "carry both".
>> If this is incorrect, please provide clarifying text.
>>
>> Original:
>> An x-PMSI/IMET route MUST NOT both carry the DCB-flag and the
>> Context-Specific Label Space ID EC.
>>
>> Currently:
>> An x-PMSI/IMET route MUST NOT carry both the DCB-flag and the
>> Context-Specific Label Space ID EC. -->
>>
>>
>> 21) <!-- [rfced] Security Considerations:  Should "one of a few" be
>> "one or a few" or "one or several" here, or does the text mean
>> "one out of several possible tables"?
>>
>> Original:
>> In all
>> cases, a receiving PE is able to identify one of a few label
>> forwarding tables to forward incoming labeled traffic.
>>
>> Possibly:
>> In all
>> cases, a receiving PE is able to identify one or several label
>> forwarding tables for forwarding incoming labeled traffic. -->
>>
>>
>> 22) <!-- [rfced] Section 5:  We cited RFC 8126 here, per standard
>> practice (e.g., RFCs 9251 and 9252), and we added a listing for
>> RFC 8126 in the Informative References section.  Please let us
>> know any concerns.
>>
>> Original:
>> The registration procedure is First Come First Served.
>>
>> Currently:
>> The registration procedure is First Come First Served
>> [RFC8126].
>> ...
>> [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
>>           Writing an IANA Considerations Section in RFCs", BCP 26,
>>           RFC 8126, DOI 10.17487/RFC8126, June 2017,
>>           <https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc8126__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAFvLV6VzA$ >. -->
>>
>>
>> 23) <!-- [rfced] Please review the "Inclusive Language" portion of the
>> online Style Guide at
>> <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAGsi0OX6Q$ >,
>> and let us know if any changes are needed.
>>
>> Note that our script did not flag any words in particular, but this
>> should still be reviewed as a best practice. -->
>>
>>
>> 24) <!-- [rfced] Please let us know if any changes are needed for the
>> following:
>>
>> a) The following terms/values were used inconsistently in this
>> document.  We chose to use the latter forms.  Please let us know any
>> objections.
>>
>> 1,000 / 1000
>>
>> 1,001 / 1001
>>
>> context label spaces (1 instance) / context-specific label spaces
>>
>> Context Label Space ID EC (1 instance) /
>>  Context-Specific Label Space ID EC
>>
>> DCB flag (2 instances) / DCB-flag (9 instances)*
>>
>> * Please note that although we updated this document so that usage
>>   of this particular term is consistent, Cluster 448
>>   (https://urldefense.com/v3/__https://www.rfc-editor.org/cluster_info.php?cid=C448__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAF5PH4-Rg$ ) otherwise
>>   does not use any hyphenated flag names.  Please let us know if
>>   you prefer that this document use "DCB flag" instead.
>>
>> Ingress Replication / ingress replication (per RFCs 9251 and 9252)
>>
>> PE Distinguisher labels / PE Distinguisher Labels (per RFCs 7582
>>  and 6513)
>>
>> per-PE/Region / per-PE/region
>>  (along the lines of "AS/region" as used in this document and
>>  companion document draft-ietf-bess-evpn-bum-procedure-updates)
>>
>> b) The following terms appear to be used inconsistently in this
>> document.  Please let us know which form is preferred.
>>
>> Customer / customer (e.g., "overlay/customer",
>>  "All Customer/overlay")
>>  (We suggest "customer" per the rest of Cluster 448.) -->
>>
>>
>> Thank you.
>>
>> RFC Editor
>>
>>
>>
>> On Apr 10, 2024, at 3:38 PM, [e-mail] wrote:
>>
>> *****IMPORTANT*****
>>
>> Updated 2024/04/10
>>
>> 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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAHIrmzhbA$ ).
>>
>> 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://urldefense.com/v3/__https://trustee.ietf.org/license-info/__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAFX1Rqm1Q$ ).
>>
>> *  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://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAGyV8c8sg$ >.
>>
>> *  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
>>
>>  *  [e-mail] (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).
>>
>>  *  [e-mail], which is a new archival mailing list
>>     to preserve AUTH48 conversations; it is not an active discussion
>>     list:
>>
>>    *  More info:
>>       https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAHzSMCLKw$
>>
>>    *  The archive itself:
>>       https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAFgTejybg$
>>
>>    *  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,
>>       [e-mail] 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9573.xml__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAE5uRYcUg$
>>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9573.html__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAEnGGzPLQ$
>>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9573.pdf__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAEcBkHGwA$
>>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9573.txt__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAFPilva1w$
>>
>> Diff file of the text:
>>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9573-diff.html__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAFnA1YUOg$
>>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9573-rfcdiff.html__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAFyS1WLKg$  (side by side)
>>
>> Diff of the XML:
>>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9573-xmldiff1.html__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAEeGbfIgQ$
>>
>> The following files are provided to facilitate creation of your own
>> diff files of the XML.
>>
>> Initial XMLv3 created using XMLv2 as input:
>>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9573.original.v2v3.xml__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAH9F7BFTA$
>>
>> XMLv3 file that is a best effort to capture v3-related format updates
>> only:
>>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9573.form.xml__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAFZOXekkQ$
>>
>>
>> Tracking progress
>> -----------------
>>
>> The details of the AUTH48 status of your document are here:
>>  https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9573__;!!NEt6yMaO-gk!FURJyqFyRTgXR3j68B8nuyMtHw-Hf8-0Pt61xGJunetDgcC4f5TEI-mhw7ig9OgA5ZvC17qGyrUYtAGpcshDFg$
>>
>> Please let us know if you have any questions.
>>
>> Thank you for your cooperation,
>>
>> RFC Editor
>>
>> --------------------------------------
>> RFC9573 (draft-ietf-bess-mvpn-evpn-aggregation-label-14)
>>
>> Title            : MVPN/EVPN Tunnel Aggregation with Common Labels
>> Author(s)        : Z. Zhang, E. Rosen, W. Lin, Z. Li, IJ. Wijnands
>> WG Chair(s)      : Matthew Bocci, Stephane Litkowski, Zhaohui (Jeffrey) Zhang
>>
>> Area Director(s) : Jim Guichard, John Scudder, Gunter Van de Velde
>>
>>
>