Hi Jeffery, Senthil, and Jorge, We have marked your approvals on the AUTH48 status page for this document (see https://www.rfc-editor.org/auth48/rfc9856).
We are still awaiting Wen's approval prior to moving this document forward in the publication process. Thank you, Sarah Tarrant RFC Production Center > On Sep 4, 2025, at 7:12 AM, Jorge Rabadan (Nokia) <[email protected]> > wrote: > > Thanks for making the changes, Sarah. Looks good. > Thanks to Jeffrey for those clarifications too. > Jorge > From: Sarah Tarrant <[email protected]> > Date: Wednesday, September 3, 2025 at 11:53 AM > To: Jeffrey (Zhaohui) Zhang <[email protected]>, Jorge Rabadan (Nokia) > <[email protected]> > Cc: [email protected] <[email protected]>, Jayant Kotalwar > (Nokia) <[email protected]>, Senthil Sathappan (Nokia) > <[email protected]>, Wen Lin <[email protected]>, [email protected] > <[email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]>, Gunter van de Velde (Nokia) > <[email protected]>, > [email protected]<[email protected]> > Subject: Re: AUTH48: RFC-to-be 9856 > <draft-ietf-bess-evpn-redundant-mcast-source-15> for your review > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/extfor additional > information. > > > > Hi Jeffery and Jorge, > > We have updated the document accordingly! > > Please review the document carefully to ensure satisfaction as we do not make > changes once it has been published as an RFC. > > We will await approvals from each author prior to moving forward in the > publication process. > > The updated files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9856.txt > https://www.rfc-editor.org/authors/rfc9856.pdf > https://www.rfc-editor.org/authors/rfc9856.html > https://www.rfc-editor.org/authors/rfc9856.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9856-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9856-auth48diff.html (AUTH48 changes > only) > > Note that it may be necessary for you to refresh your browser to view the > most recent version. > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9856 > > Thank you, > Sarah Tarrant > RFC Production Center > > > On Sep 3, 2025, at 1:15 PM, Jeffrey (Zhaohui) Zhang <[email protected]> > > wrote: > > > > Hi Sarah, > > > > Jorge and I discussed about a few editorial changes that I'd like to > > propose: > > > > 1.2.1. Intra-Subnet IP Multicast Forwarding > > > > ... > > Procedures for Model (b) are specified in [RFC9251]. > > > > [RFC9572] should also be added here: > > > > Procedures for Model (b) are specified in [RFC9251] and [RFC9572]. > > > > For the following: > > > > An SFG can be represented as (*,G) if any source transmitting > > multicast traffic to group G is considered a redundant G-source. > > Alternatively, this document allows an SFG to be represented as > > (S,G), where the source IP address S is a prefix of variable length. > > In this case, a source is deemed a redundant G-source for the SFG if > > its address falls within the specified prefix. > > > > In the alternative case, we'd need (S,G) state but in some places of the > > document only talks about (*G). We can add one sentence to clarify: > > > > ... In the remainder of this document, some examples use (*,G) state for > > brevity. Wherever an SFG is represented as (*,G), it should be understood > > as interchangeable with (S,G).” > > > > In the following (and the remainder of the document): > > > > ... In this > > solution, all upstream PEs connected to redundant G-sources for an > > SFG (*,G) or (S,G) elect a "Single Forwarder (SF)" among themselves. > > After the Single Forwarder is elected, the upstream PEs apply Reverse > > Path Forwarding checks to the multicast state for the SFG: > > > > * Non-Single Forwarder Behavior: A non-Single Forwarder upstream PE > > discards all (*,G) or (S,G) packets received over its local AC. > > > > The wording "Non-Single Forwarder" is better replaced with "Non-SF". > > > > For the following warm-standby procedure: > > > > - Route Targets (RTs): The Supplementary Broadcast Domain > > Route Target (SBD-RT), if applicable, and the Broadcast > > Domain Route Target (BD-RT) of the Broadcast Domain > > receiving the traffic. The SBD-RT is needed so that the > > route is imported by all PEs attached to the tenant domain > > in an OISM solution. > > > > We should flip the order of SBD-RT and BD-RT, as follows: > > > > - Route Targets (RTs): The Broadcast > > Domain Route Target (BD-RT) of the Broadcast Domain > > receiving the traffic, and, if applicable the Supplementary > > Broadcast Domain Route Target (SBD-RT), which is needed so that > > the > > route is imported by all PEs attached to the tenant domain > > in an OISM solution. > > > > Thanks. > > Jeffrey > > > > > > Juniper Business Use Only > > -----Original Message----- > > From: Sarah Tarrant <[email protected]> > > Sent: Friday, August 29, 2025 9:12 AM > > To: Jorge Rabadan (Nokia) <[email protected]> > > Cc: [email protected]; Jayant Kotalwar (Nokia) > > <[email protected]>; Senthil Sathappan (Nokia) > > <[email protected]>; Jeffrey (Zhaohui) Zhang > > <[email protected]>; Wen Lin <[email protected]>; [email protected]; > > [email protected]; [email protected]; Gunter van de Velde (Nokia) > > <[email protected]>; [email protected] > > Subject: Re: AUTH48: RFC-to-be 9856 > > <draft-ietf-bess-evpn-redundant-mcast-source-15> for your review > > > > [External Email. Be cautious of content] > > > > > > Hi Author, > > > > Thank you for your reply. We have marked your approval on the AUTH48 status > > page for this document > > (seehttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9856__%3B!!NEt6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97acvcxa0N4d6yIGx8yietKEz4V3RNrN6jcbTIWfp8jt3_EqADKR7izqfk%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224021925905%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CxZ2D0H6UBt%2FD3mvnlnr4J3%2BpuseJCp3UwHHV7OhLtY%3D&reserved=0 > > ). > > > > Unless we hear objection at that time, we will assume your assent to any > > further changes submitted by your coauthors. > > > > We will await approvals from each of the parties listed at the AUTH48 > > status page prior to moving this document forward in the publication > > process. > > > > Thank you, > > Sarah Tarrant > > RFC Production Center > > > >> On Aug 29, 2025, at 3:23 AM, Jorge Rabadan (Nokia) > >> <[email protected]> wrote: > >> > >> Hi Sarah, > >> Thank you very much for making the changes and your work on this. > >> It looks good now and I approve the document for publication. > >> Thanks! > >> Jorge > >> From: Sarah Tarrant <[email protected]> > >> Date: Thursday, August 28, 2025 at 1:59 PM > >> To: Jorge Rabadan (Nokia) <[email protected]> > >> Cc: [email protected] <[email protected]>, Jayant > >> Kotalwar (Nokia) <[email protected]>, Senthil Sathappan > >> (Nokia) <[email protected]>, [email protected] > >> <[email protected]>, [email protected]<[email protected]>, > >> [email protected] <[email protected]>, [email protected] > >> <[email protected]>, [email protected] <[email protected]>, > >> Gunter van de Velde (Nokia) <[email protected]>, > >> [email protected] <[email protected]> > >> Subject: Re: AUTH48: RFC-to-be 9856 > >> <draft-ietf-bess-evpn-redundant-mcast-source-15> 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 for additional > >> information. > >> > >> > >> > >> Hi Jorge, > >> > >> Thank you for your reply. We have updated the document accordingly. > >> > >> Please review the document carefully to ensure satisfaction as we do not > >> make changes once it has been published as an RFC. Contact us with any > >> further updates or with your approval of the document in its current form. > >> We will await approvals from each author prior to moving forward in the > >> publication process. > >> > >> The updated files have been posted here (please refresh): > >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9856&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224021997859%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=GSn6mK8eAhT3cBLAWwnPcnIHy6jg%2BIYanidfLgjUGRA%3D&reserved=0 > >> .txt__;!!NEt6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97acvcxa0N4d6yIG > >> x8yietKEz4V3RNrN6jcbTIWfp8jt3_EqADK4CMmXm0$ > >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9856&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224022056785%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=72%2FZ6rXvJrahYxRxVC%2BaOJkNUJQzAk%2F5mQtccYFynXM%3D&reserved=0 > >> .pdf__;!!NEt6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97acvcxa0N4d6yIG > >> x8yietKEz4V3RNrN6jcbTIWfp8jt3_EqADKLhq2irc$ > >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9856&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224022100094%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Qftm7zA%2FNclXF61hoWAQEGroIce%2BekKwbDjo6LvkE1Y%3D&reserved=0 > >> .html__;!!NEt6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97acvcxa0N4d6yI > >> Gx8yietKEz4V3RNrN6jcbTIWfp8jt3_EqADKDFJ53M4$ > >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9856&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224022128841%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=DYpuH3W%2BRK6qHrvGqmFxuqFY13LxXJEY%2FWqkobIcd2A%3D&reserved=0 > >> .xml__;!!NEt6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97acvcxa0N4d6yIG > >> x8yietKEz4V3RNrN6jcbTIWfp8jt3_EqADKxBXMyIc$ > >> > >> The relevant diff files have been posted here (please refresh): > >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9856&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224022146525%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=zH8pTMrgHu9y3QXpRBCaOJbZWeGl%2BIcFYWi6RLLWROc%3D&reserved=0 > >> -diff.html__;!!NEt6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97acvcxa0N > >> 4d6yIGx8yietKEz4V3RNrN6jcbTIWfp8jt3_EqADKZ1PmYRI$ (comprehensive > >> diff) > >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9856&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224022163232%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=35Y5gxbSFpvx6e7sN4vqBqa55GzDAUVkIGPmtY6pepE%3D&reserved=0 > >> -auth48diff.html__;!!NEt6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97ac > >> vcxa0N4d6yIGx8yietKEz4V3RNrN6jcbTIWfp8jt3_EqADK-A21ruk$ (AUTH48 > >> changes only) > >> > >> Note that it may be necessary for you to refresh your browser to view the > >> most recent version. > >> > >> For the AUTH48 status of this document, please see: > >> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9856_&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224022178468%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XNsf%2BQqmUpFUIrF3ophgLnf5nYdevPfswsB9OGcTeqg%3D&reserved=0 > >> _;!!NEt6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97acvcxa0N4d6yIGx8yie > >> tKEz4V3RNrN6jcbTIWfp8jt3_EqADKR7izqfk$ > >> > >> Thank you, > >> Sarah Tarrant > >> RFC Production Center > >> > >>> On Aug 28, 2025, at 4:26 AM, Jorge Rabadan (Nokia) > >>> <[email protected]> wrote: > >>> > >>> Hi Sarah, > >>> Apologies for the delay. > >>> Here you have my comments, please see in-line with [jorge]. > >>> Thanks very much for your work on this. > >>> Jorge > >>> From: [email protected] <[email protected]> > >>> Date: Tuesday, August 19, 2025 at 11:05 AM > >>> To: Jorge Rabadan (Nokia) <[email protected]>, Jayant Kotalwar > >>> (Nokia) <[email protected]>, Senthil Sathappan (Nokia) > >>> <[email protected]>, [email protected] > >>> <[email protected]>, [email protected]<[email protected]> > >>> Cc: [email protected] <[email protected]>, > >>> [email protected] <[email protected]>, [email protected] > >>> <[email protected]>, [email protected]<[email protected]>, > >>> Gunter van de Velde (Nokia) <[email protected]>, > >>> [email protected] <[email protected]> > >>> Subject: Re: AUTH48: RFC-to-be 9856 > >>> <draft-ietf-bess-evpn-redundant-mcast-source-15> 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 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] Would you like the references to be alphabetized or > >>> left in their current order? > >>> --> > >>> [jorge] yes, please > >>> > >>> > >>> > >>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear > >>> in the title) for use on > >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fsearch__%3B!!NE&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224022193198%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=YD8FUL7L6VD2ztC7NpxcPBQ%2Fpbl8OP75yGzJMLf%2BbXg%3D&reserved=0 > >>> t6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97acvcxa0N4d6yIGx8yietKEz > >>> 4V3RNrN6jcbTIWfp8jt3_EqADKNjS4J8Y$ . --> [jorge] Warm standby, hot > >>> standby, OISM, redundant G-source, SFG, Single Flow Group > >>> > >>> > >>> > >>> 3) <!-- [rfced] We have removed "(IP DA)" as the abbreviation does > >>> not seem to be used in this document. DA (by itself) also does not > >>> appear. > >>> Elsewhere, the text refers to "destination IP address". Are these > >>> the same? Should the definition for G-traffic be updated for consistency? > >>> > >>> Original: > >>> * G-traffic: any frame with an IP payload whose IP Destination > >>> Address (IP DA) is a multicast group G. > >>> > >>> Perhaps: > >>> G-traffic: Any frame with an IP payload whose destination IP address > >>> is a multicast group G. > >>> [jorge] your suggestion is good > >>> > >>> > >>> --> > >>> > >>> > >>> 4) <!-- [rfced] Should "destinated" be "destined? > >>> > >>> Original: > >>> In these scenarios, the upstream PE pushes > >>> the S-ESI labels on packets not only destinated for PEs > >>> sharing the ES but also for all PEs within the tenant > >>> domain. > >>> --> > >>> [jorge] yes, it should be “destined” > >>> > >>> > >>> > >>> 5) <!-- [rfced] Since RFC 9573 uses the term "Context-Specific Label > >>> Space ID Extended Community" rather than "Context Label Space ID > >>> Extended Community", may we update to match? Note this would also > >>> update the following terms to the term on the right: > >>> > >>> context label spaces > context-specific label spaces > >>> context label space ID > context-specific label space ID > >>> --> > >>> [jorge] yes, I agree it should match > >>> > >>> > >>> > >>> 6) <!-- [rfced] Should "Flag" be part of the name? The other > >>> registered values do not include "Flag". It seems redundant, since > >>> it is a registry of flags. If "Flag" is to be removed, we will ask > >>> IANA to update their registry accordingly. > >>> > >>> Original Table 2: > >>> +=====+==============+===============+ > >>> | Bit | Name | Reference | > >>> +=====+==============+===============+ > >>> | 5 | ESI-DCB Flag | This Document | > >>> --> > >>> [jorge] yes, it is redundant, it can be suppressed if you want. > >>> > >>> > >>> > >>> 7) <!-- [rfced] Throughout the text, several abbreviations are > >>> introduced but not used or are repeatedly defined. Please consider > >>> whether the abbreviated form should be used in most cases once the > >>> term has been introduced. > >>> > >>> For example: > >>> Attachment Circuit (AC) > >>> Assisted Replication (AR) > >>> Bit Indexed Explicit Replication (BIER) > >>> Domain-wide Common Block (DCB) > >>> Designated Forwarder (DF) > >>> Ethernet Segment (ES) > >>> Ethernet Segment Identifier (ESI) > >>> Inclusive Multicast Ethernet Tag (IMET) > >>> Ingress Replication (IR) > >>> Supplementary Broadcast Domain (SBD) > >>> Supplementary Broadcast Domain Route Target (SBD-RT) > >>> Selective Multicast Ethernet Tag (SMET) > >>> --> > >>> [jorge] yes, once introduced, the abbreviated form can be used > >>> > >>> > >>> > >>> 8) <!-- [rfced] Throughout the text, the following terminology > >>> appears to be capitalized inconsistently. Please review these > >>> occurrences and let us know if/how they may be made consistent. > >>> > >>> Downstream vs. downstream > >>> ESI Label vs. ESI label > >>> Upstream vs. upstream > >>> --> > >>> [jorge] we should use “downstream”, “ESI label” and “upstream” > >>> consistently if possible. > >>> > >>> > >>> > >>> 9) <!-- [rfced] Please review the "Inclusive Language" portion of > >>> the online Style Guide > >>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2Fp&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224022207750%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=V4khGh0KmijNpO9ur5YeKqBGDp1xuAUwSwVIjLJAqhg%3D&reserved=0 > >>> art2/*inclusive_language__;Iw!!NEt6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97acvcxa0N4d6yIGx8yietKEz4V3RNrN6jcbTIWfp8jt3_EqADKEqevvKs$ > >>> > and let us know if any changes are needed. Updates of this nature > >>> typically result in more precise language, which is helpful for readers. > >>> > >>> Note that our script did not flag any words in particular, but this > >>> should still be reviewed as a best practice. > >>> --> > >>> [jorge] I didn’t find any word that could be replaced.. > >>> [jorge] in addition, could you please make the following change (it > >>> should be “multicast” and not “multicasts”?: > >>> CURRENT (in the edited version) > >>> In conventional IP multicast networks, such as those running > >>> Protocol Independent Multicasts (PIMs) [RFC7761] NEW In conventional > >>> IP multicast networks, such as those running Protocol Independent > >>> Multicast (PIM) [RFC7761] Thank you! > >>> Jorge > >>> > >>> > >>> > >>> Thank you. > >>> > >>> Sarah Tarrant and Sandy Ginoza > >>> RFC Production Center > >>> > >>> > >>> > >>> On Aug 19, 2025, at 10:59 AM, [email protected] wrote: > >>> > >>> *****IMPORTANT***** > >>> > >>> Updated 2025/08/19 > >>> > >>> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F__%3B!!NEt6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97acvcxa0N4d6yIGx8yietKEz4V3RNrN6jcbTIWfp8jt3_EqADKbLLUprU%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224022222252%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=aLoYE7ygY2RqBlp8XJZs3W3zrJFVwVCO5Zo6mGsrZq0%3D&reserved=0 > >>> ). > >>> > >>> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Ftrustee.ietf.org%2Flicense-info__%3B!!NEt6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97acvcxa0N4d6yIGx8yietKEz4V3RNrN6jcbTIWfp8jt3_EqADKeEclNb4%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224022236738%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bTe0B%2FnDwc1CJ55vv8OgNjd%2BRm0WQGCz61AnhenwMBI%3D&reserved=0 > >>> ). > >>> > >>> * 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fauthors.ietf.org%2Frfcxml-vocabulary__%3B!!NEt6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97acvcxa0N4d6yIGx8yietKEz4V3RNrN6jcbTIWfp8jt3_EqADKpD5_eoU%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224022251679%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=uxcsAxVeUtqQU5m2uyLr3q7Grls3YCiwRF3rX2Gegz4%3D&reserved=0 > >>> >. > >>> > >>> * 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 > >>> > >>> * [email protected] (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). > >>> > >>> * [email protected], which is a new archival mailing list > >>> to preserve AUTH48 conversations; it is not an active discussion > >>> list: > >>> > >>> * More info: > >>> > >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fie&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224022268492%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HPzXjQp%2F3mr7e%2FW2vRbpIzebCMxHxjp2Xi6a4epZvlA%3D&reserved=0 > >>> tf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!GvcdQU1qwnLE > >>> AD-VOlPPWPvjiUomNVrv_97acvcxa0N4d6yIGx8yietKEz4V3RNrN6jcbTIWfp8jt3_E > >>> qADKSTwlcdc$ > >>> > >>> * The archive itself: > >>> > >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224022294595%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yEkTypy4OPgHaWN73hFrkRLQz%2FZfrLks0s%2FhLE%2BoYs4%3D&reserved=0 > >>> /auth48archive/__;!!NEt6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97a > >>> cvcxa0N4d6yIGx8yietKEz4V3RNrN6jcbTIWfp8jt3_EqADKFJTb2X0$ > >>> > >>> * 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, > >>> [email protected] 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9856.xml__%3B!!NEt6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97acvcxa0N4d6yIGx8yietKEz4V3RNrN6jcbTIWfp8jt3_EqADKxBXMyIc%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224022317366%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=D%2B2qccw%2BkUAyECVAJL6cyf0mHzfGib2%2BiwE4IYTWYcc%3D&reserved=0 > >>> > >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9856.html__%3B!!NEt6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97acvcxa0N4d6yIGx8yietKEz4V3RNrN6jcbTIWfp8jt3_EqADKDFJ53M4%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224022339382%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cyF5d8S9OO5tTSdO7xk2j8nSU9nmOmKAEtjOqcFmCVs%3D&reserved=0 > >>> > >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9856.pdf__%3B!!NEt6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97acvcxa0N4d6yIGx8yietKEz4V3RNrN6jcbTIWfp8jt3_EqADKLhq2irc%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224022361009%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=D2ndQQ%2F82dTsfVNuQbvXedMEU7gfYjq17KaSBQwF1jE%3D&reserved=0 > >>> > >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc98&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224022385258%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=GadTScdsEzjsEqojtxiv8gMrSejSsqDIKZkYAUZdHHk%3D&reserved=0 > >>> 56.txt__;!!NEt6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97acvcxa0N4d > >>> 6yIGx8yietKEz4V3RNrN6jcbTIWfp8jt3_EqADK4CMmXm0$ > >>> > >>> Diff file of the text: > >>> > >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9856-diff.html__%3B!!NEt6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97acvcxa0N4d6yIGx8yietKEz4V3RNrN6jcbTIWfp8jt3_EqADKZ1PmYRI%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224022415552%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fdYSq50BVVjMvzThq3dcwqSeA%2FLTd44TWU89uCUBGqU%3D&reserved=0 > >>> > >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc98&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224022449391%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=kv4s3YtoG%2BbbvB5kOm6f%2FZ4GAlYTA4H0%2BfMFVcFYi7w%3D&reserved=0 > >>> 56-rfcdiff.html__;!!NEt6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97a > >>> cvcxa0N4d6yIGx8yietKEz4V3RNrN6jcbTIWfp8jt3_EqADK1GAgmPg$ (side by > >>> side) > >>> > >>> Diff of the XML: > >>> > >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc98&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224022481318%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bscC9%2FHeLlnyq00%2BYcFk6Mr8TI3e8y%2BnDi77w2X%2FIxw%3D&reserved=0 > >>> 56-xmldiff1.html__;!!NEt6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97 > >>> acvcxa0N4d6yIGx8yietKEz4V3RNrN6jcbTIWfp8jt3_EqADKGxod01U$ > >>> > >>> > >>> Tracking progress > >>> ----------------- > >>> > >>> The details of the AUTH48 status of your document are here: > >>> > >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc985&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cc8bf0e164b9a40a0189108ddeb1b09ea%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638925224022510729%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wjJtl9YoqHDAFdj0e8AR6KlDgy2jOX1DtiHCGoxUJbc%3D&reserved=0 > >>> 6__;!!NEt6yMaO-gk!GvcdQU1qwnLEAD-VOlPPWPvjiUomNVrv_97acvcxa0N4d6yIGx > >>> 8yietKEz4V3RNrN6jcbTIWfp8jt3_EqADKR7izqfk$ > >>> > >>> Please let us know if you have any questions. > >>> > >>> Thank you for your cooperation, > >>> > >>> RFC Editor > >>> > >>> -------------------------------------- > >>> RFC 9856 (draft-ietf-bess-evpn-redundant-mcast-source-15) > >>> > >>> Title : Multicast Source Redundancy in EVPN Networks > >>> Author(s) : J. Rabadan, J. Kotalwar, S. Sathappan, Z. Zhang, W. Lin > >>> WG Chair(s) : Matthew Bocci, Stephane Litkowski, Zhaohui (Jeffrey) > >>> Zhang > >>> > >>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de > >>> Velde > > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
