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

[Lynne Bartholomew <[e-mail]>]

Gunter, forwarding to your Nokia address as an FYI.  (We got a bounce for <[e-mail] <mailto:[e-mail]>>.)

> On Apr 19, 2024, at 2:02 PM, Lynne Bartholomew <[e-mail]> wrote:
> 
> Hi again, Jeffrey.  Thank you for this email as well!
> 
> RFC Editor/lb
> 
>> On Apr 19, 2024, at 1:56 PM, Jeffrey (Zhaohui) Zhang <[e-mail]> wrote:
>> 
>> 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
>>>> 
>>>> 
>>> 
>> 
>