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

From: Chris Bowers <[email-masked]>
Date: Mon, 6 Dec 2021 13:54:16 -0600

I support publication of this document, as a co-author.

Chris

On Mon, Nov 22, 2021 at 1:47 PM Acee Lindem (acee) <acee=
[email-masked]> wrote:

> 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
>
>
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 7 Dec 2021 18:17:03 +0000

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.

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.)

   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: Tony Li <[email-masked]>
Date: Tue, 7 Dec 2021 10:36:58 -0800

Hi Les,

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

I’m not sure where you got that perspective about Area Proxy. That is not the intent at all.

Legacy IS-IS forces a provider to expose some of the topology of an L1 area in L2 if the L1 area is to provide transit.  You literally have to make big chunks of the topology L1L2 and it all shows up in the L2 database. As a result, the amount of abstraction that’s achieved is minimal: only the portions of the L1 area that are NOT L1L2 are abstracted away.

Area Proxy turns up the abstraction dial. Nothing more, nothing less. Abstract away ALL of the L1 area topology. The L1L2 portion of the topology is still present, it’s just no longer visible in the L2 LSDB outside of the area. That’s the scalability win.

There is still an L2 backbone, that is unchanged. Only the abstraction has changed.

> 1)Is this a problem which needs to be solved by link-state protocols?

Yes. IS-IS has an inherent scalability limitation without some additional abstraction.

> Also, many datacenters use BGP (w or w/o IGP) and therefore have other ways to address such issues.

The problem comes from exactly this use case: what happens when your data center becomes a transit node for your backbone?

> 2)If link state protocols do need to solve this problem, what is the preferred way to do that?

I don’t see this as an either/or choice, nor is it one where we’re going to make a useful decision without some market input.

> (The Experimental Track status for these drafts reflects that reality.)

I would suggest that, as always, the IETF is at its best when it is documenting de facto standards. :-)

Tony

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 7 Dec 2021 19:42:28 +0100

One thing Les is missing here is that proxy & reflection present in terms
of deployment requirements and ultimate properties very different
engineering & operational trade-offs. Different customers follow different
philosophies here IME

So we are not strictly standardizing here 2 solutions for the same thing,
we are standardizing two solutions that meet very different deployment and
operational requirements albeit from 20K feet view all that stuff looks the
same of course as any other thing does ...

-- tony

On Tue, Dec 7, 2021 at 7:17 PM Les Ginsberg (ginsberg) <ginsberg=
[email-masked]> wrote:

> 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.
>
>
>
> 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.
>
> 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.
>
>
>
> 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.
>
> 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
>
>
>