Hi IANA, Please make the following updates in the "Border Gateway Protocol (BGP) Extended Communities” registry. Updates are noted below; they can also be viewed in <https://www.rfc-editor.org/authors/rfc9746-rfcdiff.html>.
A) EVPN ESI Label Extended Community Flags https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#evpn-esi-label-extended-community-flags Old: 6-7 Split Horizon Type New (hyphen): 6-7 Split-Horizon Type B) Multihoming Redundancy Mode https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#multihoming-redundancy-mode Old: 00 All-Active mode 01 Single-Active mode New (remove “mode”): 00 All-Active 01 Single-Active C) Split Horizon Type https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#split-horizon-type C.1) Old title: Split Horizon Type New (hyphen): Split-Horizon Type C.2) Old column header: Split Horizon Type Value New (hyphen): Split-Horizon Type Value C.3) Old value 10: 10 ESI Label based filtering New (hyphen): 10 ESI Label-based filtering Please let us know if you have any questions. Otherwise, please let us know when the updates are complete. Thank you, RFC Editor/sg > On Mar 3, 2025, at 12:03 PM, Wen Lin <w...@juniper.net> wrote: > > Hi Sandy and Jorge, > > Thank you for advancing the draft to this stage. > > I reviewed the latest. It looks good. I approve the publication as an RFC. > > Wen > > > Juniper Business Use Only > > From: Sandy Ginoza <sgin...@staff.rfc-editor.org> > Date: Monday, March 3, 2025 at 10:07 AM > To: Ali Sajassi (sajassi) <saja...@cisco.com> > Cc: Kiran Nagaraj (Nokia) <kiran.naga...@nokia.com>, Jorge Rabadan (Nokia) > <jorge.raba...@nokia.com>, RFC Editor <rfc-edi...@rfc-editor.org>, Wen Lin > <w...@juniper.net>, bess-...@ietf.org <bess-...@ietf.org>, > bess-cha...@ietf.org <bess-cha...@ietf.org>, Jeffrey (Zhaohui) Zhang > <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 > > [External Email. Be cautious of content] > > > Hi Ali, > > Thank you for your review. We have noted your approval on the AUTH48 page > <https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9746__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRCx3kJs0$ > >. We will wait to hear from Wen before continuing with the process. > > Thank you, > RFC Editor/sg > > > > On Mar 2, 2025, at 1:09 PM, Ali Sajassi (sajassi) <saja...@cisco.com> wrote: > > > > Hi Sandy, > > > > I reviewed it and it looked good . Thanks for your work. I approve the > > publication of this RFC. > > > > Cheers, > > Ali > > > > From: Sandy Ginoza <sgin...@staff.rfc-editor.org> > > Date: Friday, February 28, 2025 at 11:39 AM > > To: Kiran Nagaraj (Nokia) <kiran.naga...@nokia.com> > > Cc: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, RFC Editor > > <rfc-edi...@rfc-editor.org>, w...@juniper.net <w...@juniper.net>, Ali > > Sajassi (sajassi) <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 > > > > Hi Wen and Ali, > > > > Please note that we await your review of RFC-to-be 9746 before continuing > > with the publication process. Please review and let us know if any updates > > are needed or if you approve the RFC for publication. > > > > The current files are available here: > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746.xml__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRFwUxWIg$ > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746.txt__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRQeRvL-8$ > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746.pdf__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vR_d3ClH8$ > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746.html__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRpeiSVBE$ > > > > AUTH48 diffs: > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746-auth48diff.html__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vR9rk8n_E$ > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746-auth48rfcdiff.html__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vROUPpKvo$ > > (side by side) > > > > Comprehensive diffs: > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746-diff.html__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRNyybZAs$ > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746-rfcdiff.html__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRxzIodOY$ > > (side by side) > > > > Thank you, > > RFC Editor/sg > > > > > > > > > On Feb 24, 2025, at 10:40 AM, Sandy Ginoza <sgin...@staff.rfc-editor.org> > > > wrote: > > > > > > Hi Kiran, > > > > > > Thank you for your review. We have noted your approval on the AUTH48 > > > page > > > <https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9746__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRCx3kJs0$ > > > >. > > > > > > 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 > > >> athttps://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRj2C5yYI$ > > >> ] > > >> > > >> 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://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9746__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRCx3kJs0$ > > >> >. 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://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRj2C5yYI$ > > >>> ] > > >>> > > >>> 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746.xml__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRFwUxWIg$ > > >>> > > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746.txt__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRQeRvL-8$ > > >>> > > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746.pdf__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vR_d3ClH8$ > > >>> > > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746.html__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRpeiSVBE$ > > >>> > > >>> AUTH48 diffs: > > >>> > > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746-auth48diff.html__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vR9rk8n_E$ > > >>> > > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746-auth48rfcdiff.html__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vROUPpKvo$ > > >>> (side > > >>> by side) > > >>> > > >>> Comprehensive diffs: > > >>> > > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746-diff.html__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRNyybZAs$ > > >>> > > >>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746-rfcdiff.html__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRxzIodOY$ > > >>> (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://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vR7P8vQMA$ > > >>>> . --> > > >>>> > > >>>> [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://urldefense.com/v3/__https://www.rfc-editor.org/rfc/rfc8126.html*section-6__;Iw!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRz303NOo$ > > >>>> > 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://urldefense.com/v3/__https://eur03.safelinks.protection.outlook.com/?url=https*3A*2F*2Fww__;JSUl!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vR2IYPsDg$ > > >>>> 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://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRPqqoIkQ$ > > >>>> > > > >>>> 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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRXEli_vU$ > > >>>> ). > > >>>> > > >>>> 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://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRMZaFfHE$ > > >>>> ). > > >>>> > > >>>> * 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://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vROfzigsg$ > > >>>> >. > > >>>> > > >>>> * 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2US__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRCXlkn0U$ > > >>>> xIAe6P8O4Zc > > >>>> > > >>>> * The archive itself: > > >>>> > > >>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vR8SD3tkc$ > > >>>> > > >>>> * 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746.xml__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRFwUxWIg$ > > >>>> > > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746.html__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRpeiSVBE$ > > >>>> > > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746.pdf__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vR_d3ClH8$ > > >>>> > > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746.txt__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRQeRvL-8$ > > >>>> > > >>>> Diff file of the text: > > >>>> > > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746-diff.html__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRNyybZAs$ > > >>>> > > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746-rfcdiff.html__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRxzIodOY$ > > >>>> (side by > > >>>> side) > > >>>> > > >>>> Diff of the XML: > > >>>> > > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9746-xmldiff1.html__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vR9ybFjas$ > > >>>> > > >>>> > > >>>> Tracking progress > > >>>> ----------------- > > >>>> > > >>>> The details of the AUTH48 status of your document are here: > > >>>> > > >>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9746__;!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRCx3kJs0$ > > >>>> > > >>>> 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
