Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 7 Dec 2021 18:31:24 +0000

Hi Les,

From: Lsr <[email-masked]> on behalf of "Les Ginsberg (ginsberg)" <ginsberg=[email-masked]>
Date: Tuesday, December 7, 2021 at 1:17 PM
To: "Acee Lindem (acee)" <acee=[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

When I look at this request, I see it in a larger context.

There are two drafts which attempt to address the same problem in very different ways:

https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-flood-reflection/

and

https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-area-proxy/

Both of them discuss in their respective introductions the motivation – which is to address scaling issues in deployment scenarios where the existing IS-IS hierarchy is being asked to “stand on its head” i.e., interconnection between different L1 areas is not to be achieved by utilizing an L2 backbone – rather it is the L1 areas themselves which are required to be used for interconnection of sites (e.g., two datacenters) and the scaling properties of the existing protocol hierarchy when used in this way are not attractive.

I find no technical basis on which to choose between the two proposed solutions – so in my mind a last call for “Flood-Reflection” presupposes a last call for “Area Proxy” – and therein lies my angst.
The end result will be that multiple incompatible solutions to the same problem will be defined. It will then be left to customers to try to determine which of the solutions seems best to them – which in turn will put the onus on vendors to support both solutions (depending on the set of customers each vendor supports).
This – to me – represents an utter failure of the standards process. We are reduced to a set of constituencies which never find common ground – the end result being sub-optimal for the industry as a whole.

It seems to me that the proper role of the WG is to address the big questions first:

1)Is this a problem which needs to be solved by link-state protocols?
We certainly have folks who are clever enough to define solutions – the two drafts are a proof of that.
But whether this is a wise use of the IGPs I think has never been fully discussed/answered.
Relevant to this point is past experience with virtual links in OSPF – use of which was problematic and which has largely fallen out of use.
Also, many datacenters use BGP (w or w/o IGP) and therefore have other ways to address such issues.
Although I am familiar with the “one protocol is simpler” argument, whether that justifies altering the IGPs in any of the proposed ways is still an important question to discuss.

Given the discussions of these solutions over the last two years in LSR, I don’t think we need to rehash this – especially on the experimental track.

2)If link state protocols do need to solve this problem, what is the preferred way to do that?
This requires meaningful dialogue and a willingness to engage on complex technical issues.

The alternative is to do what we seem to be doing – allowing multiple solutions to move forward largely without comment. In which case I see no basis on which to object – anyone who can demonstrate a deployment case should then be allowed to move a draft forward – and there are then no standardized solutions.
(The Experimental Track status for these drafts reflects that reality.)

Are you saying you don’t want any experimental solutions unless we have one standardized solution that everybody agrees on? Please review this one as part of WG last call.

Thanks,
Acee

   Les

P.S.  (Aside: There is a third draft offering a solution in this space https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-ttz/  - but as that draft continues to promote its primary usage as a means of more easily changing area boundaries (merging/splitting) I have not discussed it here. However, if the authors of that draft claim it as a solution to the same problem space claimed by Area Proxy/Flood Reflection then the WG would have no basis but to also progress it – which would result in three solutions being advanced.)

From: Lsr <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Monday, November 22, 2021 11:47 AM
To: [email-masked]
Subject: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

This begins the WG Last for draft-ietf-lsr-isis-flood-reflection-05. Please post your support or objection to this list by 12:00 AM UTC on Dec 14th , 2021. Also please post your comments on the draft. I’m allowing as extra week as I like to get some additional reviews – although my comments have been addressed.

Thanks,
Acee

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 7 Dec 2021 22:10:44 +0000

Let me try to respond to Acee/Tony/Tony in one email.

Acee – I don’t like any of the proposals. I believe they are all abusing the protocols to some degree.
I fully believe that the authors are clever enough to figure out how to make this work – but that doesn’t mean any of them are desirable.
So if I have to “vote” – I vote “no”.

Tony Li –

Area Proxy Introduction says in part:

“Following the current rules of IS-IS, all spine routers would
   necessarily be part of the Level 2 topology, plus all links between a
   Level 2 leaf and the spines.  In the limit, where all leaves need to
   support Level 2, it implies that the entire L3LS topology becomes
   part of Level 2.  This is seriously problematic as it more than
   doubles the LSDB held in the L3LS topology and eliminates any
   benefits of the hierarchy.”

