Subject: [Lsr] Using L1 for Transit Traffic in IS-IS

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 8 Dec 2021 03:23:03 +0000

(Subject was:  RE: [Lsr] WG Last Call for "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05)

(Changing the subject as Acee has suggested that discussion of the problem space is inappropriate for the WG LC thread)

Tony (and everyone) –

This isn’t the first contentious issue the WG has considered. By way of comparison (hopefully a useful one), a number of folks (including you and I) are participating in another contentious issue – fast-flooding.
But for fast-flooding there is broad WG consensus that fast-flooding is something that IS-IS should do. The contentious part is regarding what is the best way to do it. And we are proceeding in a manner where different algorithms are being tested while still in the WG document stage. And there is hope (still TBD) that multiple algorithms may be able to interoperate.

Here, I am not convinced that there is broad WG consensus that this is a problem that the IGPs should solve. (If I am wrong on that I presume the WG members will let me know.)
And, we have multiple proposals, none of which have any hope of interoperating with each other.
And we have had very little discussion about the problem space. (not your fault – certainly you have been willing as have the authors of the competing draft)

So, at best, I think WG LC is premature. I would like to see more discussion as to whether this is a problem that IGPs should solve as well as a general look at how this might be done with and/or without the IGPs.
And since all of the proposed solutions have been allocated code points, they can continue to gain implementation/deployment experience in the meantime. Therefore, I do not see that we need to make this choice now.

I realize that you are not the one asking for WG LC and I don’t know when you plan to do so and I am not trying to influence you in that regard.
But for me, WG LC is at best premature.

As regards you trying to solve a real world customer ask, I was aware of that. And I believe the authors of flood-reflection can make the same claim.

Thanx for listening,

    Les

From: Tony Li <[email-masked]> On Behalf Of Tony Li
Sent: Tuesday, December 7, 2021 2:53 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Acee Lindem (acee) <[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

Les,

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

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: Aijun Wang <[email-masked]>
Date: Wed, 8 Dec 2021 12:29:39 +0800

I agree with Les.

We are rushing to the solutions for the none universal problems that should not be solved by IGP.
There are many ways to implement the network connections, why design IGP areas in so strange manner and let the IGP behave BGP like?

Aijun Wang
China Telecom

> On Dec 8, 2021, at 11:23, Les Ginsberg (ginsberg) <ginsberg=[email-masked]> wrote:
> 
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

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

Les,

> Here, I am not convinced that there is broad WG consensus that this is a problem that the IGPs should solve. (If I am wrong on that I presume the WG members will let me know.)

I can’t believe what I’m hearing.  The problem that we’re solving is IGP scalability. Your saying that IGPs shouldn’t scale better????

I’m having a hard time believing that this is you, Les.

> I realize that you are not the one asking for WG LC and I don’t know when you plan to do so and I am not trying to influence you in that regard.

Me, I’m ready to ask that we just progress Area Proxy to RFC as experimental.

> As regards you trying to solve a real world customer ask, I was aware of that. And I believe the authors of flood-reflection can make the same claim.

So then why are you accusing us of something else?

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 8 Dec 2021 08:03:00 +0000

Tony -

From: Tony Li <[email-masked]> On Behalf Of Tony Li
Sent: Tuesday, December 7, 2021 10:52 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Acee Lindem (acee) <[email-masked]>; [email-masked]
Subject: Re: Using L1 for Transit Traffic in IS-IS

Les,

I’m having a hard time believing that this is you, Les.
[LES:] I’ll take that as a compliment. 😊
You can’t justify any and all changes by saying “It improves scalability”.
Right now my opinion is that the nature of the changes are so inconsistent with the design of the protocol that the badness outweighs the goodness.

[LES:] Thanx for the clarification.

[LES:] I didn’t make an accusation.
My comment was that just because a customer proposes a specific solution that does not mean it is the best way to solve the problem – or even a good way to solve the problem.
I have no doubt that both proposals are well intentioned and were driven by a real customer ask. You wouldn’t have spent the time you have otherwise.

   Les

Tony

---

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

Les, all sounds to me unfortunately like a gripe (and a late one @ that now
that things were worked on in WG for years & are ready to RFC being
customer deployed, @ least flood reflection is).

Plus,  unless you have a dramatically better idea than the drafts extended
I fail to understand what your point is except as Tony1 says "we should not
scale IGP higher?" (AFAIS hierarchy is not an answer here unless you ask
customers for a flag day with lots new static configuration everywhere and
possibly restructuring of their network to a hard-coded "hierarchy" and
albeit such effort may work in some totalitarian countries on in pretty
small networks, the majority of large ISIS customers will end such
discussions in timeframe of single minutes clock count ;-)

-- tony

On Wed, Dec 8, 2021 at 4:23 AM Les Ginsberg (ginsberg) <ginsberg=
[email-masked]> wrote:

> (Subject was:  RE: [Lsr] WG Last Call for "IS-IS Flood Reflection"
> -draft-ietf-lsr-isis-flood-reflection-05)
>
>
>
> (Changing the subject as Acee has suggested that discussion of the problem
> space is inappropriate for the WG LC thread)
>
>
>
> Tony (and everyone) –
>
>
>
> This isn’t the first contentious issue the WG has considered. By way of
> comparison (hopefully a useful one), a number of folks (including you and
> I) are participating in another contentious issue – fast-flooding.
>
> But for fast-flooding there is broad WG consensus that fast-flooding is
> something that IS-IS should do. The contentious part is regarding what is
> the best way to do it. And we are proceeding in a manner where different
> algorithms are being tested while still in the WG document stage. And there
> is hope (still TBD) that multiple algorithms may be able to interoperate.
>
>
>
> Here, I am not convinced that there is broad WG consensus that this is a
> problem that the IGPs should solve. (If I am wrong on that I presume the WG
> members will let me know.)
>
> And we have had very little discussion about the problem space. (not your
> fault – certainly you have been willing as have the authors of the
> competing draft)
>
>
>
> So, at best, I think WG LC is premature. I would like to see more
> discussion as to whether this is a problem that IGPs should solve as well
> as a general look at how this might be done with and/or without the IGPs.
>
> And since all of the proposed solutions have been allocated code points,
> they can continue to gain implementation/deployment experience in the
> meantime. Therefore, I do not see that we need to make this choice now.
>
>
>
> I realize that you are not the one asking for WG LC and I don’t know when
> you plan to do so and I am not trying to influence you in that regard.
>
> As regards you trying to solve a real world customer ask, I was aware of
> that. And I believe the authors of flood-reflection can make the same claim.
>
>
>
> Thanx for listening,
>
>
>
>     Les
>
>
>
>
>
>
>
>
>
> *From:* Tony Li <[email-masked]> *On Behalf Of *Tony Li
> *Sent:* Tuesday, December 7, 2021 2:53 PM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>
> *Cc:* Acee Lindem (acee) <[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
>
>
>
>
>
> 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.
>
>
>
>
>
> 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.
>
>
>
>
>

---

From: Tony Li <[email-masked]>
Date: Wed, 8 Dec 2021 08:39:15 -0800

Les,

> You can’t justify any and all changes by saying “It improves scalability”.

Very true.  Only the ones that do.  Which in this case is accurate.

> Right now my opinion is that the nature of the changes are so inconsistent with the design of the protocol that the badness outweighs the goodness.

In short, it tastes wrong.  Gee, thanks.  

If you have constructive criticism or an alternative to propose, I would welcome that.

> [LES:] I didn’t make an accusation.

I beg to differ.

> I have no doubt that both proposals are well intentioned and were driven by a real customer ask. You wouldn’t have spent the time you have otherwise.

So your comment was completely inappropriate then. Both proposals are customer inspired, but not customer proposed.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 9 Dec 2021 19:05:02 +0000

Let me try to clarify my position…

Two disjoint sets of authors looked at the same problem space and independently came up with two different (and incompatible) protocol extensions to provide a solution.

(Aside: I believe fully that both sets of authors have done their best to define what they think is a good solution. If anything I have said suggests otherwise,  that was not my intent and I apologize to both sets of authors for any misunderstanding.)

Both solutions have been published as WG documents and assigned protocol codepoints.
We are now being asked to publish both drafts as RFCs (I am assuming based on Tony Li’s response that the LC request for Area Proxy is soon to happen.)

I don’t believe the WG has reached consensus that the IGPs should be extended to address the problem.
I don’t believe the WG has reached consensus as to which solution is “better”.
I don’t believe the WG has even discussed whether a single solution or multiple solutions are required.
If multiple solutions are required, there has been no discussion as to when each of the solutions should be used. Are there some deployment scenarios where flood-reflection is a better fit and some where area proxy is a better fit?
Is there a need for additional solutions i.e., deployments where neither of the current candidates are suitable?

It seems to me that by entertaining a LC request at this point we are simply functioning as a pass through to allow multiple individual solutions to be published as RFCs. And while there are currently two solutions to the same problem space asking to progress, I think we can expect others and we have no basis on which to reject other proposals.

This is very different from how any other work brought before the LSR/OSPF/IS-IS WGs has been done in the 20+ years during which I have been an active participant.
In all other cases, the WG has strived to come up with a single interoperable solution.
Sometimes only one solution is proposed and it is refined based on discussion and then progressed.
Sometimes multiple solutions are proposed and there is discussion of both which results in choosing one over the other or some sort of merge of the solutions.
But I do not recall a case where the WG simply allowed multiple non-interoperable solutions to the same problem to be published as RFCs largely w/o comment.

I do not think this is an appropriate use of the Standards process and I do not think this serves the industry.
This does not mean that either solution is w/o merit – but I do think the requests for Last Call are premature.
But, this is just my opinion.
If the WG (members, chairs, and ADs) think otherwise then the WG should act appropriately.

Thanx for listening.

   Les

From: Tony Przygienda <[email-masked]>
Sent: Wednesday, December 8, 2021 5:27 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Tony Li <[email-masked]>; [email-masked]; Acee Lindem (acee) <[email-masked]>
Subject: Re: [Lsr] Using L1 for Transit Traffic in IS-IS

Les, all sounds to me unfortunately like a gripe (and a late one @ that now that things were worked on in WG for years & are ready to RFC being customer deployed, @ least flood reflection is).

Plus,  unless you have a dramatically better idea than the drafts extended I fail to understand what your point is except as Tony1 says "we should not scale IGP higher?" (AFAIS hierarchy is not an answer here unless you ask customers for a flag day with lots new static configuration everywhere and possibly restructuring of their network to a hard-coded "hierarchy" and albeit such effort may work in some totalitarian countries on in pretty small networks, the majority of large ISIS customers will end such discussions in timeframe of single minutes clock count ;-)

-- tony

On Wed, Dec 8, 2021 at 4:23 AM Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>> wrote:
(Subject was:  RE: [Lsr] WG Last Call for "IS-IS Flood Reflection" -draft-ietf-lsr-isis-flood-reflection-05)

Tony (and everyone) –

Thanx for listening,

    Les

From: Tony Li <[email-masked]<mailto:[email-masked]>> On Behalf Of Tony Li
Sent: Tuesday, December 7, 2021 2:53 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; Acee Lindem (acee) <[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

Les,

Tony

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 9 Dec 2021 20:41:31 +0100

On Thu, Dec 9, 2021 at 8:05 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> ...

AFAI the process for that is an adoption call. And with a quick look I see
you on

Sun, Jun 21, 2020
supporting the adoption of @ least the reflection draft and working on the
problem space so what I read here is wildly inconsistent in my eyes. I
think I also responded with a detailed answer then why the "hierarchical
isis" draft will likely not scratch the itch I am asked to scratch. That
seemed to close the thread to your satisfaction.

> If multiple solutions are required, there has been no discussion as to
> when each of the solutions should be used. Are there some deployment
> scenarios where flood-reflection is a better fit and some where area proxy
> is a better fit?
>

Drafts have been there for 2 years more or less & I don't remember you
showing particular interest in it on the 50 odds threads regarding
reflection at least that I find on mailing list in addition to all the
private reviews/comments I got ... At least from my side the progress was
well documented and co-authorship of other vendors was invited more than
once.

So, frankly, I acknowledge your current feelings and opinions without any
hard technical input but the world needed the problem solved, things had to
move in a timely manner & so the world now deploys the solution that meets
the requirements and was converged on technically in IETF and having an RFC
has really as always just the function of having a "stable snapshot" and
facilitate RFPs ...

so, ?

-- tony

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 9 Dec 2021 21:58:55 +0000

Hi Les,

I know you don’t feel that the IGP should solve this problem but there was lots of interest in the three solutions to reduce the overhead when using IS-IS L1 as transit for IS- IS L2. Let’s not rehash that.

What do feel needs to be done? Note that I’m on vacation and unlikely to engage again until next week…

Thanks,
Acee

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thursday, December 9, 2021 at 2:05 PM
To: Tony Przygienda <[email-masked]>
Cc: Tony Li <[email-masked]>, "[email-masked]" <[email-masked]>, Acee Lindem <[email-masked]>
Subject: RE: [Lsr] Using L1 for Transit Traffic in IS-IS

Thanx for listening.

   Les

-- tony

Tony (and everyone) –

Thanx for listening,

    Les

Les,

Tony

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 9 Dec 2021 22:19:03 +0000

And I meant to add that IS-IS already fully supports using L1 for transit – these solutions just make it work better.
Acee

From: Lsr <[email-masked]> on behalf of "Acee Lindem (acee)" <acee=[email-masked]>
Date: Thursday, December 9, 2021 at 4:59 PM
To: "Les Ginsberg (ginsberg)" <[email-masked]>, Tony Przygienda <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Tony Li <[email-masked]>
Subject: Re: [Lsr] Using L1 for Transit Traffic in IS-IS

Hi Les,

Thanks,
Acee

Thanx for listening.

   Les

-- tony

Tony (and everyone) –

Thanx for listening,

    Les

Les,

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 10 Dec 2021 00:37:50 +0000

Acee –

Thanx for responding while you are on vacation.

While it is true I am not enthusiastic about any of the solutions, my point of emphasis is that it’s a failure of WG process to simply move forward with all solutions – which it seems to me is what is about to happen.

Note that this is completely consistent with what I said back when WG adoption for the drafts was being discussed (thanx to Tony P for pointing me back to that time (June 21, 2020)):

<snip>
I support the WG adoption of  https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/ .

(I also support WG adoption of https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection )

I believe the problem space addressed by these two drafts warrants attention.
…
The easy road for the WG to take would be to simply allow both drafts to proceed to Experimental RFCs, but I hope we are able to do more than this. Multiple solutions place undesirable burdens on vendors and providers alike.

To the extent they feel comfortable, I encourage folks who wish to deploy such solutions to share their requirements and discuss how each of the solutions
address their requirements/fall short of addressing their requirements. I think this would help the WG discover better ways forward.

<end snip>

Don’t think we have made progress in that regard…

   Les

From: Acee Lindem (acee) <[email-masked]>
Sent: Thursday, December 9, 2021 1:59 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; Tony Przygienda <[email-masked]>
Cc: Tony Li <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Using L1 for Transit Traffic in IS-IS

Hi Les,

Thanks,
Acee

From: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, December 9, 2021 at 2:05 PM
To: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Cc: Tony Li <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Acee Lindem <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] Using L1 for Transit Traffic in IS-IS

Thanx for listening.

   Les

From: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, December 8, 2021 5:27 AM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Tony Li <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] Using L1 for Transit Traffic in IS-IS

-- tony

Tony (and everyone) –

Thanx for listening,

    Les

Les,

Tony

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Fri, 10 Dec 2021 12:23:35 +0530

Hi,

It is possible to designate experimental RFCs as historic if there is no
evidence of widespread use over a period of time, as is currently being
done for HTTP-related experimental RFCs:
https://datatracker.ietf.org/doc/status-change-http-experiments-to-historic/

Hence, I think having multiple experimental publications for a problem is
ok..

Regards,
Muthu

On Fri, Dec 10, 2021 at 6:08 AM Les Ginsberg (ginsberg) <ginsberg=
[email-masked]> wrote:

> While it is true I am not enthusiastic about any of the solutions, my
> point of emphasis is that it’s a failure of WG process to simply move
> forward with all solutions – which it seems to me is what is about to
> happen.
>
>
>
> Note that this is completely consistent with what I said back when WG
> adoption for the drafts was being discussed (thanx to Tony P for pointing
> me back to that time (June 21, 2020)):
>
>
>
> *<snip>*
>
> *I support the WG adoption of
> https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/
> <https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/> .*
>
>
>
> *(I also support WG adoption of
> https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection
> <https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection> )*
>
>
>
> *I believe the problem space addressed by these two drafts warrants
> attention.*
>
> *…*
>
> *The easy road for the WG to take would be to simply allow both drafts to
> proceed to Experimental RFCs, but I hope we are able to do more than this.
> Multiple solutions place undesirable burdens on vendors and providers
> alike.*
>
>
>
> *To the extent they feel comfortable, I encourage folks who wish to deploy
> such solutions to share their requirements and discuss how each of the
> solutions*
>
> *address their requirements/fall short of addressing their requirements. I
> think this would help the WG discover better ways forward.*
>
>
>
> *<end snip>*
>
>
>
> *From:* Acee Lindem (acee) <[email-masked]>
> *Sent:* Thursday, December 9, 2021 1:59 PM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>; Tony Przygienda <
> [email-masked]>
> *Cc:* Tony Li <[email-masked]>; [email-masked]
> *Subject:* Re: [Lsr] Using L1 for Transit Traffic in IS-IS
>
>
>
> Hi Les,
>
>
>
> I know you don’t feel that the IGP should solve this problem but there was
> lots of interest in the three solutions to reduce the overhead when using
> IS-IS L1 as transit for IS- IS L2. Let’s not rehash that.
>
>
>
> *From: *"Les Ginsberg (ginsberg)" <[email-masked]>
> *Date: *Thursday, December 9, 2021 at 2:05 PM
> *To: *Tony Przygienda <[email-masked]>
> *Cc: *Tony Li <[email-masked]>, "[email-masked]" <[email-masked]>, Acee
> Lindem <[email-masked]>
> *Subject: *RE: [Lsr] Using L1 for Transit Traffic in IS-IS
>
>
>
> Two disjoint sets of authors looked at the same problem space and
> independently came up with two different (and incompatible) protocol
> extensions to provide a solution.
>
>
>
> (Aside: I believe fully that both sets of authors have done their best to
> define what they think is a good solution. If anything I have said suggests
> otherwise,  that was not my intent and I apologize to both sets of authors
> for any misunderstanding.)
>
>
>
> We are now being asked to publish both drafts as RFCs (I am assuming based
> on Tony Li’s response that the LC request for Area Proxy is soon to happen.)
>
>
>
> It seems to me that by entertaining a LC request at this point we are
> simply functioning as a pass through to allow multiple individual solutions
> to be published as RFCs. And while there are currently two solutions to the
> same problem space asking to progress, I think we can expect others and we
> have no basis on which to reject other proposals.
>
>
>
> This is very different from how any other work brought before the
> LSR/OSPF/IS-IS WGs has been done in the 20+ years during which I have been
> an active participant.
>
> Sometimes multiple solutions are proposed and there is discussion of both
> which results in choosing one over the other or some sort of merge of the
> solutions.
>
> But I do not recall a case where the WG simply allowed multiple
> non-interoperable solutions to the same problem to be published as RFCs
> largely w/o comment.
>
>
>
> *From:* Tony Przygienda <[email-masked]>
> *Sent:* Wednesday, December 8, 2021 5:27 AM
> *Cc:* Tony Li <[email-masked]>; [email-masked]; Acee Lindem (acee) <
> [email-masked]>
> *Subject:* Re: [Lsr] Using L1 for Transit Traffic in IS-IS
>
>
>
> Les, all sounds to me unfortunately like a gripe (and a late one @ that
> now that things were worked on in WG for years & are ready to RFC being

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 10 Dec 2021 20:46:14 -0500

All

As Acee mentioned per the subject of this thread “Using L1 for transit
traffic in IS-IS” is supported today and is deployed by operators with
large backbones as well today, and both solutions,  area proxy and flood
reflection now allows the L1 transit solution  to scale.

Speaking from an operators perspective we are in favor of multiple
solutions as their maybe use cases where one applies better then the other
and vice versa.  Flexibility is a good thing.

Kind Regards

Gyan

On Fri, Dec 10, 2021 at 1:54 AM Muthu Arul Mozhi Perumal <
[email-masked]> wrote:

>> *To the extent they feel comfortable, I encourage folks who wish to
>> deploy such solutions to share their requirements and discuss how each of
>> the solutions*
>>
>> *address their requirements/fall short of addressing their requirements.
>> I think this would help the WG discover better ways forward.*
>>
>>
>>
>> *<end snip>*
>>
>>
>>
>> I know you don’t feel that the IGP should solve this problem but there
>> was lots of interest in the three solutions to reduce the overhead when
>> using IS-IS L1 as transit for IS- IS L2. Let’s not rehash that.
>>
>>
>>
>> We are now being asked to publish both drafts as RFCs (I am assuming
>> based on Tony Li’s response that the LC request for Area Proxy is soon to
>> happen.)
>>
>>
>>
>> Plus,  unless you have a dramatically better idea than the drafts
>> extended I fail to understand what your point is except as Tony1 says "we
>> should not scale IGP higher?" (AFAIS hierarchy is not an answer here unless
>> you ask customers for a flag day with lots new static configuration
>> everywhere and possibly restructuring of their network to a hard-coded
>> "hierarchy" and albeit such effort may work in some totalitarian countries
>> on in pretty small networks, the majority of large ISIS customers will end
>> such discussions in timeframe of single minutes clock count ;-)
>>
>>
>>
>> -- tony
>>
>>
>>
>> (Changing the subject as Acee has suggested that discussion of the
>> problem space is inappropriate for the WG LC thread)
>>
>>
>>
>> Tony (and everyone) –
>>
>>
>>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 11 Dec 2021 05:23:56 +0000

Gyan –

I am interested in your perspective – but could you provide more details?
What deployment scenarios do you have in mind where one solution is advantageous over the other? And why are both scenarios likely to be seen in the real world?

I think you can appreciate that implementation of either solution is non-trivial – as is insuring interoperability – as is the actual deployment.
What justifies doubling that effort?

Thanx.

    Les

From: Gyan Mishra <[email-masked]>
Sent: Friday, December 10, 2021 5:46 PM
To: Muthu Arul Mozhi Perumal <[email-masked]>
Cc: Acee Lindem (acee) <[email-masked]>; Les Ginsberg (ginsberg) <[email-masked]>; Tony Li <[email-masked]>; Tony Przygienda <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Using L1 for Transit Traffic in IS-IS

All

As Acee mentioned per the subject of this thread “Using L1 for transit traffic in IS-IS” is supported today and is deployed by operators with large backbones as well today, and both solutions,  area proxy and flood reflection now allows the L1 transit solution  to scale.

Speaking from an operators perspective we are in favor of multiple solutions as their maybe use cases where one applies better then the other and vice versa.  Flexibility is a good thing.

Kind Regards

Gyan

On Fri, Dec 10, 2021 at 1:54 AM Muthu Arul Mozhi Perumal <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

It is possible to designate experimental RFCs as historic if there is no evidence of widespread use over a period of time, as is currently being done for HTTP-related experimental RFCs:
https://datatracker.ietf.org/doc/status-change-http-experiments-to-historic/

Hence, I think having multiple experimental publications for a problem is ok..

Regards,
Muthu

On Fri, Dec 10, 2021 at 6:08 AM Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:[email-masked]>> wrote:
Acee –

<snip>

<end snip>

   Les

From: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, December 9, 2021 1:59 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>
Cc: Tony Li <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Using L1 for Transit Traffic in IS-IS

Hi Les,

Thanks,
Acee

Thanx for listening.

   Les

-- tony

Tony (and everyone) –

Thanx for listening,

    Les

Les,

Tony

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 11 Dec 2021 01:56:04 -0500

Hi Les

My thoughts are that as both of these drafts are experimental, if both get
published we can let the industry decide which is to be the preferred
solution which can then progress as standards track to address
interoperability issues with a single solution implemented by vendors.

I think by picking one now over the other we are not letting the cards fall
on the table and prematurely making a decision and not letting things
naturally play out.

I agree the implementation of each is non trivial however the router
configuration could boil down to a simple knob similar to fast flooding.
As an example there maybe use cases that for a DC CLOS topology where area
proxy with n-way ECMP paths leaf to scale out spine maybe better suited,
however in a core or aggregation domain maybe flood reflection maybe
preferred from a topological perspective  during the study phase.

I don’t have a crystal ball but it’s possible just as winning the lottery
is possible that both drafts garnish industry support and from a sales and
marketing perspective vendors can still have their cake and eat it too by
solving a major backbone scalability issue win win for all and so
developing both solutions that become standards track and implemented by
all vendors.  No interoperability issues.

I am in agreement on implementation that in the end having a single
solution is most desirable to avoid interoperability.

Kind Regards

Gyan

On Sat, Dec 11, 2021 at 12:24 AM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> What deployment scenarios do you have in mind where one solution is
> advantageous over the other? And why are both scenarios likely to be seen
> in the real world?
>
>
>
> I think you can appreciate that implementation of either solution is
> non-trivial – as is insuring interoperability – as is the actual deployment.
>
> *From:* Gyan Mishra <[email-masked]>
> *Sent:* Friday, December 10, 2021 5:46 PM
> *To:* Muthu Arul Mozhi Perumal <[email-masked]>
> *Cc:* Acee Lindem (acee) <[email-masked]>; Les Ginsberg (ginsberg) <
> [email-masked]>; Tony Li <[email-masked]>; Tony Przygienda <
> [email-masked]>; [email-masked]
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 11 Dec 2021 16:14:24 +0100

Well WFIW IDR solved this dilemma by mandating at least two documented
implementations before proceeding with any proposal to IESG (irrespective
of the RFC document type).

After all nothing stops anyone from implementing an idea described in the
WG document using if needed early code point allocations.

On the other hand having RFC experimental status of any proposal ensures it
has been reviewed by a number of people and that at least no major issues
have been found during the review.

Of course IGP is not BGP though both use multiple vendors network elements,
but I guess that would narrow the gates of single vendors pushing their own
proprietary solutions via IETF.

Kind regards,
Robert

On Sat, Dec 11, 2021 at 7:56 AM Gyan Mishra <[email-masked]> wrote:

> I think by picking one now over the other we are not letting the cards
> fall on the table and prematurely making a decision and not letting things
> naturally play out.
>
> On Sat, Dec 11, 2021 at 12:24 AM Les Ginsberg (ginsberg) <
> [email-masked]> wrote:
>
>> Gyan –
>>
>>
>>

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 11 Dec 2021 16:26:44 +0100

it's a circular argument to an extent (though I'm sympathetic with the
thought). Unless a draft is an experimental RFC there is no real stable
point to implement & deploy so it's hard these days to get 2
implementations unless one sponsors an open source one (and nature of ISIS
is that there is barely any open source given that it runs normally @ scale
& feature count that open source is simply not efficient enough though I
admit it maybe just my lens to an extent).

