Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9574 <draft-ietf-bess-evpn-optimized-ir-12> for your review

["Jorge Rabadan (Nokia)" <[e-mail]>]

Hi Lynne,

Thanks very much.
About this:

“>> We are not sure whether or not to remove the hyphens.  Would "To WAN" and OIF to G1" be correct in the figure, or would they change your intended meaning?
> [jorge2] it does not change the intended meaning, so you can remove the hyphens if you prefer that way.
In Figure 1, we changed "OIF to-G" to "OIF to G".  Should these be "OIF to G1"?  In other words, it's still not clear to us what "G" is as opposed to "G1".  Do G and G1 mean the same thing?  If not, will the distinction be clear to readers?”


Sorry, I should have been more specific – they should be “OIF to G1”.

Thanks!
Jorge



From: Lynne Bartholomew <[e-mail]>
Date: Tuesday, April 16, 2024 at 9:14 AM
To: Jorge Rabadan (Nokia) <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, Senthil Sathappan (Nokia) <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Matthew Bocci (Nokia) <[e-mail]>, [e-mail] <[e-mail]>
Subject: *[AD] Re: AUTH48: RFC-to-be 9574 <draft-ietf-bess-evpn-optimized-ir-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, Jorge and *AD (Gunter).

Jorge, thank you again for another quick reply!  We have further updated this document per your notes below.**

