Hi James and John, We have updated your email addresses and affiliations accordingly.
Thank you, RFC Editor/st > On Mar 10, 2025, at 2:47 PM, je_dr...@yahoo.com wrote: > > Sarah, > > Would you please also change my affiliation to ‘Independent’? > > Thanks, > > John > > Sent from my iPhone > >> On Mar 10, 2025, at 12:35 PM, je_dr...@yahoo.com wrote: >> >> Thanks! >> >> Sent from my iPhone >> >>> On Mar 10, 2025, at 12:14 PM, Sarah Tarrant <starr...@staff.rfc-editor.org> >>> wrote: >>> >>> Hi John, >>> >>> We have updated your email address accordingly. >>> >>> We will await approvals from each of the parties listed at the AUTH48 >>> status page prior to moving this document forward in the publication >>> process (see https://www.rfc-editor.org/auth48/rfc9744). >>> >>> Thank you, >>> RFC Editor/st >>> >>>>> On Mar 10, 2025, at 8:37 AM, je_dr...@yahoo.com wrote: >>>> >>>> Sarah, >>>> >>>> Please update my email address in the RFC to be. >>>> >>>> Thanks, >>>> >>>> John >>>> >>>> Sent from my iPhone >>>> >>>>>> On Mar 10, 2025, at 9:34 AM, Sarah Tarrant >>>>>> <starr...@staff.rfc-editor.org> wrote: >>>>> >>>>> Hi John and Patrice, >>>>> >>>>> Thank you for your replies. We have marked your approval on the AUTH48 >>>>> status page for this document (see >>>>> https://www.rfc-editor.org/auth48/rfc9744). >>>>> >>>>> John - Apologies for this email chain from not getting to your correct >>>>> email. Would you like to have your information in the draft be updated? >>>>> Also, the entire email thread for this pending RFC can be viewed at the >>>>> IETF Mail Archive: https://mailarchive.ietf.org/arch/. >>>>> >>>>> We will await approvals from each of the parties listed at the AUTH48 >>>>> status page prior to moving this document forward in the publication >>>>> process. >>>>> >>>>> Thank you, >>>>> RFC Editor/st >>>>> >>>>>> On Mar 7, 2025, at 3:52 PM, Patrice Brissette (pbrisset) >>>>>> <pbris...@cisco.com> wrote: >>>>>> >>>>>> Hi everyone, >>>>>> The document looks very good. Thanks for the hard work from Ali and >>>>>> everyone. >>>>>> I approve it. >>>>>> Regards, >>>>>> Patrice Brissette >>>>>> Distinguished Engineer >>>>>> Cisco Systems >>>>>> From: Sarah Tarrant <starr...@staff.rfc-editor.org> >>>>>> Date: Thursday, March 6, 2025 at 10:09 >>>>>> To: Ali Sajassi (sajassi) <saja...@cisco.com>, Patrice Brissette >>>>>> (pbrisset) <pbris...@cisco.com>, utt...@att.com <utt...@att.com>, >>>>>> jdr...@juniper.net <jdr...@juniper.net>, sbout...@ciena.com >>>>>> <sbout...@ciena.com>, Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, >>>>>> Matthew Bocci (Nokia) <matthew.bo...@nokia.com> >>>>>> Cc: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>, >>>>>> rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, bess-...@ietf.org >>>>>> <bess-...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, >>>>>> slitkows.i...@gmail.com <slitkows.i...@gmail.com>, >>>>>> auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> >>>>>> Subject: Re: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> >>>>>> for your review >>>>>> Hello all, >>>>>> >>>>>> We have updated the document accordingly and have no further questions >>>>>> or comments. We will await approvals from each author prior to moving >>>>>> forward in the publication process. >>>>>> >>>>>> Please review the document carefully to ensure satisfaction as we do not >>>>>> make changes once it has been published as an RFC. Contact us with any >>>>>> further updates or with your approval of the document in its current >>>>>> form. >>>>>> >>>>>> The updated files have been posted here (please refresh): >>>>>> https://www.rfc-editor.org/authors/rfc9744.txt >>>>>> https://www.rfc-editor.org/authors/rfc9744.pdf >>>>>> https://www.rfc-editor.org/authors/rfc9744.html >>>>>> https://www.rfc-editor.org/authors/rfc9744.xml >>>>>> >>>>>> The relevant diff files have been posted here (please refresh): >>>>>> https://www.rfc-editor.org/authors/rfc9744-diff.html (comprehensive diff) >>>>>> https://www.rfc-editor.org/authors/rfc9744-auth48diff.html (AUTH48 >>>>>> changes only) >>>>>> >>>>>> Note that it may be necessary for you to refresh your browser to view >>>>>> the most recent version. >>>>>> >>>>>> For the AUTH48 status of this document, please see: >>>>>> https://www.rfc-editor.org/auth48/rfc9744 >>>>>> >>>>>> Thank you, >>>>>> RFC Editor/st >>>>>> >>>>>>>> On Mar 6, 2025, at 4:42 AM, Matthew Bocci (Nokia) >>>>>>>> <matthew.bo...@nokia.com> wrote: >>>>>>> >>>>>>> Hi Sarah, Ali >>>>>>> This looks good to me. >>>>>>> Thanks >>>>>>> Matthew >>>>>>> From: Sarah Tarrant <starr...@staff.rfc-editor.org> >>>>>>> Date: Wednesday, 5 March 2025 at 20:14 >>>>>>> To: Ali Sajassi (sajassi) <saja...@cisco.com>, Gunter van de Velde >>>>>>> (Nokia) <gunter.van_de_ve...@nokia.com>, Matthew Bocci (Nokia) >>>>>>> <matthew.bo...@nokia.com> >>>>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Patrice >>>>>>> Brissette (pbrisset) <pbris...@cisco.com>, utt...@att.com >>>>>>> <utt...@att.com>, jdr...@juniper.net <jdr...@juniper.net>, >>>>>>> sbout...@ciena.com<sbout...@ciena.com>, Jorge Rabadan (Nokia) >>>>>>> <jorge.raba...@nokia.com>,bess-...@ietf.org <bess-...@ietf.org>, >>>>>>> bess-cha...@ietf.org <bess-cha...@ietf.org>, slitkows.i...@gmail.com >>>>>>> <slitkows.i...@gmail.com>, auth48archive@rfc-editor.org >>>>>>> <auth48archive@rfc-editor.org> >>>>>>> Subject: Re: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> >>>>>>> for your review >>>>>>> [You don't often get email from starr...@staff.rfc-editor.org. Learn >>>>>>> why this is important at https://aka.ms/LearnAboutSenderIdentification ] >>>>>>> >>>>>>> CAUTION: This is an external email. Please be very careful when >>>>>>> clicking links or opening attachments. See the URL nok.it/ext for >>>>>>> additional information. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Ali, Gunter, and Matthew, >>>>>>> >>>>>>> Thank you for your replies. >>>>>>> >>>>>>> Ali - Thank you for the new proposed text. >>>>>>> >>>>>>> Gunter - Thank you for your approval of Ali's proposed text. >>>>>>> >>>>>>> Matthew - Are there any objections to Ali's proposed text and document >>>>>>> updates? We ask because Ali wrote: >>>>>>> >>>>>>>> Hi Sarah, if no objections from Matthew and Gunter, then please update >>>>>>>> the draft accordingly. >>>>>>> >>>>>>> A) >>>>>>> Original: >>>>>>> Additionally, when the remote ES fails and the PE receives the "mass >>>>>>> withdrawal" message associated with the failed ES per [RFC7432], a PE >>>>>>> device can quickly update its BGP list of available remote entries to >>>>>>> invalidate all VPWS service tunnels sharing the ESI field and achieve >>>>>>> fast convergence for multi-homing scenarios. Even if fast >>>>>>> convergence was not needed, there would still be a need for signaling >>>>>>> each AC failure (via its corresponding VPWS service tunnel) >>>>>>> associated with the failed ES so that the BGP path list for each of >>>>>>> them gets updated accordingly and the packets are sent to a backup PE >>>>>>> (in case of Single-Active multi-homing) or to other PEs in the >>>>>>> redundancy group (in case of All-Active multi-homing). In the >>>>>>> absence of updating the BGP path list, the traffic for that VPWS >>>>>>> service tunnel will be black-holed. >>>>>>> >>>>>>> Proposed: >>>>>>> Additionally, when the remote ES fails and the PE receives the "mass >>>>>>> withdrawal" message associated with the failed ES per [RFC7432], a PE >>>>>>> device can quickly update its next-hop adjacency list (adjacency list) >>>>>>> for all VPWS service tunnels sharing the ESI field and achieve >>>>>>> fast convergence for multi-homing scenarios. Even if fast >>>>>>> convergence was not needed, there would still be a need for signaling >>>>>>> each AC failure (via its corresponding VPWS service tunnel) >>>>>>> associated with the failed ES so that the adjacency list >>>>>>> gets updated and the packets are sent to a backup PE >>>>>>> (in case of Single-Active multi-homing) or to other PEs in the >>>>>>> redundancy group (in case of All-Active multi-homing). In the >>>>>>> absence of updating the adjacency list properly, the >>>>>>> traffic for that VPWS service tunnel will be dropped by the egress PE >>>>>>> with a failed ES/AC. >>>>>>> >>>>>>> B) >>>>>>> Original: >>>>>>> * Default FXC (Figure 1): In the default mode, a VLAN or AC failure >>>>>>> is not signaled. Consequently, in case of an AC failure, such as >>>>>>> VID1 on CE2, there is nothing to prevent PE3 from directing >>>>>>> traffic from CE4 to PE1, leading to a potential black hole. >>>>>>> >>>>>>> Proposed: >>>>>>> * Default FXC (Figure 1): In the default mode, a VLAN or AC failure >>>>>>> is not signaled. Consequently, in case of an AC failure, such as >>>>>>> VID1 on CE2, there is nothing to prevent PE3 from directing >>>>>>> traffic from CE4 to PE1, leading to a potential packet loss at the >>>>>>> egress >>>>>>> PE with a failed AC. >>>>>>> >>>>>>> C) >>>>>>> Replace all instances of the following terms with "adjacency list": >>>>>>> BGP list >>>>>>> BGP path list >>>>>>> path list >>>>>>> >>>>>>> Sincerely, >>>>>>> RFC Editor/st >>>>>>> >>>>>>> >>>>>>>> On Mar 5, 2025, at 1:16 PM, Ali Sajassi (sajassi) <saja...@cisco.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Thanks Gunter! >>>>>>>> Sarah, can you please update the draft based on the proposed text. >>>>>>>> Thanks very much, >>>>>>>> Ali >>>>>>>> From: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com> >>>>>>>> Date: Wednesday, March 5, 2025 at 12:09 AM >>>>>>>> To: Ali Sajassi (sajassi) <saja...@cisco.com>, Matthew Bocci (Nokia) >>>>>>>> <matthew.bo...@nokia.com>, Sarah Tarrant >>>>>>>> <starr...@staff.rfc-editor.org>, Ali Sajassi (sajassi) >>>>>>>> <sajassi=40cisco....@dmarc.ietf.org> >>>>>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Patrice >>>>>>>> Brissette (pbrisset) <pbris...@cisco.com>, utt...@att.com >>>>>>>> <utt...@att.com>, jdr...@juniper.net <jdr...@juniper.net>, >>>>>>>> sbout...@ciena.com <sbout...@ciena.com>, Jorge Rabadan (Nokia) >>>>>>>> <jorge.raba...@nokia.com>, bess-...@ietf.org <bess-...@ietf.org>, >>>>>>>> bess-cha...@ietf.org <bess-cha...@ietf.org>, slitkows.i...@gmail.com >>>>>>>> <slitkows.i...@gmail.com>, auth48archive@rfc-editor.org >>>>>>>> <auth48archive@rfc-editor.org> >>>>>>>> Subject: RE: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> >>>>>>>> for your review >>>>>>>> Ali, >>>>>>>> Thanks. This sounds good to me, and approved. It describes the failure >>>>>>>> impacts more accurately. >>>>>>>> G/ >>>>>>>> From: Ali Sajassi (sajassi) <saja...@cisco.com> >>>>>>>> Sent: Wednesday, March 5, 2025 4:44 AM >>>>>>>> To: Matthew Bocci (Nokia) <matthew.bo...@nokia.com>; Gunter van de >>>>>>>> Velde (Nokia) <gunter.van_de_ve...@nokia.com>; Sarah Tarrant >>>>>>>> <starr...@staff.rfc-editor.org>; Ali Sajassi (sajassi) >>>>>>>> <sajassi=40cisco....@dmarc.ietf.org> >>>>>>>> Cc: rfc-edi...@rfc-editor.org; Patrice Brissette (pbrisset) >>>>>>>> <pbris...@cisco.com>; utt...@att.com; jdr...@juniper.net; >>>>>>>> sbout...@ciena.com; Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>; >>>>>>>> bess-...@ietf.org; bess-cha...@ietf.org; slitkows.i...@gmail.com; >>>>>>>> auth48archive@rfc-editor.org >>>>>>>> Subject: Re: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> >>>>>>>> for your review >>>>>>>> CAUTION: This is an external email. Please be very careful when >>>>>>>> clicking links or opening attachments. See the URL nok.it/ext for >>>>>>>> additional information. >>>>>>>> Hi Matthew, Gunter: Thanks for your input. In the context of the >>>>>>>> failure scenarios that is being discussed, there won’t be a routing >>>>>>>> loop or other misrouting but rather a traffic loss (aka black hole). I >>>>>>>> think for better clarification, the term “next-hop adjacencies” needs >>>>>>>> to be used instead of “BGP path list”. So, I’d like to purpose the >>>>>>>> following changes: >>>>>>>> Hi Sarah, if no objections from Matthew and Gunter, then please update >>>>>>>> the draft accordingly. >>>>>>>> ORIGINAL#1: >>>>>>>> Additionally, when the remote ES fails and the PE receives the "mass >>>>>>>> withdrawal" message associated with the failed ES per [RFC7432], a PE >>>>>>>> device can quickly update its BGP list of available remote entries to >>>>>>>> invalidate all VPWS service tunnels sharing the ESI field and achieve >>>>>>>> fast convergence for multi-homing scenarios. Even if fast >>>>>>>> convergence was not needed, there would still be a need for signaling >>>>>>>> each AC failure (via its corresponding VPWS service tunnel) >>>>>>>> associated with the failed ES so that the BGP path list for each of >>>>>>>> them gets updated accordingly and the packets are sent to a backup PE >>>>>>>> (in case of Single-Active multi-homing) or to other PEs in the >>>>>>>> redundancy group (in case of All-Active multi-homing). In the >>>>>>>> absence of updating the BGP path list, the traffic for that VPWS >>>>>>>> service tunnel will be black-holed. >>>>>>>> PROPOSED#1: >>>>>>>> Additionally, when the remote ES fails and the PE receives the "mass >>>>>>>> withdrawal" message associated with the failed ES per [RFC7432], a PE >>>>>>>> device can quickly update its next-hop adjacency list (adjacency list) >>>>>>>> for all VPWS service tunnels sharing the ESI field and achieve >>>>>>>> fast convergence for multi-homing scenarios. Even if fast >>>>>>>> convergence was not needed, there would still be a need for signaling >>>>>>>> each AC failure (via its corresponding VPWS service tunnel) >>>>>>>> associated with the failed ES so that the adjacency list >>>>>>>> gets updated and the packets are sent to a backup PE >>>>>>>> (in case of Single-Active multi-homing) or to other PEs in the >>>>>>>> redundancy group (in case of All-Active multi-homing). In the >>>>>>>> absence of updating the adjacency list properly, the >>>>>>>> traffic for that VPWS service tunnel will be dropped by the egress >>>>>>>> PE with a failed ES/AC. >>>>>>>> >>>>>>>> ORIGINAL#2: >>>>>>>> * Default FXC (Figure 1): In the default mode, a VLAN or AC failure >>>>>>>> is not signaled. Consequently, in case of an AC failure, such as >>>>>>>> VID1 on CE2, there is nothing to prevent PE3 from directing >>>>>>>> traffic from CE4 to PE1, leading to a potential black hole. >>>>>>>> >>>>>>>> PROPOSED#2: >>>>>>>> * Default FXC (Figure 1): In the default mode, a VLAN or AC failure >>>>>>>> is not signaled. Consequently, in case of an AC failure, such as >>>>>>>> VID1 on CE2, there is nothing to prevent PE3 from directing >>>>>>>> traffic from CE4 to PE1, leading to a potential packet loss at the >>>>>>>> egress >>>>>>>> PE with a failed AC. >>>>>>>> Also please replace all instances of “BGP list” or “BGP path list” or >>>>>>>> “path list” with “adjacency list” throughout the document. >>>>>>>> Cheers, >>>>>>>> Ali >>>>>>>> From: Matthew Bocci (Nokia) <matthew.bo...@nokia.com> >>>>>>>> Date: Tuesday, March 4, 2025 at 7:02 AM >>>>>>>> To: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>, Sarah >>>>>>>> Tarrant <starr...@staff.rfc-editor.org>, Ali Sajassi (sajassi) >>>>>>>> <sajassi=40cisco....@dmarc.ietf.org> >>>>>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Patrice >>>>>>>> Brissette (pbrisset) <pbris...@cisco.com>, utt...@att.com >>>>>>>> <utt...@att.com>,jdr...@juniper.net <jdr...@juniper.net>, >>>>>>>> sbout...@ciena.com<sbout...@ciena.com>, Jorge Rabadan (Nokia) >>>>>>>> <jorge.raba...@nokia.com>, Ali Sajassi (sajassi) <saja...@cisco.com>, >>>>>>>> bess-...@ietf.org <bess-...@ietf.org>, bess-cha...@ietf.org >>>>>>>> <bess-cha...@ietf.org>,slitkows.i...@gmail.com >>>>>>>> <slitkows.i...@gmail.com>, auth48archive@rfc-editor.org >>>>>>>> <auth48archive@rfc-editor.org> >>>>>>>> Subject: Re: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> >>>>>>>> for your review >>>>>>>> I am not sure “pathologies” is the right word here. Can I suggest >>>>>>>> rephrasing that sentence to “potential routing loops or other >>>>>>>> conditions where traffic is unintentionally misrouted or discarded.” >>>>>>>> Matthew >>>>>>>> From: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com> >>>>>>>> Date: Tuesday, 4 March 2025 at 12:37 >>>>>>>> To: Sarah Tarrant <starr...@staff.rfc-editor.org>, Ali Sajassi >>>>>>>> (sajassi) <sajassi=40cisco....@dmarc.ietf.org> >>>>>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Patrice >>>>>>>> Brissette (pbrisset) <pbris...@cisco.com>, utt...@att.com >>>>>>>> <utt...@att.com>,jdr...@juniper.net <jdr...@juniper.net>, >>>>>>>> sbout...@ciena.com<sbout...@ciena.com>, Jorge Rabadan (Nokia) >>>>>>>> <jorge.raba...@nokia.com>, Ali Sajassi (sajassi) <saja...@cisco.com>, >>>>>>>> bess-...@ietf.org <bess-...@ietf.org>, bess-cha...@ietf.org >>>>>>>> <bess-cha...@ietf.org>,slitkows.i...@gmail.com >>>>>>>> <slitkows.i...@gmail.com>, auth48archive@rfc-editor.org >>>>>>>> <auth48archive@rfc-editor.org> >>>>>>>> Subject: RE: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> >>>>>>>> for your review >>>>>>>> Hi All, >>>>>>>> >>>>>>>>> For example, please consider whether the following should be updated: >>>>>>>>> >>>>>>>>> black hole >>>>>>>>> block-holed >>>>>>>>> --> >>>>>>>>> Ali> I would prefer “black hole” and “black holed” >>>>>>>> >>>>>>>> Aloi, All, From an inclusiveness language would the following work? >>>>>>>> >>>>>>>> ORIGINAL#1: >>>>>>>> In the >>>>>>>> absence of updating the BGP path list, the traffic for that VPWS >>>>>>>> service tunnel will be black-holed. >>>>>>>> >>>>>>>> PROPOSED#1: >>>>>>>> In the >>>>>>>> absence of updating the BGP path list, the traffic for that VPWS >>>>>>>> service tunnel will ***suffer from routing loops, misrouting or other >>>>>>>> pathologies***. >>>>>>>> >>>>>>>> ORIGINAL#2: >>>>>>>> * Default FXC (Figure 1): In the default mode, a VLAN or AC failure >>>>>>>> is not signaled. Consequently, in case of an AC failure, such as >>>>>>>> VID1 on CE2, there is nothing to prevent PE3 from directing >>>>>>>> traffic from CE4 to PE1, leading to a potential black hole. >>>>>>>> >>>>>>>> PROPOSED#2: >>>>>>>> * Default FXC (Figure 1): In the default mode, a VLAN or AC failure >>>>>>>> is not signaled. Consequently, in case of an AC failure, such as >>>>>>>> VID1 on CE2, there is nothing to prevent PE3 from directing >>>>>>>> traffic from CE4 to PE1, leading to ***potential routing loops, >>>>>>>> misrouting or other pathologies***. >>>>>>>> >>>>>>>> G/ >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Sarah Tarrant <starr...@staff.rfc-editor.org> >>>>>>>> Sent: Monday, March 3, 2025 6:08 PM >>>>>>>> To: Ali Sajassi (sajassi) <sajassi=40cisco....@dmarc.ietf.org> >>>>>>>> Cc: rfc-edi...@rfc-editor.org; Patrice Brissette (pbrisset) >>>>>>>> <pbris...@cisco.com>;utt...@att.com; jdr...@juniper.net; >>>>>>>> sbout...@ciena.com; Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>; >>>>>>>> Ali Sajassi (sajassi) <saja...@cisco.com>; bess-...@ietf.org; >>>>>>>> bess-cha...@ietf.org; slitkows.i...@gmail.com; Gunter van de Velde >>>>>>>> (Nokia) <gunter.van_de_ve...@nokia.com>; auth48archive@rfc-editor.org >>>>>>>> Subject: Re: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> >>>>>>>> for your review >>>>>>>> >>>>>>>> >>>>>>>> CAUTION: This is an external email. Please be very careful when >>>>>>>> clicking links or opening attachments. See the URL nok.it/ext for >>>>>>>> additional information. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Ali, >>>>>>>> >>>>>>>> Thank you for your reply. We have updated the document accordingly. >>>>>>>> >>>>>>>> Please review the document carefully to ensure satisfaction as we do >>>>>>>> not make changes once it has been published as an RFC. Contact us with >>>>>>>> any further updates or with your approval of the document in its >>>>>>>> current form. We will await approvals from each author prior to moving >>>>>>>> forward in the publication process. >>>>>>>> >>>>>>>> The updated files have been posted here (please refresh): >>>>>>>> https://www.rfc-editor.org/authors/rfc9744.txt >>>>>>>> https://www.rfc-editor.org/authors/rfc9744.pdf >>>>>>>> https://www.rfc-editor.org/authors/rfc9744.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9744.xml >>>>>>>> >>>>>>>> The relevant diff files have been posted here (please refresh): >>>>>>>> https://www.rfc-editor.org/authors/rfc9744-diff.html (comprehensive >>>>>>>> diff)https://www.rfc-editor.org/authors/rfc9744-auth48diff.html >>>>>>>> (AUTH48 changes only) >>>>>>>> >>>>>>>> Note that it may be necessary for you to refresh your browser to view >>>>>>>> the most recent version. >>>>>>>> >>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>> https://www.rfc-editor.org/auth48/rfc9744 >>>>>>>> >>>>>>>> Thank you, >>>>>>>> RFC Editor/st >>>>>>>> >>>>>>>>> On Feb 28, 2025, at 12:01 AM, Ali Sajassi (sajassi) >>>>>>>>> <sajassi=40cisco....@dmarc.ietf.org> wrote: >>>>>>>>> >>>>>>>>> Dear RFC-Editor, >>>>>>>>> Thanks you for your recommendations, please refer to my comments >>>>>>>>> inline marked with “Ali>” . Once they are incorporated, I will be >>>>>>>>> happy to approve it. >>>>>>>>> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> >>>>>>>>> Date: Wednesday, February 26, 2025 at 2:41 PM >>>>>>>>> To: Ali Sajassi (sajassi) <saja...@cisco.com>, Patrice Brissette >>>>>>>>> (pbrisset) <pbris...@cisco.com>, utt...@att.com <utt...@att.com>, >>>>>>>>> jdr...@juniper.net<jdr...@juniper.net>, sbout...@ciena.com >>>>>>>>> <sbout...@ciena.com>, jorge.raba...@nokia.com >>>>>>>>> <jorge.raba...@nokia.com> >>>>>>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, >>>>>>>>> bess-...@ietf.org<bess-...@ietf.org>, bess-cha...@ietf.org >>>>>>>>> <bess-cha...@ietf.org>, slitkows.i...@gmail.com >>>>>>>>> <slitkows.i...@gmail.com>, gunter.van_de_ve...@nokia.com >>>>>>>>> <gunter.van_de_ve...@nokia.com>,auth48archive@rfc-editor.org >>>>>>>>> <auth48archive@rfc-editor.org> >>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9744 <draft-ietf-bess-evpn-vpws-fxc-12> >>>>>>>>> for your review Authors, >>>>>>>>> >>>>>>>>> While reviewing this document during AUTH48, please resolve (as >>>>>>>>> necessary) the following questions, which are also in the XML file. >>>>>>>>> >>>>>>>>> 1) <!-- [rfced] Please note that the title of the document has been >>>>>>>>> updated as follows. Abbreviations have been expanded per Section 3.6 >>>>>>>>> of RFC 7322 ("RFC Style Guide"). Please review. >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> EVPN VPWS Flexible Cross-Connect Service >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> EVPN Virtual Private Wire Service (VPWS) Flexible Cross-Connect (FXC) >>>>>>>>> Service >>>>>>>>> --> >>>>>>>>> Ali> That’ fine. >>>>>>>>> >>>>>>>>> >>>>>>>>> 2) <!-- [rfced] We're having trouble understanding "can designate on" >>>>>>>>> in the text below. Should this be updated to "can designate"? >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> [RFC8214] describes a solution to deliver P2P services using BGP >>>>>>>>> constructs defined in [RFC7432]. It delivers this P2P service >>>>>>>>> between a pair of Attachment Circuits (ACs), where an AC can >>>>>>>>> designate on a PE, a port, a VLAN on a port, or a group of VLANs on a >>>>>>>>> port. >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> [RFC8214] describes a solution to deliver P2P services using BGP >>>>>>>>> constructs defined in [RFC7432]. It delivers this P2P service >>>>>>>>> between a pair of Attachment Circuits (ACs), where an AC can >>>>>>>>> designate a PE, a port, a VLAN on a port, or a group of VLANs on a >>>>>>>>> port. >>>>>>>>> --> >>>>>>>>> Ali> It should be changed to “…, where an AC on a PE can represent a >>>>>>>>> port, a VLAN on a port, or a group of VLANs on a port.” >>>>>>>>> >>>>>>>>> 3) <!--[rfced] To have a 1:1 matchup between the following >>>>>>>>> abbreviations and their expansions, may we update as follows? >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> Ethernet A-D: Ethernet Auto-Discovery (A-D) per EVI and Ethernet A-D >>>>>>>>> per ESI routes, as defined in [RFC7432] and [RFC8214]. >>>>>>>>> ... >>>>>>>>> PE: Provider Edge device >>>>>>>>> ... >>>>>>>>> VRF: VPN Routing and Forwarding table >>>>>>>>> ... >>>>>>>>> IP-VRF: VPN Routing and Forwarding table, for IP lookup >>>>>>>>> ... >>>>>>>>> MAC-VRF: VPN Routing and Forwarding table, for MAC lookup >>>>>>>>> ... >>>>>>>>> VID-VRF: VPN Routing and Forwarding table, for Normalized VID >>>>>>>>> lookup >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> Ethernet A-D: Ethernet Auto-Discovery (per EVI and per ESI routes, >>>>>>>>> as defined in [RFC7432] and [RFC8214]) >>>>>>>>> Ali> also use “or” instead of “and”: “ Ethernet A-D: Ethernet >>>>>>>>> Auto-Discovery (per EVI or per ESI routes, as defined in [RFC7432] >>>>>>>>> and [RFC8214])” >>>>>>>>> ... >>>>>>>>> PE: Provider Edge >>>>>>>>> ... >>>>>>>>> VRF: VPN Routing and Forwarding >>>>>>>>> ... >>>>>>>>> IP-VRF: VPN Routing and Forwarding for IP lookup >>>>>>>>> >>>>>>>>> MAC-VRF: VPN Routing and Forwarding for MAC lookup >>>>>>>>> >>>>>>>>> VID-VRF: VPN Routing and Forwarding for normalized VID lookup >>>>>>>>> --> >>>>>>>>> >>>>>>>>> >>>>>>>>> 4) <!-- [rfced] We were unable to find exactly "12-bit VPWS service >>>>>>>>> instance identifiers" in [RFC8214]. We did find the following in >>>>>>>>> Section 3 of [RFC8214]: >>>>>>>>> >>>>>>>>> The VPWS service instance identifier value MAY be set to a 24-bit >>>>>>>>> value, >>>>>>>>> and when a 24-bit value is used, it MUST be right-aligned. >>>>>>>>> >>>>>>>>> For a more accurate citation, may we update to something like the >>>>>>>>> following? >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> As stated in [RFC8214], 12-bit and 24-bit VPWS service instance >>>>>>>>> identifiers >>>>>>>>> representing normalized VIDs MUST be right-aligned. >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> 24-bit VPWS service instance identifiers [RFC8214] as well as 12-bit >>>>>>>>> VPWS service instance identifiers representing normalized VIDs MUST >>>>>>>>> be right-aligned. >>>>>>>>> --> >>>>>>>>> Ali> That’s fine. >>>>>>>>> >>>>>>>>> 5) <!--[rfced] To clarify the numbered list, we have updated this >>>>>>>>> sentence in Section 3.2. Please review and ensure that the intended >>>>>>>>> meaning has not changed. Note that we have made a similar update to a >>>>>>>>> sentence in Section 3.3. >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> Additionally, this route >>>>>>>>> is sent with the EVPN Layer-2 Extended Community defined in >>>>>>>>> Section 3.1 of [RFC8214] with two new flags (outlined in Section 4) >>>>>>>>> that indicate: 1) this VPWS service tunnel is for the default >>>>>>>>> Flexible Cross-Connect, and 2) the normalized VID type (single versus >>>>>>>>> double). >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> Additionally, this route >>>>>>>>> is sent with the EVPN Layer 2 Extended Community defined in >>>>>>>>> Section 3.1 of [RFC8214] with two new flags (outlined in Section 4) >>>>>>>>> that indicate: 1) this VPWS service tunnel for the default >>>>>>>>> Flexible Cross-Connect and 2) the normalized VID type (single versus >>>>>>>>> double). >>>>>>>>> --> >>>>>>>>> Ali> Please change it to: “… 1) the VPW service tunnel (set to >>>>>>>>> default Flexible Cross-Connect) and 2) the normalized VID type (set >>>>>>>>> to normalized single-VID or double-VID)” >>>>>>>>> >>>>>>>>> >>>>>>>>> 6) <!--[rfced] Please note that a slash (/) can mean "and", "or", or >>>>>>>>> "and/or". >>>>>>>>> We have updated it to "and" in the text below for clarity. Please >>>>>>>>> review and let us know if any further updates are needed. >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> In this mode of operation, similar to the default FXC mode described >>>>>>>>> in Section 3.2, many normalized VIDs representing ACs across several >>>>>>>>> Ethernet Segments/interfaces are multiplexed into a single EVPN VPWS >>>>>>>>> service tunnel. >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> In this mode of operation, similar to the default FXC mode described >>>>>>>>> in Section 3.2, many normalized VIDs representing ACs across several >>>>>>>>> Ethernet Segments and interfaces are multiplexed into a single EVPN >>>>>>>>> VPWS >>>>>>>>> service tunnel. >>>>>>>>> --> >>>>>>>>> Ali> That’s fine. >>>>>>>>> >>>>>>>>> >>>>>>>>> 7) <!--[rfced] May we remove "service" after "FXC" in the following >>>>>>>>> sentence? >>>>>>>>> Additionally, please note that we have numbered the items listed to >>>>>>>>> improve readability. >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> However, only two VPWS >>>>>>>>> Service Tunnels are required: VPWS Service Tunnel 1 (sv.T1) between >>>>>>>>> PE1's FXC service and PE3's FXC, and VPWS Service Tunnel 2 (sv.T2) >>>>>>>>> between PE2's FXC and PE3's FXC. >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> However, only two VPWS >>>>>>>>> Service Tunnels are required: 1) VPWS Service Tunnel 1 (sv.T1) between >>>>>>>>> PE1's FXC and PE3's FXC and 2) VPWS Service Tunnel 2 (sv.T2) >>>>>>>>> between PE2's FXC and PE3's FXC. >>>>>>>>> --> >>>>>>>>> Ali> That’s fine. >>>>>>>>> >>>>>>>>> >>>>>>>>> 8) <!--[rfced] May we update the following acronyms and their >>>>>>>>> expansions to better reflect the text in RFC 5885? >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> The failure detection of an EVPN VPWS service can be performed via >>>>>>>>> OAM mechanisms such as VCCV-BFD (Bidirectional Forwarding Detection >>>>>>>>> for the Pseudowire Virtual Circuit Connectivity Verification, >>>>>>>>> [RFC5885]) and upon such failure detection, the switch over procedure >>>>>>>>> to the backup S-PE is the same as the one described above. >>>>>>>>> >>>>>>>>> Perhaps: >>>>>>>>> The failure detection of an EVPN VPWS service can be performed via >>>>>>>>> OAM mechanisms such as Bidirectional Forwarding Detection (BFD) >>>>>>>>> for the pesudowire Virtual Circuit Connectivity Verification (VCCV) >>>>>>>>> [RFC5885], and upon such failure detection, the switch over procedure >>>>>>>>> to the backup S-PE is the same as the one described above. >>>>>>>>> --> >>>>>>>>> Ali> That’s fine. >>>>>>>>> >>>>>>>>> >>>>>>>>> 9) <!-- [rfced] Terminology >>>>>>>>> >>>>>>>>> A) To match usage in RFC 8214, may we update the following terms to >>>>>>>>> the format on the right? >>>>>>>>> >>>>>>>>> single-active > Single-Active >>>>>>>>> all-active > All-Active >>>>>>>>> EVPN VPWS > EVPN-VPWS >>>>>>>>> Ethernet A-D per EVI route > Ethernet A-D per-EVI route Ethernet A-D >>>>>>>>> per ES route > Ethernet A-D per-ES route VLAN-bundle > VLAN bundle >>>>>>>>> Ali> Please do so. >>>>>>>>> >>>>>>>>> >>>>>>>>> B) Throughout the text, the following terminology appears to be used >>>>>>>>> inconsistently. May we update them to the format on the right? >>>>>>>>> >>>>>>>>> Normalized VID > normalized VID >>>>>>>>> VLAN-signaled flexible cross-connect > VLAN-signaled FXC VLAN-signaled >>>>>>>>> Flexible Cross-Connect > VLAN-signaled FXC >>>>>>>>> Ali> Please do so. >>>>>>>>> >>>>>>>>> >>>>>>>>> C) Since RFC 8214 uses "EVPN Layer 2 Attributes Extended Community", >>>>>>>>> should the following terms be update to match? We ask because of the >>>>>>>>> possible addition of "Attributes". >>>>>>>>> >>>>>>>>> EVPN Layer 2 Extended Community (Sections 3.2 and 3.3) EVPN Layer 2 >>>>>>>>> attribute extended community (Section 4) >>>>>>>>> --> >>>>>>>>> Ali> Please update to match RFC 8214. >>>>>>>>> >>>>>>>>> 10) <!--[rfced] Abbreviations >>>>>>>>> >>>>>>>>> A) FYI - We have added expansions for the following abbreviations per >>>>>>>>> Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >>>>>>>>> expansion in the document carefully to ensure correctness. >>>>>>>>> >>>>>>>>> Autonomous System (AS) >>>>>>>>> Switching Provider Edge (S-PE) >>>>>>>>> Ali> Please change S-PE to PE. I don’t think you need to expand PE >>>>>>>>> as it has been used many times previously. >>>>>>>>> >>>>>>>>> B) Both the expansion and the acronym for Ethernet Segment (ES) are >>>>>>>>> used throughout the document. Would you like to update to using the >>>>>>>>> expansion upon first usage and the acronym for the rest of the >>>>>>>>> document for consistency? >>>>>>>>> Ali> Please do so. >>>>>>>>> >>>>>>>>> >>>>>>>>> C) We note that "FXC" appears to be expanded in different ways >>>>>>>>> throughout the document. May we update all these instances to be >>>>>>>>> "Flexible Cross-Connect" >>>>>>>>> for consistency? >>>>>>>>> >>>>>>>>> Flexible Xconnect >>>>>>>>> Flexible Cross Connect >>>>>>>>> Flexible Cross-Connect >>>>>>>>> Ali> Please do so. >>>>>>>>> >>>>>>>>> >>>>>>>>> D) We note that "VCCV" is expaned in two different ways in this >>>>>>>>> document. >>>>>>>>> Please review and let us know which version should be updated for >>>>>>>>> consistency. >>>>>>>>> >>>>>>>>> Virtual Circuit Connectivity Verification Virtual Circuit Connection >>>>>>>>> Verification >>>>>>>>> --> >>>>>>>>> Ali> The top one – ie., Virtual Circuit Connectivity Verification >>>>>>>>> >>>>>>>>> 11) <!-- [rfced] Please review the "Inclusive Language" portion of the >>>>>>>>> online Style Guide >>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>>>>>>>> and let us know if any changes are needed. Updates of this nature >>>>>>>>> typically result in more precise language, which is helpful for >>>>>>>>> readers. >>>>>>>>> >>>>>>>>> For example, please consider whether the following should be updated: >>>>>>>>> >>>>>>>>> black hole >>>>>>>>> block-holed >>>>>>>>> --> >>>>>>>>> Ali> I would prefer “black hole” and “black holed” >>>>>>>>> Regards, >>>>>>>>> Ali >>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you. >>>>>>>>> >>>>>>>>> RFC Editor/st/ap >>>>>>>>> >>>>>>>>> >>>>>>>>> On Feb 26, 2025, at 2:29 PM, rfc-edi...@rfc-editor.org wrote: >>>>>>>>> >>>>>>>>> *****IMPORTANT***** >>>>>>>>> >>>>>>>>> Updated 2025/02/26 >>>>>>>>> >>>>>>>>> RFC Author(s): >>>>>>>>> -------------- >>>>>>>>> >>>>>>>>> Instructions for Completing AUTH48 >>>>>>>>> >>>>>>>>> Your document has now entered AUTH48. Once it has been reviewed and >>>>>>>>> approved by you and all coauthors, it will be published as an RFC. >>>>>>>>> If an author is no longer available, there are several remedies >>>>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>>>>>>>> >>>>>>>>> You and you coauthors are responsible for engaging other parties >>>>>>>>> (e.g., Contributors or Working Group) as necessary before providing >>>>>>>>> your approval. >>>>>>>>> >>>>>>>>> Planning your review >>>>>>>>> --------------------- >>>>>>>>> >>>>>>>>> Please review the following aspects of your document: >>>>>>>>> >>>>>>>>> * RFC Editor questions >>>>>>>>> >>>>>>>>> Please review and resolve any questions raised by the RFC Editor >>>>>>>>> that have been included in the XML file as comments marked as >>>>>>>>> follows: >>>>>>>>> >>>>>>>>> <!-- [rfced] ... --> >>>>>>>>> >>>>>>>>> These questions will also be sent in a subsequent email. >>>>>>>>> >>>>>>>>> * Changes submitted by coauthors >>>>>>>>> >>>>>>>>> Please ensure that you review any changes submitted by your >>>>>>>>> coauthors. We assume that if you do not speak up that you >>>>>>>>> agree to changes submitted by your coauthors. >>>>>>>>> >>>>>>>>> * Content >>>>>>>>> >>>>>>>>> Please review the full content of the document, as this cannot >>>>>>>>> change once the RFC is published. Please pay particular attention to: >>>>>>>>> - IANA considerations updates (if applicable) >>>>>>>>> - contact information >>>>>>>>> - references >>>>>>>>> >>>>>>>>> * Copyright notices and legends >>>>>>>>> >>>>>>>>> Please review the copyright notice and legends as defined in >>>>>>>>> RFC 5378 and the Trust Legal Provisions >>>>>>>>> (TLP – https://trustee.ietf.org/license-info). >>>>>>>>> >>>>>>>>> * Semantic markup >>>>>>>>> >>>>>>>>> Please review the markup in the XML file to ensure that elements of >>>>>>>>> content are correctly tagged. For example, ensure that <sourcecode> >>>>>>>>> and <artwork> are set correctly. See details at >>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>. >>>>>>>>> >>>>>>>>> * Formatted output >>>>>>>>> >>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>>>>>> formatted output, as generated from the markup in the XML file, is >>>>>>>>> reasonable. Please note that the TXT will have formatting >>>>>>>>> limitations compared to the PDF and HTML. >>>>>>>>> >>>>>>>>> >>>>>>>>> Submitting changes >>>>>>>>> ------------------ >>>>>>>>> >>>>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>>>>>>>> the parties CCed on this message need to see your changes. The parties >>>>>>>>> include: >>>>>>>>> >>>>>>>>> * your coauthors >>>>>>>>> >>>>>>>>> * rfc-edi...@rfc-editor.org (the RPC team) >>>>>>>>> >>>>>>>>> * other document participants, depending on the stream (e.g., >>>>>>>>> IETF Stream participants are your working group chairs, the >>>>>>>>> responsible ADs, and the document shepherd). >>>>>>>>> >>>>>>>>> * auth48archive@rfc-editor.org, which is a new archival mailing list >>>>>>>>> to preserve AUTH48 conversations; it is not an active discussion >>>>>>>>> list: >>>>>>>>> >>>>>>>>> * More info: >>>>>>>>> >>>>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxI >>>>>>>>> Ae6P8O4Zc >>>>>>>>> >>>>>>>>> * The archive itself: >>>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>>>>>>> >>>>>>>>> * Note: If only absolutely necessary, you may temporarily opt out >>>>>>>>> of the archiving of messages (e.g., to discuss a sensitive matter). >>>>>>>>> If needed, please add a note at the top of the message that you >>>>>>>>> have dropped the address. When the discussion is concluded, >>>>>>>>> auth48archive@rfc-editor.org will be re-added to the CC list and >>>>>>>>> its addition will be noted at the top of the message. >>>>>>>>> >>>>>>>>> You may submit your changes in one of two ways: >>>>>>>>> >>>>>>>>> An update to the provided XML file >>>>>>>>> — OR — >>>>>>>>> An explicit list of changes in this format >>>>>>>>> >>>>>>>>> Section # (or indicate Global) >>>>>>>>> >>>>>>>>> OLD: >>>>>>>>> old text >>>>>>>>> >>>>>>>>> NEW: >>>>>>>>> new text >>>>>>>>> >>>>>>>>> You do not need to reply with both an updated XML file and an explicit >>>>>>>>> list of changes, as either form is sufficient. >>>>>>>>> >>>>>>>>> We will ask a stream manager to review and approve any changes that >>>>>>>>> seem beyond editorial in nature, e.g., addition of new text, deletion >>>>>>>>> of text, and technical changes. Information about stream managers can >>>>>>>>> be found in the FAQ. Editorial changes do not require approval from >>>>>>>>> a stream manager. >>>>>>>>> >>>>>>>>> >>>>>>>>> Approving for publication >>>>>>>>> -------------------------- >>>>>>>>> >>>>>>>>> To approve your RFC for publication, please reply to this email >>>>>>>>> stating that you approve this RFC for publication. Please use ‘REPLY >>>>>>>>> ALL’, as all the parties CCed on this message need to see your >>>>>>>>> approval. >>>>>>>>> >>>>>>>>> >>>>>>>>> Files >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> The files are available here: >>>>>>>>> https://www.rfc-editor.org/authors/rfc9744.xml >>>>>>>>> https://www.rfc-editor.org/authors/rfc9744.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9744.pdf >>>>>>>>> https://www.rfc-editor.org/authors/rfc9744.txt >>>>>>>>> >>>>>>>>> Diff file of the text: >>>>>>>>> https://www.rfc-editor.org/authors/rfc9744-diff.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9744-rfcdiff.html (side by >>>>>>>>> side) >>>>>>>>> >>>>>>>>> Diff of the XML: >>>>>>>>> https://www.rfc-editor.org/authors/rfc9744-xmldiff1.html >>>>>>>>> >>>>>>>>> >>>>>>>>> Tracking progress >>>>>>>>> ----------------- >>>>>>>>> >>>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>>> https://www.rfc-editor.org/auth48/rfc9744 >>>>>>>>> >>>>>>>>> Please let us know if you have any questions. >>>>>>>>> >>>>>>>>> Thank you for your cooperation, >>>>>>>>> >>>>>>>>> RFC Editor >>>>>>>>> >>>>>>>>> -------------------------------------- >>>>>>>>> RFC9744 (draft-ietf-bess-evpn-vpws-fxc-12) >>>>>>>>> >>>>>>>>> Title : EVPN VPWS Flexible Cross-Connect Service >>>>>>>>> Author(s) : A. Sajassi, P. Brissette, J. Uttaro, J. Drake, S. >>>>>>>>> Boutros, J. Rabadan >>>>>>>>> WG Chair(s) : Matthew Bocci, Stephane Litkowski, Zhaohui >>>>>>>>> (Jeffrey) Zhang >>>>>>>>> >>>>>>>>> Area Director(s) : Jim Guichard, John Scudder, Gunter Van de Velde >>>>>>>>> >>>>> >>>>> >>>> >>> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org