All, We have now received all necessary approvals and consider AUTH48 complete: https://www.rfc-editor.org/auth48/rfc9744
Thank you for your attention and guidance during the AUTH48 process. We will move this document forward in the publication process at this time. Sincerely, RFC Editor/st > On Mar 10, 2025, at 3:10 PM, je_dr...@yahoo.com wrote: > > 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
