Hi Kiran, Thank you for your review. We have noted your approval on the AUTH48 page <https://www.rfc-editor.org/auth48/rfc9746>.
Thank you, RFC Editor/sg > On Feb 24, 2025, at 9:10 AM, Kiran Nagaraj (Nokia) <kiran.naga...@nokia.com> > wrote: > > Hi Sandy, > Thank you very much for you work on this. The RFC looks good to me and I > approve it for publication. > > Thanks > Kiran > > -----Original Message----- > From: Sandy Ginoza <sgin...@staff.rfc-editor.org> > Sent: Monday, February 24, 2025 8:41 AM > To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> > Cc: RFC Editor <rfc-edi...@rfc-editor.org>; Kiran Nagaraj (Nokia) > <kiran.naga...@nokia.com>; w...@juniper.net; saja...@cisco.com; > bess-...@ietf.org; bess-cha...@ietf.org; zzh...@juniper.net; Gunter van de > Velde (Nokia) <gunter.van_de_ve...@nokia.com>; auth48archive@rfc-editor.org > Subject: Re: AUTH48: RFC-to-be 9746 > <draft-ietf-bess-evpn-mh-split-horizon-11> for your review > > [You don't often get email from sgin...@staff.rfc-editor.org. Learn why this > is important at 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. > > > > Hi Jorge, > > Thank you for your review. We have noted your approval on the AUTH48 page > <https://www.rfc-editor.org/auth48/rfc9746>. Please note that we will wait > to hear from your coauthors as well before continuing with the publication > process. > > Thank you, > RFC Editor/sg > > >> On Feb 24, 2025, at 2:57 AM, Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> >> wrote: >> >> Hi Sandy, >> >> Looks good. >> I approve the RFC for publication. >> >> Thanks! >> Jorge >> >> From: Sandy Ginoza <sgin...@staff.rfc-editor.org> >> Date: Wednesday, February 19, 2025 at 4:31 PM >> To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> >> Cc: RFC Editor <rfc-edi...@rfc-editor.org>, Kiran Nagaraj (Nokia) >> <kiran.naga...@nokia.com>, w...@juniper.net <w...@juniper.net>, >> saja...@cisco.com <saja...@cisco.com>, bess-...@ietf.org >> <bess-...@ietf.org>, bess-cha...@ietf.org >> <bess-cha...@ietf.org>,zzh...@juniper.net <zzh...@juniper.net>, Gunter >> van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>, >> auth48archive@rfc-editor.org<auth48archive@rfc-editor.org> >> Subject: Re: AUTH48: RFC-to-be 9746 >> <draft-ietf-bess-evpn-mh-split-horizon-11> for your review >> >> [You don't often get email from sgin...@staff.rfc-editor.org. Learn >> why this is important at 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. >> >> >> >> Hi Jorge, >> >> Thank you for your detailed review. We have updated the document based on >> the replies below, but please review these followup notes. >> >> a) We updated the terms as noted here. However, we left “Local Bias” and >> “Split-Horizon Type” in Table 1, and where the values seemed to refer to the >> IANA value or the expansion of SHT. Please review and let us know if any >> adjustments are needed. >> >>> [jorge] Since RFC7432 was the first spec that introduced the concept, we >>> should probably use “split-horizon”. >>> [jorge] if we follow the same reasoning as in (a), we should use >>> “local-bias” >>> [jorge] “Geneve” based on the same reason. >> >> >> >> b) We updated the text to refer to Table 2. Please let us know if you >> prefer otherwise. >> >>> [jorge] it refers to the multihoming redundancy mode field in table >>> 2 (of section 5, IANA considerations) >> >> >> >> The current files are available here: >> https://www.rfc-editor.org/authors/rfc9746.xml >> https://www.rfc-editor.org/authors/rfc9746.txt >> https://www.rfc-editor.org/authors/rfc9746.pdf >> https://www.rfc-editor.org/authors/rfc9746.html >> >> AUTH48 diffs: >> https://www.rfc-editor.org/authors/rfc9746-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9746-auth48rfcdiff.html (side >> by side) >> >> Comprehensive diffs: >> https://www.rfc-editor.org/authors/rfc9746-diff.html >> https://www.rfc-editor.org/authors/rfc9746-rfcdiff.html (side by >> side) >> >> Please review the updates carefully and let us know if any corrections are >> needed or if you approve the RFC for publication. >> >> Thank you, >> RFC Editor/sg >> >> >> >>> On Feb 18, 2025, at 10:40 AM, Jorge Rabadan (Nokia) >>> <jorge.rabadan=40nokia....@dmarc.ietf.org> wrote: >>> >>> Dear RFC-editor team, >>> >>> Thank you very much for your work on this. >>> Please find our comments to your suggestions below with [jorge]. >>> >>> Thanks! >>> Jorge >>> >>> >>> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> >>> Date: Monday, February 10, 2025 at 7:36 PM >>> To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, Kiran Nagaraj >>> (Nokia) <kiran.naga...@nokia.com>, w...@juniper.net >>> <w...@juniper.net>, saja...@cisco.com <saja...@cisco.com> >>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, >>> bess-...@ietf.org <bess-...@ietf.org>, bess-cha...@ietf.org >>> <bess-cha...@ietf.org>, zzh...@juniper.net <zzh...@juniper.net>, >>> Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>, >>> auth48archive@rfc-editor.org<auth48archive@rfc-editor.org> >>> Subject: Re: AUTH48: RFC-to-be 9746 >>> <draft-ietf-bess-evpn-mh-split-horizon-11> 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] Please insert any keywords (beyond those that appear >>> in the title) for use on https://www.rfc-editor.org/search. --> >>> >>> [jorge] some keywords: >>> >>> EVPN Multihoming, Split Horizon Filtering, Local Bias, ESI, >>> encapsulations, SHT >>> >>> >>> >>> >>> 2) <!-- [rfced] We see the following terms used in various ways in the RFC >>> Series. This document was consistent in their use of the capitalziation >>> for the terms below. Is this the preferred form for future documents >>> related to this subject? >>> >>> a) RFC 7432 uses "split-horizon" (lowercase and hyphenated) when acting as >>> an adjective appearing before the noun, while this document uses the >>> initial-capitalized form without a hyphen consistently. >>> >>> Examples from this document: >>> Split Horizon procedure >>> Split Horizon filtering >>> Split Horizon method >>> Split Horizon behavior >>> Split Horizon Type (SHT) >>> >>> [jorge] Since RFC7432 was the first spec that introduced the concept, we >>> should probably use “split-horizon”. >>> >>> >>> >>> >>> b) "Local Bias" (this document) vs "local-bias" per RFCs 8365 and >>> 9252 >>> >>> [jorge] if we follow the same reasoning as in (a), we should use >>> “local-bias” >>> >>> >>> >>> c) "GENEVE" (this document) vs "Geneve" per RFC 8926 >>> --> >>> >>> [jorge] “Geneve” based on the same reason. >>> >>> >>> >>> >>> 3) <!-- [rfced] Please review the following questions and changes >>> regarding the terminology list in Section 1.1. >>> >>> a.) We have made some adjustments for readability and to demonstrate >>> 1:1 relationships between abbreviations and their expansions. Please >>> carefully review and let us know any objections. >>> >>> [jorge] looks good, thanks. >>> >>> >>> >>> b.) We were unable to find the "EVPN Ethernet Auto-Discovery per ES route" >>> explicitly mentioned in RFC 7432. May we update this item as follows >>> for accuracy and concision? >>> >>> Original: >>> >>> * A-D per ES route: refers to the EVPN Ethernet Auto-Discovery per >>> ES route defined in [RFC7432]. >>> >>> Perhaps: >>> >>> A-D per ES route: Auto-Discovery per Ethernet Segment route (as defined >>> in >>> [RFC7432]). >>> >>> [jorge] yes, that’s the one. Thanks. >>> >>> >>> >>> >>> c.) Arg.FE2 is mentioned in RFC 9252; however, RFC 9252 says that >>> "the Arg.FE2 notation [is] introduced in [RFC8986]". Would you like >>> to update the citation below to RFC 8986? >>> >>> Original: >>> >>> * Arg.FE2: refers to the ESI filtering argument used for Split >>> Horizon as specified in [RFC9252]. >>> >>> [jorge] I’d prefer to keep RFC9252. Although first introduced in RFC8986, >>> it’s use is really specified in RFC9252. >>> >>> >>> >>> d.) Several abbreviations appear in this document but are not >>> included in this terminology list (see some examples below). Please >>> review and let us know if you would like to add these or any additional >>> terms to this list. >>> >>> Type-Length-Value (TLV) >>> Route Targets (RTs) >>> Provider Edge (PE) >>> Customer Edge (CE) >>> --> >>> >>> [jorge] yes please, add those to the terminology list. >>> >>> >>> >>> >>> 4) <!-- [rfced] The parentheses in the text below seem to contain a >>> mixture of abbreviations and additional context. For clarity and >>> readability, may we update as follows? >>> >>> Original: >>> >>> The ingress Network Virtualization Edge (NVE) device appends a label >>> corresponding to the source Ethernet Segment Identifier (ESI label) >>> during packet encapsulation. The egress NVE verifies the ESI label >>> when >>> attempting to forward a multi-destination frame through a local >>> Ethernet Segment (ES) interface. If the ESI label matches the site >>> identifier (ESI) associated with that ES interface, the packet is not >>> forwarded... >>> >>> Perhaps: >>> >>> The ingress NVE device appends a label corresponding to the source ESI >>> (the ESI label) during packet encapsulation. The egress NVE verifies >>> the ESI label when attempting to forward a multi-destination frame >>> through a local ES interface. If the ESI label matches the site >>> identifier (the ESI) associated with that ES interface, then the >>> packet >>> is not forwarded... >>> >>> [jorge] your suggestion is good, please go ahead. >>> >>> >>> >>> --> >>> >>> >>> 5) <!-- [rfced] For clarity and consistency with other list items, >>> may we adjust the term "(SR-)MPLS" as seen below? >>> >>> Original: >>> >>> This document classifies the tunnel encapsulations used by EVPN into: >>> >>> 1. IP-based MPLS tunnels >>> >>> 2. (SR-)MPLS tunnels, that is, MPLS and Segment Routing with MPLS >>> data plane tunnels >>> >>> 3. IP tunnels >>> >>> 4. SRv6 tunnels >>> >>> Perhaps: >>> >>> This document classifies the tunnel encapsulations used by EVPN into: >>> >>> 1. IP-based MPLS tunnels >>> >>> 2. MPLS and SR-MPLS tunnels >>> >>> 3. IP tunnels >>> >>> 4. SRv6 tunnels >>> >>> [jorge] yes, go ahead please. >>> >>> >>> >>> >>> b.) "(SR-)MPLS" also appears in the instances below. For ease of the >>> reader, may we update these instances similarly? >>> >>> Originals: >>> >>> * (SR-)MPLS tunnels only support ESI Label-based Split Horizon >>> filtering >>> >>> | (SR-)MPLS | ESI Label filtering | No | Yes | >>> >>> --> >>> >>> [jorge] sure >>> >>> >>> >>> >>> 6) <!-- [rfced] Please review the artwork in Section 2.1 and let us >>> know what "Section 5" refers to and if any other updates are needed. >>> Perhaps this refers to Table 3? >>> >>> Original: >>> RED = "Multihoming Redundancy Mode" field (section 5) >>> --> >>> >>> [jorge] it refers to the multihoming redundancy mode field in table >>> 2 (of section 5, IANA considerations) >>> >>> >>> >>> >>> 7) <!-- [rfced] The figure in Section 2.1 indicates that value 11 is >>> "reserved for future use". However, table 3 (and the IANA registry) >>> indicates the value is unassigned. "Reserved" and "Unassigned" have >>> distinct meanings. Please review "Well-Known Registration Status >>> Terminology" in RFC 8126 >>> <https://www.rfc-editor.org/rfc/rfc8126.html#section-6> and let us know >>> which is correct. >>> >>> Section 2.1 (double hyphen changed to single hyphen so this comment appears >>> correctly in the XML file: >>> 1 1 -> reserved for future use >>> >>> Table 3: >>> | 11 | Unassigned | | >>> >>> --> >>> >>> [jorge] please change the figure to “Unassigned” >>> >>> >>> >>> >>> 8) <!-- [rfced] How may we adjust the text below to avoid using an >>> RFC as an adjective? >>> >>> Original: >>> An egress NVE MUST NOT use an SHT value other than 00 when >>> advertising an A-D per ES route with [RFC9012] Tunnel encapsulation >>> types of VXLAN (type 8), NVGRE (type 9), MPLS (type 10), or no BGP >>> tunnel encapsulation extended community at all. >>> >>> Perhaps: >>> An egress NVE MUST NOT use an SHT value other than 00 when >>> advertising an A-D per ES route with the following tunnel encapsulation >>> types from [RFC9012]: VXLAN (type 8), NVGRE (type 9), MPLS (type 10), or >>> no BGP >>> Tunnel Encapsulation Extended Community at all. >>> >>> --> >>> >>> [jorge] your suggestion looks good to me >>> >>> >>> >>> >>> 9) <!-- [rfced] How may we update the citations in the text below? >>> We were unable to find either "Tunnel encapsulation type 19" or >>> "GENEVE" encapsulation in [RFC9012]. We note that the IANA entry refers to >>> RFC 8926 (19 Geneve Encapsulation). >>> >>> Original: >>> >>> An egress NVE advertising A-D per ES route(s) for an ES with GENEVE >>> encapsulation ([RFC9012], Tunnel encapsulation type 19, >>> [I-D.ietf-bess-evpn-geneve]) MAY use an SHT value of 01 or 10. >>> >>> Perhaps: >>> >>> An egress NVE advertising A-D per ES route(s) for an ES with GENEVE >>> encapsulation [RFC9012] (and tunnel encapsulation type 19 [EVPN-GENEVE]) >>> MAY >>> use an SHT value of 01 or 10. >>> --> >>> >>> [jorge] Hmm.. I think this is more accurate: >>> >>> ORIGINAL: >>> An egress NVE advertising A-D per ES route(s) for an ES with GENEVE >>> encapsulation ([RFC9012], Tunnel encapsulation type 19, >>> [I-D.ietf-bess-evpn-geneve]) MAY use an SHT value of 01 or 10. >>> >>> NEW: >>> >>> An egress NVE advertising A-D per ES route(s) for an ES with GENEVE >>> encapsulation (tunnel encapsulation type 19 in the BGP Tunnel >>> Encapsulation attribute [RFC9012]) MAY >>> use an SHT value of 01 or 10. >>> >>> >>> >>> >>> 10) <!-- [rfced] How may we rephrase the title of this section to >>> avoid using an RFC as an adjective? >>> >>> Original: >>> >>> 2.4. Backwards Compatibility With RFC8365 NVEs >>> >>> Perhaps (no RFC mentioned): >>> >>> 2.4. Backwards Compatibility with NVEs >>> >>> Perhaps (RFC mentioned): >>> >>> 2.4. Backwards Compatibility with NVEs from RFC 8365 >>> --> >>> >>> [jorge] use the latter one please – “2.4. Backwards Compatibility with >>> NVEs from RFC 8365” >>> >>> >>> >>> >>> 11) <!-- [rfced] May we make these registry titles plural? >>> >>> Multihoming Redundancy Mode -> Multihoming Redundancy Modes Split >>> Horizon Type -> Split Horizon Types >>> --> >>> >>> [jorge] I don’t think so, it reads better the way it is >>> >>> >>> >>> >>> 12) <!-- [rfced] Because "mode" is part of the registry and column titles, >>> does "mode" need to appear in description? >>> >>> From Table 3 and the IANA registry [1]: >>> +=======+=============================+===========+ >>> | Value | Multihoming redundancy mode | Reference | >>> +=======+=============================+===========+ >>> | 00 | All-Active mode | [RFC7432] | >>> | 01 | Single-Active mode | [RFC7432] | >>> >>> [1] >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww >>> w.iana.org%2Fassignments%2Fbgp-extended-communities%2Fbgp-extended-c >>> ommunities.xhtml%23multihoming-redundancy-mode&data=05%7C02%7Ckiran. >>> nagaraj%40nokia.com%7C4f6980c5bf9a4351ccd608dd54f24d2a%7C5d471751967 >>> 5428d917b70f44f9630b0%7C0%7C0%7C638760122149077373%7CUnknown%7CTWFpb >>> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI >>> kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7XZv%2B8E8kYSZvSG >>> cFZAMh00gKiO2DkZa5QJEVpFJOjk%3D&reserved=0 >>> --> >>> >>> [jorge] no, it does not. You can change those values to “All-Active” and >>> “Single-Active” and remove the “mode”. >>> >>> >>> >>> >>> 13) <!-- [rfced] Please review the following questions and changes >>> regarding the terminology used in this document: >>> >>> a.) We note that the term "MPLSoX" does not appear in this document >>> after it is introduced in Section 1. May we remove this term from the >>> terminology list? >>> >>> Original: >>> * MPLSoX: refers to MPLS over any IP encapsulation. Examples are >>> MPLS-over-UDP or MPLS-over-GRE. >>> >>> [jorge] But it appears in the introduction and it may still help if the >>> reader does not know what MPLSoX means in the introduction… I would leave >>> it. >>> >>> >>> >>> b.) FYI - For consistency with RFCs 8402, 8986, and 9252, we have updated >>> the terms below as follows. Please review and let us know any objections. >>> >>> Original: >>> >>> Segment Routing with MPLS data plane (SR-MPLS) Segment Routing with >>> IPv6 data plane (SRv6) >>> >>> Current: >>> >>> SR over MPLS (SR-MPLS) >>> Segment Routing over IPv6 (SRv6) >>> >>> --> >>> >>> [jorge] sounds good, thanks. >>> >>> >>> >>> >>> 14) <!-- [rfced] The references in this document do not appear to be sorted. >>> Would you like to order them alphanumerically? --> >>> >>> [jorge] yes, please >>> >>> >>> >>> >>> 15) <!-- [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. 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 checked, but couldn’t identify anything to change. >>> >>> >>> >>> >>> Thank you. >>> >>> RFC Editor >>> >>> >>> >>> On Feb 10, 2025, at 7:28 PM, rfc-edi...@rfc-editor.org wrote: >>> >>> *****IMPORTANT***** >>> >>> Updated 2025/02/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 >>> >>> * rfc-edi...@rfc-editor.org (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). >>> >>> * auth48archive@rfc-editor.org, 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-4Q9l2US >>> xIAe6P8O4Zc >>> >>> * 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, >>> auth48archive@rfc-editor.org 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/rfc9746.xml >>> https://www.rfc-editor.org/authors/rfc9746.html >>> https://www.rfc-editor.org/authors/rfc9746.pdf >>> https://www.rfc-editor.org/authors/rfc9746.txt >>> >>> Diff file of the text: >>> https://www.rfc-editor.org/authors/rfc9746-diff.html >>> https://www.rfc-editor.org/authors/rfc9746-rfcdiff.html (side by >>> side) >>> >>> Diff of the XML: >>> https://www.rfc-editor.org/authors/rfc9746-xmldiff1.html >>> >>> >>> Tracking progress >>> ----------------- >>> >>> The details of the AUTH48 status of your document are here: >>> https://www.rfc-editor.org/auth48/rfc9746 >>> >>> Please let us know if you have any questions. >>> >>> Thank you for your cooperation, >>> >>> RFC Editor >>> >>> -------------------------------------- >>> RFC 9746 (draft-ietf-bess-evpn-mh-split-horizon-11) >>> >>> Title : BGP EVPN Multi-Homing Extensions for Split Horizon >>> Filtering >>> Author(s) : J. Rabadan, K. Nagaraj, W. Lin, A. Sajassi >>> WG Chair(s) : Matthew Bocci, Stephane Litkowski, Zhaohui (Jeffrey) >>> Zhang >>> >>> Area Director(s) : Jim Guichard, John Scudder, Gunter Van de Velde -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
