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

[Lynne Bartholomew <[e-mail]>]

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://www.rfc-editor.org/authors/rfc9573.xml
  https://www.rfc-editor.org/authors/rfc9573.html
  https://www.rfc-editor.org/authors/rfc9573.pdf
  https://www.rfc-editor.org/authors/rfc9573.txt

Diff file of the text:
  https://www.rfc-editor.org/authors/rfc9573-diff.html
  https://www.rfc-editor.org/authors/rfc9573-rfcdiff.html (side by side)

Diff of the XML: 
  https://www.rfc-editor.org/authors/rfc9573-xmldiff1.html

The following files are provided to facilitate creation of your own diff files of the XML.  

Initial XMLv3 created using XMLv2 as input:
  https://www.rfc-editor.org/authors/rfc9573.original.v2v3.xml 

XMLv3 file that is a best effort to capture v3-related format updates only: 
  https://www.rfc-editor.org/authors/rfc9573.form.xml


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://www.rfc-editor.org/search>. -->
> 
> 
> 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://trustee.ietf.org/license-info 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://www.rfc-editor.org/cluster_info.php?cid=C448))
> and per Section 4.8.1 ("Introduction Section") of RFC 7322
> ("RFC Style Guide" - https://www.rfc-editor.org/info/rfc7322).
> 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://www.rfc-editor.org/cluster_info.php?cid=C448).
> 
> 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://www.rfc-editor.org/errata/eid5554)?
> 
> 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://www.rfc-editor.org/info/rfc8126>. -->
> 
> 
> 23) <!-- [rfced] Please review the "Inclusive Language" portion of the
> online Style Guide at
> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
> 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://www.rfc-editor.org/cluster_info.php?cid=C448) 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://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
> 
>   *  [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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> 
>     *  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, 
>        [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://www.rfc-editor.org/authors/rfc9573.xml
>   https://www.rfc-editor.org/authors/rfc9573.html
>   https://www.rfc-editor.org/authors/rfc9573.pdf
>   https://www.rfc-editor.org/authors/rfc9573.txt
> 
> Diff file of the text:
>   https://www.rfc-editor.org/authors/rfc9573-diff.html
>   https://www.rfc-editor.org/authors/rfc9573-rfcdiff.html (side by side)
> 
> Diff of the XML: 
>   https://www.rfc-editor.org/authors/rfc9573-xmldiff1.html
> 
> The following files are provided to facilitate creation of your own 
> diff files of the XML.  
> 
> Initial XMLv3 created using XMLv2 as input:
>   https://www.rfc-editor.org/authors/rfc9573.original.v2v3.xml 
> 
> XMLv3 file that is a best effort to capture v3-related format updates 
> only: 
>   https://www.rfc-editor.org/authors/rfc9573.form.xml
> 
> 
> Tracking progress
> -----------------
> 
> The details of the AUTH48 status of your document are here:
>   https://www.rfc-editor.org/auth48/rfc9573
> 
> 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
> 
>