Re: [Lsr] Request WG adoption of TTZ

[Tianran Zhou]

Hi Henk,

"Adding a new concept, with very little benefit, hurts the protocol in the long 
run. The ability to abstract an area, and not also a zone, is strong enough to 
be worthwhile, imho."

Your conclusion here seems very subjective.
What's the criterion the evaluate the benefit? What I see the TTZ does have 
benefit.
I am also wandering how it hurts the protocol in the long run?


Tianran


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Henk Smit
Sent: Wednesday, July 15, 2020 8:22 PM
To: Huaimo Chen 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Huaimo Chen wrote on 2020-07-14 06:09:

>  2). IS-IS TTZ abstracts a zone to a single node. A zone is any target 
> block or piece of an IS-IS area, which is to be abstracted. This seems 
> more flexible and convenient to users.

I don't agree that this convenience is really beneficial.
I actually think this convenience is a downside.


Link-state protocols are not easy to understand. And we already have the 
misfortune that IS-IS and OSPF use different names for things.
Adding the new concept of a "zone", while we already have the concept of an 
area makes things only more complex.

How often will this new flexibility be used in the real world ?
I still haven't seen an answer to Christian Hopp's simple question:
"Has RFC8099 been deployed by anyone ?"
Anyone who has an answer ?

My favorite rule of RFC1925 is rule 12:
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.

Adding a new concept, with very little benefit, hurts the protocol in the long 
run. The ability to abstract an area, and not also a zone, is strong enough to 
be worthwhile, imho.

henk.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request WG adoption of TTZ

[Uma Chunduri]

Acee,

In-line ..

On Wed, Jul 15, 2020 at 10:14 AM Acee Lindem (acee)  wrote:

> Speaking as WG member…
>
>
>
> See inline.
>
>
>
> *From: *Lsr  on behalf of Uma Chunduri <
> umac.i...@gmail.com>
> *Date: *Wednesday, July 15, 2020 at 12:52 PM
> *To: *Henk Smit 
> *Cc: *"lsr@ietf.org" , Huaimo Chen <
> huaimo.c...@futurewei.com>
> *Subject: *Re: [Lsr] Request WG adoption of TTZ
>
>
>
>
>
>
>
> On Wed, Jul 15, 2020 at 5:22 AM Henk Smit  wrote:
>
> Huaimo Chen wrote on 2020-07-14 06:09:
>
> >  2). IS-IS TTZ abstracts a zone to a single node. A zone is any target
> > block or piece of an IS-IS area, which is to be abstracted. This seems
> > more flexible and convenient to users.
>
> I don't agree that this convenience is really beneficial.
>
> I actually think this convenience is a downside.
>
>
>
> I actually think not  having more configuration across the network to
> enable a new feature is more useful even if
>
> you don't do this operation every single day (especially if you want to
> roll back).
>
>
>
>
>
> Link-state protocols are not easy to understand. And we already
> have the misfortune that IS-IS and OSPF use different names for things.
> Adding the new concept of a "zone", while we already have the
> concept of an area makes things only more complex.
>
>
>
> Agree in general.
>
>
>
> I would say this is no more complex than what has been adopted already or
> the slew of proposals we have been seeing here.
>
>
>
> I too think as some other said we should have ideally adopted only one
> proposal by merging whatever possible.
>
> As  that is not the case and 2 parallel proposals have already been
> accepted as WG experimental track, and given the interest/support on this
> particular topic
>
> I would think it's reasonable to continue this experiment in IS-IS too as
> is done in OSPF.
>
>
>
> I think that the two proposals that have already been adopted as
> experimental are VERY different in the way they solve the problem of better
> LSDB scalability across an IS-IS routing domain.
>

You are right, of course. IS-IS TTZ draft focuses on abstracting a zone
(i.e., block) of an IS-IS area to a single node.

RFC 8099 is for abstracting a zone of an OSPF area to its edges full mesh.
So, afais, IS-IS TTZ is much better than RFC 8099 regarding improving
network scalability.


Conversely, now that the IS-IS TTZ has adopted the Area Proxy mechanisms of
> having an Area/Zone leader generate a single LSP representing the
> Area/Zone, the two proposals are very similar.
>

Thanks for pointing this;


> I agree with Henk, Les, and John that the purported advantages of TTZ are
> not required.
>
These advantages being arbitrary abstraction boundaries and a description
> of the transition mechanisms.
>

