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

[Lynne Bartholomew <[e-mail]>]

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
> >>
> >>
> >
>