Subject: [Lsr] Request to consider Flood Reflection going into LC

From: Tony Przygienda <[email-masked]>
Date: Fri, 9 Jul 2021 07:26:17 +0200

Dear chairs, flood reflection is implemented/shipped and deploying and
we’re on early alloc codepoints that expire start Aug’. No further
discussions on the list happened.

As far as we see as authors stuff looks shaken out, all things that were
found in implementation/use are in the latest draft version and I’d like to
test the waters of LC’ing it rather than dragging it on as draft and asking
for temporary alloc again which does not seem to serve a purpose AFAIS.

thanks

-- tony

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 12 Jul 2021 09:57:10 +0200

speaking of which, can I have 5 mins on the agenda for update flood
reflection draft v2/v3? earlier in the session would be merciful since it's
1am-3am session on Fri for me. thx. tony

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 22 Jul 2021 16:20:15 +0000

Speaking as WG member:

Hi Tony,
Thank you for starting this discussion. I’ve reviewed the draft and have a few comments and questions.

  1.  I think the concept of a flood reflection cluster should be defined earlier in the document
as opposed to being introduced in the TLV description. It seems there can only be one cluster
per level-1 area so why isn’t the cluster implied by the area? I don’t see the reason for having
a separate Flood Reduction Cluster ID?

  1.  On Page 7, there is the statement “A solution without tunnels…” I think this should be removed

or at least there should be a qualification that it is beyond the scope of the document. I know

there are subtle allusions to the tunnel-less solution in other sections but these introduce

confusion as well.

  1.  For the TLVs in section 3, 4, and 5, it is a “MUST” to only have a single instance of the TLVs.

However, if there are more than one, this violation is ignored and the first instance of the

TLV is used. Perhaps, this should be a “SHOULD”.  Also, these violations SHOULD be logged

subject to rate-limiting.

  1.  Section 6 – How does a flood reflector ensure that there are no normal L2 adjacencies? Will

adjacency establishment fail if an attempt is made to establish one? This should be specified.

  1.  Section 6 – Establishment of tunnels between flood reflector clients is a MAY yet the solution

work without it unless all the L2 routes are leaked into L1. This is related to #2.

  1.  Section 7 – This section needs to specify what happens if the adjacency criteria are not met.
  2.  Section 8 – Does this section assume no tunnels? Is the assumption that if there is an L1/L2

edge router that is not a flood reflector client, there will be another L1/L2 edge that is? Or is

this to cover cases where there is an existing portion of the L2 topology that doesn’t support

flood reflection. If it is the latter case, than leaking is required to get the L2 routes for this

portion of the L2 topology to the flood reflector(s).

  1.  I don’t understand the last statement in section 9. What do you mean by “look ‘shorter’”? Why

wouldn’t the flood reflected path cost be accurate? The L2-only path would certainly be

accurate.

Thanks,
Acee

From: Lsr <[email-masked]> on behalf of Tony Przygienda <[email-masked]>
Date: Friday, July 9, 2021 at 1:27 AM
To: lsr <[email-masked]>
Subject: [Lsr] Request to consider Flood Reflection going into LC

Dear chairs, flood reflection is implemented/shipped and deploying and we’re on early alloc codepoints that expire start Aug’. No further discussions on the list happened.

As far as we see as authors stuff looks shaken out, all things that were found in implementation/use are in the latest draft version and I’d like to test the waters of LC’ing it rather than dragging it on as draft and asking for temporary alloc again which does not seem to serve a purpose AFAIS.

thanks

-- tony