I would leave this to folks who want to deploy, if these advantages matter
for them or not matter much.

Thank you!

--
Uma C.


>
>
> Thanks,
> Acee
>
>
>
>
>
> --
>
> Uma C.
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request WG adoption of TTZ

[Acee Lindem (acee)]

Speaking as WG member…

See inline.

From: Lsr  on behalf of Uma Chunduri 
Date: Wednesday, July 15, 2020 at 12:52 PM
To: Henk Smit 
Cc: "lsr@ietf.org" , Huaimo Chen 
Subject: Re: [Lsr] Request WG adoption of TTZ



On Wed, Jul 15, 2020 at 5:22 AM Henk Smit 
mailto:henk.i...@xs4all.nl>> wrote:
Huaimo Chen wrote on 2020-07-14 06:09:

>  2). IS-IS TTZ abstracts a zone to a single node. A zone is any target
> block or piece of an IS-IS area, which is to be abstracted. This seems
> more flexible and convenient to users.

I don't agree that this convenience is really beneficial.
I actually think this convenience is a downside.

I actually think not  having more configuration across the network to enable a 
new feature is more useful even if
you don't do this operation every single day (especially if you want to roll 
back).


Link-state protocols are not easy to understand. And we already
have the misfortune that IS-IS and OSPF use different names for things.
Adding the new concept of a "zone", while we already have the
concept of an area makes things only more complex.

Agree in general.

I would say this is no more complex than what has been adopted already or the 
slew of proposals we have been seeing here.

I too think as some other said we should have ideally adopted only one proposal 
by merging whatever possible.
As  that is not the case and 2 parallel proposals have already been accepted as 
WG experimental track, and given the interest/support on this particular topic
I would think it's reasonable to continue this experiment in IS-IS too as is 
done in OSPF.

I think that the two proposals that have already been adopted as experimental 
are VERY different in the way they solve the problem of better LSDB scalability 
across an IS-IS routing domain. Conversely, now that the IS-IS TTZ has adopted 
the Area Proxy mechanisms of having an Area/Zone leader generate a single LSP 
representing the Area/Zone, the two proposals are very similar. I agree with 
Henk, Les, and John that the purported advantages of TTZ are not required. 
These advantages being arbitrary abstraction boundaries and a description of 
the transition mechanisms.

Thanks,
Acee


--
Uma C.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request WG adoption of TTZ

[Uma Chunduri]

On Wed, Jul 15, 2020 at 5:22 AM Henk Smit  wrote:

> Huaimo Chen wrote on 2020-07-14 06:09:
>
> >  2). IS-IS TTZ abstracts a zone to a single node. A zone is any target
> > block or piece of an IS-IS area, which is to be abstracted. This seems
> > more flexible and convenient to users.
>
> I don't agree that this convenience is really beneficial.
>
I actually think this convenience is a downside.
>

I actually think not  having more configuration across the network to
enable a new feature is more useful even if
you don't do this operation every single day (especially if you want to
roll back).


Link-state protocols are not easy to understand. And we already
> have the misfortune that IS-IS and OSPF use different names for things.
> Adding the new concept of a "zone", while we already have the
> concept of an area makes things only more complex.
>

Agree in general.

I would say this is no more complex than what has been adopted already or
the slew of proposals we have been seeing here.

I too think as some other said we should have ideally adopted only one
proposal by merging whatever possible.
As  that is not the case and 2 parallel proposals have already been
accepted as WG experimental track, and given the interest/support on this
particular topic
I would think it's reasonable to continue this experiment in IS-IS too as
is done in OSPF.

--
Uma C.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request WG adoption of TTZ

[Richard Li]

I support the adoption of the IS-IS TTZ draft.

Using TTZ it is straightforward and easy to turn a zone into a single 
virtualized node. TTZ can provably achieve  topology complexity reduction and 
scalability enhancement. The operation is simple, and the customer experience 
is enhanced. Its benefit weighs more than its cost. The LSR should let the work 
on TTZ move forward.

Stay safe and healthy, everyone!

Thanks,

Richard



