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
