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

["Kiran Nagaraj (Nokia)" <[e-mail]>]

Hi Alice,
Thank you for your work on this. The document looks good to me and is ok to be published.
Thanks
Kiran

From: Jorge Rabadan (Nokia) <[e-mail]>
Sent: Tuesday, February 6, 2024 12:36 PM
To: Alice Russo <[e-mail]>
Cc: Kiran Nagaraj (Nokia) <[e-mail]>; Senthil Sathappan (Nokia) <[e-mail]>; [e-mail]; Matthew Bocci (Nokia) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: AUTH48: RFC-to-be 9541 <draft-ietf-bess-pbb-evpn-isid-cmacflush-09> for your review

Hi Alice,

Yes, the figure looks good, thanks.

It is approved from my side.

Thank you!
Jorge

From: Alice Russo <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, February 6, 2024 at 11:50 AM
To: Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Cc: Kiran Nagaraj (Nokia) <[e-mail]<mailto:[e-mail]>>, Senthil Sathappan (Nokia) <[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]>>, [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]>>, [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
You don't often get email from [e-mail]<mailto:[e-mail]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.


Jorge,

Thank you for your reply. We have updated Figure 1 accordingly; please review that it is accurate -- in particular, please check that the arrows on the first line are aligned with the diagram as you intended. (We recommend looking at Figure 1 in https://www.rfc-editor.org/authors/rfc9541-rfcdiff.html)

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

This diff file shows only the changes since the last posted version:
  https://www.rfc-editor.org/authors/rfc9541-lastrfcdiff.html

Re:
[jorge] once you make that minor change, you can note my approval.

Will do after you confirm that Figure 1 appears as you intended.
This page shows the AUTH48 status of your document:
  https://www.rfc-editor.org/auth48/rfc9541

Thank you.
RFC Editor/ar

On Feb 2, 2024, at 5:19 AM, Jorge Rabadan (Nokia) <jorge.rabadan=[e-mail]<mailto:jorge.rabadan=[e-mail]>> wrote:

Hi Alice,

Thanks very much for your work on this.
Please see my comments in-line with [jorge].


From: Alice Russo <[e-mail]<mailto:[e-mail]>>
Date: Thursday, February 1, 2024 at 7:53 PM
To: Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Senthil Sathappan (Nokia) <[e-mail]<mailto:[e-mail]>>, Rebecca VanRheenen <[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]>>, [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
You don't often get email from [e-mail]<mailto:[e-mail]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>


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.

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
[jorge] the current abbreviated title for the PDF header looks good for me. As you say it matches the name in section 1, and it is clear enough.

Re: #4, updated the sentences with your new text; thank you for providing text that is more clear.
[jorge] looks good, thanks.

Re: #7b, updated to use abbreviations; please review that the text is still clear.
[jorge] looks good, thanks.

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.
[jorge] you are right, it might not be clear for all readers. If it does not bother any other object in the Figure, can you please expand it to “standby”?

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
[jorge] once you make that minor change, you can note my approval.
Thanks again!
Jorge


Thank you.
RFC Editor/ar

On Jan 30, 2024, at 5:34 AM, Jorge Rabadan (Nokia) <jorge.rabadan=[e-mail]<mailto: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>
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/).

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

    *  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]<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.html
  https://www.rfc-editor.org/authors/rfc9541.pdf
  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-rfcdiff.html (side by side)

Diff of the XML:
  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

XMLv3 file that is a best effort to capture v3-related format updates
only:
  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

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