> On Thu, Jun 18, 2020 at 11:38 PM Huaimo Chen 
>  wrote:
>
> Hi Chris and Acee, and everyone,
>
>
>
> I would like to request working group adoption of "Topology-Transparent 
> Zone"
>
> (TTZ for short) https://datatracker.ietf.org/doc/draft-chen-isis-ttz/ .
>
>
> This draft comprises the following solutions for helping to improve 
> scalability:
>
> 1) abstracting a zone to a single pseudo node in IS-IS,
>
> 2) abstracting a zone to a single pseudo node in OSPF,
>
> 3) abstracting a zone to zone edges' full mess in IS-IS, and
>
> 4) transferring smoothly between a zone and a single pseudo node.
>
> A zone is a block of an area (IS-IS L2 or L1 area, OSPF backbone or
>
> non-backbone area).
>
>
>
> When a network area becomes (too) big, we can reduce its size in the sense
>
> of its LSDB size through abstracting a zone to a single pseudo node or
>
> abstracting a few zones to a few pseudo nodes.
>
>
>
> While a zone is being abstracted (or transferred) to a single pseudo node,
>
> the network is stable. There is no or minimum service interruption.
>
>
>
> After abstracting a few zones to a few pseudo nodes, if we want to 
> reconstruct
>
> them, we can transfer (or roll) any of the pseudo nodes back to its zone 
> smoothly
>
> with no or minimum service interruption.
>
>
>
> We had a prototype implementation of abstracting a zone to zone edges' 
> full
>
> mess in OSPF. The procedures and related protocol extensions for transferring
>
> smoothly from a zone to zone edges' full mess are implemented and tested.
>
> A zone (block of an OSPF area) is smoothly transferred to its edges' full mess
>
> without any routing disruptions. The routes on every router are stable while
>
> the zone is being transferred to its edges' mess. It is very easy to operate
>
> the transferring.
>
>
>
> There are two other drafts for improving scalability: "Area Proxy for 
> IS-IS"
>
> (Area Proxy for short) and "IS-IS Flood Reflection" (Flood Reflection for 
> short).
>
>
>
> "Area Proxy" https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03
>
> abstracts an existing IS-IS L1 area to a single pseudo node.
>
>
>
> "Flood Reflection" 
> https://tools.ietf.org/html/draft-przygienda-lsr-flood-reflection-01
>
> abstracts an existing IS-IS L1 area to its edges' connections via one or more
>
> flood reflectors.
>
>
>
> We believe that TTZ has some special advantages even though
>
> Area Proxy and Flood Reflection are very worthy. We would like
>
> to ask for working group adoption of TTZ.
>
>
>
> Best Regards,
>
> Huaimo
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request WG adoption of TTZ

[Uma Chunduri]

Dear Chris,


On Sat, Jul 11, 2020 at 4:44 AM Christian Hopps  wrote:

>
>
> > On Jul 10, 2020, at 7:07 PM, Uma Chunduri  wrote:
> >
> >  I would support the IS-IS TTZ solution for WG adoption.
> >
> > Of course, obviously not with OSPF encodings or concepts only relevant
> to OSPF (thx for the updated version).
> > Thanks for the good work which was started way back on TTZs with OSPF
> protocol first (RFC 8099).
>
> Has RFC8099 been deployed by anyone?
>

The simple answer is I don't know. I would let the authors of 8099 speak up
who might know about the deployment status and how this experimental RFC
helped.

I also believe this question is more relevant if there is a BIS document
for the same as discussed in the list for further enhancements and
possible deployment experience (as it's possible who is using this and
might not be active here).

--
Uma C.


> I would be very interested in hearing from operators who have experience
> with TTZ since RFC8099 has been around for over 3 years now.
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request WG adoption of TTZ

[Les Ginsberg (ginsberg)]

+1

I think Henk has spoken eloquently here - as have others before him.

Abstracting an area may be useful - the WG has yet to fully decide on that.
But nothing so far has demonstrated that we need to go even further and 
abstract a subset of an area.

   Les


