Subject: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

From: Christian Hopps <[email-masked]>
Date: Wed, 10 Jun 2020 15:27:53 -0400

This begins a 2 week WG adoption call for the following draft:

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

The draft would be adopted on the Experimental track.

Please indicate your support or objection by June 24, 2020.

Authors, please respond to the list indicating whether you are aware of any IPR that applies to this draft.

Thanks,
Chris and Acee.

---

From: Tony Li <[email-masked]>
Date: Wed, 10 Jun 2020 12:37:24 -0700

> On Jun 10, 2020, at 12:27 PM, Christian Hopps <[email-masked]> wrote:
> 

Support, as author.

IPR has been filed: https://datatracker.ietf.org/ipr/4016/ <https://datatracker.ietf.org/ipr/4016/>

Tony

---

From: <[email-masked]>
Date: Thu, 11 Jun 2020 08:08:36 +0000

Hi Chris, Acee,

I support adoption.
I've provided comments on the draft a couple of days ago.

Regards,
--Bruno

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: Wednesday, June 10, 2020 9:28 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Christian Hopps
Subject: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

Thanks,
Chris and Acee.

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 11 Jun 2020 11:32:48 +0200

Support.

Thx,
R.

---

From: Sarah Chen <[email-masked]>
Date: Thu, 11 Jun 2020 11:32:35 -0700

Support, as co-author.

Thanks,
Sarah

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 11 Jun 2020 19:46:23 +0000

Thanks Sarah – as a co-author, please state your awareness of IPR.
Acee

From: Sarah Chen <[email-masked]>
Date: Thursday, June 11, 2020 at 2:34 PM
To: Robert Raszuk <[email-masked]>
Cc: Christian Hopps <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06
Resent-From: <[email-masked]>
Resent-To: Christian Hopps <[email-masked]>, Acee Lindem <[email-masked]>, Yingzhen Qu <[email-masked]>
Resent-Date: Thursday, June 11, 2020 at 2:33 PM

Support, as co-author.

Thanks,
Sarah

On Thu, Jun 11, 2020 at 2:33 AM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Support.

Thx,
R.

On Wed, Jun 10, 2020 at 9:28 PM Christian Hopps <[email-masked]<mailto:[email-masked]>> wrote:
This begins a 2 week WG adoption call for the following draft:

Thanks,
Chris and Acee.

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

---

From: Sarah Chen <[email-masked]>
Date: Thu, 11 Jun 2020 15:13:13 -0700

I am not aware of any other related IPR, except for the one Tony mentioned:
https://datatracker.ietf.org/ipr/4016/ .

Thanks,
Sarah

On Thu, Jun 11, 2020 at 12:46 PM Acee Lindem (acee) <[email-masked]> wrote:

> *From: *Sarah Chen <[email-masked]>
> *Date: *Thursday, June 11, 2020 at 2:34 PM
> *To: *Robert Raszuk <[email-masked]>
> *Cc: *Christian Hopps <[email-masked]>, "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06
> *Resent-From: *<[email-masked]>
> *Resent-To: *Christian Hopps <[email-masked]>, Acee Lindem <
> [email-masked]>, Yingzhen Qu <[email-masked]>
> *Resent-Date: *Thursday, June 11, 2020 at 2:33 PM
>
>
>
> Support, as co-author.
>
>
>
> Thanks,
>
> Sarah
>
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 13 Jun 2020 20:11:39 +0000

Speaking as WG  member:

I support WG adoption of this draft on the experimental track. I think it is better for the WG to move forward and get some data points on these competing solutions than to be gridlocked.

Thanks,
Acee

On 6/10/20, 3:28 PM, "Christian Hopps" <[email-masked]> wrote:

    Thanks,
    Chris and Acee.

---

From: Henk Smit <[email-masked]>
Date: Mon, 15 Jun 2020 12:45:36 +0200

I support the area-proxy draft.

I think both the area-proxy draft and the flood-reflection drafts are
a bit hacky. However, the result of the area-proxy draft has a certain
elegance: only one L2 LSP per area in the backbone.

The flood-reflection draft is just messy, imho.
1) The edge-routers of each area are still visible in L2.
Making the L2 scaling benefits a factor less, compared to area-proxy.
2) You need a new tunneling technology to flood LSPs between
edge-routers and the flood-reflector. Even when you simply use TCP,
this adds new and unnecessary complexity.
3) You either need to tunnel user-traffic between edge-routers.
Or you redistribute all L2 prefixes into L1. Negating the benefit of
having L1-only routers in your transit area. I don't like either option.

BTW, personally I think the proper solution to scale IS-IS to larger
networks is 8 levels of hierarchy. Too bad that idea gets so little
push from vendors and operators.

henk.

---

From: [email-masked]
Date: Mon, 15 Jun 2020 08:12:02 -0700

> On Jun 15, 2020, at 3:45 AM, Henk Smit <[email-masked]> wrote:
> 

Hi Henk,

It’s very clear that this is inadequate.  The structure of legacy IS-IS areas effectively precludes a scalable network for using lower levels for transit. This constrains ISPs to ‘cauliflower’ topology where you have L1 on the outside, L2 just inside of L1, L3 inside of L2, etc.  

We already see networks who are unwilling to use the two levels that we have today due to this constraint.

Regards,
Tony

---

From: Henk Smit <[email-masked]>
Date: Mon, 15 Jun 2020 18:08:59 +0200

> It’s very clear that this is inadequate.

It's not so clear to me, sorry.
Does anyone have an example (link or jpg) of a (sensible) topology
that would not work with multiple levels of hierarchy, but works
nicely/better with area-proxies (or FRs) ? Just curious.

> The structure of legacy
> IS-IS areas effectively precludes a scalable network for using lower
> levels for transit. This constrains ISPs to ‘cauliflower’ topology
> where you have L1 on the outside, L2 just inside of L1, L3 inside of
> L2, etc.

I understand. L1-8 forces a hierarchical network designs.
But even if one would have the tools to design a non-hierarchical
network, that doesn't mean one should do so. :-)

> we have today due to this constraint.

I think L1-8 levels would be a good starting principle for designing 
large networks.
If there are spots in the network where the hierarchical constraints
are a problem in the real world, indeed it would be nice to have tools
like area-proxies in the tool-set, to help solve those problems.

I would like to have both tools.
I think you do too (as you are author of both drafts).

henk.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 15 Jun 2020 18:19:39 +0200

Hi Tony,

> It’s very clear that this is inadequate.

Doesn't this really depend how you architect multiple levels ? Sure you
have some physical topology - but it seems to me that the trick is in
properly laying out levels on top of them and between them.

To my original question - how many levels can you run on the physical box ?
And can levels be locally and logically interconnected ?

Then of course if you have applications (MPLS exact FEC match or SR-MPLS
with SRLBs) which do not allow any aggregation you are pretty much stuck no
matter what :).

Rgs,
R.

On Mon, Jun 15, 2020 at 5:12 PM <[email-masked]> wrote:

> It’s very clear that this is inadequate.  The structure of legacy IS-IS
> areas effectively precludes a scalable network for using lower levels for
> transit. This constrains ISPs to ‘cauliflower’ topology where you have L1
> on the outside, L2 just inside of L1, L3 inside of L2, etc.
>

---

From: [email-masked]
Date: Mon, 15 Jun 2020 10:27:35 -0700

Hi Henk,

> nicely/better with area-proxies (or FRs) ? Just curious.

Certainly.  Draw a 3x3 grid with nodes at each intersection.

Replace each node with an L1 area.

Image: https://upload.wikimedia.org/wikipedia/commons/0/0f/Figure_11-_a_three_by_three_grid.png

> network, that doesn't mean one should do so. :-)

Hierarchical abstraction is a fine thing, but traffic cannot be constrained to be hierarchical. Doing so forces the top of the hierarchy to have capacity that is greater than lower levels. Pragmatically, we can’t build things that have infinite capacity, so we have to make do with finite sized switching elements. Fortunately Clos taught us how to do this. :-)

The result is that we need to have transit areas.

> I think you do too (as you are author of both drafts).

I concur.

Tony

---

From: [email-masked]
Date: Mon, 15 Jun 2020 10:37:30 -0700

Hi Robert,

> Doesn't this really depend how you architect multiple levels ? Sure you have some physical topology - but it seems to me that the trick is in properly laying out levels on top of them and between them. 

The very pragmatic viewpoint is that network architects will construct the physical topology that best suits their traffic pattern and that trying to contort that physical topology into some kind of hierarchy will create additional (and perhaps significant) cost.  People don’t want to do that.  They want scalable networks that match their physical topology.  For this to work, our hierarchical abstractions need to be independent of the topology and that forces us into having transit areas.

> To my original question - how many levels can you run on the physical box ? And can levels be locally and logically interconnected ? 

The constraint on a physical box is the amount of memory and CPU.  Running 8 levels, each with 1000 LSPs per level is not out of the realm of doable within the next decade.

Yes, levels can be logically interconnected through higher levels.

I don’t understand what you mean by ‘locally interconnected’.

> Then of course if you have applications (MPLS exact FEC match or SR-MPLS with SRLBs) which do not allow any aggregation you are pretty much stuck no matter what :).

Broken architectures are everywhere. Folks that have solutions that do not allow for a hierarchical control plane are necessarily going to have issues. Hierarchy is the only tool that we have to fight scalability.

Tony

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 15 Jun 2020 10:56:42 -0700

On Mon, Jun 15, 2020 at 10:37 AM <[email-masked]> wrote:

> The very pragmatic viewpoint is that network architects will construct the
> physical topology that best suits their traffic pattern and that trying to
> contort that physical topology into some kind of hierarchy will create
> additional (and perhaps significant) cost.  People don’t want to do that.
> They want scalable networks that match their physical topology.  For this
> to work, our hierarchical abstractions need to be independent of the
> topology and that forces us into having transit areas.
>
>
>
PNNI had transit areas in hierarchy working but the trick was connection
setup cranck-back. Such a thing would work for RSVP or any of the stateful
connection setups but alas, this is not fashionable right now.
Unfortunately, generic hierarchy with reachability summarization ends up
with very sub-optimal routing or black-holing on aggregates since we cannot
"back-off" generic LPM packet forwarding when we realize we're @ a dead end
due to aggregation. To prevent bi-furcation of topology or transit
horizontals several solutions exist, one of which (configure hierarchy
statically everywhere) the current draft has in now but alas, the topology
is star of stars (you can actually see CLOS conceptually as something like
this as well ;-)

my meta 2c

-- tony

---

From: [email-masked]
Date: Mon, 15 Jun 2020 11:01:47 -0700

> On Jun 15, 2020, at 10:56 AM, Tony Przygienda <[email-masked]> wrote:
> 
> PNNI had transit areas in hierarchy working but the trick was connection setup cranck-back. Such a thing would work for RSVP or any of the stateful connection setups but alas, this is not fashionable right now. Unfortunately, generic hierarchy with reachability summarization ends up  with very sub-optimal routing or black-holing on aggregates since we cannot "back-off" generic LPM packet forwarding when we realize we're @ a dead end due to aggregation. To prevent bi-furcation of topology or transit horizontals several solutions exist, one of which (configure hierarchy statically everywhere) the current draft has in now but alas, the topology is star of stars (you can actually see CLOS conceptually as something like this as well ;-)

Hi Tony,

The modern solution of choice is to relegate all of the traffic engineering to an out-of-band controller that no longer operates in real-time and has the scale to span levels and areas.

Tony

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 15 Jun 2020 11:23:18 -0700

yepp, it's one philosophy and design point which I'm  quite well aware off
;-) and it's feasible of course that instead of a signalling protocol or
even SR the controller provisions all paths via e.g. PCE of course if one
can live with the delay and implications of large scale failures. If we
rely on controller fixing LPM as well under failures then really, who needs
IGPs anymore anyway except for bunch of loopbacks and SPF for the
controller to do all the FIB work and hence discussions like high
hierarchies or anisotropic routing are largely superfluous me thinks ;-)

-- tony

On Mon, Jun 15, 2020 at 11:01 AM <[email-masked]> wrote:

> The modern solution of choice is to relegate all of the traffic
> engineering to an out-of-band controller that no longer operates in
> real-time and has the scale to span levels and areas.
>
> Tony
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 15 Jun 2020 20:24:43 +0200

Tony P,

> or black-holing on aggregates since we cannot "back-off" generic LPM
packet forwarding when we
> realize we're @ a dead end due to aggregation.

I hope you are not stating that aggregation is a bad thing here and all we
should be distributing are host routes :)

But to your point - IGP is a servant to the application/service which is
BGP. So removal of BGP service routes in a topology independent fashion can
be really fast and take one or two hops. Assume we detect failure of a
remote node - I am not sure if BGP will withdraw service routes faster
across two RRs or IGP will remove next hop by flooding via area over N
nodes then crossing ABR or ASBR and flooding again over N nodes will be any
faster.

Last time I measured the speed of BGP transit of withdraw message via
control plane only RR with decent BGP implementation it was in ranges of
ms.

Thx,
R.

On Mon, Jun 15, 2020 at 7:57 PM Tony Przygienda <[email-masked]> wrote:

>> The very pragmatic viewpoint is that network architects will construct
>> the physical topology that best suits their traffic pattern and that trying
>> to contort that physical topology into some kind of hierarchy will create

---

From: [email-masked]
Date: Mon, 15 Jun 2020 11:32:23 -0700

Tony,

> If we rely on controller fixing LPM as well under failures then really, who needs IGPs anymore anyway except for bunch of loopbacks and SPF for the controller to do all the FIB work and hence discussions like high hierarchies or anisotropic routing are largely superfluous me thinks ;-) 

A fair point that many seem to agree with. The IGP provides topology for the controller and it simply dominates the control plane. The issue, of course, is recovery.  The IGP is still a necessity to provide reachability to the controller and to deal with failure recovery. 

I agree that people who do go down the controller path may avoid certain issues. It also seems to be true that folks who avoid the controller path avoid other issues.

Choose your battles…

T

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 16 Jun 2020 00:54:58 -0400

I support WG adoption of this draft as experimental track.

Kind regards

Gyan

On Mon, Jun 15, 2020 at 2:32 PM <[email-masked]> wrote:

>
> Tony,
>
> > If we rely on controller fixing LPM as well under failures then really,
> who needs IGPs anymore anyway except for bunch of loopbacks and SPF for the
> A fair point that many seem to agree with. The IGP provides topology for
> the controller and it simply dominates the control plane. The issue, of
> course, is recovery.  The IGP is still a necessity to provide reachability
> to the controller and to deal with failure recovery.
>
> I agree that people who do go down the controller path may avoid certain
> issues. It also seems to be true that folks who avoid the controller path
> avoid other issues.
>
> Choose your battles…
>
> T
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 21 Jun 2020 14:36:18 +0000

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.

I am not yet overly enthused about approaches which promote non-hierarchical network architectures. But it seems clear that there is interest in deploying non-hierarchical solutions and both drafts present solutions
which merit further evaluation.

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.

   Les

> From: Lsr <[email-masked]> On Behalf Of Christian Hopps
> Sent: Wednesday, June 10, 2020 12:28 PM
> To: [email-masked]
> <[email-masked]>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 24 Jun 2020 10:17:47 -0400

I support adoption on experimental track. 

Sue Hares 

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Saturday, June 13, 2020 4:12 PM
To: Christian Hopps; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

Speaking as WG  member:

Thanks,
Acee

    Thanks,
    Chris and Acee.

---

From: Christian Hopps <[email-masked]>
Date: Mon, 29 Jun 2020 17:09:55 -0400

The work is adopted.

Authors, please resubmit with new name draft-ietf-lsr-isis-area-proxy and updating the track to experimental.

Thanks,
Chris.

> On Jun 10, 2020, at 3:27 PM, Christian Hopps <[email-masked]> wrote:
>