So having nothing experimental and nevertheless deployed generates then
de-facto proprietary stuff since deployed solutions become pretty immovable
targets as we all know.

So, take your pick but it's hard to have it both ways these days IMO ...

-- tony

On Sat, Dec 11, 2021 at 4:14 PM Robert Raszuk <[email-masked]> wrote:

> On the other hand having RFC experimental status of any proposal ensures
> it has been reviewed by a number of people and that at least no major
> issues have been found during the review.
>
> Of course IGP is not BGP though both use multiple vendors network
> elements, but I guess that would narrow the gates of single vendors pushing
> their own proprietary solutions via IETF.
>
> Kind regards,
> Robert
>
>> My thoughts are that as both of these drafts are experimental, if both
>> get published we can let the industry decide which is to be the preferred
>>> *The easy road for the WG to take would be to simply allow both drafts
>>> to proceed to Experimental RFCs, but I hope we are able to do more than
>>> this. Multiple solutions place undesirable burdens on vendors and providers
>>> alike.*
>>>
>>>
>>>
>>> (Aside: I believe fully that both sets of authors have done their best
>>> to define what they think is a good solution. If anything I have said
>>> suggests otherwise,  that was not my intent and I apologize to both sets of
>>> authors for any misunderstanding.)
>>>
>>>
>>>
>>> Sometimes multiple solutions are proposed and there is discussion of
>>> both which results in choosing one over the other or some sort of merge of
>>> the solutions.
>>>
>>> This does not mean that either solution is w/o merit – but I do think
>>> the requests for Last Call are premature.
>>>
>>> And we have had very little discussion about the problem space. (not
>>> your fault – certainly you have been willing as have the authors of the
>>> competing draft)
>>>
>>>
>>>
>>> I realize that you are not the one asking for WG LC and I don’t know
>>> when you plan to do so and I am not trying to influence you in that regard.
>>>
>>> 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.”
>>>
>>>
>>>
>>>
>>>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 11 Dec 2021 15:43:05 +0000