> -Original Message-
> From: Lsr  On Behalf Of John E Drake
> Sent: Wednesday, July 15, 2020 7:19 AM
> To: Henk Smit ; Huaimo Chen
> 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> I agree w/ Henk.  The TTZ seems to be a gratuitous addition.
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
> > -Original Message-
> > From: Lsr  On Behalf Of Henk Smit
> > Sent: Wednesday, July 15, 2020 8:22 AM
> > To: Huaimo Chen 
> > Cc: lsr@ietf.org
> > Subject: Re: [Lsr] Request WG adoption of TTZ
> >
> > [External Email. Be cautious of content]
> >
> >
> > Huaimo Chen wrote on 2020-07-14 06:09:
> >
> > >  2). IS-IS TTZ abstracts a zone to a single node. A zone is any target
> > > block or piece of an IS-IS area, which is to be abstracted. This seems
> > > more flexible and convenient to users.
> >
> > I don't agree that this convenience is really beneficial.
> > I actually think this convenience is a downside.
> >
> >
> > Link-state protocols are not easy to understand. And we already have the
> > misfortune that IS-IS and OSPF use different names for things.
> > Adding the new concept of a "zone", while we already have the concept of
> an
> > area makes things only more complex.
> >
> > How often will this new flexibility be used in the real world ?
> > I still haven't seen an answer to Christian Hopp's simple question:
> > "Has RFC8099 been deployed by anyone ?"
> > Anyone who has an answer ?
> >
> > My favorite rule of RFC1925 is rule 12:
> > In protocol design, perfection has been reached not when there is
> > nothing left to add, but when there is nothing left to take away.
> >
> > Adding a new concept, with very little benefit, hurts the protocol in the
> long run.
> > The ability to abstract an area, and not also a zone, is strong enough to be
> > worthwhile, imho.
> >
> > henk.
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!
> !NEt
> > 6yMaO-
> >
> gk!Qd22Qan7jubM_Vup5P5G6gsGg_horPl4PSDx8qS_v03ZIb8sNalgwEsGJ7Q6
> 1cc
> > $
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request WG adoption of TTZ

[John E Drake]

I agree w/ Henk.  The TTZ seems to be a gratuitous addition.

Yours Irrespectively,

John


Juniper Business Use Only

> -Original Message-
> From: Lsr  On Behalf Of Henk Smit
> Sent: Wednesday, July 15, 2020 8:22 AM
> To: Huaimo Chen 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> [External Email. Be cautious of content]
> 
> 
> Huaimo Chen wrote on 2020-07-14 06:09:
> 
> >  2). IS-IS TTZ abstracts a zone to a single node. A zone is any target
> > block or piece of an IS-IS area, which is to be abstracted. This seems
> > more flexible and convenient to users.
> 
> I don't agree that this convenience is really beneficial.
> I actually think this convenience is a downside.
> 
> 
> Link-state protocols are not easy to understand. And we already have the
> misfortune that IS-IS and OSPF use different names for things.
> Adding the new concept of a "zone", while we already have the concept of an
> area makes things only more complex.
> 
> How often will this new flexibility be used in the real world ?
> I still haven't seen an answer to Christian Hopp's simple question:
> "Has RFC8099 been deployed by anyone ?"
> Anyone who has an answer ?
> 
> My favorite rule of RFC1925 is rule 12:
> In protocol design, perfection has been reached not when there is
> nothing left to add, but when there is nothing left to take away.
> 
> Adding a new concept, with very little benefit, hurts the protocol in the 
> long run.
> The ability to abstract an area, and not also a zone, is strong enough to be
> worthwhile, imho.
> 
> henk.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt
> 6yMaO-
> gk!Qd22Qan7jubM_Vup5P5G6gsGg_horPl4PSDx8qS_v03ZIb8sNalgwEsGJ7Q61cc
> $

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request WG adoption of TTZ

[Henk Smit]

Huaimo Chen wrote on 2020-07-14 06:09:


 2). IS-IS TTZ abstracts a zone to a single node. A zone is any target
block or piece of an IS-IS area, which is to be abstracted. This seems
more flexible and convenient to users.


I don't agree that this convenience is really beneficial.
I actually think this convenience is a downside.


Link-state protocols are not easy to understand. And we already
have the misfortune that IS-IS and OSPF use different names for things.
Adding the new concept of a "zone", while we already have the
concept of an area makes things only more complex.

How often will this new flexibility be used in the real world ?
I still haven't seen an answer to Christian Hopp's simple question:
"Has RFC8099 been deployed by anyone ?"
Anyone who has an answer ?

My favorite rule of RFC1925 is rule 12:
   In protocol design, perfection has been reached not when there is
   nothing left to add, but when there is nothing left to take away.

Adding a new concept, with very little benefit, hurts the protocol
in the long run. The ability to abstract an area, and not also a zone,
is strong enough to be worthwhile, imho.

henk.

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr