Sarah, Would you please also change my affiliation to ‘Independent’?
Thanks, John Sent from my iPhone > On Mar 10, 2025, at 12:35 PM, je_dr...@yahoo.com wrote: > > Thanks! > > Sent from my iPhone > >> On Mar 10, 2025, at 12:14 PM, Sarah Tarrant <starr...@staff.rfc-editor.org> >> wrote: >> >> Hi John, >> >> We have updated your email address accordingly. >> >> 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 (see >> https://www.rfc-editor.org/auth48/rfc9744). >> >> Thank you, >> RFC Editor/st >> >>>> On Mar 10, 2025, at 8:37 AM, je_dr...@yahoo.com wrote: >>> >>> Sarah, >>> >>> Please update my email address in the RFC to be. >>> >>> Thanks, >>> >>> John >>> >>> Sent from my iPhone >>> >>>>> On Mar 10, 2025, at 9:34 AM, Sarah Tarrant >>>>> <starr...@staff.rfc-editor.org> wrote: >>>> >>>> Hi John and Patrice, >>>> >>>> Thank you for your replies. We have marked your approval on the AUTH48 >>>> status page for this document (see >>>> https://www.rfc-editor.org/auth48/rfc9744). >>>> >>>> John - Apologies for this email chain from not getting to your correct >>>> email. Would you like to have your information in the draft be updated? >>>> Also, the entire email thread for this pending RFC can be viewed at the >>>> IETF Mail Archive: https://mailarchive.ietf.org/arch/. >>>> >>>> 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, >>>> RFC Editor/st >>>> >>>>> On Mar 7, 2025, at 3:52 PM, Patrice Brissette (pbrisset) >>>>> <pbris...@cisco.com> wrote: >>>>> >>>>> Hi everyone, >>>>> The document looks very good. Thanks for the hard work from Ali and >>>>> everyone. >>>>> I approve it. >>>>> Regards, >>>>> Patrice Brissette >>>>> Distinguished Engineer >>>>> Cisco Systems >>>>> From: Sarah Tarrant <starr...@staff.rfc-editor.org> >>>>> Date: Thursday, March 6, 2025 at 10:09 >>>>> To: Ali Sajassi (sajassi) <saja...@cisco.com>, Patrice Brissette >>>>> (pbrisset) <pbris...@cisco.com>, utt...@att.com <utt...@att.com>, >>>>> jdr...@juniper.net <jdr...@juniper.net>, sbout...@ciena.com >>>>> <sbout...@ciena.com>, Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, >>>>> Matthew Bocci (Nokia) <matthew.bo...@nokia.com> >>>>> Cc: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>, >>>>> rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, bess-...@ietf.org >>>>> <bess-...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, >>>>> slitkows.i...@gmail.com <slitkows.i...@gmail.com>, >>>>> auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> >>>>> Subject: Re: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> >>>>> for your review >>>>> Hello all, >>>>> >>>>> We have updated the document accordingly and have no further questions or >>>>> comments. We will await approvals from each author prior to moving >>>>> forward in the publication process. >>>>> >>>>> 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. >>>>> >>>>> The updated files have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9744.txt >>>>> https://www.rfc-editor.org/authors/rfc9744.pdf >>>>> https://www.rfc-editor.org/authors/rfc9744.html >>>>> https://www.rfc-editor.org/authors/rfc9744.xml >>>>> >>>>> The relevant diff files have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9744-diff.html (comprehensive diff) >>>>> https://www.rfc-editor.org/authors/rfc9744-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/rfc9744 >>>>> >>>>> Thank you, >>>>> RFC Editor/st >>>>> >>>>>>> On Mar 6, 2025, at 4:42 AM, Matthew Bocci (Nokia) >>>>>>> <matthew.bo...@nokia.com> wrote: >>>>>> >>>>>> Hi Sarah, Ali >>>>>> This looks good to me. >>>>>> Thanks >>>>>> Matthew >>>>>> From: Sarah Tarrant <starr...@staff.rfc-editor.org> >>>>>> Date: Wednesday, 5 March 2025 at 20:14 >>>>>> To: Ali Sajassi (sajassi) <saja...@cisco.com>, Gunter van de Velde >>>>>> (Nokia) <gunter.van_de_ve...@nokia.com>, Matthew Bocci (Nokia) >>>>>> <matthew.bo...@nokia.com> >>>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Patrice >>>>>> Brissette (pbrisset) <pbris...@cisco.com>, utt...@att.com >>>>>> <utt...@att.com>, jdr...@juniper.net <jdr...@juniper.net>, >>>>>> sbout...@ciena.com<sbout...@ciena.com>, Jorge Rabadan (Nokia) >>>>>> <jorge.raba...@nokia.com>,bess-...@ietf.org <bess-...@ietf.org>, >>>>>> bess-cha...@ietf.org <bess-cha...@ietf.org>, slitkows.i...@gmail.com >>>>>> <slitkows.i...@gmail.com>, auth48archive@rfc-editor.org >>>>>> <auth48archive@rfc-editor.org> >>>>>> Subject: Re: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> >>>>>> for your review >>>>>> [You don't often get email from starr...@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 Ali, Gunter, and Matthew, >>>>>> >>>>>> Thank you for your replies. >>>>>> >>>>>> Ali - Thank you for the new proposed text. >>>>>> >>>>>> Gunter - Thank you for your approval of Ali's proposed text. >>>>>> >>>>>> Matthew - Are there any objections to Ali's proposed text and document >>>>>> updates? We ask because Ali wrote: >>>>>> >>>>>>> Hi Sarah, if no objections from Matthew and Gunter, then please update >>>>>>> the draft accordingly. >>>>>> >>>>>> A) >>>>>> Original: >>>>>> Additionally, when the remote ES fails and the PE receives the "mass >>>>>> withdrawal" message associated with the failed ES per [RFC7432], a PE >>>>>> device can quickly update its BGP list of available remote entries to >>>>>> invalidate all VPWS service tunnels sharing the ESI field and achieve >>>>>> fast convergence for multi-homing scenarios. Even if fast >>>>>> convergence was not needed, there would still be a need for signaling >>>>>> each AC failure (via its corresponding VPWS service tunnel) >>>>>> associated with the failed ES so that the BGP path list for each of >>>>>> them gets updated accordingly and the packets are sent to a backup PE >>>>>> (in case of Single-Active multi-homing) or to other PEs in the >>>>>> redundancy group (in case of All-Active multi-homing). In the >>>>>> absence of updating the BGP path list, the traffic for that VPWS >>>>>> service tunnel will be black-holed. >>>>>> >>>>>> Proposed: >>>>>> Additionally, when the remote ES fails and the PE receives the "mass >>>>>> withdrawal" message associated with the failed ES per [RFC7432], a PE >>>>>> device can quickly update its next-hop adjacency list (adjacency list) >>>>>> for all VPWS service tunnels sharing the ESI field and achieve >>>>>> fast convergence for multi-homing scenarios. Even if fast >>>>>> convergence was not needed, there would still be a need for signaling >>>>>> each AC failure (via its corresponding VPWS service tunnel) >>>>>> associated with the failed ES so that the adjacency list >>>>>> gets updated and the packets are sent to a backup PE >>>>>> (in case of Single-Active multi-homing) or to other PEs in the >>>>>> redundancy group (in case of All-Active multi-homing). In the >>>>>> absence of updating the adjacency list properly, the >>>>>> traffic for that VPWS service tunnel will be dropped by the egress PE >>>>>> with a failed ES/AC. >>>>>> >>>>>> B) >>>>>> Original: >>>>>> * Default FXC (Figure 1): In the default mode, a VLAN or AC failure >>>>>> is not signaled. Consequently, in case of an AC failure, such as >>>>>> VID1 on CE2, there is nothing to prevent PE3 from directing >>>>>> traffic from CE4 to PE1, leading to a potential black hole. >>>>>> >>>>>> Proposed: >>>>>> * Default FXC (Figure 1): In the default mode, a VLAN or AC failure >>>>>> is not signaled. Consequently, in case of an AC failure, such as >>>>>> VID1 on CE2, there is nothing to prevent PE3 from directing >>>>>> traffic from CE4 to PE1, leading to a potential packet loss at the >>>>>> egress >>>>>> PE with a failed AC. >>>>>> >>>>>> C) >>>>>> Replace all instances of the following terms with "adjacency list": >>>>>> BGP list >>>>>> BGP path list >>>>>> path list >>>>>> >>>>>> Sincerely, >>>>>> RFC Editor/st >>>>>> >>>>>> >>>>>>> On Mar 5, 2025, at 1:16 PM, Ali Sajassi (sajassi) <saja...@cisco.com> >>>>>>> wrote: >>>>>>> >>>>>>> Thanks Gunter! >>>>>>> Sarah, can you please update the draft based on the proposed text. >>>>>>> Thanks very much, >>>>>>> Ali >>>>>>> From: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com> >>>>>>> Date: Wednesday, March 5, 2025 at 12:09 AM >>>>>>> To: Ali Sajassi (sajassi) <saja...@cisco.com>, Matthew Bocci (Nokia) >>>>>>> <matthew.bo...@nokia.com>, Sarah Tarrant >>>>>>> <starr...@staff.rfc-editor.org>, Ali Sajassi (sajassi) >>>>>>> <sajassi=40cisco....@dmarc.ietf.org> >>>>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Patrice >>>>>>> Brissette (pbrisset) <pbris...@cisco.com>, utt...@att.com >>>>>>> <utt...@att.com>, jdr...@juniper.net <jdr...@juniper.net>, >>>>>>> sbout...@ciena.com <sbout...@ciena.com>, Jorge Rabadan (Nokia) >>>>>>> <jorge.raba...@nokia.com>, bess-...@ietf.org <bess-...@ietf.org>, >>>>>>> bess-cha...@ietf.org <bess-cha...@ietf.org>, slitkows.i...@gmail.com >>>>>>> <slitkows.i...@gmail.com>, auth48archive@rfc-editor.org >>>>>>> <auth48archive@rfc-editor.org> >>>>>>> Subject: RE: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> >>>>>>> for your review >>>>>>> Ali, >>>>>>> Thanks. This sounds good to me, and approved. It describes the failure >>>>>>> impacts more accurately. >>>>>>> G/ >>>>>>> From: Ali Sajassi (sajassi) <saja...@cisco.com> >>>>>>> Sent: Wednesday, March 5, 2025 4:44 AM >>>>>>> To: Matthew Bocci (Nokia) <matthew.bo...@nokia.com>; Gunter van de >>>>>>> Velde (Nokia) <gunter.van_de_ve...@nokia.com>; Sarah Tarrant >>>>>>> <starr...@staff.rfc-editor.org>; Ali Sajassi (sajassi) >>>>>>> <sajassi=40cisco....@dmarc.ietf.org> >>>>>>> Cc: rfc-edi...@rfc-editor.org; Patrice Brissette (pbrisset) >>>>>>> <pbris...@cisco.com>; utt...@att.com; jdr...@juniper.net; >>>>>>> sbout...@ciena.com; Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>; >>>>>>> bess-...@ietf.org; bess-cha...@ietf.org; slitkows.i...@gmail.com; >>>>>>> auth48archive@rfc-editor.org >>>>>>> Subject: Re: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> >>>>>>> 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 Matthew, Gunter: Thanks for your input. In the context of the >>>>>>> failure scenarios that is being discussed, there won’t be a routing >>>>>>> loop or other misrouting but rather a traffic loss (aka black hole). I >>>>>>> think for better clarification, the term “next-hop adjacencies” needs >>>>>>> to be used instead of “BGP path list”. So, I’d like to purpose the >>>>>>> following changes: >>>>>>> Hi Sarah, if no objections from Matthew and Gunter, then please update >>>>>>> the draft accordingly. >>>>>>> ORIGINAL#1: >>>>>>> Additionally, when the remote ES fails and the PE receives the "mass >>>>>>> withdrawal" message associated with the failed ES per [RFC7432], a PE >>>>>>> device can quickly update its BGP list of available remote entries to >>>>>>> invalidate all VPWS service tunnels sharing the ESI field and achieve >>>>>>> fast convergence for multi-homing scenarios. Even if fast >>>>>>> convergence was not needed, there would still be a need for signaling >>>>>>> each AC failure (via its corresponding VPWS service tunnel) >>>>>>> associated with the failed ES so that the BGP path list for each of >>>>>>> them gets updated accordingly and the packets are sent to a backup PE >>>>>>> (in case of Single-Active multi-homing) or to other PEs in the >>>>>>> redundancy group (in case of All-Active multi-homing). In the >>>>>>> absence of updating the BGP path list, the traffic for that VPWS >>>>>>> service tunnel will be black-holed. >>>>>>> PROPOSED#1: >>>>>>> Additionally, when the remote ES fails and the PE receives the "mass >>>>>>> withdrawal" message associated with the failed ES per [RFC7432], a PE >>>>>>> device can quickly update its next-hop adjacency list (adjacency list) >>>>>>> for all VPWS service tunnels sharing the ESI field and achieve >>>>>>> fast convergence for multi-homing scenarios. Even if fast >>>>>>> convergence was not needed, there would still be a need for signaling >>>>>>> each AC failure (via its corresponding VPWS service tunnel) >>>>>>> associated with the failed ES so that the adjacency list >>>>>>> gets updated and the packets are sent to a backup PE >>>>>>> (in case of Single-Active multi-homing) or to other PEs in the >>>>>>> redundancy group (in case of All-Active multi-homing). In the >>>>>>> absence of updating the adjacency list properly, the >>>>>>> traffic for that VPWS service tunnel will be dropped by the egress >>>>>>> PE with a failed ES/AC. >>>>>>> >>>>>>> ORIGINAL#2: >>>>>>> * Default FXC (Figure 1): In the default mode, a VLAN or AC failure >>>>>>> is not signaled. Consequently, in case of an AC failure, such as >>>>>>> VID1 on CE2, there is nothing to prevent PE3 from directing >>>>>>> traffic from CE4 to PE1, leading to a potential black hole. >>>>>>> >>>>>>> PROPOSED#2: >>>>>>> * Default FXC (Figure 1): In the default mode, a VLAN or AC failure >>>>>>> is not signaled. Consequently, in case of an AC failure, such as >>>>>>> VID1 on CE2, there is nothing to prevent PE3 from directing >>>>>>> traffic from CE4 to PE1, leading to a potential packet loss at the >>>>>>> egress >>>>>>> PE with a failed AC. >>>>>>> Also please replace all instances of “BGP list” or “BGP path list” or >>>>>>> “path list” with “adjacency list” throughout the document. >>>>>>> Cheers, >>>>>>> Ali >>>>>>> From: Matthew Bocci (Nokia) <matthew.bo...@nokia.com> >>>>>>> Date: Tuesday, March 4, 2025 at 7:02 AM >>>>>>> To: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>, Sarah >>>>>>> Tarrant <starr...@staff.rfc-editor.org>, Ali Sajassi (sajassi) >>>>>>> <sajassi=40cisco....@dmarc.ietf.org> >>>>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Patrice >>>>>>> Brissette (pbrisset) <pbris...@cisco.com>, utt...@att.com >>>>>>> <utt...@att.com>,jdr...@juniper.net <jdr...@juniper.net>, >>>>>>> sbout...@ciena.com<sbout...@ciena.com>, Jorge Rabadan (Nokia) >>>>>>> <jorge.raba...@nokia.com>, Ali Sajassi (sajassi) <saja...@cisco.com>, >>>>>>> bess-...@ietf.org <bess-...@ietf.org>, bess-cha...@ietf.org >>>>>>> <bess-cha...@ietf.org>,slitkows.i...@gmail.com >>>>>>> <slitkows.i...@gmail.com>, auth48archive@rfc-editor.org >>>>>>> <auth48archive@rfc-editor.org> >>>>>>> Subject: Re: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> >>>>>>> for your review >>>>>>> I am not sure “pathologies” is the right word here. Can I suggest >>>>>>> rephrasing that sentence to “potential routing loops or other >>>>>>> conditions where traffic is unintentionally misrouted or discarded.” >>>>>>> Matthew >>>>>>> From: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com> >>>>>>> Date: Tuesday, 4 March 2025 at 12:37 >>>>>>> To: Sarah Tarrant <starr...@staff.rfc-editor.org>, Ali Sajassi >>>>>>> (sajassi) <sajassi=40cisco....@dmarc.ietf.org> >>>>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Patrice >>>>>>> Brissette (pbrisset) <pbris...@cisco.com>, utt...@att.com >>>>>>> <utt...@att.com>,jdr...@juniper.net <jdr...@juniper.net>, >>>>>>> sbout...@ciena.com<sbout...@ciena.com>, Jorge Rabadan (Nokia) >>>>>>> <jorge.raba...@nokia.com>, Ali Sajassi (sajassi) <saja...@cisco.com>, >>>>>>> bess-...@ietf.org <bess-...@ietf.org>, bess-cha...@ietf.org >>>>>>> <bess-cha...@ietf.org>,slitkows.i...@gmail.com >>>>>>> <slitkows.i...@gmail.com>, auth48archive@rfc-editor.org >>>>>>> <auth48archive@rfc-editor.org> >>>>>>> Subject: RE: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> >>>>>>> for your review >>>>>>> Hi All, >>>>>>> >>>>>>>> For example, please consider whether the following should be updated: >>>>>>>> >>>>>>>> black hole >>>>>>>> block-holed >>>>>>>> --> >>>>>>>> Ali> I would prefer “black hole” and “black holed” >>>>>>> >>>>>>> Aloi, All, From an inclusiveness language would the following work? >>>>>>> >>>>>>> ORIGINAL#1: >>>>>>> In the >>>>>>> absence of updating the BGP path list, the traffic for that VPWS >>>>>>> service tunnel will be black-holed. >>>>>>> >>>>>>> PROPOSED#1: >>>>>>> In the >>>>>>> absence of updating the BGP path list, the traffic for that VPWS >>>>>>> service tunnel will ***suffer from routing loops, misrouting or other >>>>>>> pathologies***. >>>>>>> >>>>>>> ORIGINAL#2: >>>>>>> * Default FXC (Figure 1): In the default mode, a VLAN or AC failure >>>>>>> is not signaled. Consequently, in case of an AC failure, such as >>>>>>> VID1 on CE2, there is nothing to prevent PE3 from directing >>>>>>> traffic from CE4 to PE1, leading to a potential black hole. >>>>>>> >>>>>>> PROPOSED#2: >>>>>>> * Default FXC (Figure 1): In the default mode, a VLAN or AC failure >>>>>>> is not signaled. Consequently, in case of an AC failure, such as >>>>>>> VID1 on CE2, there is nothing to prevent PE3 from directing >>>>>>> traffic from CE4 to PE1, leading to ***potential routing loops, >>>>>>> misrouting or other pathologies***. >>>>>>> >>>>>>> G/ >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Sarah Tarrant <starr...@staff.rfc-editor.org> >>>>>>> Sent: Monday, March 3, 2025 6:08 PM >>>>>>> To: Ali Sajassi (sajassi) <sajassi=40cisco....@dmarc.ietf.org> >>>>>>> Cc: rfc-edi...@rfc-editor.org; Patrice Brissette (pbrisset) >>>>>>> <pbris...@cisco.com>;utt...@att.com; jdr...@juniper.net; >>>>>>> sbout...@ciena.com; Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>; >>>>>>> Ali Sajassi (sajassi) <saja...@cisco.com>; bess-...@ietf.org; >>>>>>> bess-cha...@ietf.org; slitkows.i...@gmail.com; Gunter van de Velde >>>>>>> (Nokia) <gunter.van_de_ve...@nokia.com>; auth48archive@rfc-editor.org >>>>>>> Subject: Re: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> >>>>>>> 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 Ali, >>>>>>> >>>>>>> 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://www.rfc-editor.org/authors/rfc9744.txt >>>>>>> https://www.rfc-editor.org/authors/rfc9744.pdf >>>>>>> https://www.rfc-editor.org/authors/rfc9744.html >>>>>>> https://www.rfc-editor.org/authors/rfc9744.xml >>>>>>> >>>>>>> The relevant diff files have been posted here (please refresh): >>>>>>> https://www.rfc-editor.org/authors/rfc9744-diff.html (comprehensive >>>>>>> diff)https://www.rfc-editor.org/authors/rfc9744-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/rfc9744 >>>>>>> >>>>>>> Thank you, >>>>>>> RFC Editor/st >>>>>>> >>>>>>>> On Feb 28, 2025, at 12:01 AM, Ali Sajassi (sajassi) >>>>>>>> <sajassi=40cisco....@dmarc.ietf.org> wrote: >>>>>>>> >>>>>>>> Dear RFC-Editor, >>>>>>>> Thanks you for your recommendations, please refer to my comments >>>>>>>> inline marked with “Ali>” . Once they are incorporated, I will be >>>>>>>> happy to approve it. >>>>>>>> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> >>>>>>>> Date: Wednesday, February 26, 2025 at 2:41 PM >>>>>>>> To: Ali Sajassi (sajassi) <saja...@cisco.com>, Patrice Brissette >>>>>>>> (pbrisset) <pbris...@cisco.com>, utt...@att.com <utt...@att.com>, >>>>>>>> jdr...@juniper.net<jdr...@juniper.net>, sbout...@ciena.com >>>>>>>> <sbout...@ciena.com>, jorge.raba...@nokia.com >>>>>>>> <jorge.raba...@nokia.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>, slitkows.i...@gmail.com >>>>>>>> <slitkows.i...@gmail.com>, gunter.van_de_ve...@nokia.com >>>>>>>> <gunter.van_de_ve...@nokia.com>,auth48archive@rfc-editor.org >>>>>>>> <auth48archive@rfc-editor.org> >>>>>>>> Subject: Re: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> >>>>>>>> for your review Authors, >>>>>>>> >>>>>>>> While reviewing this document during AUTH48, please resolve (as >>>>>>>> necessary) the following questions, which are also in the XML file. >>>>>>>> >>>>>>>> 1) <!-- [rfced] Please note that the title of the document has been >>>>>>>> updated as follows. Abbreviations have been expanded per Section 3.6 >>>>>>>> of RFC 7322 ("RFC Style Guide"). Please review. >>>>>>>> >>>>>>>> Original: >>>>>>>> EVPN VPWS Flexible Cross-Connect Service >>>>>>>> >>>>>>>> Current: >>>>>>>> EVPN Virtual Private Wire Service (VPWS) Flexible Cross-Connect (FXC) >>>>>>>> Service >>>>>>>> --> >>>>>>>> Ali> That’ fine. >>>>>>>> >>>>>>>> >>>>>>>> 2) <!-- [rfced] We're having trouble understanding "can designate on" >>>>>>>> in the text below. Should this be updated to "can designate"? >>>>>>>> >>>>>>>> Original: >>>>>>>> [RFC8214] describes a solution to deliver P2P services using BGP >>>>>>>> constructs defined in [RFC7432]. It delivers this P2P service >>>>>>>> between a pair of Attachment Circuits (ACs), where an AC can >>>>>>>> designate on a PE, a port, a VLAN on a port, or a group of VLANs on a >>>>>>>> port. >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> [RFC8214] describes a solution to deliver P2P services using BGP >>>>>>>> constructs defined in [RFC7432]. It delivers this P2P service >>>>>>>> between a pair of Attachment Circuits (ACs), where an AC can >>>>>>>> designate a PE, a port, a VLAN on a port, or a group of VLANs on a >>>>>>>> port. >>>>>>>> --> >>>>>>>> Ali> It should be changed to “…, where an AC on a PE can represent a >>>>>>>> port, a VLAN on a port, or a group of VLANs on a port.” >>>>>>>> >>>>>>>> 3) <!--[rfced] To have a 1:1 matchup between the following >>>>>>>> abbreviations and their expansions, may we update as follows? >>>>>>>> >>>>>>>> Original: >>>>>>>> Ethernet A-D: Ethernet Auto-Discovery (A-D) per EVI and Ethernet A-D >>>>>>>> per ESI routes, as defined in [RFC7432] and [RFC8214]. >>>>>>>> ... >>>>>>>> PE: Provider Edge device >>>>>>>> ... >>>>>>>> VRF: VPN Routing and Forwarding table >>>>>>>> ... >>>>>>>> IP-VRF: VPN Routing and Forwarding table, for IP lookup >>>>>>>> ... >>>>>>>> MAC-VRF: VPN Routing and Forwarding table, for MAC lookup >>>>>>>> ... >>>>>>>> VID-VRF: VPN Routing and Forwarding table, for Normalized VID >>>>>>>> lookup >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> Ethernet A-D: Ethernet Auto-Discovery (per EVI and per ESI routes, >>>>>>>> as defined in [RFC7432] and [RFC8214]) >>>>>>>> Ali> also use “or” instead of “and”: “ Ethernet A-D: Ethernet >>>>>>>> Auto-Discovery (per EVI or per ESI routes, as defined in [RFC7432] and >>>>>>>> [RFC8214])” >>>>>>>> ... >>>>>>>> PE: Provider Edge >>>>>>>> ... >>>>>>>> VRF: VPN Routing and Forwarding >>>>>>>> ... >>>>>>>> IP-VRF: VPN Routing and Forwarding for IP lookup >>>>>>>> >>>>>>>> MAC-VRF: VPN Routing and Forwarding for MAC lookup >>>>>>>> >>>>>>>> VID-VRF: VPN Routing and Forwarding for normalized VID lookup >>>>>>>> --> >>>>>>>> >>>>>>>> >>>>>>>> 4) <!-- [rfced] We were unable to find exactly "12-bit VPWS service >>>>>>>> instance identifiers" in [RFC8214]. We did find the following in >>>>>>>> Section 3 of [RFC8214]: >>>>>>>> >>>>>>>> The VPWS service instance identifier value MAY be set to a 24-bit >>>>>>>> value, >>>>>>>> and when a 24-bit value is used, it MUST be right-aligned. >>>>>>>> >>>>>>>> For a more accurate citation, may we update to something like the >>>>>>>> following? >>>>>>>> >>>>>>>> Current: >>>>>>>> As stated in [RFC8214], 12-bit and 24-bit VPWS service instance >>>>>>>> identifiers >>>>>>>> representing normalized VIDs MUST be right-aligned. >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> 24-bit VPWS service instance identifiers [RFC8214] as well as 12-bit >>>>>>>> VPWS service instance identifiers representing normalized VIDs MUST >>>>>>>> be right-aligned. >>>>>>>> --> >>>>>>>> Ali> That’s fine. >>>>>>>> >>>>>>>> 5) <!--[rfced] To clarify the numbered list, we have updated this >>>>>>>> sentence in Section 3.2. Please review and ensure that the intended >>>>>>>> meaning has not changed. Note that we have made a similar update to a >>>>>>>> sentence in Section 3.3. >>>>>>>> >>>>>>>> Original: >>>>>>>> Additionally, this route >>>>>>>> is sent with the EVPN Layer-2 Extended Community defined in >>>>>>>> Section 3.1 of [RFC8214] with two new flags (outlined in Section 4) >>>>>>>> that indicate: 1) this VPWS service tunnel is for the default >>>>>>>> Flexible Cross-Connect, and 2) the normalized VID type (single versus >>>>>>>> double). >>>>>>>> >>>>>>>> Current: >>>>>>>> Additionally, this route >>>>>>>> is sent with the EVPN Layer 2 Extended Community defined in >>>>>>>> Section 3.1 of [RFC8214] with two new flags (outlined in Section 4) >>>>>>>> that indicate: 1) this VPWS service tunnel for the default >>>>>>>> Flexible Cross-Connect and 2) the normalized VID type (single versus >>>>>>>> double). >>>>>>>> --> >>>>>>>> Ali> Please change it to: “… 1) the VPW service tunnel (set to >>>>>>>> default Flexible Cross-Connect) and 2) the normalized VID type (set to >>>>>>>> normalized single-VID or double-VID)” >>>>>>>> >>>>>>>> >>>>>>>> 6) <!--[rfced] Please note that a slash (/) can mean "and", "or", or >>>>>>>> "and/or". >>>>>>>> We have updated it to "and" in the text below for clarity. Please >>>>>>>> review and let us know if any further updates are needed. >>>>>>>> >>>>>>>> Original: >>>>>>>> In this mode of operation, similar to the default FXC mode described >>>>>>>> in Section 3.2, many normalized VIDs representing ACs across several >>>>>>>> Ethernet Segments/interfaces are multiplexed into a single EVPN VPWS >>>>>>>> service tunnel. >>>>>>>> >>>>>>>> Current: >>>>>>>> In this mode of operation, similar to the default FXC mode described >>>>>>>> in Section 3.2, many normalized VIDs representing ACs across several >>>>>>>> Ethernet Segments and interfaces are multiplexed into a single EVPN >>>>>>>> VPWS >>>>>>>> service tunnel. >>>>>>>> --> >>>>>>>> Ali> That’s fine. >>>>>>>> >>>>>>>> >>>>>>>> 7) <!--[rfced] May we remove "service" after "FXC" in the following >>>>>>>> sentence? >>>>>>>> Additionally, please note that we have numbered the items listed to >>>>>>>> improve readability. >>>>>>>> >>>>>>>> Original: >>>>>>>> However, only two VPWS >>>>>>>> Service Tunnels are required: VPWS Service Tunnel 1 (sv.T1) between >>>>>>>> PE1's FXC service and PE3's FXC, and VPWS Service Tunnel 2 (sv.T2) >>>>>>>> between PE2's FXC and PE3's FXC. >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> However, only two VPWS >>>>>>>> Service Tunnels are required: 1) VPWS Service Tunnel 1 (sv.T1) between >>>>>>>> PE1's FXC and PE3's FXC and 2) VPWS Service Tunnel 2 (sv.T2) >>>>>>>> between PE2's FXC and PE3's FXC. >>>>>>>> --> >>>>>>>> Ali> That’s fine. >>>>>>>> >>>>>>>> >>>>>>>> 8) <!--[rfced] May we update the following acronyms and their >>>>>>>> expansions to better reflect the text in RFC 5885? >>>>>>>> >>>>>>>> Original: >>>>>>>> The failure detection of an EVPN VPWS service can be performed via >>>>>>>> OAM mechanisms such as VCCV-BFD (Bidirectional Forwarding Detection >>>>>>>> for the Pseudowire Virtual Circuit Connectivity Verification, >>>>>>>> [RFC5885]) and upon such failure detection, the switch over procedure >>>>>>>> to the backup S-PE is the same as the one described above. >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> The failure detection of an EVPN VPWS service can be performed via >>>>>>>> OAM mechanisms such as Bidirectional Forwarding Detection (BFD) >>>>>>>> for the pesudowire Virtual Circuit Connectivity Verification (VCCV) >>>>>>>> [RFC5885], and upon such failure detection, the switch over procedure >>>>>>>> to the backup S-PE is the same as the one described above. >>>>>>>> --> >>>>>>>> Ali> That’s fine. >>>>>>>> >>>>>>>> >>>>>>>> 9) <!-- [rfced] Terminology >>>>>>>> >>>>>>>> A) To match usage in RFC 8214, may we update the following terms to >>>>>>>> the format on the right? >>>>>>>> >>>>>>>> single-active > Single-Active >>>>>>>> all-active > All-Active >>>>>>>> EVPN VPWS > EVPN-VPWS >>>>>>>> Ethernet A-D per EVI route > Ethernet A-D per-EVI route Ethernet A-D >>>>>>>> per ES route > Ethernet A-D per-ES route VLAN-bundle > VLAN bundle >>>>>>>> Ali> Please do so. >>>>>>>> >>>>>>>> >>>>>>>> B) Throughout the text, the following terminology appears to be used >>>>>>>> inconsistently. May we update them to the format on the right? >>>>>>>> >>>>>>>> Normalized VID > normalized VID >>>>>>>> VLAN-signaled flexible cross-connect > VLAN-signaled FXC VLAN-signaled >>>>>>>> Flexible Cross-Connect > VLAN-signaled FXC >>>>>>>> Ali> Please do so. >>>>>>>> >>>>>>>> >>>>>>>> C) Since RFC 8214 uses "EVPN Layer 2 Attributes Extended Community", >>>>>>>> should the following terms be update to match? We ask because of the >>>>>>>> possible addition of "Attributes". >>>>>>>> >>>>>>>> EVPN Layer 2 Extended Community (Sections 3.2 and 3.3) EVPN Layer 2 >>>>>>>> attribute extended community (Section 4) >>>>>>>> --> >>>>>>>> Ali> Please update to match RFC 8214. >>>>>>>> >>>>>>>> 10) <!--[rfced] Abbreviations >>>>>>>> >>>>>>>> A) FYI - We have added expansions for the following abbreviations per >>>>>>>> Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >>>>>>>> expansion in the document carefully to ensure correctness. >>>>>>>> >>>>>>>> Autonomous System (AS) >>>>>>>> Switching Provider Edge (S-PE) >>>>>>>> Ali> Please change S-PE to PE. I don’t think you need to expand PE as >>>>>>>> it has been used many times previously. >>>>>>>> >>>>>>>> B) Both the expansion and the acronym for Ethernet Segment (ES) are >>>>>>>> used throughout the document. Would you like to update to using the >>>>>>>> expansion upon first usage and the acronym for the rest of the >>>>>>>> document for consistency? >>>>>>>> Ali> Please do so. >>>>>>>> >>>>>>>> >>>>>>>> C) We note that "FXC" appears to be expanded in different ways >>>>>>>> throughout the document. May we update all these instances to be >>>>>>>> "Flexible Cross-Connect" >>>>>>>> for consistency? >>>>>>>> >>>>>>>> Flexible Xconnect >>>>>>>> Flexible Cross Connect >>>>>>>> Flexible Cross-Connect >>>>>>>> Ali> Please do so. >>>>>>>> >>>>>>>> >>>>>>>> D) We note that "VCCV" is expaned in two different ways in this >>>>>>>> document. >>>>>>>> Please review and let us know which version should be updated for >>>>>>>> consistency. >>>>>>>> >>>>>>>> Virtual Circuit Connectivity Verification Virtual Circuit Connection >>>>>>>> Verification >>>>>>>> --> >>>>>>>> Ali> The top one – ie., Virtual Circuit Connectivity Verification >>>>>>>> >>>>>>>> 11) <!-- [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. >>>>>>>> >>>>>>>> For example, please consider whether the following should be updated: >>>>>>>> >>>>>>>> black hole >>>>>>>> block-holed >>>>>>>> --> >>>>>>>> Ali> I would prefer “black hole” and “black holed” >>>>>>>> Regards, >>>>>>>> Ali >>>>>>>> >>>>>>>> >>>>>>>> Thank you. >>>>>>>> >>>>>>>> RFC Editor/st/ap >>>>>>>> >>>>>>>> >>>>>>>> On Feb 26, 2025, at 2:29 PM, rfc-edi...@rfc-editor.org wrote: >>>>>>>> >>>>>>>> *****IMPORTANT***** >>>>>>>> >>>>>>>> Updated 2025/02/26 >>>>>>>> >>>>>>>> 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-4Q9l2USxI >>>>>>>> Ae6P8O4Zc >>>>>>>> >>>>>>>> * 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/rfc9744.xml >>>>>>>> https://www.rfc-editor.org/authors/rfc9744.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9744.pdf >>>>>>>> https://www.rfc-editor.org/authors/rfc9744.txt >>>>>>>> >>>>>>>> Diff file of the text: >>>>>>>> https://www.rfc-editor.org/authors/rfc9744-diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9744-rfcdiff.html (side by >>>>>>>> side) >>>>>>>> >>>>>>>> Diff of the XML: >>>>>>>> https://www.rfc-editor.org/authors/rfc9744-xmldiff1.html >>>>>>>> >>>>>>>> >>>>>>>> Tracking progress >>>>>>>> ----------------- >>>>>>>> >>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>> https://www.rfc-editor.org/auth48/rfc9744 >>>>>>>> >>>>>>>> Please let us know if you have any questions. >>>>>>>> >>>>>>>> Thank you for your cooperation, >>>>>>>> >>>>>>>> RFC Editor >>>>>>>> >>>>>>>> -------------------------------------- >>>>>>>> RFC9744 (draft-ietf-bess-evpn-vpws-fxc-12) >>>>>>>> >>>>>>>> Title : EVPN VPWS Flexible Cross-Connect Service >>>>>>>> Author(s) : A. Sajassi, P. Brissette, J. Uttaro, J. Drake, S. >>>>>>>> Boutros, J. Rabadan >>>>>>>> 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