* Gunter, although it seems clear that the update to Section 6 (changing "two-hop" to "single-hop" is fine, because we are not subject-matter experts and the update could be considered "beyond editorial" by some, we need to err on the side of caution and ask you to quickly review the update and let us know if you approve.

** Jorge, regarding this item:

>> 5) <!-- [rfced] Figure 1:  Should the three instances of "to-G" be
>> > "to G1", in which case perhaps we should also change "To-WAN" to
>> > "To WAN")?  (in other words, do these hyphenated entries mean
>> > "(from the) OIF to G" and "To (the) WAN"?
>> >
>> > Original:
>> >  To-WAN
>> > ...
>> >  OIF to-G ... -->
>> > [jorge] the suggestion is correct, thanks (OIF to-G and To-WAN)
>>
>> We are not sure whether or not to remove the hyphens.  Would "To WAN" and OIF to G1" be correct in the figure, or would they change your intended meaning?
> [jorge2] it does not change the intended meaning, so you can remove the hyphens if you prefer that way.

In Figure 1, we changed "OIF to-G" to "OIF to G".  Should these be "OIF to G1"?  In other words, it's still not clear to us what "G" is as opposed to "G1".  Do G and G1 mean the same thing?  If not, will the distinction be clear to readers?

The latest files are posted here.  Please refresh your browser:

   https://www.rfc-editor.org/authors/rfc9574.txt
   https://www.rfc-editor.org/authors/rfc9574.pdf
   https://www.rfc-editor.org/authors/rfc9574.html
   https://www.rfc-editor.org/authors/rfc9574.xml
   https://www.rfc-editor.org/authors/rfc9574-diff.html
   https://www.rfc-editor.org/authors/rfc9574-rfcdiff.html
   https://www.rfc-editor.org/authors/rfc9574-auth48diff.html
   https://www.rfc-editor.org/authors/rfc9574-lastdiff.html
   https://www.rfc-editor.org/authors/rfc9574-lastrfcdiff.html

   https://www.rfc-editor.org/authors/rfc9574-xmldiff1.html
   https://www.rfc-editor.org/authors/rfc9574-xmldiff2.html

Thanks again!

RFC Editor/lb


> On Apr 15, 2024, at 12:38 PM, Jorge Rabadan (Nokia) <[e-mail]> wrote:
>
> Hi Lynne,
>  Thanks!
> I read the entire text and found a small issue in section 6, that is fixed as follows, since AR-LEAFs of the same set create single-hop trees (AR-LEAF->AR-REPLICATOR->AR-LEAF):
>  ------
> OLD:
> Compared to the selective solution, the non-selective AR method assumes that all the AR-LEAFs of the BD are in the same set and always creates two-hop trees among AR-LEAFs.
>  NEW:
> Compared to the selective solution, the non-selective AR method assumes that all the AR-LEAFs of the BD are in the same set and always creates single-hop trees among AR-LEAFs.
> ------
>  Other than that, please see my replies to your questions below, in-line with [jorge2].
>   From: Lynne Bartholomew <[e-mail]>
> Date: Monday, April 15, 2024 at 10:44 AM
> To: Jorge Rabadan (Nokia) <[e-mail]>
> Cc: [e-mail] <[e-mail]>, Senthil Sathappan (Nokia) <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Matthew Bocci (Nokia) <[e-mail]>, [e-mail] <[e-mail]>
> Subject: Re: AUTH48: RFC-to-be 9574 <draft-ietf-bess-evpn-optimized-ir-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.
>
>
>
> Dear Jorge,
>
> Thank you very much for your answers to our questions!
>
> We have three follow-up items for you.
>
> Regarding this question and your reply:
>
> > 5) <!-- [rfced] Figure 1:  Should the three instances of "to-G" be
> > "to G1", in which case perhaps we should also change "To-WAN" to
> > "To WAN")?  (in other words, do these hyphenated entries mean
> > "(from the) OIF to G" and "To (the) WAN"?
> >
> > Original:
> >  To-WAN
> > ...
> >  OIF to-G ... -->
> > [jorge] the suggestion is correct, thanks (OIF to-G and To-WAN)
>
> We are not sure whether or not to remove the hyphens.  Would "To WAN" and OIF to G1" be correct in the figure, or would they change your intended meaning?
> [jorge2] it does not change the intended meaning, so you can remove the hyphens if you prefer that way.
>
>
> = = = = =
>
> Regarding this question and your reply:
>
> > 25) <!-- [rfced] Section 6.2:  As the original text seemed to indicate
> > that the AR-LEAF should wait for a timer, we updated the text to
> > indicate that the AR-LEAF should wait for some interval to pass.  If
> > this is incorrect, please provide clarifying text (e.g., are some
> > words missing?).
> >
> > Original:
> >  It is RECOMMENDED that the Selective AR-LEAF waits for an AR-
> >  LEAF-join-wait-timer (in seconds, default value is 3) before
> >  sending the Leaf Auto-Discovery route, so that the AR-LEAF can
> >  collect all the Replicator-AR routes for the BD before
> >  advertising the Leaf Auto-Discovery route.
> >
> > Currently:
> >  It is
> >  RECOMMENDED that the Selective AR-LEAF wait for a period
> >  specified by an AR-LEAF-join-wait-timer (in seconds, with a
> >  default value of 3) before sending the Leaf A-D route, so that
> >  the AR-LEAF can collect all the Replicator-AR routes for the BD
> >  before advertising the Leaf A-D route. -->
> > [jorge] the suggested text is good. Shouldn’t it be “AR-LEAF waits” instead of “AR-LEAF wait”?
>
> We had applied what is called "subjunctive mood" here and also in the third sentence of the third bullet under item c. in Section 6.2.  Subjunctive mood is commonly used in RFCs, but it is not required.  Please let us know if you would prefer that we not use it.
> [jorge2] ah ok, that’s fine, if it is common in RFCs we should of course use it, you are the editor!
>
>
> = = = = =
>
> Regarding this item from our question 32)b) and your reply:
>
> >  T (AR role type) (2 instances) /
> >    T (Assisted-Replication type) (1 instance)
> > [jorge]  T (AR role type)
>
> Apologies for not spotting this earlier:  We see "T" mostly defined as "Assisted Replication Type".  For example:
>
> T = Assisted Replication Type (Figure 3)
> Assisted Replication Type (T) field  (first bullet below Figure 3)
> Assisted Replication Type (T) (Table 2)
> T is the Assisted Replication Type field (fourth bullet below Figure 3)
> the T (Assisted Replication type) field (later in Section 4)
> the Assisted Replication Type field (3 instances)
>
> Per <https://www.iana.org/assignments/bgp-parameters/>, we suggest changing "T (AR role type)" to "T (Assisted Replication type)".  Again, apologies for missing this earlier.
> [jorge2] I’m good with the suggestion then.
> Thank you!
> Jorge
>
>
> = = = = =
>
> The latest files are posted here.  Please refresh your browser:
>
>    https://www.rfc-editor.org/authors/rfc9574.txt
>    https://www.rfc-editor.org/authors/rfc9574.pdf
>    https://www.rfc-editor.org/authors/rfc9574.html
>    https://www.rfc-editor.org/authors/rfc9574.xml
>    https://www.rfc-editor.org/authors/rfc9574-diff.html
>    https://www.rfc-editor.org/authors/rfc9574-rfcdiff.html
>    https://www.rfc-editor.org/authors/rfc9574-auth48diff.html
>
>    https://www.rfc-editor.org/authors/rfc9574-xmldiff1.html
>    https://www.rfc-editor.org/authors/rfc9574-xmldiff2.html
>
> Because there are many updates, please review the updates carefully, and let us know if we missed anything or anything is incorrect.
>
> Thanks again for your help!
>
> RFC Editor/lb
>
>
> > On Apr 12, 2024, at 9:20 AM, Jorge Rabadan (Nokia) <jorge.rabadan=[e-mail]> wrote:
> >
> > Dear RFC-editor,
> >  Please see my comments in-line with [jorge].
> >  Thanks.
> > Jorge
> >  From: [e-mail] <[e-mail]>
> > Date: Wednesday, April 10, 2024 at 3:50 PM
> > To: Jorge Rabadan (Nokia) <[e-mail]>, Senthil Sathappan (Nokia) <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
> > Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Matthew Bocci (Nokia) <[e-mail]>, [e-mail] <[e-mail]>
> > Subject: Re: AUTH48: RFC-to-be 9574 <draft-ietf-bess-evpn-optimized-ir-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.
> >
> >
> >
> > Authors,
> >
> > While reviewing this document during AUTH48, please resolve (as necessary)
> > the following questions, which are also in the XML file.
> >
> > 1) <!-- [rfced] We updated the document title as follows.  Please let us
> > know any objections.
> >
> > Original:
> >  Optimized Ingress Replication Solution for Ethernet VPN (EVPN)
> >
> > Currently:
> >  Optimized Ingress Replication Solution for Ethernet VPNs (EVPNs) -->
> > [jorge] No objections.
> >
> >
> >
> > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
> > title) for use on <https://www.rfc-editor.org/search>. -->
> > [jorge] Assisted Replication, AR, AR-Replicator, RNVE, Pruned Flood List, PFL, Pruned Flooding List
> >
> >
> >
> > 3) <!-- [rfced] Section 1:  Does "as many copies of the frame as remote
> > NVEs/PEs are attached" mean "as many copies of the frame as the
> > number of remote NVEs/PEs that are attached"?  If the suggested text
> > is not correct, please clarify.
> >
> > Original:
> >  In the Ingress Replication approach, the ingress NVE receving a BUM
> >  frame from the Tenant System will create as many copies of the frame
> >  as remote NVEs/PEs are attached to the BD.
> >
> > Suggested ("receving" has been fixed):
> >  In the ingress replication approach, the ingress NVE receiving a BUM
> >  frame from the Tenant System (TS) will create as many copies of the
> >  frame as the number of remote NVEs/PEs that are attached to the BD. -->
> > [jorge] suggestion looks good, thanks.
> >
> > 4) <!-- [rfced] Section 1:  We changed "NV3" to "NVE3" per Figure 1.  If
> > this is incorrect, please define "NV".
> >
> > Original:
> >  On the left-hand
> >  side, NVE1 uses Ingress Replication to send a BUM frame (originated
> >  from Tenant System TS1) to the remote nodes attached to the BD, i.e.,
> >  NVE2, NV3, PE1.
> >
> > Currently:
> >  On the left-hand
> >  side of the diagram, NVE1 uses ingress replication to send a BUM
> >  frame (originated from Tenant System TS1) to the remote nodes
> >  attached to the BD, i.e., NVE2, NVE3, and PE1. -->
> > [jorge] the suggestion is correct, thanks.
> >
> >
> >
> > 5) <!-- [rfced] Figure 1:  Should the three instances of "to-G" be
> > "to G1", in which case perhaps we should also change "To-WAN" to
> > "To WAN")?  (in other words, do these hyphenated entries mean
> > "(from the) OIF to G" and "To (the) WAN"?
> >
> > Original:
> >  To-WAN
> > ...
> >  OIF to-G ... -->
> > [jorge] the suggestion is correct, thanks (OIF to-G and To-WAN)
> >
> >
> >
> > 6) <!-- [rfced] Sections 1 and subsequent:  We do not see the hyphenated
> > form "Pruned-Flood-Lists" in any published RFCs to date.  However, we
> > see "Pruned Flood Lists (PFLs)" in RFC 9469.  May we remove the
> > hyphens?
> > [jorge] ok, please remove the hyphens
> >
> >
> > Also, RFC 9469 appears to be the only published RFC to date that uses
> > "Flood List" (via case-insensitive search).  Perhaps
> > "Pruned Flooding Lists"? -->
> > [jorge] “Pruned Flooding Lists” is ok
> >
> >
> > 7) <!-- [rfced] Sections 1 and subsequent:  We see that RFC 6514 uses
> > "Next Hop field" (no hyphen) and that the only published RFCs to date
> > that use "Next-Hops" are RFCs 2749 and 5286.  May we change
> > instances of "Next-Hop" to "Next Hop" where it is used as a noun
> > (e.g., "will set the Next-Hop to an IP address") and change instances
> > of "Next-Hops" to "next hops"
> > (per draft-ietf-bess-evpn-bum-procedure-updates and most published
> > RFCs)? -->
> > [jorge] yes, the suggestion is good, please go ahead
> >
> >
> >
> > 8) <!-- [rfced] Section 2:  We see that the list of terms is mostly
> > alphabetized.  Would you like the list to be alphabetized? -->
> > [jorge] yes please, thanks
> >
> >
> >
> > 9) <!-- [rfced] Sections 2 and 6.1:  These two instances of
> > "destination IP AR-IP" read oddly.  Should they be "destination AR-IP"?
> > Are some words missing?
> >
> > Original:
> >  -  Asisted Replication forwarding mode: for an AR-LEAF, it means
> >     sending an Attachment Circuit BM packet to a single AR-REPLICATOR
> >     with tunnel destination IP AR-IP.
> > ...
> >  The
> >  tunnel destination IP AR-IP will be an indication for the
> >  remote Selective AR-REPLICATOR that the packet needs
> >  further replication to its AR-LEAFs. -->
> > [jorge] no words missing. Maybe you can replace “destination IP AR-IP” with “destination address AR-IP” if it reads better. It does not change the meaning.
> >
> >
> >
> > 10) <!-- [rfced] Section 3:  For ease of the reader, we expanded "CE" as
> > "Customer Edge".  If this is incorrect, please provide the correct
> > definition.
> >
> > Original:
> >  c.  The solution is compatible with [RFC7432] and [RFC8365] and has
> >      no impact on the CE procedures for BM traffic.
> >
> > Currently:
> >  c.  The solution is compatible with [RFC7432] and [RFC8365] and has
> >      no impact on the Customer Edge (CE) procedures for BM traffic. -->
> > [jorge] the suggestion is correct, thanks
> >
> >
> >
> > 11) <!-- [rfced] Sections 4 and 7:  As this document discusses several
> > solutions, which solution is referred to in these sentences - the
> > ingress replication optimization solution in general or one of the
> > solutions discussed in Sections 5 and 6?
> >
> > Original:
> >  This solution extends the [RFC7432] Inclusive Multicast Ethernet Tag
> >  routes and attributes so that an NVE/PE can signal its optimized
> >  Ingress Replication capabilities.
> > ...
> >  In addition to AR, the second optimization supported by this solution
> >  is the ability for the all the BD nodes to signal Pruned-Flood-Lists
> >  (PFL).
> >
> > Possibly:
> >  The ingress replication optimization solution specified in this
> >  document extends the Inclusive Multicast Ethernet Tag routes and
> >  attributes described in [RFC7432] so that an NVE/PE can signal its
> >  optimized ingress replication capabilities.
> > ...
> >  In addition to AR, the second optimization supported by the ingress
> >  replication optimization solution specified in this document is the
> >  ability of all the BD nodes to signal PFLs. -->
> > [jorge] the suggestion is good, thanks
> >
> >
> >
> > 12) <!-- [rfced] Figure 2:  We changed "Inclusive Multicast Tag" to
> > "Inclusive Multicast Ethernet Tag" per "Inclusive Multicast Ethernet
> > Tag route [RFC7432] is shown in Figure 2" in the paragraph just prior
> > to the figure and "the above Inclusive Multicast Ethernet Tag route
> > (Figure 2)" a few paragraphs later.  If this is incorrect, please
> > define this new term, which we don't see anywhere else in this
> > document or in any published RFC except for RFC 9489.
> >
> > Original:
> >  Figure 2: EVPN Inclusive Multicast Tag Route's NLRI
> >
> > Currently:
> >  Figure 2: EVPN Inclusive Multicast Ethernet Tag Route's NLRI -->
> > [jorge] the suggestion is correct, thanks
> >
> >
> >
> > 13) <!-- [rfced] Sections 4 and 7:  These sentences are difficult to
> > follow.  Does "prune-me" mean "prune me (from the indicated list)"?
> > If yes, may we update as suggested?
> >
> > Original:
> >  o  Broadcast and Multicast (BM) flag.  BM=1 means "prune-me" from
> >     the BM flooding list.  BM=0 means regular behavior.
> >
> >  o  Unknown (U) flag.  U=1 means "prune-me" from the Unknown
> >     flooding list.  U=0 means regular behavior.
> > ...
> >  -  BM is the Broadcast and Multicast flag.  BM=1 means "prune-me"
> >     from the BM flood-list.  BM=0 means regular behavior.
> >
> >  -  U is the Unknown flag.  U=1 means "prune-me" from the Unknown
> >     flood-list.  U=0 means regular behavior.
> >
> > Suggested (assuming that "flood-list" and "flooding list" mean the
> >   same thing):
> >  -  Broadcast and Multicast (BM) flag.  BM = 1 means "prune me from
> >     the BM flooding list".  BM = 0 indicates regular behavior.
> >
> >  -  Unknown (U) flag.  U = 1 means "prune me from the Unknown
> >     flooding list".  U = 0 indicates regular behavior.
> > ...
> >  *  BM is the Broadcast and Multicast flag.  BM = 1 means "prune me
> >     from the BM flooding list".  BM = 0 indicates regular behavior.
> >
> >  *  U is the Unknown flag.  U = 1 means "prune me from the Unknown
> >     flooding list".  U = 0 indicates regular behavior. -->
> > [jorge] the suggestion is good, thanks
> >
> >
> >
> > 14) <!-- [rfced] Section 4:  The text in this paragraph was difficult to
> > follow from the standpoint of whether some terms were field names or
> > were used generally.  We updated as follows.  If this is incorrect,
> > please provide clarifying text.
> >
> > Also, please note that per our previous question about "Next-Hop", we
> > suggest removing the hyphen in the field name per more common usage
> > in published RFCs.
> >
> > Original:
> >  +  The Tunnel Identifier and Next-Hop SHOULD be set to the same
> >     IP address as the Originating Router's IP address when the
> >     NVE/PE originates the route, that is, when the NVE/PE is not
> >     an ASBR as in section 10.2 of [RFC8365].  Irrespective of
> >     the values in the Tunnel Identifier and Originating Router's
> >     IP Address fields, the ingress NVE/PE will process the
> >     received Replicator-AR route and will use the IP Address in
> >     the Next-Hop field to create IP tunnels to the AR-
> >     REPLICATOR.
> >
> > Currently:
> >  -  The Tunnel Identifier and Next-Hop fields SHOULD be set to
> >     the same IP address as the Originating Router's IP Address
> >     field when the NVE/PE originates the route - that is, when
> >     the NVE/PE is not an ASBR; see Section 10.2 of [RFC8365].
> >     Irrespective of the values in the Tunnel Identifier and
> >     Originating Router's IP Address fields, the ingress NVE/PE
> >     will process the received Replicator-AR route and will use
> >     the IP address setting in the Next-Hop field to create IP
> >     tunnels to the AR-REPLICATOR. -->
> > [jorge] the updated text is good, thanks.
> >
> >
> >
> > 15) <!-- [rfced] Section 4:  Per Section 11 and per "Tunnel Type MUST be
> > set to Assisted-Replication Tunnel" used earlier in this section, we
> > changed "set to AR" to "set to Assisted-Replication Tunnel".  Please
> > let us know any concerns.
> >
> > Original:
> >  o  The Leaf Auto-Discovery route MUST include the PMSI Tunnel
> >     attribute with the Tunnel Type set to AR (Section 11), T (AR
> >     role type) set to AR-LEAF and the Tunnel Identifier set to the
> >     IP address of the advertising AR-LEAF.
> >
> > Currently:
> >  *  The Leaf A-D route MUST include the PMSI Tunnel Attribute with
> >     Tunnel Type set to Assisted-Replication Tunnel (Section 11), T (AR
> >     role type) set to AR-LEAF, and Tunnel Identifier set to the IP
> >     address of the advertising AR-LEAF. -->
> > [jorge] the updated text is good, thanks.
> >
> >
> >
> > 16) <!-- [rfced] Section 5.2:
> >
> > a) We see "Inclusive Multicast Ethernet Tag route" in RFC 7432 but
> > not "inclusive multicast route" or "Inclusive Multicast Route".
> > Will these distinctions be clear to readers, or should "Ethernet Tag"
> > be added?
> >
> > Original:
> >  b.  In this non-selective AR solution, the AR-LEAF MUST advertise a
> >      single Regular-IR inclusive multicast route as in [RFC7432].
> > ...
> >  c.  In a BD where there are no AR-REPLICATORs due to the AR-
> >      REPLICATORs being down or reconfigured, the AR-LEAF MUST use
> >      regular Ingress Replication, based on the remote Regular-IR
> >      Inclusive Multicast Routes as described in [RFC7432].
> > ...
> >  The AR-REPLICATOR-activation-timer SHOULD be
> >  configurable in seconds, and its value account for the time it
> >  takes for the AR-LEAF Regular-IR inclusive multicast route to get
> >  to the AR-REPLICATOR and be programmed.
> > [jorge] we can add “Ethernet Tag”, i.e. Inclusive Multicast Ethernet Tag route.
> >
> >
> > b) We had trouble following the meaning of "make any difference for"
> > here.  If the suggested text is not correct, please provide
> > clarifying text.
> >
> > Original:
> >  Note that although this field does not make any difference
> >  for the remote nodes when creating an EVPN destination to the AR-
> >  LEAF, this field is useful for an easy operation and
> >  troubleshooting of the BD.
> >
> > Suggested:
> >  Note that although this field does not affect the remote nodes when
> >  creating an EVPN destination to the AR-LEAF, this field is useful
> >  from the standpoint of ease of operation and troubleshooting of the
> >  BD. -->
> > [jorge] the suggested text is correct and better, thanks.
> >
> >
> >
> > 17) <!-- [rfced] Section 5.2:  This sentence does not parse.  Should "and
> > its value account for" say "and its value SHOULD account for",
> > "and its value needs to account for", or something else?  In other
> > words, to what does "SHOULD" apply in this sentence?
> >
> > Original:
> >  The AR-REPLICATOR-activation-timer SHOULD be
> >  configurable in seconds, and its value account for the time it
> >  takes for the AR-LEAF Regular-IR inclusive multicast route to get
> >  to the AR-REPLICATOR and be programmed. -->
> > [jorge] we can do as follows:
> > OLD:
> >  The AR-REPLICATOR-activation-timer SHOULD be
> >  configurable in seconds, and its value account for the time it
> >  takes for the AR-LEAF Regular-IR inclusive multicast route to get
> >  to the AR-REPLICATOR and be programmed. -->
> > NEW:
> >  The AR-REPLICATOR-activation-timer SHOULD be
> >  configurable in seconds, and its value needs to account for the time it
> >  takes for the AR-LEAF Regular-IR Inclusive Multicast Ethernet Tag route to get
> >  to the AR-REPLICATOR and be programmed. -->
> >
> >
> >
> > 18) <!-- [rfced] Section 5.2:  As it appears that "a matter of local
> > policy" indicates whether or not to change to a new preferred
> > AR-REPLICATOR (as opposed to always making the change), we updated
> > this sentence accordingly.  If this is incorrect, please provide
> > clarifying text.
> >
> > Original:
> >  f.  If the AR-LEAF has selected an AR-REPLICATOR, it is a matter of
> >      local policy to change to a new preferred AR-REPLICATOR for the
> >      existing BM traffic flows.
> >
> > Currently:
> >  f.  If the AR-LEAF has selected an AR-REPLICATOR, whether or not to
> >      change to a new preferred AR-REPLICATOR for the existing BM
> >      traffic flows is a matter of local policy. -->
> > [jorge] the updated text is correct
> >
> >
> >
> > 19) <!-- [rfced] Figure 5:  We changed "LEAF-set1" to "LEAF-set-1",
> > but is it correct to have two "LEAF-set-1"s in the diagram?  In other
> > words, are three distinct LEAF-sets shown here, or two?
> >
> > Original:
> >  | LEAF-set1 |        |LEAF-set-1 |       |LEAF-set-2 |
> >
> > Currently:
> >  |LEAF-set-1 |        |LEAF-set-1 |       |LEAF-set-2 |
> >
> > Possibly (if there should be three LEAF-sets):
> >  |LEAF-set-1 |        |LEAF-set-2 |       |LEAF-set-3 | -->
> > [jorge] the current figure is correct, i.e.,:
> > |LEAF-set-1 |        |LEAF-set-1 |       |LEAF-set-2 |
> >
> >
> >
> > 20) <!-- [rfced] Section 6:  We found this sentence confusing, as it
> > seems that the AR roles are defined more clearly in Section 5 than
> > in Section 4.  Should Section 5 also be cited here?
> >
> > Original:
> >  The same AR roles
> >  defined in Section 4 are used here, however the procedures are
> >  different. -->
> > [jorge] we can do:
> > OLD:
> >  The same AR roles
> >  defined in Section 4 are used here, however the procedures are
> >  different. NEW:
> >  The same AR roles
> >  defined in Section 4 and Section 5 are used here, however the procedures are
> >  different.
> >
> >
> > 21) <!-- [rfced] Section 6.1:  This sentence is difficult to follow.  May
> > we update the text per item a. in Section 5.1?  If not, please
> > clarify "part of an Assisted-Replication-enabled BD as the AR role
> > itself".
> >
> > Original:
> >  a.  The Selective AR-REPLICATOR capability SHOULD be an
> >      administrative choice in any NVE/PE that is part of an Assisted-
> >      Replication-enabled BD, as the AR role itself.
> >
> > Suggested:
> >  a.  The AR-REPLICATOR role SHOULD be an
> >      administrative choice in any NVE/PE that is part of an Assisted-
> >      Replication-enabled BD. -->
> > [jorge] I would do:
> > OLD:
> >  a.  The Selective AR-REPLICATOR capability SHOULD be an
> >      administrative choice in any NVE/PE that is part of an Assisted-
> >      Replication-enabled BD, as the AR role itself.
> > NEW:
> >  a.  The Selective AR-REPLICATOR role SHOULD be an
> >      administrative choice in any NVE/PE that is part of an Assisted-
> >      Replication-enabled BD.
> >
> >
> >
> > 22) <!-- [rfced] Section 6.1:  It seems odd to repeat "Replicator-AR
> > route" in this sentence.  May we update as suggested, or should the
> > wording be revised?
> >
> > Original:
> >  o  The Replicator-AR route MUST include L=1 (Leaf Information
> >     Required) in the Replicator-AR route.
> >
> > Suggested:
> >  *  The Replicator-AR route MUST have the L flag set to 1. -->
> > [jorge] I would suggest this:
> > OLD:
> >  o  The Replicator-AR route MUST include L=1 (Leaf Information
> >     Required) in the Replicator-AR route.
> > NEW:
> >  o  The AR-REPLICATOR MUST have the L flag set to 1 when advertising the Replicator-AR route.
> >
> >
> >
> > 23) <!-- [rfced] Section 6.1:  This sentence does not parse.  Does the
> > "MUST" in this sentence also apply to "but skipping"?  If the
> > suggested text is not correct, please provide clarifying text.
> >
> > Original:
> >  o  If the destination IP address matches its AR-IP and the source
> >     IP address does not match any IP address of its Selective AR-
> >     LEAF-set, the AR-REPLICATOR MUST forward the BM packet to
> >     flood-list #2 but skipping the AR-REPLICATOR-set.  Non-BM
> >     overlay tunnels are skipped when sending BM packets.
> >
> > Suggested (assuming that "MUST" applies to both forwarding and
> >   skipping):
> >  -  If the destination IP address matches its AR-IP and the source
> >     IP address does not match any IP address of its Selective AR-
> >     LEAF-set, the AR-REPLICATOR MUST forward the BM packet to
> >     flood-list #2, skipping the AR-REPLICATOR-set.  Non-BM
> >     overlay tunnels are skipped when sending BM packets. -->
> > [jorge] the suggestion is correct, thx
> >
> >
> >
> > 24) <!-- [rfced] Section 6.2:  We updated this sentence per item a. in
> > Section 5.2.  If this is incorrect, please clarify "role selective
> > capability".
> >
> > Original:
> >  a.  The AR-LEAF role selective capability SHOULD be an administrative
> >      choice in any NVE/PE that is part of an Assisted-Replication-
> >      enabled BD.
> >
> > Currently:
> >  a.  The AR-LEAF role SHOULD be an administrative choice in any NVE/PE
> >      that is part of an Assisted-Replication-enabled BD. -->
> > [jorge] This is what I would do:
> > OLD:
> >  a.  The AR-LEAF role selective capability SHOULD be an administrative
> >      choice in any NVE/PE that is part of an Assisted-Replication-
> >      enabled BD.
> > NEW:
> >  a.  The Selective AR-LEAF role SHOULD be an administrative choice in any NVE/PE
> >      that is part of an Assisted-Replication-enabled BD.
> >
> >
> >
> > 25) <!-- [rfced] Section 6.2:  As the original text seemed to indicate
> > that the AR-LEAF should wait for a timer, we updated the text to
> > indicate that the AR-LEAF should wait for some interval to pass.  If
> > this is incorrect, please provide clarifying text (e.g., are some
> > words missing?).
> >
> > Original:
> >  It is RECOMMENDED that the Selective AR-LEAF waits for an AR-
> >  LEAF-join-wait-timer (in seconds, default value is 3) before
> >  sending the Leaf Auto-Discovery route, so that the AR-LEAF can
> >  collect all the Replicator-AR routes for the BD before
> >  advertising the Leaf Auto-Discovery route.
> >
> > Currently:
> >  It is
> >  RECOMMENDED that the Selective AR-LEAF wait for a period
> >  specified by an AR-LEAF-join-wait-timer (in seconds, with a
> >  default value of 3) before sending the Leaf A-D route, so that
> >  the AR-LEAF can collect all the Replicator-AR routes for the BD
> >  before advertising the Leaf A-D route. -->
> > [jorge] the suggested text is good. Shouldn’t it be “AR-LEAF waits” instead of “AR-LEAF wait”?
> >
> >
> >
> > 26) <!-- [rfced] Section 6.2:
> >
> > a) We changed "a timer AR-REPLICATOR-activation-timer" to "an
> > AR-REPLICATOR-activation-timer", but we still find this sentence
> > difficult to follow.  Should "behavior for an
> > AR-REPLICATOR-activation-timer" be "behavior after a specified
> > AR-REPLICATOR-activation-timer interval"?  If not, please provide
> > clarifying text.
> >
> > Original:
> >  In case of failure of the active Selective AR-
> >  REPLICATOR, it is RECOMMENDED for the Selective AR-LEAF to
> >  revert to Ingress Replication behavior for a timer AR-
> >  REPLICATOR-activation-timer (in seconds, default value is 3)
> >  to mitigate the traffic impact.
> >
> > Currently:
> >  In the
> >  case of failure of the active Selective AR-REPLICATOR, it is
> >  RECOMMENDED that the Selective AR-LEAF revert to ingress
> >  replication behavior for an AR-REPLICATOR-activation-timer (in
> >  seconds, with a default value of 3) to mitigate the traffic
> >  impact.
> > [jorge] suggestion looks good, thanks
> >
> >
> > b) Does "the same configurable parameter as in Section 5.2" mean
> > "the same configurable parameter as the parameter discussed in
> > Section 5.2", "the same configurable parameter, as discussed in
> > Section 5.2", or something else?  Please clarify.
> >
> > Original:
> >  The AR-REPLICATOR-activation-timer
> >  MAY be the same configurable parameter as in Section 5.2. -->
> > [jorge] it means "the same configurable parameter as the parameter discussed in Section 5.2",
> >
> >
> >
> > 27) <!-- [rfced] Section 7.1:  As it appears that "the solution described
> > in this document" refers to the PFLs solution and not to the
> > Assisted-Replication solution as mentioned in Section 1 ("The
> > Assisted-Replication solution described in this document") or the
> > optimized ingress replication solution in general, we updated this
> > sentence accordingly.  If this is incorrect, please provide
> > clarifying text.
> >
> > Original:
> >  In order to illustrate the use of the solution described in this
> >  document, we will assume that BD-1 in Figure 4 is optimized Ingress
> >  Replication enabled and:
> >
> > Currently:
> >  In order to illustrate the use of the PFLs solution, we will assume
> >  that BD-1 in Figure 4 is optimized ingress replication enabled and: -->
> > [jorge] the suggested text is correct, thanks
> >
> >
> >
> > 28) <!-- [rfced] Section 7.1:  As it appears that "will reply ARP
> > Requests" means "will reply to ARP Requests", we updated this
> > sentence accordingly.  If this is incorrect, please provide
> > clarifying text.
> >
> > Original:
> >  Proxy-ARP
> >  [I-D.ietf-bess-evpn-proxy-arp-nd] on the remote NVE/PEs will
> >  reply ARP Requests locally, and no other Broadcast is expected.
> >
> > Currently:
> >  Proxy ARP
> >  [RFC9161] on the remote NVEs/PEs will reply to ARP Requests
> >  locally, and no other broadcast traffic is expected. -->
> > [jorge] the suggested text is correct, thanks.
> >
> >
> >
> > 29) <!-- [rfced] Section 8:  As it appears that "Ingress Replication or
> > Assisted Replication forwarding mode" means "Ingress Replication
> > forwarding mode or Assisted Replication forwarding mode" as opposed
> > to "ingress replication or Assisted Replication forwarding mode", we
> > updated this paragraph accordingly.  If this is incorrect, please
> > clarify the text.
> >
> > Original:
> >  -  An AR-REPLICATOR will perform Ingress Replication or Assisted
> >     Replication forwarding mode for the incoming Overlay packets based
> >     on an ingress VNI lookup, as opposed to the tunnel IP DA lookup.
> >     Note that, when replicating to remote AR-REPLICATOR nodes, the use
> >     of the IR-VNI or AR-VNI advertised by the egress node will
> >     determine the Ingress Replication or Assisted Replication
> >     forwarding mode at the subsequent AR-REPLICATOR.
> >
> > Currently:
> >  *  An AR-REPLICATOR will perform Ingress Replication forwarding mode
> >     or Assisted Replication forwarding mode for the incoming overlay
> >     packets based on an ingress VNI lookup as opposed to the tunnel IP
> >     DA lookup.  Note that when replicating to remote AR-REPLICATOR
> >     nodes, the use of the IR-VNI or AR-VNI advertised by the egress
> >     node will determine whether Ingress Replication forwarding mode or
> >     Assisted Replication forwarding mode is used at the subsequent AR-
> >     REPLICATOR. -->
> > [jorge] the suggested text is correct, thanks.
> >
> >
> >
> > 30) <!-- [rfced] Section 10:
> >
> > a) As it appears that the AR-LEAF nodes are the entities making
> > selections (per "other AR-LEAFs' selections" in Section 5.2), we
> > updated this sentence accordingly.  If this is incorrect, please
> > provide clarifying text.
> >
> > Original:
> >  Also, an attack on the AR-REPLICATOR and
> >  change of the advertised AR type will modify the selection on the AR-
> >  LEAF nodes.
> >
> > Currently:
> >  Also, an attack on the AR-REPLICATOR and any change to the
> >  advertised AR type will modify the selections made by the AR-LEAF
> >  nodes.
> > [jorge] the suggested text is correct, thanks.
> >
> >
> > b) We could not follow the meaning of "attracted" as used in this
> > sentence.  Per <https://www.merriam-webster.com/dictionary/attracted>,
> > it does not appear to be a good fit.  Please provide alternative text.
> >
> > Original:
> >  The forwarding of Broadcast and Multicast (BM)
> >  traffic is modified, and BM traffic from the AR-LEAF nodes will be
> >  attracted by the existence of AR-REPLICATORs in the BD. -->
> > [jorge] suggestion:
> > OLD:
> > The forwarding of Broadcast and Multicast (BM)
> >  traffic is modified, and BM traffic from the AR-LEAF nodes will be
> >  attracted by the existence of AR-REPLICATORs in the BD.
> > NEW:
> > The forwarding of Broadcast and Multicast (BM)
> >  traffic is modified, and BM traffic from the AR-LEAF nodes will be
> >  drawn toward the AR-REPLICATORs in the BD.
> >
> >
> >
> > 31) <!-- [rfced] Would you like to list the references in alphanumeric
> > order? -->
> > [jorge] yes please
> >
> >
> >
> > 32) <!-- [rfced] Please let us know if any changes are needed for the
> > following:
> >
> > a) The following terms were used inconsistently in this document.
> > We chose to use the latter forms.  Please let us know any objections.
> >
> >  flags field / Flags field (per Cluster 448)
> >
> >  Ingress Replication / ingress replication (per RFCs 9251 and 9252)
> >
> >  NVE/PEs / NVEs/PEs
> >
> >  nvGRE (Figures 4 and 5) / NVGRE
> >
> >  Originating Router's IP address / Originating Router's IP Addr /
> >    Originating Router's IP Address (per RFC 9252)
> >
> >  PMSI Tunnel attribute / PMSI Tunnel Attribute (per RFC 9252)
> > [jorge] all the above is good
> >
> >
> >  regular-IR (2 instances) / Regular-IR (24 instances)
> >    (We see one instance of "regular IR-IP Address"; please confirm
> >     that this is correct.)
> > [jorge] Regular-IR is correct. “regular IR-IP Address” should be replaced with “IR-IP address”
> >
> >
> >  regular-IR behavior described in [RFC7432] (1 instance) /
> >    regular ingress replication behavior described in [RFC7432]
> >      (4 instances)
> >
> >  Split-horizon / split-horizon (per RFC 9252)
> >
> >  Tunnel Type / tunnel type (where used generally)
> > [jorge] all the above is ok
> >
> >
> > b) The following terms appear to be used inconsistently in this
> > document.  Please let us know which form is preferred.
> >
> >  AR-IP Address / AR-IP address
> > [jorge] AR-IP address
> >
> >
> >  Assisted-Replication / Assisted Replication
> >    (e.g., "Assisted-Replication (AR)", "Assisted Replication (AR)")
> >    (We suggest that, after selecting one form, we use the
> >    abbreviation "AR" after the initial definition in Section 1.)
> > [jorge] Assisted Replication
> >
> >
> >  Assisted-Replication Type field (4 instances) /
> >    AR type field (1 instance)
> >    (Are these two distinct fields, or do they both mean the same
> >     thing?  If the same, which form should be used?)
> > [jorge] same thing. We can use “Assisted Replication Type field”
> >
> >
> >  core network / network core (Abstract)
> > [jorge] network core
> >
> >
> >  IP Source Address / source IP address*
> >    * (e.g., as used in RFC 9251)
> > [jorge] ok, “source IP address” is good
> >
> >
> >  IR-IP Address / IR-IP address
> > [jorge] “IR-IP address”
> >
> >
> >  multi-staged / multi-stage
> > [jorge] multi-stage
> >
> >
> >  non-selective / Non-selective / Non-Selective (in running text,
> >    e.g., 'non-selective AR', 'solution is called "non-selective"',
> >    'Non-Selective solution', 'Non-selective AR-REPLICATORs',
> >    'non-selective mode', 'Non-Selective and Selective modes',
> >    'Non-Selective mode')
> >
> >    Suggested (with the exception of 'Non-selective mode', per other
> >      mode names in this cluster):
> >      non-selective, because we do not see a precedent for
> >        'Non-selective' in any published RFC.  However, we see
> >        'Non-Selective Mode' used once in RFC 9469, but this appears
> >        to be an outlier.
> > [jorge] “non-selective” is ok
> >
> >
> >  selective AR(...) / Selective AR(...)
> >    (e.g., selective AR, selective AR-LEAF-set, Selective AR-LEAF-set,
> >    selective AR-REPLICATOR, Selective AR-REPLICATOR)
> >
> >    Suggested:  selective AR(...)
> > [jorge] “selective AR” is ok
> >
> >
> >  Please note that we also see 'Selective solution' and
> >    'Selective mode'.
> >    We suggest 'selective solution', because it does not appear to be
> >      a proper term.
> >    We suggest 'Selective mode' per other mode names in this cluster.
> > [jorge] ok
> >
> >
> >  Single-IP AR-REPLICATOR
> >    ("in the Single-IP AR-REPLICATOR ..." (Section 2)) /
> >    single-IP AR-REPLICATOR (Section 10)
> > [jorge] “single-IP AR-REPLICATOR”
> >
> >
> >  T (AR role type) (2 instances) /
> >    T (Assisted-Replication type) (1 instance)
> > [jorge]  T (AR role type)
> >
> >
> >  Unknown Unicast / Unknown unicast / unknown unicast
> >    (where used generally)
> > [jorge] unknown unicast
> >
> >
> > c) This is the only document in Cluster 448
> > (https://www.rfc-editor.org/cluster_info.php?cid=C448) that uses
> > "flood-list" (e.g., "Unknown flooding list", "Unknown flood-list").
> > We also could not find any instances of "flood-list", "Flood-List",
> > or "Flood-list" in any published RFC to date.
> >
> > May we change these instances to "flooding list" as used elsewhere in
> > this document, and also per
> > draft-ietf-bess-evpn-bum-procedure-updates?  If not, how can the
> > distinction between these two terms be clarified for readers? -->
> > [jorge] ok, “flooding list” is good
> >
> >
> >
> > 33) <!-- [rfced] Please review the "Inclusive Language" portion of the
> > online Style Guide at
> > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
> > and let us know if any changes are needed.
> > [jorge] no additional changes, thanks
> >
> >
> > Note that our script did not flag any words in particular, but this
> > should still be reviewed as a best practice. -->
> >
> >
> > Thank you.
> > [jorge] thank you for such thorough review!
> > Jorge
> >
> >
> > RFC Editor
> >
> >
> > On Apr 10, 2024, at 3:41 PM, [e-mail] wrote:
> >
> > *****IMPORTANT*****
> >
> > Updated 2024/04/10
> >
> > 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
> >
> >    *  [e-mail] (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).
> >
> >    *  [e-mail], 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-4Q9l2USxIAe6P8O4Zc
> >
> >      *  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,
> >         [e-mail] 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/rfc9574.xml
> >    https://www.rfc-editor.org/authors/rfc9574.html
> >    https://www.rfc-editor.org/authors/rfc9574.pdf
> >    https://www.rfc-editor.org/authors/rfc9574.txt
> >
> > Diff file of the text:
> >    https://www.rfc-editor.org/authors/rfc9574-diff.html
> >    https://www.rfc-editor.org/authors/rfc9574-rfcdiff.html (side by side)
> >
> > Diff of the XML:
> >    https://www.rfc-editor.org/authors/rfc9574-xmldiff1.html
> >
> > The following files are provided to facilitate creation of your own
> > diff files of the XML.
> >
> > Initial XMLv3 created using XMLv2 as input:
> >    https://www.rfc-editor.org/authors/rfc9574.original.v2v3.xml
> >
> > XMLv3 file that is a best effort to capture v3-related format updates
> > only:
> >    https://www.rfc-editor.org/authors/rfc9574.form.xml
> >
> >
> > Tracking progress
> > -----------------
> >
> > The details of the AUTH48 status of your document are here:
> >    https://www.rfc-editor.org/auth48/rfc9574
> >
> > Please let us know if you have any questions.
> >
> > Thank you for your cooperation,
> >
> > RFC Editor
> >
> > --------------------------------------
> > RFC9574 (draft-ietf-bess-evpn-optimized-ir-12)
> >
> > Title            : Optimized Ingress Replication Solution for Ethernet VPN (EVPN)
> > Author(s)        : J. Rabadan, Ed., S. Sathappan, W. Lin, M. Katiyar, A. Sajassi
> > WG Chair(s)      : Matthew Bocci, Stephane Litkowski, Zhaohui (Jeffrey) Zhang
> >
> > Area Director(s) : Jim Guichard, John Scudder, Gunter Van de Velde