Gyan –

Both drafts have been adopted as WG documents and been provided with early allocation of codepoints. So there is nothing preventing implementations/deployments from proceeding and doing so without fear that if/when the documents proceed to become RFCs that there will be backwards compatibility issues because of codepoint changes.
My concern is that there is no effort underway since WG adoption to use implementation experience to compare/contrast the solutions and determine whether one is better and/or if there really is a need for multiple solutions. That seemed to me to be the point of adopting both.
I do not see the need to progress either document to RFC at this time – and I am concerned that in doing so we make it even less likely that such a comparison will ever be made.

I had hoped – as you are a representative of one of the potential users of this technology and you had suggested that there might be reasons why you were interested in both – that you could provide some input into when one solution was more desirable than another.

The value add provided by a standards organization is that it allows the industry to converge on an interoperable solution. If we simply become a means of allocating codepoints in support of multiple non-interoperable solutions then I think we as an organization have failed.
This does not mean that we should not support experimentation – and in this case I think we are doing so.

   Les

From: Gyan Mishra <[email-masked]>
Sent: Friday, December 10, 2021 10:56 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Acee Lindem (acee) <[email-masked]>; Muthu Arul Mozhi Perumal <[email-masked]>; Tony Li <[email-masked]>; Tony Przygienda <[email-masked]>; [email-masked]
Subject: Re: [Lsr] Using L1 for Transit Traffic in IS-IS

Hi Les

My thoughts are that as both of these drafts are experimental, if both get published we can let the industry decide which is to be the preferred solution which can then progress as standards track to address interoperability issues with a single solution implemented by vendors.

I think by picking one now over the other we are not letting the cards fall on the table and prematurely making a decision and not letting things naturally play out.

I agree the implementation of each is non trivial however the router configuration could boil down to a simple knob similar to fast flooding.  As an example there maybe use cases that for a DC CLOS topology where area proxy with n-way ECMP paths leaf to scale out spine maybe better suited, however in a core or aggregation domain maybe flood reflection maybe preferred from a topological perspective  during the study phase.

I don’t have a crystal ball but it’s possible just as winning the lottery is possible that both drafts garnish industry support and from a sales and marketing perspective vendors can still have their cake and eat it too by solving a major backbone scalability issue win win for all and so developing both solutions that become standards track and implemented by all vendors.  No interoperability issues.

I am in agreement on implementation that in the end having a single solution is most desirable to avoid interoperability.

Kind Regards

Gyan

On Sat, Dec 11, 2021 at 12:24 AM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
Gyan –

Thanx.

    Les

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: Friday, December 10, 2021 5:46 PM
To: Muthu Arul Mozhi Perumal <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>; Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>; Tony Przygienda <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] Using L1 for Transit Traffic in IS-IS

All

Kind Regards

Gyan

Regards,
Muthu

<snip>

<end snip>

   Les

Hi Les,

Thanks,
Acee

Thanx for listening.

   Les

-- tony

Tony (and everyone) –

Thanx for listening,

    Les

Les,

Tony

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 11 Dec 2021 16:57:58 +0100

Hey Les,

I think you are making a very valid point. Especially important in
the context of link state protocols.

To illustrate perhaps even better your point, let's assume there is a
customer who is not a single vendor one. So assume he is using vendor J
with reflection and vendor's A with proxy. And now he comes to vendor C and
is asking to implement both solutions for him.

Well you can say no.

But if you really want to grab some business from this customer your folks
selling stuff may say yes (without even asking for opinion) and then you
are stuck with implementing both which in spite of solving the same problem
makes the complexity to translate or at least interact with each
other exponentially more complex if at all possible.

Of course you can also invent your own third one and push to RFC status as
experimental.

But none of this actually helps the protocol.

Best,
R.

On Sat, Dec 11, 2021 at 4:43 PM Les Ginsberg (ginsberg) <ginsberg=
[email-masked]> wrote:

> Gyan –
>
>
>
> Both drafts have been adopted as WG documents and been provided with early
> allocation of codepoints. So there is nothing preventing
> implementations/deployments from proceeding and doing so without fear that
> if/when the documents proceed to become RFCs that there will be backwards
> compatibility issues because of codepoint changes.
>
> My concern is that there is no effort underway since WG adoption to use
> implementation experience to compare/contrast the solutions and determine
> whether one is better and/or if there really is a need for multiple
> solutions. That seemed to me to be the point of adopting both.
>
> I do not see the need to progress either document to RFC at this time –
> and I am concerned that in doing so we make it even less likely that such a
> comparison will ever be made.
>
>
>
> I had hoped – as you are a representative of one of the potential users of
> this technology and you had suggested that there might be reasons why you
> were interested in both – that you could provide some input into when one
> solution was more desirable than another.
>
>
>
> The value add provided by a standards organization is that it allows the
> industry to converge on an interoperable solution. If we simply become a
> means of allocating codepoints in support of multiple non-interoperable
> solutions then I think we as an organization have failed.
>
> *Sent:* Friday, December 10, 2021 10:56 PM
> *Cc:* Acee Lindem (acee) <[email-masked]>; Muthu Arul Mozhi Perumal <
> [email-masked]>; Tony Li <[email-masked]>; Tony Przygienda <

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 12 Dec 2021 01:02:46 -0500

Les

As co-author of the Area Proxy solution I support progressing Area Proxy
and can give some of my un-biased  reasons why Area Proxy would be more
beneficial over Flood Reflection from an operators POV.

Area proxy does provide a very elegant and simple easily deployable
solution to scale the backbone by providing a complete abstraction of the
Level 1 area topology within the Level 2 topology.

Flood Reflection tunneling hints at RFC 9012 BGP Tunnel encapsulation
attribute but is agnostic to tunnel type for the control plane flooding or
no tunneling with flood scoping to cut down on the flood adjacencies in the
backbone.

>From an Operators POV, in general are not fond of tunneling as being part
of the solution unless its a a bandaid patch to solve a problem, having to
account now for MTU packet transport  overhead. Another caveat with tunnels
is sub optimal routing and possible 1 hop short cuts that may not be
desirable which is described in the draft that could result in routing
loops.  Costing up the flood Reflection path is a workaround.

BGP Free MPLS / SR core where the RR sits in control plane outside of the
E2E data plane forwarding plane is a BGP free core design requirement and
as well for BGP MVPN, EVPN procedures which the control plane is separate
from the data plane, so is a inherent requirement for BGP.  Separation of
the IGP flooding function from the forwarding plane is quite a change to
normal IGP operation where the control plane and forwarding plane paths are
the same.

The flood reflectors can sit in the control plane so not in the forwarding
plane or can be in the forwarding plane with L1 or L2 shortcut.  So all
paths including the flood Reflector path can be used for forwarding,
however do to 1 hop L1 and L2 shortcut the flood reflector path can be
bumped up in coast so not preferred to prevent choking the flood reflectors
similar to issue where we exclude the BGP RR from forwarding plane so we
don’t choke the RR. My worry is the sub optimal routing from the 1 hop
tunnels could lead to routing loops of which as mentioned the workaround is
to cost high  the flood reflector path so it’s only used for control plane
flooding.

Responses in-line

Kind Regards

Gyan

On Sat, Dec 11, 2021 at 10:43 AM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> allocation of codepoints.
>
    Gyan> As co-author I am aware

> So there is nothing preventing implementations/deployments from proceeding
> and doing so without fear that if/when the documents proceed to become RFCs
> that there will be backwards compatibility issues because of codepoint
> changes.
>
   Gyan>  In my response here I tried to  provide an unbiased compare and
contrast of the two solutions.

 Gyan> I did the comparison above and I can further elaborate

 Gyan> Just to clarify that as an operator this is scalability issue is a
real world problem that needs to be solved.  As I am Co-Author of the Area
Proxy draft I truly believe that is a better solution, however this is a
solution that definitely needs solved..

The value add provided by a standards organization is that it allows the
industry to converge on an interoperable solution. If we simply become a
means of allocating codepoints in support of multiple non-interoperable
solutions then I think we as an organization have failed.
    Gyan> Agreed.  Interoperability is critical for all operators and is
what makes SDOs so valuable

> This does not mean that we should not support experimentation – and in
this case I think we are doing so.

 Gyan> Agreed.  And be able to progress both experimental to RFC and let
the industry decide on the best solution and then progress that solution as
standards track

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Tony Przygienda <[email-masked]>
Date: Sun, 12 Dec 2021 16:17:39 +0100

there is good amount of valid points your're making but it's worth pointing
out a couple things as well:

Area proxy is basically a first step of building a virtual chassis. That
has been tried before and lessons learned. It's not a free lunch by a long
stretch ;-)  It has lots going for it I just point a bunch things about the
not-so-free-lunch ;-) below:

AFAIS sub-optimal problem will be same or worse in area proxy simply given
the fact that whatever you do, you're hiding topology & with that cannot
make optimal decisions e2e and may choose suboptimal ingress into an area
for a destination (in terms e.g. of number hops traversed). Just think a
bit through ECMP problems involved and you will see that they look very
similar to flood reflection.

The new LSP seems to imply a forklift of the whole network which area proxy
does not require, in fact flood reflection has been carefully constructed
to touch minimum possible amount of nodes in the network and additionally
allow a node-by-node migration.  And this is e.g. one of the reason why we
chose NOT to change SPF rules for nodes "inside" the flood reflection
cluster along the lines of area proxy which would have made the forwarding
problem simpler ;-) Also, AFAIS area proxy preconditions far more
configuration that has to be "just so" on interfaces and nodes and it has
to align L1 and L2 carefully by e.g. preconditioning which interfaces are
in and whjich are out.

The "area lead" is same thing pretty much as PGL in PNNI and will exhibit
its own set of complexities the draft does not address yet. I know it's
terse statement ;-)

Just purely as personal experience and subjective view, I didn't see
implementation of area proxy yet & depending what overall system features
you expect to work with it I would venture the implementation complexity
will be significantly higher than flood reflection. Because the draft seems
to "read simpler" is not correlated with simplicity in resulting
implementation and deployment complexity in terms of system wide features
you expect to work ;-) As simple exercise, think how would you synchronize
the overload bit on startup to prevent the system trying to forward before
all nodes (which may be mix of different systems) in area proxy have the
necessary FIB ;-) Or what happens if someone manages to set overload within
the area & partition it (not hypothetical, real customer discussions from
hands-on operational experience).

One thing you got factually wrong is that shortcuts with flood reflection
will not lead to loops if that's what you were implying. Yes, the rules
need to be read and thought through carefully but they work from direct
experience here on many cases/scenarios (and having done MT & bunch things
like that I'm decently confident in the underlying algebra of those rules).

So overall, yeah, I hear your voice on allowing experimanl RFC on both &
let the stuff run and I agree. But for a different reason, slightly there
is no "better" solution here, you have two solutions that meet very
different set of requirements and present different operational/engineering
trade-off. Not everyone drives a minivan, but not everyone drives a cabrio
either ...

-- tony

On Sun, Dec 12, 2021 at 7:02 AM Gyan Mishra <[email-masked]> wrote:

> of the solution unless its a a bandaid patch to solve a problem, having
> to account now for MTU packet transport  overhead. Another caveat with
> tunnels is sub optimal routing and possible 1 hop short cuts that may not
> be desirable which is described in the draft that could result in routing
> On Sat, Dec 11, 2021 at 10:43 AM Les Ginsberg (ginsberg) <
>> Both drafts have been adopted as WG documents and been provided with
>> early allocation of codepoints.
>>
>> So there is nothing preventing implementations/deployments from
>> proceeding and doing so without fear that if/when the documents proceed to
>> become RFCs that there will be backwards compatibility issues because of
>> codepoint changes.
>>

---

From: Tony Li <[email-masked]>
Date: Sun, 12 Dec 2021 09:21:59 -0800

Tony,

> The new LSP seems to imply a forklift of the whole network which area proxy does not require, in fact flood reflection has been carefully constructed to touch minimum possible amount of nodes in the network and additionally allow a node-by-node migration.

To be accurate, area proxy requires that the nodes within the area support area proxy.  No upgrade of the nodes outside of the abstracted area is required. Only software upgrades are requires, so no forklifts are required.

> Also, AFAIS area proxy preconditions far more configuration that has to be "just so" on interfaces and nodes and it has to align L1 and L2 carefully by e.g. preconditioning which interfaces are in and whjich are out. 

Understanding which interfaces are an area boundary is expedient for not having changes at adjacency formation time. IS-IS is quite flexible and will happily allow L1 and L2 adjacencies in any combination to co-exist on a single LAN. In the Arista implementation, we found it helpful to have additional specific configuration to explicitly understand the intended abstraction. Other implementations may not require this. We have yet to see any issue with this in a practical network.

> The "area lead" is same thing pretty much as PGL in PNNI and will exhibit its own set of complexities the draft does not address yet. I know it's terse statement ;-) 

Not only is it terse, it’s content free. If you have no issues that you can cite, then this is simply Fear, Uncertainty, and Doubt. 

> Just purely as personal experience and subjective view, I didn't see implementation of area proxy yet & depending what overall system features you expect to work with it I would venture the implementation complexity will be significantly higher than flood reflection.

You don’t have any information, but you want us to believe your opinion.

> Because the draft seems to "read simpler" is not correlated with simplicity in resulting implementation and deployment complexity in terms of system wide features you expect to work ;-) As simple exercise, think how would you synchronize the overload bit on startup to prevent the system trying to forward before all nodes (which may be mix of different systems) in area proxy have the necessary FIB ;-)

No synchronization is required. If an L1L2 system within the abstracted area has the overload bit set, then its information is not included in the proxy LSP.

> Or what happens if someone manages to set overload within the area & partition it (not hypothetical, real customer discussions from hands-on operational experience). 

Partition of the area has been a longstanding problem within IS-IS and has never had an acceptable solution. Area Proxy does not claim to fix the problem. As with legacy IS-IS, operators understand this and create sufficient redundancy within the area so that the odds of a partition are extremely low. In the case of a modern data center as the abstracted area, there can easily be 128 way redundancy, so the odds of a partition are already minimal.

Tony

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 13 Dec 2021 08:44:46 +0100

On Sun, Dec 12, 2021 at 6:22 PM Tony Li <[email-masked]> wrote:

>
> Tony,
>
>
> > The new LSP seems to imply a forklift of the whole network which area
> proxy does not require, in fact flood reflection has been carefully
> constructed to touch minimum possible amount of nodes in the network and
> additionally allow a node-by-node migration.

>
> To be accurate, area proxy requires that the nodes within the area support
> area proxy.  No upgrade of the nodes outside of the abstracted area is
> required. Only software upgrades are requires, so no forklifts are required.
>
>
I re-read carefully and yes, I do stand corrected. only nodes in area need
to be upgraded

-- tony