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%2Fwww.iana.org%2Fassignments%2Fbgp-extended-communities%2Fbgp-extended-communities.xhtml%23multihoming-redundancy-mode&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C650a6358936d4d470eec08dd5145c830%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638756082752894793%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=Ranl856HraMwcT9cffXDZeTZ6eJyT5B86AKHGe1uBeI%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-4Q9l2USxIAe6P8O4Zc > > > > * The archive itself: > > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > > > * Note: If only absolutely necessary, you may temporarily opt out > > of the archiving of messages (e.g., to discuss a sensitive matter). > > If needed, please add a note at the top of the message that you > > have dropped the address. When the discussion is concluded, > > 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
