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

[[e-mail]]

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