Re: [auth48] AUTH48: RFC-to-be 9541 <draft-ietf-bess-pbb-evpn-isid-cmacflush-09> for your review

[Alice Russo <[e-mail]>]

Jorge, 

Thank you for your reply. Please see notes and an additional question below.
The revised files are here (please refresh):
  https://www.rfc-editor.org/authors/rfc9541.html
  https://www.rfc-editor.org/authors/rfc9541.txt
  https://www.rfc-editor.org/authors/rfc9541.pdf
  https://www.rfc-editor.org/authors/rfc9541.xml

This diff file shows all changes from the approved I-D:
  https://www.rfc-editor.org/authors/rfc9541-diff.html
  https://www.rfc-editor.org/authors/rfc9541-rfcdiff.html (side by side)

This diff file shows the changes made during AUTH48 thus far:
  https://www.rfc-editor.org/authors/rfc9541-auth48diff.html

Re: #1, we have updated the document's title as requested. 
The abbreviated title (which appears in the PDF as the running header) has not been updated because it matches the text in Section 1 ('The C-MAC flush procedure explained in this document is referred to as "PBB-EVPN I-SID-based C-MAC flush"'). Please let us know if you prefer that it be updated as shown below, or otherwise..

Full title:
> Option A:
>    Flush Mechanism for Customer MAC Addresses
>    Based on Service Instance Identifier (I-SID)
>    in Provider Backbone Bridging EVPN (PBB-EVPN)


Abbreviated title:
Current:    PBB-EVPN I-SID-Based C-MAC-Flush
Perhaps:   C-MAC-Flush Based on I-SID in PBB-EVPN

Re: #4, updated the sentences with your new text; thank you for providing text that is more clear.

Re: #7b, updated to use abbreviations; please review that the text is still clear.

Please reply to one additional question:
10) In Figure 1, do you think "stb" will be clear to readers? (We do not see that abbreviation used in past RFCs.) If not, would you like to do either of these?
a) Adjust the figure to change "stb" to "standby", as it appears elsewhere in this figure.
b) Add a note below the figure, e.g., "stb" means "standby" in Figure 1.

We will wait to hear from you again and from your coauthors
before continuing the publication process. This page shows 
the AUTH48 status of your document:
  https://www.rfc-editor.org/auth48/rfc9541

Thank you.
RFC Editor/ar