Flood Reflection says:

“In such scenarios, an
   alternative approach is to consider multiple L2 flooding domains
   connected together via L1 flooding domains.  In other words, L2
   flooding domains are connected by "L1/L2 lanes" through the L1 areas
   to form a single L2 backbone again.  Unfortunately, in its simplest
   implementation, this requires the inclusion of most, or all, of the
   transit L1 routers as L1/L2 to allow traffic to flow along optimal
   paths through such transit areas.  Consequently, this approach fails
   to reduce the number of L2 routers involved, so it fails to increase
   the scalability of the L2 backbone.”

These problem statements seem fundamentally similar to me.

No question the two drafts define very different solutions – but the problem statements seem quite similar to me.

Tony P – I would argue that a “20K perspective” is useful when deciding whether the overall approach is a good one.

And in response to Tony Li’s statement:  “…the IETF is at its best when it is documenting de facto standards”

1) I fully believe that our customers understand their requirements(sic) better than we (vendors) do. But that does not mean that they understand what is the best solution better than we do.
When a customer comes to me and says “Can you do this?” my first response is usually “Please fully describe your requirements independent of the solution.”

2)Not clear to me that there is an existing “de facto standard” here – which is reinforced by the fact that we have so many different solutions proposed.

   Les

From: Acee Lindem (acee) <acee=[email-masked]>
Sent: Tuesday, December 7, 2021 10:31 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; Acee Lindem (acee) <[email-masked]>; [email-masked]
Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

Hi Les,

From: Lsr <[email-masked]<mailto:[email-masked]>> on behalf of "Les Ginsberg (ginsberg)" <ginsberg=[email-masked]<mailto:ginsberg=[email-masked]>>
Date: Tuesday, December 7, 2021 at 1:17 PM
To: "Acee Lindem (acee)" <acee=[email-masked]<mailto:acee=[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

and

Thanks,
Acee

   Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Acee Lindem (acee)
Sent: Monday, November 22, 2021 11:47 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 7 Dec 2021 22:27:04 +0000

Hi Les,

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tuesday, December 7, 2021 at 5:10 PM
To: "Acee Lindem (acee)" <acee=[email-masked]>, Acee Lindem <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Lsr] WG Last Call fo "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05

That’s fine if you have technical concerns with the individual drafts. The problem space discussion is a moot point since the WG has already adopted these documents.

Thanks,
Acee

Tony Li –

Flood Reflection says:

“In such scenarios, an

   Les

Hi Les,

and

Thanks,
Acee

   Les

Thanks,
Acee

---

From: Tony Li <[email-masked]>
Date: Tue, 7 Dec 2021 14:53:19 -0800

Les,

> When a customer comes to me and says “Can you do this?” my first response is usually “Please fully describe your requirements independent of the solution.”

If it matters at all, Area Proxy is the result of a customer explaining his issues and my attempt to address them.  I’m sorry you don’t like my proposal.

> 2)Not clear to me that there is an existing “de facto standard” here – which is reinforced by the fact that we have so many different solutions proposed.

There isn’t. Yet. Thus, it’s not time to pick one vs. the other.

Tony

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 8 Dec 2021 14:17:04 +0100

Les,

> 1) I fully believe that our customers understand their requirements(sic)
> better than we (vendors) do. But that does not mean that they understand
> what is the best solution better than we do.
> When a customer comes to me and says “Can you do this?” my first response
> is usually “Please fully describe your requirements independent of the
> solution.”
>
>
>
> If it matters at all, Area Proxy is the result of a customer explaining
> his issues and my attempt to address them.  I’m sorry you don’t like my
> proposal.
>
>

which funny enough is precisely what happened in case of flood reflection
as well ;-) Given that customers are different, their networks tend to be
different, timelines, deployed sets of technologies and ultimately scar
tissue and resulting preferences for better or for worse are different, you
end up sometimes with different solutions based on different equirements
for "roughly" similar problem if want to ship the stuff, run it and move
the world on in a teimely and cost-effective manner.

As Acee said, not the time now to think whether IGP should address this
problem space (that was draft acceptance timeframe), now the question is
how to make sure all possible technical holes are closed & best possible
drafts with an eye on future extensibility and an eye on making sure we
have something backwards compatible is asked for I'd say ...

-- tony