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
