I agree, the RFC editor staff, and Sarah in particular, have done a wonderful job.
Sent from my iPhone > On Mar 11, 2025, at 3:30 PM, Ali Sajassi (sajassi) <saja...@cisco.com> wrote: > > > Thank you Sarah for all your work and edits during this Auth48 process. > > Regards, > Ali > > From: Sarah Tarrant <starr...@staff.rfc-editor.org> > Date: Tuesday, March 11, 2025 at 11:09 AM > To: je_dr...@yahoo.com <je_dr...@yahoo.com>, utt...@att.com <utt...@att.com>, > jutt...@si.rr.com <jutt...@si.rr.com>, Patrice Brissette (pbrisset) > <pbris...@cisco.com>, Ali Sajassi (sajassi) <saja...@cisco.com>, > jdr...@juniper.net <jdr...@juniper.net>, sbout...@ciena.com > <sbout...@ciena.com>, Jorge Rabadan <jorge.raba...@nokia.com> > Cc: Matthew Bocci <matthew.bo...@nokia.com>, Gunter van de Velde > <gunter.van_de_ve...@nokia.com>, rfc-editor <rfc-edi...@rfc-editor.org>, > bess-...@ietf.org <bess-...@ietf.org>, bess-cha...@ietf.org > <bess-cha...@ietf.org>, <slitkows.i...@gmail.com>, auth48archive > <auth48archive@rfc-editor.org> > Subject: Re: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> for > your review > > 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
