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

[Lynne Bartholomew <[e-mail]>]

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