Thanks! Sent from my iPhone
> On Mar 10, 2025, at 4:06 PM, Sarah Tarrant <starr...@staff.rfc-editor.org> > wrote: > > Hi James and John, > > We have updated your email addresses and affiliations accordingly. > > Thank you, > RFC Editor/st > >> On Mar 10, 2025, at 2:47 PM, je_dr...@yahoo.com wrote: >> >> 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