> On Jan 30, 2024, at 5:34 AM, Jorge Rabadan (Nokia) <jorge.rabadan=[e-mail]> wrote:
> 
> Dear RFC-editor,
>  
> Thanks for your work on this document.
> Please see the resolution to your points in-line, with [jorge].
>  
> Thanks.
> Jorge
>  
> From: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
> Date: Monday, January 29, 2024 at 11:28 PM
> To: Jorge Rabadan (Nokia) <[e-mail] <mailto:[e-mail]>>, Senthil Sathappan (Nokia) <[e-mail] <mailto:[e-mail]>>, Kiran Nagaraj (Nokia) <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]><[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>, Matthew Bocci (Nokia) <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
> Subject: Re: AUTH48: RFC-to-be 9541 <draft-ietf-bess-pbb-evpn-isid-cmacflush-09> for your review
> 
> 
> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext <http://nok.it/ext> for additional information.
> 
> 
> 
> Authors,
> 
> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
> 
> 1) <!--[rfced] We recommend updating the title of this document
> to expand abbreviations that are not well known (see RFC 7322,
> Section 4.2 for more information). May we update the title
> as follows, or otherwise?
> 
> Original:
>    PBB-EVPN ISID-based C-MAC-Flush
> 
> Option A:
>    Flush Mechanism for Customer MAC Addresses
>    Based on Service Instance Identifier (I-SID)
>    in Provider Backbone Bridging EVPN (PBB-EVPN)
> 
> Option B:
>    C-MAC Flush Based on Service Instance Identifier (I-SID)
>    in Provider Backbone Bridging EVPN (PBB-EVPN)
> 
> Rationale:
> - "Provider Backbone Bridging EVPN (PBB-EVPN)"
>   as in the titles of RFCs 9489 and 8317.
>   (Alternatively, "Provider Backbone Bridging Combined with Ethernet VPN"
>   is in the title of RFC 7623.)
> - The original contains "C-MAC: Customer MAC address".
> - For C-MAC-Flush, we recommend removing the second hyphen (i.e.,
>   change to "C-MAC Flush" in the title) in keeping with
>   "C-MAC flushing" in RFC 7623.
> -->
> [Jorge] I like Option A better. Can you please use option A?
> 
> 
> 
> 2) <!--[rfced] Please clarify the meaning of "I-SID-based C-MAC-flush
> granularity is required". May it be rephrased as follows?
> 
> Original:
>    This document complements those C-MAC-flush
>    procedures for cases in which no PBB-EVPN Ethernet Segments are
>    defined (the attachment circuit is associated to a zero Ethernet
>    Segment Identifier) and a Service Instance Identifier based (I-SID-
>    based) C-MAC-flush granularity is required.
> 
> Perhaps:
> ... and the C-MAC flush requires I-SID-level granularity.
> -->
> [Jorge] I agree with your suggestion. Thanks.
> 
> 
> 
> 3) <!--[rfced] Regarding the terminology list in Section 1.1:
> 
> a) FYI, several items have been updated to match how they
> appear in RFC 7623 (a normative reference). Please let us
> know if you prefer otherwise - such as matching RFC 9489
> instead. (For example, "CE: Customer Edge" in RFC 7623
> vs. "CE: Customer Edge Device" in RFC 9489.)
> [Jorge] updates look good to me.
> 
> 
> b) May we separate the abbreviations and terminology into two
> sections for ease of the reader? See below.
> 
> 1.1. Abbreviations
> 
>    AC:  Attachment Circuit
> 
>    B-MAC:  Backbone MAC
> 
>    CE:  Customer Edge
> 
>    C-MAC:  Customer MAC
> 
>    [...]
> 
> 1.2. Terminology and Conventions
> 
>    Familiarity with the terminology in [RFC7623] is expected.
> 
>    B-MAC/0 route:  This is an EVPN MAC/IP Advertisement route that uses
>       a B-MAC in the MAC address field and a zero Ethernet Tag ID.
> 
>    B-MAC/I-SID route:  This is an EVPN MAC/IP Advertisement route that
>       uses a B-MAC in the MAC address field and an I-SID in the Ethernet
>       Tag field.  It is used to notify remote PEs about the required C-
>       MAC-flush procedure for the C-MACs associated with the advertised
>       B-MAC and I-SID.
> 
>    G.8032:  Refers to Ethernet ring protection switching as described in
>       [G.8032].
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>    "OPTIONAL" in this document are to be interpreted as described in
>    BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
>    capitals, as shown here.
> -->
> [Jorge] It is a good suggestion. It adds clarity. Please go ahead and split it in two sections as above. Thanks.
> 
> 
> 
> 4) <!--[rfced] Please clarify these sentences, in particular
> the phrasing after "for which". How may they be updated?
> 
> Original:
>    *  The Ethernet Tag encodes the I-SID for which the PE that receives
>       the route must flush the C-MACs upon reception of the route.
> 
>    *  The MAC address field encodes the B-MAC Address for which the PE
>       that receives the route must flush the C-MACs upon reception of
>       the route.
> 
> Option A:
>    *  The Ethernet Tag encodes the I-SID that identifies for the PE
>       the route for which the PE must flush the C-MACs upon reception.
> 
>    *  The MAC address field encodes the B-MAC address that identifies
>       for the PE the route for which the PE must flush the C-MACs
>       upon reception.
> 
> Option B (splitting into two sentences each):
>    *  The Ethernet Tag encodes the I-SID. This indicates to the PE
>       that it must flush the C-MACs upon reception of the route.
> 
>    *  The MAC address field encodes the B-MAC address. This indicates
>       to the PE that it must flush the C-MACs upon reception of the route.
> -->
> [Jorge] I don’t think either option conveys what the original text meant to say. This would be my suggestion, let me know if it reads correctly:
> ------------
> OLD:
>    *  The Ethernet Tag encodes the I-SID for which the PE that receives
>       the route must flush the C-MACs upon reception of the route.
>    *  The MAC address field encodes the B-MAC Address for which the PE
>       that receives the route must flush the C-MACs upon reception of
>       the route.
>  
> NEW:
>    *  The Ethernet Tag encodes the I-SID. This indicates to the PE
>       that it must flush the C-MACs for that encoded I-SID, upon reception of the route.
>    *  The MAC address field encodes the B-MAC address. This indicates
>       to the PE that it must flush the C-MACs associated with that encoded B-MAC, upon reception of the route.
> ------------
> 
> 
> 
> 5) <!--[rfced] Would you like the references to be alphabetized or
> left in their current order? -->
> [Jorge] alphabetized, please. Thanks.
> 
> 
> 
> 6) <!--[rfced] FYI, we have deleted the empty Contributors section of this
> document. Please let us know if you prefer otherwise.
> -->
> [Jorge] that’s fine. Thanks.
> 
> 
> 
> 7) <!--[rfced] Terminology
> 
> a) We suggest removing the second hyphen from "C-MAC-flush" and
> updating to "C-MAC flush". This is in keeping with "C-MAC flushing"
> in RFC 7623.
> [Jorge] yes, please go ahead.
> 
> 
> b) Several terms appear expanded after their abbreviation is
> introduced. For concision and per Section 3.6 of RFC 7322 ("RFC Style Guide"),
> we plan to replace these terms with their abbreviations after first
> use. Please let us know if you prefer otherwise.
> 
> - Ethernet Segment(s)
> - Service Instance Identifier (I-SID)
> - Customer MAC(s)
> - Backbone MAC(s)
> - Attachment Circuit(s) (Please note that if this is not changed to
> the abbreviated form, we will lowercase this term throughout.)
> - Ethernet Segment Identifier(s)
> - Pseudowires (PWs)
> [Jorge] yes, please, go ahead.
> 
> 
> c) "EVC" is expanded as Ethernet Virtual Circuits (in this document,
> RFC 8466, and RFC 7023) but as Ethernet Virtual Connections (RFC 7796,
> RFC 6003, RFC 5254). Would you like to leave it as is?
> [Jorge] yes please, leave as is.
> 
> 
> d) The slash character "/" has been used to separate various terms
> in this document. Please review and let us know if any instances should
> be updated to "and/or", "and", or "or" for clarity. For example:
>    Access Ethernet/MPLS Networks
>    access device/network
>    enabled/disabled
>    active/standby pseudowires (also appears as "active-standby PW")
> -->
> [Jorge] please use:
> Access Ethernet and/or MPLS Networks
> access device or access network
> enabled or disabled
> active/standby pseudowires (and “active/standby pseudowire” in the other instance)
> 
> 
> 
> 8) <!-- [rfced] FYI - We have added expansions of abbreviations upon
> first use. Please review each expansion to ensure correctness.
> 
> MAC expanded as Media Access Control
> RT expanded as Route Target
> -->
> [Jorge] looks fine, thanks.
> 
> 
> 
> 9) <!--[rfced] Please review the "Inclusive Language" portion of the online
> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>>
> and let us know if any changes are needed.
> 
> For example, please consider whether "black-hole" should be updated. In the past,
> authors have used "infinite loop" or "packet loss(es)" as substitutions.
> 
> Original:
>   Section 2: The solution MUST prevent black-hole scenarios in case of ...
>   Section 5: The solution solves black-hole scenarios in case of ...
> -->
> [Jorge] please use “packet loss” in both instances
> Thank you!
> Jorge
> 
> 
> 
> Thank you.
> 
> RFC Editor/kf/ar
> 
> 
> On Jan 29, 2024, [e-mail] <mailto:[e-mail]> wrote:
> 
> *****IMPORTANT*****
> 
> Updated 2024/01/29
> 
> 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/ <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/) <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 <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] <mailto:[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] <mailto:[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 <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc>
> 
>     *  The archive itself:
>        https://mailarchive.ietf.org/arch/browse/auth48archive/ <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] <mailto:[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/rfc9541.xml <https://www.rfc-editor.org/authors/rfc9541.xml>
>   https://www.rfc-editor.org/authors/rfc9541.html <https://www.rfc-editor.org/authors/rfc9541.html>
>   https://www.rfc-editor.org/authors/rfc9541.pdf <https://www.rfc-editor.org/authors/rfc9541.pdf>
>   https://www.rfc-editor.org/authors/rfc9541.txt <https://www.rfc-editor.org/authors/rfc9541.txt>
> 
> Diff file of the text:
>   https://www.rfc-editor.org/authors/rfc9541-diff.html <https://www.rfc-editor.org/authors/rfc9541-diff.html>
>   https://www.rfc-editor.org/authors/rfc9541-rfcdiff.html <https://www.rfc-editor.org/authors/rfc9541-rfcdiff.html> (side by side)
> 
> Diff of the XML:
>   https://www.rfc-editor.org/authors/rfc9541-xmldiff1.html <https://www.rfc-editor.org/authors/rfc9541-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/rfc9541.original.v2v3.xml <https://www.rfc-editor.org/authors/rfc9541.original.v2v3.xml>
> 
> XMLv3 file that is a best effort to capture v3-related format updates
> only:
>   https://www.rfc-editor.org/authors/rfc9541.form.xml <https://www.rfc-editor.org/authors/rfc9541.form.xml>
> 
> 
> Tracking progress
> -----------------
> 
> The details of the AUTH48 status of your document are here:
>   https://www.rfc-editor.org/auth48/rfc9541 <https://www.rfc-editor.org/auth48/rfc9541>
> 
> Please let us know if you have any questions.
> 
> Thank you for your cooperation,
> 
> RFC Editor
> 
> --------------------------------------
> RFC9541 (draft-ietf-bess-pbb-evpn-isid-cmacflush-09)
> 
> Title            : PBB-EVPN ISID-based C-MAC-Flush
> Author(s)        : J. Rabadan, Ed., S. Sathappan, K. Nagaraj, M. Miyake, T. Matsuda
> WG Chair(s)      : Matthew Bocci, Stephane Litkowski, Zhaohui (Jeffrey) Zhang
> 
> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston