Sarah, I approve publication. My email address is je_dr...@yahoo.com and so I haven't received any correspondence to date regarding this pending RFC.
Thanks, John ----- Forwarded Message ----- From: Ali Sajassi (sajassi) <saja...@cisco.com>To: John Drake <je_dr...@yahoo.com>Sent: Friday, March 7, 2025 at 01:16:17 PM PSTSubject: FW: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> for your review FYI From:Sarah Tarrant <starr...@staff.rfc-editor.org> Date: Thursday, March 6, 2025 at 2:51 PM To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, Boutros, Sami <sbout...@ciena.com> Cc: Ali Sajassi (sajassi) <saja...@cisco.com>, Patrice Brissette (pbrisset) <pbris...@cisco.com>, utt...@att.com <utt...@att.com>, jdr...@juniper.net <jdr...@juniper.net>, Matthew Bocci (Nokia) <matthew.bo...@nokia.com>, 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 Hi Sami and Jorge, Thank you for your replies. We have marked your approval on the AUTH48 status page for this document (seehttps://www.rfc-editor.org/auth48/rfc9744). 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 6, 2025, at 4:34 PM, Boutros, Sami <sbout...@ciena.com> wrote: > > The same here, Thanks Ali and Sarah for all the efforts on this. > Thanks, > Sami > From: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> > Date: Thursday, March 6, 2025 at 1:33 PM > To: Sarah Tarrant <starr...@staff.rfc-editor.org>, Ali Sajassi (sajassi) > <saja...@cisco.com>, Patrice Brissette (pbrisset) <pbris...@cisco.com>, > utt...@att.com <utt...@att.com>, jdr...@juniper.net <jdr...@juniper.net>, > Boutros, Sami <sbout...@ciena.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: [**EXTERNAL**] Re: AUTH48: RFC-to-be 9744 > <draft-ietf-bess-evpn-vpws-fxc-12> for your review > Hi Sarah, > I reviewed the changes, and I have no further comments. I approve this for >publication too. > Thank you very much Ali, Sarah for all the work. > Jorge > From: Sarah Tarrant <starr...@staff.rfc-editor.org> > Date: Thursday, March 6, 2025 at 7:10 AM > 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 > [You don't often get email from starr...@staff.rfc-editor.org. Learn why this > is important athttps://aka.ms/LearnAboutSenderIdentification [aka.ms] ] > > 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. > > > > 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 [rfc-editor.org] > https://www.rfc-editor.org/authors/rfc9744.pdf [rfc-editor.org] > https://www.rfc-editor.org/authors/rfc9744.html [rfc-editor.org] > https://www.rfc-editor.org/authors/rfc9744.xml [rfc-editor.org] > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9744-diff.html > [rfc-editor.org](comprehensive diff) > https://www.rfc-editor.org/authors/rfc9744-auth48diff.html > [rfc-editor.org](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 [rfc-editor.org] > > 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 athttps://aka.ms/LearnAboutSenderIdentification [aka.ms] ] > > > > 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 [rfc-editor.org] > > > https://www.rfc-editor.org/authors/rfc9744.pdf [rfc-editor.org] > > > https://www.rfc-editor.org/authors/rfc9744.html [rfc-editor.org] > > > https://www.rfc-editor.org/authors/rfc9744.xml [rfc-editor.org] > > > > > > The relevant diff files have been posted here (please refresh): > > > https://www.rfc-editor.org/authors/rfc9744-diff.html > > > [rfc-editor.org](comprehensive > > > diff)https://www.rfc-editor.org/authors/rfc9744-auth48diff.html > > > [rfc-editor.org] (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 [rfc-editor.org] > > > > > > 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 > > > > [rfc-editor.org]> > > > > 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/ > > > > [rfc-editor.org]). > > > > > > > > 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) [trustee.ietf.org]. > > > > > > > > * 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 [authors.ietf.org]>. > > > > > > > > * 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 > > > > [mailarchive.ietf.org] > > > > Ae6P8O4Zc > > > > > > > > * The archive itself: > > > > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > > >[mailarchive.ietf.org] > > > > > > > > * 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 [rfc-editor.org] > > > > https://www.rfc-editor.org/authors/rfc9744.html [rfc-editor.org] > > > > https://www.rfc-editor.org/authors/rfc9744.pdf [rfc-editor.org] > > > > https://www.rfc-editor.org/authors/rfc9744.txt [rfc-editor.org] > > > > > > > > Diff file of the text: > > > > https://www.rfc-editor.org/authors/rfc9744-diff.html [rfc-editor.org] > > > > https://www.rfc-editor.org/authors/rfc9744-rfcdiff.html > > > >[rfc-editor.org](side by > > > > side) > > > > > > > > Diff of the XML: > > > > https://www.rfc-editor.org/authors/rfc9744-xmldiff1.html > > > >[rfc-editor.org] > > > > > > > > > > > > Tracking progress > > > > ----------------- > > > > > > > > The details of the AUTH48 status of your document are here: > > > > https://www.rfc-editor.org/auth48/rfc9744 [rfc-editor.org] > > > > > > > > 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
