Re: [Lsr] Request WG adoption of TTZ

[tony . li]

Hi Huaimo,

> > “reducing the service interruption, making operations to be simple, and 
> so on”
>  does not require introduction of zones.  We can already do so using areas – 
> including merging/splitting of an area.
> 
> [HC]: Smooth merging/splitting of an area seems not reduce the service 
> interruption while Area Proxy is abstracting an existing IS-IS area to a 
> single node because the adjacency ups and downs. IS-IS TTZ seems reduce the 
> service interruption while it is abstracting a zone to a single node since it 
> provides a smooth transferring from a zone to the single node. In addition, 
> operations on IS-IS TTZ for abstracting a zone to a single node seems simpler 
> than creating a new L1 area (through merging/splitting of an area in some 
> cases) and abstracting the L1 area to a single node.
> 
> > Until you demonstrate something compelling which cannot be done with an 
> > area but can be done with a zone, I simply do not see why we need to 
> > introduce zones to the protocol..
> 
> [HC]: It seems that “reducing the service interruption, making operations to 
> be simpler" provided by IS-IS TTZ with a zone should be compelling enough.
> 


My apologies if this comes off as too preachy, but perhaps it will help if we 
are a bit more explicit about out thinking in case language is gettiing in the 
way. 


Engineering is all about trade-offs. With everything that we design there are 
benefits (hopefully) and costs (hopefully obvious). In any design, we want the 
benefits to outweigh the costs. Unfortunately, the evaluation of those benefits 
and costs are subjective. 

You’ve just seen Area Proxy go through a major revision because some of us felt 
that the costs (a couple of extra TLV code points) were too high.  Some of us 
disagree. ;-)

No one is suggesting that the zone concept has no value. No one is saying that 
smooth transitions have no value. It’s very clear that they do.  If we could do 
that with zero costs, we certainly would. However, the costs are non-zero in 
additional complexity and additional code.

What we’re trying to tell you is that in our humble opnion, the tradeoff isn’t 
in favor of TTZ. The costs are higher than the benefits.

There is no definitive right answer in subjective situations. We, as a 
community, have to come to rough consensus. Frequently to get there, there have 
to be compromises and tough decisions.

Regards,
Tony

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

Re: [Lsr] Request WG adoption of TTZ

[Huaimo Chen]

Hi Les,


> “reducing the service interruption, making operations to be simple, and 
so on”

 does not require introduction of zones.  We can already do so using areas – 
including merging/splitting of an area.


[HC]: Smooth merging/splitting of an area seems not reduce the service 
interruption while Area Proxy is abstracting an existing IS-IS area to a single 
node because the adjacency ups and downs. IS-IS TTZ seems reduce the service 
interruption while it is abstracting a zone to a single node since it provides 
a smooth transferring from a zone to the single node. In addition, operations 
on IS-IS TTZ for abstracting a zone to a single node seems simpler than 
creating a new L1 area (through merging/splitting of an area in some cases) and 
abstracting the L1 area to a single node.

> Until you demonstrate something compelling which cannot be done with an area 
> but can be done with a zone, I simply do not see why we need to introduce 
> zones to the protocol.

[HC]: It seems that “reducing the service interruption, making operations to be 
simpler" provided by IS-IS TTZ with a zone should be compelling enough.

Best Regards,
Huaimo

From: Les Ginsberg (ginsberg) 
Sent: Thursday, July 16, 2020 5:39 PM
To: Huaimo Chen ; Acee Lindem (acee) 

Cc: lsr@ietf.org 
Subject: RE: [Lsr] Request WG adoption of TTZ


Huaimo –



I am not going to comment on the history issues – though I understand why that 
is of significance to you.



Otherwise, I don’t think you are appreciating the key point many of us are 
making – which is that we do not need to introduce a new concept “zone” (subset 
of an area).

It is sufficient to operate on an area.



  “reducing the service interruption, making operations to be simple, and 
so on”



does not require introduction of zones.  We can already do so using areas – 
including merging/splitting of an area.



The argument then against moving forward with both Area Proxy and TTZ is that 
they are redundant.



Until you demonstrate something compelling which cannot be done with an area 
but can be done with a zone, I simply do not see why we need to introduce zones 
to the protocol.



Les







From: Lsr  On Behalf Of Huaimo Chen
Sent: Thursday, July 16, 2020 12:16 PM
To: Acee Lindem (acee) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Acee,



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



[HC]:  It looks like the other way around. In 2013, IS-IS TTZ .00 draft 
describes the mechanism of having a Zone DR (called TTZ-DR) to generate a 
single LSP for representing the single node abstracted from the Zone. DR and 
Leader are just two different names of the same node. In 2018, Area Proxy .00 
draft presents the mechanism of having an Area leader to generate a single LSP 
representing the node abstracted from the Area. There are some big differences 
between IS-IS TTZ and Area Proxy even though they are similar.



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



[HC]: The three proposals (the two adopted as experimental recently and IS-IS 
TTZ) are all very different even though they solve the same problem for better 
LSDB scalability. It is would be reasonable and beneficial to allow IS-IS TTZ 
to move forward also as experimental.



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



[HC]: It seems that reducing the service interruption, making operations to be 
simple, and so on are expected by users in general.



Best Regards,

Huaimo



From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Uma 
Chunduri mailto:umac.i...@gmail.com>>
Sent: Wednesday, July 15, 2020 1:38 PM
To: Acee Lindem (acee) mailto:a...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Request WG adoption of TTZ



Acee,



In-line ..



On Wed, Jul 15, 2020 at 10:14 AM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:

Speaking as WG member…



See inline.



From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Uma 
Chunduri mailto:umac.i...@gmail.com>>
Date: Wednesday, July 15, 2020 at 12:52 PM
To: Henk Smit mailto:henk.i...@xs4all.nl>>
Cc: "l...@ietf...org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
Huaimo Chen mailto:huaimo.c...@futurewei.com>>
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

Re: [Lsr] Request WG adoption of TTZ

[Christian Hopps]

> On Jul 16, 2020, at 11:18 PM, Tianran Zhou  wrote:
> 
> Thanks. I am really glad to understand the LSR chair's thoughts.
> Well OK. I understand LSR would like a high bar for IGP extension.
> But your comparison with " research WG or a technical journal " makes no 
> sense. It's common sense.
> And your statement on the complexity twisted too many none engineer reasons.
> I would like the IETF to be more pure on technique.

[As a general IETF participant]

I believe we all would like this, but real-world dynamics impose none-the-less.

> Anyway, I respect the tradition of this WG.
> I just want to know if the WG request for interop and implementation report 
> for every draft?

[chair hat] We always prefer to have this. We do not always get it, 
unfortunately.

Thanks,
Chris.

> 
> Thanks,
> Tianran
> 
> -Original Message-
> From: Christian Hopps [mailto:cho...@chopps.org]
> Sent: Thursday, July 16, 2020 7:54 PM
> To: Tianran Zhou 
> Cc: Christian Hopps ; Henk Smit ; 
> lsr@ietf.org; Huaimo Chen 
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> My comments about what the WG should be doing are "As WGChair", I'm not 
> commenting directly on TTZ, but on the broader comments/questions below.
> 
>> On Jul 16, 2020, at 6:19 AM, Tianran Zhou  wrote:
>> 
>> Hi Henk,
>> 
>> Thanks very much for your long email.
>> I fully agree with what you said on the criterion. This is generally always 
>> correct.
>> But still you cannot score a draft with it.
>> That means I can probably say most of the IETF RFCs has  no use.
>> I can also list one hundred RFCs that is not implemented.
> 
> This is not what we strive for in LSR.
> 
>> Are you going to obsolete them all?
> 
> No, but we as a WG can strive to not contribute to this problem.
> 
>> Who knows if they are useful in the future?
> 
> LSR is not a research WG or a technical journal.
> 
>> If you find it no use, just not to implement it. How could it make your 
>> system complex?
> 
> This statement flies in the face of market realty.
> 
> People who have to fill RFPs from prospective customers, knowing that they 
> are competing against other vendors filling those same RFPs out, can tell you 
> why you can't just "not implement RFCs" if you don't want to, even when they 
> will never actually be used by those same customers. The short answer is: 
> RFPs are very often not written by the engineers that actually build and run 
> the customer's networks; however, answers to RFPs have a direct impact on 
> which vendors products are purchased by the customers.
> 
> So lots of unused RFCs leads to lots of useless code being written to win 
> customers, which then leads to huge protocol code bases that are too complex 
> and fragile, as well as protocols that are hard to comprehend and thus manage 
> properly, and so ultimately destabalize the internet -- we have failed at 
> this point.
> 
> This may be less of an issue with other WGs; however, the IGPs are a 
> *critical* part of the internet infrastructure, and they need to be treated 
> as such, and we should strive to do so.
> 
> Thanks,
> Chris.
> 
>> 
>> Best,
>> Tianran
>> 
>> -Original Message-
>> From: Henk Smit [mailto:henk.i...@xs4all.nl]
>> Sent: Thursday, July 16, 2020 4:46 PM
>> To: Tianran Zhou 
>> Cc: Huaimo Chen ; lsr@ietf.org
>> Subject: Re: [Lsr] Request WG adoption of TTZ
>> 
>> 
>> Hello Tianran,
>> 
>> Warning, long email again.
>> 
>>> What's the criterion to evaluate the benefit?
>> 
>> As people have asked before, did any provider or enterprise ever use rfc8099 
>> in their network ?
>> 
>> As I wrote, one of my criteria is rfc1925. I like technology to be 
>> understandable. I like protocols to be (relatively) easy to implement. The 
>> more unused cruft there is, the further we get away from that goal.
>> 
>> 
>> I'll give you an example. Did you, or your company ever implement rfc2973 ? 
>> That's mesh-groups in IS-IS.
>> I'm sure some customers put it on their wishlist.
>> Did any provider or customer ever use it ?
>> I asked this question at my last job, and nobody knew the answer. I suspect 
>> nobody in the world ever used mesh-groups.
>> 
>> Around the time I got in touch with IS-IS, in spring 1996, there was a 
>> problem that was seen 2 of the 3 largest ISPs in the US (UUnet and iMCI). 
>> Both networks melted because of IS-IS. All routers in their networks were 
>> 100% cpu time running IS-IS, busy exchanging LSPs. While no progress was 
>> made. Th

Re: [Lsr] Request WG adoption of TTZ

[Tianran Zhou]

Thanks. I am really glad to understand the LSR chair's thoughts.
Well OK. I understand LSR would like a high bar for IGP extension.
But your comparison with " research WG or a technical journal " makes no sense. 
It's common sense.
And your statement on the complexity twisted too many none engineer reasons.
I would like the IETF to be more pure on technique.
Anyway, I respect the tradition of this WG.
I just want to know if the WG request for interop and implementation report for 
every draft?

Thanks,
Tianran

-Original Message-
From: Christian Hopps [mailto:cho...@chopps.org] 
Sent: Thursday, July 16, 2020 7:54 PM
To: Tianran Zhou 
Cc: Christian Hopps ; Henk Smit ; 
lsr@ietf.org; Huaimo Chen 
Subject: Re: [Lsr] Request WG adoption of TTZ

My comments about what the WG should be doing are "As WGChair", I'm not 
commenting directly on TTZ, but on the broader comments/questions below.

> On Jul 16, 2020, at 6:19 AM, Tianran Zhou  wrote:
> 
> Hi Henk,
> 
> Thanks very much for your long email.
> I fully agree with what you said on the criterion. This is generally always 
> correct.
> But still you cannot score a draft with it.
> That means I can probably say most of the IETF RFCs has  no use.
> I can also list one hundred RFCs that is not implemented.

This is not what we strive for in LSR.

>  Are you going to obsolete them all?

No, but we as a WG can strive to not contribute to this problem.

> Who knows if they are useful in the future?

LSR is not a research WG or a technical journal.

> If you find it no use, just not to implement it. How could it make your 
> system complex?

This statement flies in the face of market realty.

People who have to fill RFPs from prospective customers, knowing that they are 
competing against other vendors filling those same RFPs out, can tell you why 
you can't just "not implement RFCs" if you don't want to, even when they will 
never actually be used by those same customers. The short answer is: RFPs are 
very often not written by the engineers that actually build and run the 
customer's networks; however, answers to RFPs have a direct impact on which 
vendors products are purchased by the customers.

So lots of unused RFCs leads to lots of useless code being written to win 
customers, which then leads to huge protocol code bases that are too complex 
and fragile, as well as protocols that are hard to comprehend and thus manage 
properly, and so ultimately destabalize the internet -- we have failed at this 
point.

This may be less of an issue with other WGs; however, the IGPs are a *critical* 
part of the internet infrastructure, and they need to be treated as such, and 
we should strive to do so.

Thanks,
Chris.

> 
> Best,
> Tianran
> 
> -Original Message-
> From: Henk Smit [mailto:henk.i...@xs4all.nl]
> Sent: Thursday, July 16, 2020 4:46 PM
> To: Tianran Zhou 
> Cc: Huaimo Chen ; lsr@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> 
> Hello Tianran,
> 
> Warning, long email again.
> 
>> What's the criterion to evaluate the benefit?
> 
> As people have asked before, did any provider or enterprise ever use rfc8099 
> in their network ?
> 
> As I wrote, one of my criteria is rfc1925. I like technology to be 
> understandable. I like protocols to be (relatively) easy to implement. The 
> more unused cruft there is, the further we get away from that goal.
> 
> 
> I'll give you an example. Did you, or your company ever implement rfc2973 ? 
> That's mesh-groups in IS-IS.
> I'm sure some customers put it on their wishlist.
> Did any provider or customer ever use it ?
> I asked this question at my last job, and nobody knew the answer. I suspect 
> nobody in the world ever used mesh-groups.
> 
> Around the time I got in touch with IS-IS, in spring 1996, there was a 
> problem that was seen 2 of the 3 largest ISPs in the US (UUnet and iMCI). 
> Both networks melted because of IS-IS. All routers in their networks were 
> 100% cpu time running IS-IS, busy exchanging LSPs. While no progress was 
> made. The only solution was to reboot all routers in the backbone at the same 
> time (several hundred routers).
> This happened more than once in both networks.
> 
> To relieve the burden of flooding, mesh-groups were implemented, and rfc2973 
> was written. However, a short while later I became the sole IS-IS programmer 
> for that router vendor. I was able to reproduce the problem in the lab.
> I then realized what the issue was. A fix of 10 lines of extra code fixed the 
> problem. No customer ever reported those meltdowns again. That fix was the 
> real solution.
> Not writing another RFC.
> 
> In the mean-time, we have an extra RFC, about mesh-groups.
> Every book and manual on IS-IS has to spent time explaining what mesh-gro

Re: [Lsr] Request WG adoption of TTZ

[Les Ginsberg (ginsberg)]

Huaimo -

I am not going to comment on the history issues - though I understand why that 
is of significance to you.

Otherwise, I don't think you are appreciating the key point many of us are 
making - which is that we do not need to introduce a new concept "zone" (subset 
of an area).
It is sufficient to operate on an area.

  "reducing the service interruption, making operations to be simple, and 
so on"

does not require introduction of zones.  We can already do so using areas - 
including merging/splitting of an area.

The argument then against moving forward with both Area Proxy and TTZ is that 
they are redundant.

Until you demonstrate something compelling which cannot be done with an area 
but can be done with a zone, I simply do not see why we need to introduce zones 
to the protocol.

Les



From: Lsr  On Behalf Of Huaimo Chen
Sent: Thursday, July 16, 2020 12:16 PM
To: Acee Lindem (acee) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Acee,

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

[HC]:  It looks like the other way around. In 2013, IS-IS TTZ .00 draft 
describes the mechanism of having a Zone DR (called TTZ-DR) to generate a 
single LSP for representing the single node abstracted from the Zone. DR and 
Leader are just two different names of the same node. In 2018, Area Proxy .00 
draft presents the mechanism of having an Area leader to generate a single LSP 
representing the node abstracted from the Area. There are some big differences 
between IS-IS TTZ and Area Proxy even though they are similar.

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

[HC]: The three proposals (the two adopted as experimental recently and IS-IS 
TTZ) are all very different even though they solve the same problem for better 
LSDB scalability. It is would be reasonable and beneficial to allow IS-IS TTZ 
to move forward also as experimental.

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

[HC]: It seems that reducing the service interruption, making operations to be 
simple, and so on are expected by users in general.

Best Regards,
Huaimo

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Uma 
Chunduri mailto:umac.i...@gmail.com>>
Sent: Wednesday, July 15, 2020 1:38 PM
To: Acee Lindem (acee) mailto:a...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Request WG adoption of TTZ

Acee,

In-line ..

On Wed, Jul 15, 2020 at 10:14 AM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:

Speaking as WG member...



See inline.



From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Uma 
Chunduri mailto:umac.i...@gmail.com>>
Date: Wednesday, July 15, 2020 at 12:52 PM
To: Henk Smit mailto:henk.i...@xs4all.nl>>
Cc: "l...@ietf...org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
Huaimo Chen mailto:huaimo.c...@futurewei.com>>
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 
a

Re: [Lsr] Request WG adoption of TTZ

[Huaimo Chen]

Hi Acee,

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

[HC]:  It looks like the other way around. In 2013, IS-IS TTZ .00 draft 
describes the mechanism of having a Zone DR (called TTZ-DR) to generate a 
single LSP for representing the single node abstracted from the Zone. DR and 
Leader are just two different names of the same node. In 2018, Area Proxy .00 
draft presents the mechanism of having an Area leader to generate a single LSP 
representing the node abstracted from the Area. There are some big differences 
between IS-IS TTZ and Area Proxy even though they are similar.

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

[HC]: The three proposals (the two adopted as experimental recently and IS-IS 
TTZ) are all very different even though they solve the same problem for better 
LSDB scalability. It is would be reasonable and beneficial to allow IS-IS TTZ 
to move forward also as experimental.

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

[HC]: It seems that reducing the service interruption, making operations to be 
simple, and so on are expected by users in general.

Best Regards,
Huaimo

From: Lsr  on behalf of Uma Chunduri 

Sent: Wednesday, July 15, 2020 1:38 PM
To: Acee Lindem (acee) 
Cc: lsr@ietf.org 
Subject: Re: [Lsr] Request WG adoption of TTZ

Acee,

In-line ..

On Wed, Jul 15, 2020 at 10:14 AM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:

Speaking as WG member…



See inline.



From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Uma 
Chunduri mailto:umac.i...@gmail.com>>
Date: Wednesday, July 15, 2020 at 12:52 PM
To: Henk Smit mailto:henk.i...@xs4all.nl>>
Cc: "l...@ietf..org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>, 
Huaimo Chen mailto:huaimo.c...@futurewei.com>>
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.

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

[Christian Hopps]

My comments about what the WG should be doing are "As WGChair", I'm not 
commenting directly on TTZ, but on the broader comments/questions below.

> On Jul 16, 2020, at 6:19 AM, Tianran Zhou  wrote:
> 
> Hi Henk,
> 
> Thanks very much for your long email.
> I fully agree with what you said on the criterion. This is generally always 
> correct.
> But still you cannot score a draft with it.
> That means I can probably say most of the IETF RFCs has  no use.
> I can also list one hundred RFCs that is not implemented.

This is not what we strive for in LSR.

>  Are you going to obsolete them all?

No, but we as a WG can strive to not contribute to this problem.

> Who knows if they are useful in the future?

LSR is not a research WG or a technical journal.

> If you find it no use, just not to implement it. How could it make your 
> system complex?

This statement flies in the face of market realty.

People who have to fill RFPs from prospective customers, knowing that they are 
competing against other vendors filling those same RFPs out, can tell you why 
you can't just "not implement RFCs" if you don't want to, even when they will 
never actually be used by those same customers. The short answer is: RFPs are 
very often not written by the engineers that actually build and run the 
customer's networks; however, answers to RFPs have a direct impact on which 
vendors products are purchased by the customers.

So lots of unused RFCs leads to lots of useless code being written to win 
customers, which then leads to huge protocol code bases that are too complex 
and fragile, as well as protocols that are hard to comprehend and thus manage 
properly, and so ultimately destabalize the internet -- we have failed at this 
point.

This may be less of an issue with other WGs; however, the IGPs are a *critical* 
part of the internet infrastructure, and they need to be treated as such, and 
we should strive to do so.

Thanks,
Chris.

> 
> Best,
> Tianran
> 
> -Original Message-
> From: Henk Smit [mailto:henk.i...@xs4all.nl]
> Sent: Thursday, July 16, 2020 4:46 PM
> To: Tianran Zhou 
> Cc: Huaimo Chen ; lsr@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> 
> Hello Tianran,
> 
> Warning, long email again.
> 
>> What's the criterion to evaluate the benefit?
> 
> As people have asked before, did any provider or enterprise ever use rfc8099 
> in their network ?
> 
> As I wrote, one of my criteria is rfc1925. I like technology to be 
> understandable. I like protocols to be (relatively) easy to implement. The 
> more unused cruft there is, the further we get away from that goal.
> 
> 
> I'll give you an example. Did you, or your company ever implement rfc2973 ? 
> That's mesh-groups in IS-IS.
> I'm sure some customers put it on their wishlist.
> Did any provider or customer ever use it ?
> I asked this question at my last job, and nobody knew the answer. I suspect 
> nobody in the world ever used mesh-groups.
> 
> Around the time I got in touch with IS-IS, in spring 1996, there was a 
> problem that was seen 2 of the 3 largest ISPs in the US (UUnet and iMCI). 
> Both networks melted because of IS-IS. All routers in their networks were 
> 100% cpu time running IS-IS, busy exchanging LSPs. While no progress was 
> made. The only solution was to reboot all routers in the backbone at the same 
> time (several hundred routers).
> This happened more than once in both networks.
> 
> To relieve the burden of flooding, mesh-groups were implemented, and rfc2973 
> was written. However, a short while later I became the sole IS-IS programmer 
> for that router vendor. I was able to reproduce the problem in the lab.
> I then realized what the issue was. A fix of 10 lines of extra code fixed the 
> problem. No customer ever reported those meltdowns again. That fix was the 
> real solution.
> Not writing another RFC.
> 
> In the mean-time, we have an extra RFC, about mesh-groups.
> Every book and manual on IS-IS has to spent time explaining what mesh-groups 
> are. Every vendor has to implement it.
> Even when nobody in the world is using it. Mesh-groups were a superfluous 
> idea. What I (and many others) are saying is that we don't want to specify 
> and implement unnecessary things.
> Even when nobody is using such a thing, it will live on forever.
> 
>> What I see the TTZ does have benefit.
> 
> Yes, TTZ and proxy-areas have benefit. Nobody is disagreeing.
> 
> But what people don't like is the new concept of a zone.
> If you can abstract exactly one area into exactly one proxy-LSP, that is good 
> enough for 99.9 % of cases. In OSPF it is harder to split or merge an area. 
> In IS-IS it is a lot easier. So a network operator can design and change his 
> are

Re: [Lsr] Request WG adoption of TTZ

[Tianran Zhou]

Hi Henk,

Thanks very much for your long email.
I fully agree with what you said on the criterion. This is generally always 
correct. 
But still you cannot score a draft with it.
That means I can probably say most of the IETF RFCs has  no use. 
I can also list one hundred RFCs that is not implemented. Are you going to 
obsolete them all?
Who knows if they are useful in the future?
If you find it no use, just not to implement it. How could it make your system 
complex?

Best,
Tianran

-Original Message-
From: Henk Smit [mailto:henk.i...@xs4all.nl] 
Sent: Thursday, July 16, 2020 4:46 PM
To: Tianran Zhou 
Cc: Huaimo Chen ; lsr@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ


Hello Tianran,

Warning, long email again.

> What's the criterion to evaluate the benefit?

As people have asked before, did any provider or enterprise ever use rfc8099 in 
their network ?

As I wrote, one of my criteria is rfc1925. I like technology to be 
understandable. I like protocols to be (relatively) easy to implement. The more 
unused cruft there is, the further we get away from that goal.


I'll give you an example. Did you, or your company ever implement rfc2973 ? 
That's mesh-groups in IS-IS.
I'm sure some customers put it on their wishlist.
Did any provider or customer ever use it ?
I asked this question at my last job, and nobody knew the answer. I suspect 
nobody in the world ever used mesh-groups.

Around the time I got in touch with IS-IS, in spring 1996, there was a problem 
that was seen 2 of the 3 largest ISPs in the US (UUnet and iMCI). Both networks 
melted because of IS-IS. All routers in their networks were 100% cpu time 
running IS-IS, busy exchanging LSPs. While no progress was made. The only 
solution was to reboot all routers in the backbone at the same time (several 
hundred routers).
This happened more than once in both networks.

To relieve the burden of flooding, mesh-groups were implemented, and rfc2973 
was written. However, a short while later I became the sole IS-IS programmer 
for that router vendor. I was able to reproduce the problem in the lab.
I then realized what the issue was. A fix of 10 lines of extra code fixed the 
problem. No customer ever reported those meltdowns again. That fix was the real 
solution.
Not writing another RFC.

In the mean-time, we have an extra RFC, about mesh-groups.
Every book and manual on IS-IS has to spent time explaining what mesh-groups 
are. Every vendor has to implement it.
Even when nobody in the world is using it. Mesh-groups were a superfluous idea. 
What I (and many others) are saying is that we don't want to specify and 
implement unnecessary things.
Even when nobody is using such a thing, it will live on forever.

> What I see the TTZ does have benefit.

Yes, TTZ and proxy-areas have benefit. Nobody is disagreeing.

But what people don't like is the new concept of a zone.
If you can abstract exactly one area into exactly one proxy-LSP, that is good 
enough for 99.9 % of cases. In OSPF it is harder to split or merge an area. In 
IS-IS it is a lot easier. So a network operator can design and change his areas 
first. And then implement proxy-areas as she/he wishes. Without much downtime.

If we introduce the concept of a "zone", someone is going to have to explain 
that to everybody in the world who uses IS-IS.
Have you ever taught a class on IS-IS to people who don't know routing 
protocols very well ?

> I am also wandering how it hurts the protocol in the long run ?

Adding stuff that nobody uses makes everything more complex.
I know it seems as if the goal over the last 15 years was to make every thing 
more complex. So what's the problem with adding yet another RFC ?

But I like simple things.

henk.


Tianran Zhou wrote on 2020-07-16 02:41:

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

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

Re: [Lsr] Request WG adoption of TTZ

[Henk Smit]

Hello Tianran,

Warning, long email again.


What's the criterion to evaluate the benefit?


As people have asked before, did any provider or
enterprise ever use rfc8099 in their network ?

As I wrote, one of my criteria is rfc1925. I like
technology to be understandable. I like protocols to
be (relatively) easy to implement. The more unused
cruft there is, the further we get away from that goal.


I'll give you an example. Did you, or your company ever
implement rfc2973 ? That's mesh-groups in IS-IS.
I'm sure some customers put it on their wishlist.
Did any provider or customer ever use it ?
I asked this question at my last job, and nobody knew the
answer. I suspect nobody in the world ever used mesh-groups.

Around the time I got in touch with IS-IS, in spring 1996,
there was a problem that was seen 2 of the 3 largest ISPs
in the US (UUnet and iMCI). Both networks melted because
of IS-IS. All routers in their networks were 100% cpu
time running IS-IS, busy exchanging LSPs. While no progress
was made. The only solution was to reboot all routers in
the backbone at the same time (several hundred routers).
This happened more than once in both networks.

To relieve the burden of flooding, mesh-groups were
implemented, and rfc2973 was written. However, a short
while later I became the sole IS-IS programmer for that
router vendor. I was able to reproduce the problem in the lab.
I then realized what the issue was. A fix of 10 lines
of extra code fixed the problem. No customer ever reported
those meltdowns again. That fix was the real solution.
Not writing another RFC.

In the mean-time, we have an extra RFC, about mesh-groups.
Every book and manual on IS-IS has to spent time explaining
what mesh-groups are. Every vendor has to implement it.
Even when nobody in the world is using it. Mesh-groups were
a superfluous idea. What I (and many others) are saying is
that we don't want to specify and implement unnecessary things.
Even when nobody is using such a thing, it will live on forever.


What I see the TTZ does have benefit.


Yes, TTZ and proxy-areas have benefit. Nobody is disagreeing.

But what people don't like is the new concept of a zone.
If you can abstract exactly one area into exactly one proxy-LSP,
that is good enough for 99.9 % of cases. In OSPF it is harder to
split or merge an area. In IS-IS it is a lot easier. So a
network operator can design and change his areas first. And
then implement proxy-areas as she/he wishes. Without much
downtime.

If we introduce the concept of a "zone", someone is going to
have to explain that to everybody in the world who uses IS-IS.
Have you ever taught a class on IS-IS to people who don't know
routing protocols very well ?


I am also wandering how it hurts the protocol in the long run ?


Adding stuff that nobody uses makes everything more complex.
I know it seems as if the goal over the last 15 years was to make
every thing more complex. So what's the problem with adding yet
another RFC ?

But I like simple things.

henk.


Tianran Zhou wrote on 2020-07-16 02:41:


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


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

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

Re: [Lsr] Request WG adoption of TTZ

[Acee Lindem (acee)]

Linda, 

On 7/14/20, 1:57 PM, "Linda Dunbar"  wrote:

Acee, 

Many networks have BGP or/and ISIS. 
Encoding of BGP messages are discussed in IDR WG, and the encoding of ISIS 
is discussed LSR WG. 
The TTZ zone draft is about ISIS encoding of TTZ, therefore, the discussion 
should be in the LSR Wg, instead of RTGwg (in my opinion). 

Maybe, the discussion on why TTZ should replace BGP can be in RTGwg. But 
this TTZ zone draft is not about replacing BGP. 

But you just said "TTZ is another option?" And if IS-IS isn't running over the 
SDWAN overlay, how is IS-IS TTZ even applicable to solving any problem in SDWAN?

Thanks,
Acee

Linda 

-Original Message-
From: Acee Lindem (acee)  
Sent: Tuesday, July 14, 2020 12:32 PM
To: Linda Dunbar ; Christian Hopps 

Cc: LEI LIU ; Huaimo Chen ; 
lsr@ietf.org; lsr-cha...@ietf.org
    Subject: Re: [Lsr] Request WG adoption of TTZ

Linda, 

On 7/14/20, 1:26 PM, "Linda Dunbar"  wrote:

Acee, 

We have deployment of using BGP to group a set of SDWAN nodes as one 
entity and exchange link/paths/ports information among sites/nodes. 

TTZ could be another option. 

I don't see how it would work to replace BGP and RR with IS-IS TTZ for  
SDWAN Fabric setup. However, that is probably a topic that would be better 
addressed in the RTG WG. 

Thanks,
Acee


Linda

-Original Message-
From: Acee Lindem (acee)  
Sent: Tuesday, July 14, 2020 11:59 AM
To: Linda Dunbar ; Christian Hopps 

Cc: LEI LIU ; Huaimo Chen ; 
lsr@ietf.org; lsr-cha...@ietf.org
    Subject: Re: [Lsr] Request WG adoption of TTZ

Linda, 

So the IS-IS runs over the overlay in your SDWAN solution? Have you 
deployed this? __

Acee

On 7/14/20, 12:52 PM, "Linda Dunbar"  wrote:

Christian, 

The SDWAN use case  is about grouping a set of nodes in 
geographically different locations to be one TTZ zone being treated as one 
Virtual Node. 

Linda

-Original Message-
From: Christian Hopps  
Sent: Saturday, July 11, 2020 6:42 AM
To: Linda Dunbar 
Cc: Christian Hopps ; LEI LIU ; 
Huaimo Chen ; lsr@ietf.org; lsr-cha...@ietf.org
    Subject: Re: [Lsr] Request WG adoption of TTZ



> On Jul 10, 2020, at 4:39 PM, Linda Dunbar 
 wrote:
> 
> I also support the adoption of TTZ draft.
> 
> The Virtual Zone concept would be very useful for the Overlay 
networks. The proposed TTZ can group a set of nodes not geographically together 
into one virtual area to scale virtual overlay networks with lots of nodes. 
Those kind overlay networks are getting more momentum in SDWAN and CDN 
environment.

I'm not sure I follow this use-case. The intent of TTZ is to treat 
a bunch of nodes as a single node (or subset of nodes in early work) to reduce 
the link-state DB size and flooding requirements, AFAICT.

Thanks,
Chris.
[As WG member]


> 
> Linda Dunbar
> 
> From: Lsr  On Behalf Of LEI LIU
> Sent: Friday, July 10, 2020 12:42 PM
> To: Huaimo Chen 
            > Cc: lsr@ietf.org; lsr-cha...@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> I support the adoption of the TTZ draft.
> 
> The operation on TTZ is simple. Smooth transferring between a 
zone and a single node will improve customer experience. The work on TTZ should 
be moved forward.
> 
> Thanks,
> Best regards,
> 
> Lei
> 
> On Thu, Jun 18, 2020 at 8: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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2Fdata=02%7C01%7Clinda.dunbar%40futurewei.com%7Cd8af0da5bafd40e70fce08d8281bd3e7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303447263980613sdata=L8xHMIno4kitHe9mnfLNJ0yeRTbRrKX3gVK6AnbAet4%3Dreserved=0
 .
> 
> 
> 
> 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,
> 
>

Re: [Lsr] Request WG adoption of TTZ

[Linda Dunbar]

Acee, 

Many networks have BGP or/and ISIS. 
Encoding of BGP messages are discussed in IDR WG, and the encoding of ISIS is 
discussed LSR WG. 
The TTZ zone draft is about ISIS encoding of TTZ, therefore, the discussion 
should be in the LSR Wg, instead of RTGwg (in my opinion). 

Maybe, the discussion on why TTZ should replace BGP can be in RTGwg. But this 
TTZ zone draft is not about replacing BGP. 

Linda 

-Original Message-
From: Acee Lindem (acee)  
Sent: Tuesday, July 14, 2020 12:32 PM
To: Linda Dunbar ; Christian Hopps 

Cc: LEI LIU ; Huaimo Chen ; 
lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Linda, 

On 7/14/20, 1:26 PM, "Linda Dunbar"  wrote:

Acee, 

We have deployment of using BGP to group a set of SDWAN nodes as one entity 
and exchange link/paths/ports information among sites/nodes. 

TTZ could be another option. 

I don't see how it would work to replace BGP and RR with IS-IS TTZ for  SDWAN 
Fabric setup. However, that is probably a topic that would be better addressed 
in the RTG WG. 

Thanks,
Acee


Linda

-Original Message-
From: Acee Lindem (acee)  
Sent: Tuesday, July 14, 2020 11:59 AM
To: Linda Dunbar ; Christian Hopps 

Cc: LEI LIU ; Huaimo Chen ; 
lsr@ietf.org; lsr-cha...@ietf.org
    Subject: Re: [Lsr] Request WG adoption of TTZ

Linda, 

So the IS-IS runs over the overlay in your SDWAN solution? Have you 
deployed this? __

Acee

On 7/14/20, 12:52 PM, "Linda Dunbar"  wrote:

Christian, 

The SDWAN use case  is about grouping a set of nodes in geographically 
different locations to be one TTZ zone being treated as one Virtual Node. 

Linda

-Original Message-
From: Christian Hopps  
Sent: Saturday, July 11, 2020 6:42 AM
To: Linda Dunbar 
Cc: Christian Hopps ; LEI LIU ; 
Huaimo Chen ; lsr@ietf.org; lsr-cha...@ietf.org
        Subject: Re: [Lsr] Request WG adoption of TTZ



> On Jul 10, 2020, at 4:39 PM, Linda Dunbar 
 wrote:
> 
> I also support the adoption of TTZ draft.
> 
> The Virtual Zone concept would be very useful for the Overlay 
networks. The proposed TTZ can group a set of nodes not geographically together 
into one virtual area to scale virtual overlay networks with lots of nodes. 
Those kind overlay networks are getting more momentum in SDWAN and CDN 
environment.

I'm not sure I follow this use-case. The intent of TTZ is to treat a 
bunch of nodes as a single node (or subset of nodes in early work) to reduce 
the link-state DB size and flooding requirements, AFAICT.

Thanks,
Chris.
[As WG member]


> 
> Linda Dunbar
> 
> From: Lsr  On Behalf Of LEI LIU
> Sent: Friday, July 10, 2020 12:42 PM
> To: Huaimo Chen 
> Cc: lsr@ietf.org; lsr-cha...@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> I support the adoption of the TTZ draft.
> 
> The operation on TTZ is simple. Smooth transferring between a zone 
and a single node will improve customer experience. The work on TTZ should be 
moved forward.
> 
> Thanks,
> Best regards,
> 
> Lei
> 
> On Thu, Jun 18, 2020 at 8: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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2Fdata=02%7C01%7Clinda.dunbar%40futurewei.com%7Cd8af0da5bafd40e70fce08d8281bd3e7%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303447263980613sdata=L8xHMIno4kitHe9mnfLNJ0yeRTbRrKX3gVK6AnbAet4%3Dreserved=0
 .
> 
> 
> 
> 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

Re: [Lsr] Request WG adoption of TTZ

[Acee Lindem (acee)]

Linda, 

On 7/14/20, 1:26 PM, "Linda Dunbar"  wrote:

Acee, 

We have deployment of using BGP to group a set of SDWAN nodes as one entity 
and exchange link/paths/ports information among sites/nodes. 

TTZ could be another option. 

I don't see how it would work to replace BGP and RR with IS-IS TTZ for  SDWAN 
Fabric setup. However, that is probably a topic that would be better addressed 
in the RTG WG. 

Thanks,
Acee


Linda

-Original Message-
From: Acee Lindem (acee)  
Sent: Tuesday, July 14, 2020 11:59 AM
To: Linda Dunbar ; Christian Hopps 

Cc: LEI LIU ; Huaimo Chen ; 
lsr@ietf.org; lsr-cha...@ietf.org
    Subject: Re: [Lsr] Request WG adoption of TTZ

Linda, 

So the IS-IS runs over the overlay in your SDWAN solution? Have you 
deployed this? __

Acee

On 7/14/20, 12:52 PM, "Linda Dunbar"  wrote:

Christian, 

The SDWAN use case  is about grouping a set of nodes in geographically 
different locations to be one TTZ zone being treated as one Virtual Node. 

Linda

-Original Message-
From: Christian Hopps  
Sent: Saturday, July 11, 2020 6:42 AM
To: Linda Dunbar 
Cc: Christian Hopps ; LEI LIU ; 
Huaimo Chen ; lsr@ietf.org; lsr-cha...@ietf.org
        Subject: Re: [Lsr] Request WG adoption of TTZ



> On Jul 10, 2020, at 4:39 PM, Linda Dunbar 
 wrote:
> 
> I also support the adoption of TTZ draft.
> 
> The Virtual Zone concept would be very useful for the Overlay 
networks. The proposed TTZ can group a set of nodes not geographically together 
into one virtual area to scale virtual overlay networks with lots of nodes. 
Those kind overlay networks are getting more momentum in SDWAN and CDN 
environment.

I'm not sure I follow this use-case. The intent of TTZ is to treat a 
bunch of nodes as a single node (or subset of nodes in early work) to reduce 
the link-state DB size and flooding requirements, AFAICT.

Thanks,
Chris.
[As WG member]


> 
> Linda Dunbar
> 
> From: Lsr  On Behalf Of LEI LIU
> Sent: Friday, July 10, 2020 12:42 PM
> To: Huaimo Chen 
> Cc: lsr@ietf.org; lsr-cha...@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> I support the adoption of the TTZ draft.
> 
> The operation on TTZ is simple. Smooth transferring between a zone 
and a single node will improve customer experience. The work on TTZ should be 
moved forward.
> 
> Thanks,
> Best regards,
> 
> Lei
> 
> On Thu, Jun 18, 2020 at 8: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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2Fdata=02%7C01%7Clinda.dunbar%40futurewei.com%7C787e31692b91480c725c08d828172572%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303427174223715sdata=%2F4hwW%2FHPgVyrbjmdXOSZCZezIaDj8UbVrlXWDLjrgkU%3Dreserved=0
 .
> 
> 
> 
> 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 p

Re: [Lsr] Request WG adoption of TTZ

[Linda Dunbar]

Acee, 

We have deployment of using BGP to group a set of SDWAN nodes as one entity and 
exchange link/paths/ports information among sites/nodes. 

TTZ could be another option. 

Linda

-Original Message-
From: Acee Lindem (acee)  
Sent: Tuesday, July 14, 2020 11:59 AM
To: Linda Dunbar ; Christian Hopps 

Cc: LEI LIU ; Huaimo Chen ; 
lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Linda, 

So the IS-IS runs over the overlay in your SDWAN solution? Have you deployed 
this? __

Acee

On 7/14/20, 12:52 PM, "Linda Dunbar"  wrote:

Christian, 

The SDWAN use case  is about grouping a set of nodes in geographically 
different locations to be one TTZ zone being treated as one Virtual Node. 

Linda

-Original Message-
From: Christian Hopps  
Sent: Saturday, July 11, 2020 6:42 AM
To: Linda Dunbar 
Cc: Christian Hopps ; LEI LIU ; Huaimo 
Chen ; lsr@ietf.org; lsr-cha...@ietf.org
    Subject: Re: [Lsr] Request WG adoption of TTZ



> On Jul 10, 2020, at 4:39 PM, Linda Dunbar  
wrote:
> 
> I also support the adoption of TTZ draft.
> 
> The Virtual Zone concept would be very useful for the Overlay networks. 
The proposed TTZ can group a set of nodes not geographically together into one 
virtual area to scale virtual overlay networks with lots of nodes. Those kind 
overlay networks are getting more momentum in SDWAN and CDN environment.

I'm not sure I follow this use-case. The intent of TTZ is to treat a bunch 
of nodes as a single node (or subset of nodes in early work) to reduce the 
link-state DB size and flooding requirements, AFAICT.

Thanks,
Chris.
[As WG member]


> 
> Linda Dunbar
> 
> From: Lsr  On Behalf Of LEI LIU
> Sent: Friday, July 10, 2020 12:42 PM
> To: Huaimo Chen 
> Cc: lsr@ietf.org; lsr-cha...@ietf.org
    > Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> I support the adoption of the TTZ draft.
> 
> The operation on TTZ is simple. Smooth transferring between a zone and a 
single node will improve customer experience. The work on TTZ should be moved 
forward.
> 
> Thanks,
> Best regards,
> 
> Lei
> 
> On Thu, Jun 18, 2020 at 8: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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2Fdata=02%7C01%7Clinda.dunbar%40futurewei.com%7C787e31692b91480c725c08d828172572%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637303427174223715sdata=%2F4hwW%2FHPgVyrbjmdXOSZCZezIaDj8UbVrlXWDLjrgkU%3Dreserved=0
 .
> 
> 
> 
> 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 imp

Re: [Lsr] Request WG adoption of TTZ

[Acee Lindem (acee)]

Linda, 

So the IS-IS runs over the overlay in your SDWAN solution? Have you deployed 
this? __

Acee

On 7/14/20, 12:52 PM, "Linda Dunbar"  wrote:

Christian, 

The SDWAN use case  is about grouping a set of nodes in geographically 
different locations to be one TTZ zone being treated as one Virtual Node. 

Linda

-Original Message-
From: Christian Hopps  
Sent: Saturday, July 11, 2020 6:42 AM
To: Linda Dunbar 
Cc: Christian Hopps ; LEI LIU ; Huaimo 
Chen ; lsr@ietf.org; lsr-cha...@ietf.org
    Subject: Re: [Lsr] Request WG adoption of TTZ



> On Jul 10, 2020, at 4:39 PM, Linda Dunbar  
wrote:
> 
> I also support the adoption of TTZ draft.
> 
> The Virtual Zone concept would be very useful for the Overlay networks. 
The proposed TTZ can group a set of nodes not geographically together into one 
virtual area to scale virtual overlay networks with lots of nodes. Those kind 
overlay networks are getting more momentum in SDWAN and CDN environment.

I'm not sure I follow this use-case. The intent of TTZ is to treat a bunch 
of nodes as a single node (or subset of nodes in early work) to reduce the 
link-state DB size and flooding requirements, AFAICT.

Thanks,
Chris.
[As WG member]


> 
> Linda Dunbar
> 
> From: Lsr  On Behalf Of LEI LIU
> Sent: Friday, July 10, 2020 12:42 PM
> To: Huaimo Chen 
> Cc: lsr@ietf.org; lsr-cha...@ietf.org
    > Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> I support the adoption of the TTZ draft.
> 
> The operation on TTZ is simple. Smooth transferring between a zone and a 
single node will improve customer experience. The work on TTZ should be moved 
forward.
> 
> Thanks,
> Best regards,
> 
> Lei
> 
> On Thu, Jun 18, 2020 at 8: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

Re: [Lsr] Request WG adoption of TTZ

[Linda Dunbar]

Christian, 

The SDWAN use case  is about grouping a set of nodes in geographically 
different locations to be one TTZ zone being treated as one Virtual Node. 

Linda

-Original Message-
From: Christian Hopps  
Sent: Saturday, July 11, 2020 6:42 AM
To: Linda Dunbar 
Cc: Christian Hopps ; LEI LIU ; Huaimo Chen 
; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



> On Jul 10, 2020, at 4:39 PM, Linda Dunbar  wrote:
> 
> I also support the adoption of TTZ draft.
> 
> The Virtual Zone concept would be very useful for the Overlay networks. The 
> proposed TTZ can group a set of nodes not geographically together into one 
> virtual area to scale virtual overlay networks with lots of nodes. Those kind 
> overlay networks are getting more momentum in SDWAN and CDN environment.

I'm not sure I follow this use-case. The intent of TTZ is to treat a bunch of 
nodes as a single node (or subset of nodes in early work) to reduce the 
link-state DB size and flooding requirements, AFAICT.

Thanks,
Chris.
[As WG member]


> 
> Linda Dunbar
> 
> From: Lsr  On Behalf Of LEI LIU
> Sent: Friday, July 10, 2020 12:42 PM
> To: Huaimo Chen 
> Cc: lsr@ietf.org; lsr-cha...@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> I support the adoption of the TTZ draft.
> 
> The operation on TTZ is simple. Smooth transferring between a zone and a 
> single node will improve customer experience. The work on TTZ should be moved 
> forward.
> 
> Thanks,
> Best regards,
> 
> Lei
> 
> On Thu, Jun 18, 2020 at 8: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

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

Re: [Lsr] Request WG adoption of TTZ

[Tony Li]

Hi Huaimo,


> 1).  It seems that Area Proxy can not be amended to IS-IS TTZ. IS-IS TTZ 
> abstracts a zone to a single node. This abstraction is supported by the 
> extensions to IS-IS, and some of these extensions are not defined in Area 
> Proxy. For example, the extensions for the edge nodes of the zone are not 
> defined in Area Proxy.
> 
> The details is underlined above. It says that some of the extensions in 
> IS-IS TTZ are not defined in Area Proxy. It seems accurate if we look at the 
> details


Apparently, we have very different understandings of the words “amended to”.

And so it goes.

Regards,
Tony


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

Re: [Lsr] Request WG adoption of TTZ

[Huaimo Chen]

Hi Tony，

1).  It seems that Area Proxy can not be amended to IS-IS TTZ. IS-IS TTZ 
abstracts a zone to a single node. This abstraction is supported by the 
extensions to IS-IS, and some of these extensions are not defined in Area 
Proxy. For example, the extensions for the edge nodes of the zone are not 
defined in Area Proxy.

The details is underlined above. It says that some of the extensions in 
IS-IS TTZ are not defined in Area Proxy. It seems accurate if we look at the 
details.

Best Regards,
Huaimo

From: Tony Li 
Sent: Tuesday, July 14, 2020 12:20 AM
To: Huaimo Chen 
Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Huaimo,


1).  It seems that Area Proxy can not be amended to IS-IS TTZ.



I feel that this is somewhat imprecise.

>From my perspective, our attempts to collaborate have been hampered by 
>governmental regulations that are wholly out of our control. The suggestions 
>that I’ve made for continued collaboration within the bounds of those controls 
>have not been well received. Thus, to say that something cannot be done is 
>overstating the case.  We have simply not been wiilling to do so, which is 
>most unfortunate.  Who can say what could happen if we could find a way for 
>all three proposals to collaborate?

Regards,
Tony

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

Re: [Lsr] Request WG adoption of TTZ

[Tony Li]

Hi Huaimo,


> 1).  It seems that Area Proxy can not be amended to IS-IS TTZ. 



I feel that this is somewhat imprecise.

From my perspective, our attempts to collaborate have been hampered by 
governmental regulations that are wholly out of our control. The suggestions 
that I’ve made for continued collaboration within the bounds of those controls 
have not been well received. Thus, to say that something cannot be done is 
overstating the case.  We have simply not been wiilling to do so, which is most 
unfortunate.  Who can say what could happen if we could find a way for all 
three proposals to collaborate?

Regards,
Tony

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

Re: [Lsr] Request WG adoption of TTZ

[Huaimo Chen]

I support the adoption of IS-IS TTZ draft.
1).  It seems that Area Proxy can not be amended to IS-IS TTZ. IS-IS TTZ 
abstracts a zone to a single node. This abstraction is supported by the 
extensions to IS-IS, and some of these extensions are not defined in Area 
Proxy. For example, the extensions for the edge nodes of the zone are not 
defined in Area Proxy.
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.
3). IS-IS TTZ provides smooth transferring between a zone and its single 
virtual node. That is that a zone can be smoothly transferred to a single 
virtual node, and the virtual node can be smoothly rolled back to the zone. 
This should improve customer experience since converting any block of an area 
to a single node is smooth with minimum or no service interruption.
4). Using IS-IS TTZ for network scalability may reduce the users' workload or 
make their work easier. They may put less efforts on planning a zone to be 
abstracted to a node. After the zone is abstracted to a node, the node can be 
rolled back to the zone smoothly if they want to redefine the zone.

BTW, RFC 8099 (OSPF TTZ) is for abstracting a zone of an OSPF area to its edges 
full mesh. IS-IS TTZ is much better than RFC 8099 regarding to improving 
network scalability since IS-IS TTZ focuses on abstracting a zone to a single 
node.

Best Regards,
Huaimo

From: Kiran Makhijani 
Sent: Monday, July 13, 2020 3:36 PM
To: Yanhe Fan ; Donald Eastlake ; 
Huaimo Chen 
Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
Subject: RE: [Lsr] Request WG adoption of TTZ

I support IS-IS TTZ adoption for its value in reducing LSDB through abstraction.
-Kiran

-Original Message-
From: Lsr  On Behalf Of Yanhe Fan
Sent: Sunday, July 12, 2020 7:33 AM
To: Donald Eastlake ; Huaimo Chen 
Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

I support adaption of this IS-IS TTZ draft. It is a useful work to address 
network scalability.

Thanks,
Yanhe

-Original Message-
From: Lsr  On Behalf Of Donald Eastlake
Sent: Friday, July 10, 2020 1:08 PM
To: Huaimo Chen 
Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

I support adoption of the IS-IS TTZ draft.

It seems more flexible and capable although some editorial/nomenclature 
improvements in the draft would be good. I will send some more detailed 
suggestions to the authors.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA  d3e...@gmail.com

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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2Fdata=02%7C01%7Chuaimo.chen%40futurewei.com%7Ce6b542df05de428ba29a08d82764136c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637302658065143399sdata=A4bYj%2B6ViMLIBApX1qQj93306nRIyL4aKs5QR0t%2B%2FJg%3Dreserved=0
>  .
>
>
> 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 i

Re: [Lsr] Request WG adoption of TTZ

[Kiran Makhijani]

I support IS-IS TTZ adoption for its value in reducing LSDB through abstraction.
-Kiran

-Original Message-
From: Lsr  On Behalf Of Yanhe Fan
Sent: Sunday, July 12, 2020 7:33 AM
To: Donald Eastlake ; Huaimo Chen 
Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

I support adaption of this IS-IS TTZ draft. It is a useful work to address 
network scalability.

Thanks,
Yanhe

-Original Message-
From: Lsr  On Behalf Of Donald Eastlake
Sent: Friday, July 10, 2020 1:08 PM
To: Huaimo Chen 
Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

I support adoption of the IS-IS TTZ draft.

It seems more flexible and capable although some editorial/nomenclature 
improvements in the draft would be good. I will send some more detailed 
suggestions to the authors.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA  d3e...@gmail.com

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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2Fdata=02%7C01%7Ckiranm%40futurewei.com%7C72917e53d6d94074876208d826709d01%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637301612416445576sdata=yxhI0GPxnBm5t0hosQNld4qq7O4bu3V2p4RExVjMcqE%3Dreserved=0
>  .
>
>
> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-li-lsr-isis-area-proxy-03data=02%7C01%7
> Ckiranm%40futurewei.com%7C72917e53d6d94074876208d826709d01%7C0fee8ff2a
> 3b240189c753a1d5591fedc%7C1%7C0%7C637301612416445576sdata=E95AXx%
> 2Bq4Xul3auIUt%2FUI203nvzgDODJDOs8l1Dlk9o%3Dreserved=0
>
> abstracts an existing IS-IS L1 area to a single pseudo node.
>
>
>
> "Flood Reflection" 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-przygienda-lsr-flood-reflection-01data=
> 02%7C01%7Ckiranm%40futurewei.com%7C72917e53d6d94074876208d826709d01%7C
> 0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637301612416445576sdat
> a=iNunk3YCV%2FiXEEYNYxozwgRlavMPB%2B%2FF1k6K6CCcWkA%3Dreserved=0
>
> 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://nam1

Re: [Lsr] Request WG adoption of TTZ

[ruoxin huang]

I strongly support the adoption of the IS-IS TTZ draft.
For the large scale network, if we just run the IS-IS in a large area, the LSDB 
will be very large.
In addition, the convergence time will last for a long time. But TTZ is a good 
way to reduce the network size and the number of the Link state can be reduced 
largely.

BR,
Rouxin

From: Lsr  on behalf of reta Yang 
Sent: Monday, July 13, 2020 8:20 PM
To: lsr@ietf.org 
Subject: Re: [Lsr] Request WG adoption of TTZ

I support adoption of the IS-IS TTZ draft.
It is very useful for the large network with abstracting a zone to a single 
virtual node.
The size of the LSDB can be reduced dramatically.

best,
Reta

From: Lsr  on behalf of Toy, Mehmet 

Sent: Monday, July 13, 2020 8:06 AM
To: lsr@ietf.org 
Cc: lsr-cha...@ietf.org 
Subject: Re: [Lsr] Request WG adoption of TTZ


I support adoption of the IS-IS TTZ draft.

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

Re: [Lsr] Request WG adoption of TTZ

[reta Yang]

I support adoption of the IS-IS TTZ draft.
It is very useful for the large network with abstracting a zone to a single 
virtual node.
The size of the LSDB can be reduced dramatically.

best,
Reta

From: Lsr  on behalf of Toy, Mehmet 

Sent: Monday, July 13, 2020 8:06 AM
To: lsr@ietf.org 
Cc: lsr-cha...@ietf.org 
Subject: Re: [Lsr] Request WG adoption of TTZ


I support adoption of the IS-IS TTZ draft.

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

Re: [Lsr] Request WG adoption of TTZ

[Toy, Mehmet]

I support adoption of the IS-IS TTZ draft.

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

Re: [Lsr] Request WG adoption of TTZ

[Yanhe Fan]

I support adaption of this IS-IS TTZ draft. It is a useful work to address 
network scalability.

Thanks,
Yanhe

-Original Message-
From: Lsr  On Behalf Of Donald Eastlake
Sent: Friday, July 10, 2020 1:08 PM
To: Huaimo Chen 
Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

I support adoption of the IS-IS TTZ draft.

It seems more flexible and capable although some editorial/nomenclature 
improvements in the draft would be good. I will send some more detailed 
suggestions to the authors.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA  d3e...@gmail.com

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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request WG adoption of TTZ

[Liu Vic]

Using TTZ for network scalability will keep good customer experience. TTZ
draft should be adopted.
I would support the IS-IS TTZ solution for WG adoption.

Vic

Anil Kumar  于2020年7月11日周六 上午9:22写道：

>
>  I would support the IS-IS TTZ solution for WG adoption.
>
> With Regards
> Anil S N
>
> On Sat, Jul 11, 2020 at 4:38 AM 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).
>>
>>
>> I will send my specific comments/suggestions a bit later.
>>
>> --
>>
>> Uma C..
>>
>>
>>
>> On Thu, Jun 18, 2020 at 8: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
>>
> ___
> 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

[Anil Kumar]

 I would support the IS-IS TTZ solution for WG adoption.

With Regards
Anil S N

On Sat, Jul 11, 2020 at 4:38 AM 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).
>
>
> I will send my specific comments/suggestions a bit later.
>
> --
>
> Uma C.
>
>
>
> On Thu, Jun 18, 2020 at 8: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
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request WG adoption of TTZ

[Christian Hopps]

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

I would be very interested in hearing from operators who have experience with 
TTZ since RFC8099 has been around for over 3 years now.

Thanks,
Chris.
[As WG member]


> I will send my specific comments/suggestions a bit later.
> --
> Uma C.
> 
> 
> On Thu, Jun 18, 2020 at 8: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



signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request WG adoption of TTZ

[Christian Hopps]

> On Jul 10, 2020, at 4:39 PM, Linda Dunbar  wrote:
> 
> I also support the adoption of TTZ draft.
> 
> The Virtual Zone concept would be very useful for the Overlay networks. The 
> proposed TTZ can group a set of nodes not geographically together into one 
> virtual area to scale virtual overlay networks with lots of nodes. Those kind 
> overlay networks are getting more momentum in SDWAN and CDN environment.

I'm not sure I follow this use-case. The intent of TTZ is to treat a bunch of 
nodes as a single node (or subset of nodes in early work) to reduce the 
link-state DB size and flooding requirements, AFAICT.

Thanks,
Chris.
[As WG member]


> 
> Linda Dunbar
> 
> From: Lsr  On Behalf Of LEI LIU
> Sent: Friday, July 10, 2020 12:42 PM
> To: Huaimo Chen 
> Cc: lsr@ietf.org; lsr-cha...@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> I support the adoption of the TTZ draft.
> 
> The operation on TTZ is simple. Smooth transferring between a zone and a 
> single node will improve customer experience. The work on TTZ should be moved 
> forward.
> 
> Thanks,
> Best regards,
> 
> Lei
> 
> On Thu, Jun 18, 2020 at 8: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



signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Request WG adoption of TTZ

[Uma Chunduri]

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


I will send my specific comments/suggestions a bit later.

--

Uma C.



On Thu, Jun 18, 2020 at 8: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

[Haoyu Song]

IS-IS TTZ is useful and I support the adoption of the TTZ draft too.
Thanks!

Haoyu
From: Linda Dunbar 
Sent: Friday, July 10, 2020 1:40 PM
To: LEI LIU ; Huaimo Chen 
Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

I also support the adoption of TTZ draft.

The Virtual Zone concept would be very useful for the Overlay networks. The 
proposed TTZ can group a set of nodes not geographically together into one 
virtual area to scale virtual overlay networks with lots of nodes. Those kind 
overlay networks are getting more momentum in SDWAN and CDN environment.

Linda Dunbar

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of LEI 
LIU
Sent: Friday, July 10, 2020 12:42 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: [Lsr] Request WG adoption of TTZ

I support the adoption of the TTZ draft.

The operation on TTZ is simple. Smooth transferring between a zone and a single 
node will improve customer experience. The work on TTZ should be moved forward.

Thanks,
Best regards,

Lei

On Thu, Jun 18, 2020 at 8:38 PM Huaimo Chen 
mailto:huaimo.c...@futurewei.com>> 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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2F=02%7C01%7Clinda.dunbar%40futurewei.com%7Cf4502b794e7a4b66836408d824f8c059%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63728093803058=tqunOWC7trBoFu3XBvAFrLDzyFdlLQl9xYMtMdPSMgo%3D=0>
 .



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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-lsr-isis-area-proxy-03=02%7C01%7Clinda.dunbar%40futurewei.com%7Cf4502b794e7a4b66836408d824f8c059%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63728093808054=OxU3ikjVtGtL7piPPc2WJQ8GatTz1XMnoREwVA00%2F2E%3D=0>

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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-przygienda-lsr-flood-reflection-01=02%7C01%7Clinda.dunbar%40futurewei.com%7Cf4502b794e7a4b66836408d824f8c059%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63728093818056=jiSeOvvxabugWULFhFag%2BvVHEbmXBF6mza9cSwbi5t8%3D=0>

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<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr=02%7C01%7Clinda.dunbar%40futurewei.com%7Cf4502b794e7a4b

Re: [Lsr] Request WG adoption of TTZ

[Linda Dunbar]

I also support the adoption of TTZ draft.

The Virtual Zone concept would be very useful for the Overlay networks. The 
proposed TTZ can group a set of nodes not geographically together into one 
virtual area to scale virtual overlay networks with lots of nodes. Those kind 
overlay networks are getting more momentum in SDWAN and CDN environment.

Linda Dunbar

From: Lsr  On Behalf Of LEI LIU
Sent: Friday, July 10, 2020 12:42 PM
To: Huaimo Chen 
Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

I support the adoption of the TTZ draft.

The operation on TTZ is simple. Smooth transferring between a zone and a single 
node will improve customer experience. The work on TTZ should be moved forward.

Thanks,
Best regards,

Lei

On Thu, Jun 18, 2020 at 8:38 PM Huaimo Chen 
mailto:huaimo.c...@futurewei.com>> 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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-isis-ttz%2F=02%7C01%7Clinda.dunbar%40futurewei.com%7Cf4502b794e7a4b66836408d824f8c059%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63728093803058=tqunOWC7trBoFu3XBvAFrLDzyFdlLQl9xYMtMdPSMgo%3D=0>
 .



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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-lsr-isis-area-proxy-03=02%7C01%7Clinda.dunbar%40futurewei.com%7Cf4502b794e7a4b66836408d824f8c059%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63728093808054=OxU3ikjVtGtL7piPPc2WJQ8GatTz1XMnoREwVA00%2F2E%3D=0>

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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-przygienda-lsr-flood-reflection-01=02%7C01%7Clinda.dunbar%40futurewei.com%7Cf4502b794e7a4b66836408d824f8c059%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63728093818056=jiSeOvvxabugWULFhFag%2BvVHEbmXBF6mza9cSwbi5t8%3D=0>

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<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr=02%7C01%7Clinda.dunbar%40futurewei.com%7Cf4502b794e7a4b66836408d824f8c059%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63728093823049=mqXl2c5rWwvbP%2BW6iRJCK8%2FtTktq56eKhfB53gF4y38%3D=0>


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

Re: [Lsr] Request WG adoption of TTZ

[LEI LIU]

I support the adoption of the TTZ draft.

The operation on TTZ is simple. Smooth transferring between a zone and a
single node will improve customer experience. The work on TTZ should be
moved forward.

Thanks,
Best regards,

Lei

On Thu, Jun 18, 2020 at 8: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

[Donald Eastlake]

I support adoption of the IS-IS TTZ draft.

It seems more flexible and capable although some
editorial/nomenclature improvements in the draft would be good. I will
send some more detailed suggestions to the authors.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

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

[Huaimo Chen]

Hi Acee,

Thank you very much for your suggestion.
I have removed the OSPF details from the draft.

Best Regards,
Huaimo

From: Acee Lindem (acee) 
Sent: Wednesday, July 8, 2020 9:37 AM
To: Huaimo Chen ; Christian Hopps 

Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
Subject: Re: [Lsr] Request WG adoption of TTZ


On PTO so will be brief… Inline



From: Huaimo Chen 
Date: Tuesday, July 7, 2020 at 11:22 PM
To: Acee Lindem , Christian Hopps 
Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" 
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Acee,



Thank you very much for your comments.

My answers/explanations are inline below with prefix [HC].



Best Regards,

Huaimo



From: Acee Lindem (acee) 
Sent: Tuesday, July 7, 2020 4:33 PM
To: Huaimo Chen ; Christian Hopps 

Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
Subject: Re: [Lsr] Request WG adoption of TTZ



Speaking as WG member:



Hi Huaimo,



Independent of the major issue with Area Proxy differentiation, I have a couple 
other issues that I didn’t want to include in the same Email thread.



1.   You can’t describe IS-IS protocol details and then just include OSPF 
encodings and expect the readers to intuit the OSPF specific details. These 
area abstraction drafts modify basic protocol mechanisms and OSPF details would 
be better specified in an update to RFC 8099 then just adding encodings to this 
IS-IS TTZ draft.
[HC]: We will add more OSPF details. I am OK for OSPF details to be in an 
update to RFC 8099.



Just not in the IS-IS TTZ draft. OSPF and IS-IS have different protocol 
mechanisms and completely different terminology.

Thanks,

Acee



2.   The draft uses the term IS-IS Pseudo-node yet this is defined in IS-IS 
as a specific LSP to represent a multi-access network. I don’t know if the 
usage of the terminology was meant to differentiate the mechanisms from Area 
Proxy but I find the repurposing of the term pseudo-node in the context of 
IS-IS very confusing.
[HC]: We will change it to another term.

3.   The document keeps referring to  “edges full mess” and I believe you 
mean “edges full mesh”.

[HC]: You are right. It should be "edges full mesh".



Thanks,

Acee



From: Lsr  on behalf of Huaimo Chen 

Date: Tuesday, July 7, 2020 at 12:01 PM
To: Christian Hopps 
Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" 
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Chris,



Thank you very much for your questions.

My answers/explanations are inline below with prefix [HC].



Best Regards,

Huaimo



From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?



[HC]: There are some differences even though they looks similar.

At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.

Area Proxy abstracts an existing area to a single pseudo node.

TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.

An area is different from a zone in general.



Secondly, the ways in which they are applied to an area for scalability are 
different.

When an area becomes bigger and bigger, we may have scalability issues. Using 
TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes 
smoothly without any interface down. Using Area Proxy, we need split the 
existing area into multiple areas, and then abstract one or a few areas to one 
or few pseudo nodes.

These differences will produce different user experiences.

For splitting an existing area into multiple areas, users may need put more 
efforts since it causes service interruptions in general. While splitting an 
area such as an OSPF area into multiple areas, the area numbers configured on 
some interfaces will be changed and each of these interfaces will be down with 
its old area number and then up with its new area number. These interface downs 
and ups will cause service interruptions in general.

For defining zones in an area, users may need less efforts since abstracting a 
zone to a single pseudo node is smooth without any interface down.



Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.



BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to a 
single pseudo node.

In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo node, 
and a zone in an IS-IS area to a single pseudo node.



There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i 
found it confusing to have this document also talking 

Re: [Lsr] Request WG adoption of TTZ

[Acee Lindem (acee)]

On PTO so will be brief… Inline

From: Huaimo Chen 
Date: Tuesday, July 7, 2020 at 11:22 PM
To: Acee Lindem , Christian Hopps 
Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" 
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Acee,

Thank you very much for your comments.
My answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo

From: Acee Lindem (acee) 
Sent: Tuesday, July 7, 2020 4:33 PM
To: Huaimo Chen ; Christian Hopps 
Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
Subject: Re: [Lsr] Request WG adoption of TTZ


Speaking as WG member:



Hi Huaimo,



Independent of the major issue with Area Proxy differentiation, I have a couple 
other issues that I didn’t want to include in the same Email thread.



1.   You can’t describe IS-IS protocol details and then just include OSPF 
encodings and expect the readers to intuit the OSPF specific details. These 
area abstraction drafts modify basic protocol mechanisms and OSPF details would 
be better specified in an update to RFC 8099 then just adding encodings to this 
IS-IS TTZ draft.
[HC]: We will add more OSPF details. I am OK for OSPF details to be in an 
update to RFC 8099.



Just not in the IS-IS TTZ draft. OSPF and IS-IS have different protocol 
mechanisms and completely different terminology.

Thanks,

Acee



2.   The draft uses the term IS-IS Pseudo-node yet this is defined in IS-IS 
as a specific LSP to represent a multi-access network. I don’t know if the 
usage of the terminology was meant to differentiate the mechanisms from Area 
Proxy but I find the repurposing of the term pseudo-node in the context of 
IS-IS very confusing.
[HC]: We will change it to another term.

3.   The document keeps referring to  “edges full mess” and I believe you 
mean “edges full mesh”.
[HC]: You are right. It should be "edges full mesh".



Thanks,

Acee



From: Lsr  on behalf of Huaimo Chen 

Date: Tuesday, July 7, 2020 at 12:01 PM
To: Christian Hopps 
Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" 
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Chris,



Thank you very much for your questions.

My answers/explanations are inline below with prefix [HC].



Best Regards,

Huaimo



From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?



[HC]: There are some differences even though they looks similar.

At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.

Area Proxy abstracts an existing area to a single pseudo node.

TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.

An area is different from a zone in general.



Secondly, the ways in which they are applied to an area for scalability are 
different.

When an area becomes bigger and bigger, we may have scalability issues. Using 
TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes 
smoothly without any interface down. Using Area Proxy, we need split the 
existing area into multiple areas, and then abstract one or a few areas to one 
or few pseudo nodes.

These differences will produce different user experiences.

For splitting an existing area into multiple areas, users may need put more 
efforts since it causes service interruptions in general. While splitting an 
area such as an OSPF area into multiple areas, the area numbers configured on 
some interfaces will be changed and each of these interfaces will be down with 
its old area number and then up with its new area number. These interface downs 
and ups will cause service interruptions in general.

For defining zones in an area, users may need less efforts since abstracting a 
zone to a single pseudo node is smooth without any interface down.



Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.



BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to a 
single pseudo node.

In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo node, 
and a zone in an IS-IS area to a single pseudo node.



There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i 
found it confusing to have this document also talking about TTZ for OSPF; is it 
redefining it, updating it, just referring to it?



[HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for 
abstracting a zone to the zone edges full mess. This document proposes a new 
solution for abstracting a zone to a single pseudo node. The new solution 
re-uses some of RFC 8099, to which are referred

Re: [Lsr] Request WG adoption of TTZ

[Acee Lindem (acee)]

Huaimo,
The LSR WG has been discussing IS-IS Area Abstraction in the context of 
flooding overhead in DC topologies for over a year now. Why are you are trying 
to hijack this discussion in favor of OSPF Area Abstraction??? The fact that 
your draft includes some OSPF encodings is NOT a differentiating feature in the 
context of this discussion. In fact, both Chris and I have asked that you 
remove the OSPF encodings from your IS-IS TTZ draft. Furthermore, if you want 
to respin RFC 8099 applying the IS-IS Area proxy mechanisms to OSPF, that is a 
totally separate discussion.
Thanks,
Acee

From: Huaimo Chen 
Date: Tuesday, July 7, 2020 at 8:42 PM
To: Acee Lindem , Christian Hopps 
Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" 
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Acee and Chris,

Thank you very much for your comments.


> I agree with Chris – when the IS-IS TTZ draft adopted the approach of having 
> the area/zone leader originate a single LSP abstracting the zone/area last 
> Oct, the main differentiation between the two approaches is the zone/area 
> terminology. The other substantive difference is the fact that the Area Proxy 
> draft includes a much more comprehensive specification of the protocol 
> mechanisms required for area/zone abstraction. I have no doubt that the Area 
> Proxy details could also be amended from area proxy to TTZ, but that is 
> exactly Chris’s point with which I agree – there essentially isn’t a 
> difference.



Thanks,

Acee

There are really some differences between TTZ and Area Proxy, which are 
listed below for OSPF and IS-IS:
Differences between OSPF TTZ and OSPF Area Proxy (note: assume that OSPF 
Area Proxy is similar to IS-IS Area Proxy even though OSPF Area Proxy is not 
defined in the Area Proxy draft) include:
1).  It seems that OSPF Area Proxy can not be amended to OSPF TTZ. OSPF TTZ 
abstracts a zone to a single pseudo node. This abstraction is supported by the 
extensions to OSPF, and some of these extensions are not defined in OSPF Area 
Proxy. For example, the extensions for the edge nodes of the zone are not 
defined in OSPF Area Proxy.
2).  OSPF Area Proxy abstracts an existing OSPF area to a single pseudo 
node.  OSPF TTZ abstracts a zone to a single pseudo node. A zone is a piece or 
block of an OSPF area. An OSPF area is different from a zone in general.
3). The ways in which they are applied to an OSPF area for scalability are 
different. When an OSPF area becomes bigger and bigger, we may have scalability 
issues. Using OSPF TTZ, we can abstract one or a few zones in the OSPF area to 
one or few pseudo nodes smoothly without any interface down. Using OSPF Area 
Proxy, we need split the existing OSPF area into multiple OSPF areas, and then 
abstract one or a few OSPF areas to one or few pseudo nodes. Some people may 
like the one step operation in OSPF TTZ. Others may like the two step 
operations in OSPF Area Proxy.
4). The user experiences are different. For splitting an existing OSPF area 
into multiple OSPF areas, users may need put more efforts since it causes 
service interruptions in general. While splitting an OSPF area into multiple 
OSPF areas, the area numbers configured on some interfaces will be changed and 
each of these interfaces will be down with its old area number and then up with 
its new area number. These interface downs and ups will cause service 
interruptions in general. For defining zones in an OSPF area, users may need 
less efforts since abstracting a zone to a single pseudo node is smooth without 
any interface down.
5). OSPF TTZ provides smooth transferring between a zone and its single 
pseudo node. That is that a zone can be smoothly transferred to a single pseudo 
node, and the pseudo node can be smoothly rolled back to the zone.

Differences between IS-IS TTZ and IS-IS Area Proxy are similar to
the above 1). 2). 3). and 5) between OSPF TTZ and OSPF Area Proxy.

Best Regards,
Huaimo

From: Acee Lindem (acee) 
Sent: Tuesday, July 7, 2020 3:41 PM
To: Huaimo Chen ; Christian Hopps 
Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
Subject: Re: [Lsr] Request WG adoption of TTZ


Speaking as WG member:



I agree with Chris – when the IS-IS TTZ draft adopted the approach of having 
the area/zone leader originate a single LSP abstracting the zone/area last Oct, 
the main differentiation between the two approaches is the zone/area 
terminology. The other substantive difference is the fact that the Area Proxy 
draft includes a much more comprehensive specification of the protocol 
mechanisms required for area/zone abstraction. I have no doubt that the Area 
Proxy details could also be amended from area proxy to TTZ, but that is exactly 
Chris’s point with which I agree – there essentially isn’t a difference.



Thanks,
Acee

From: Lsr  on behalf of Huaimo Chen 

Date: Tuesday, July 7, 2020 at 12:01 PM
To:

Re: [Lsr] Request WG adoption of TTZ

[Huaimo Chen]

Hi Acee,

Thank you very much for your comments.
My answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo

From: Acee Lindem (acee) 
Sent: Tuesday, July 7, 2020 4:33 PM
To: Huaimo Chen ; Christian Hopps 

Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
Subject: Re: [Lsr] Request WG adoption of TTZ


Speaking as WG member:



Hi Huaimo,



Independent of the major issue with Area Proxy differentiation, I have a couple 
other issues that I didn’t want to include in the same Email thread.



  1.  You can’t describe IS-IS protocol details and then just include OSPF 
encodings and expect the readers to intuit the OSPF specific details. These 
area abstraction drafts modify basic protocol mechanisms and OSPF details would 
be better specified in an update to RFC 8099 then just adding encodings to this 
IS-IS TTZ draft.
[HC]: We will add more OSPF details. I am OK for OSPF details to be in an 
update to RFC 8099.
  2.  The draft uses the term IS-IS Pseudo-node yet this is defined in IS-IS as 
a specific LSP to represent a multi-access network. I don’t know if the usage 
of the terminology was meant to differentiate the mechanisms from Area Proxy 
but I find the repurposing of the term pseudo-node in the context of IS-IS very 
confusing.
[HC]: We will change it to another term.
  3.  The document keeps referring to  “edges full mess” and I believe you mean 
“edges full mesh”.

[HC]: You are right. It should be "edges full mesh".



Thanks,

Acee



From: Lsr  on behalf of Huaimo Chen 

Date: Tuesday, July 7, 2020 at 12:01 PM
To: Christian Hopps 
Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" 
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Chris,



Thank you very much for your questions.

My answers/explanations are inline below with prefix [HC].



Best Regards,

Huaimo



From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?



[HC]: There are some differences even though they looks similar.

At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.

Area Proxy abstracts an existing area to a single pseudo node.

TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.

An area is different from a zone in general.



Secondly, the ways in which they are applied to an area for scalability are 
different.

When an area becomes bigger and bigger, we may have scalability issues. Using 
TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes 
smoothly without any interface down. Using Area Proxy, we need split the 
existing area into multiple areas, and then abstract one or a few areas to one 
or few pseudo nodes.

These differences will produce different user experiences.

For splitting an existing area into multiple areas, users may need put more 
efforts since it causes service interruptions in general. While splitting an 
area such as an OSPF area into multiple areas, the area numbers configured on 
some interfaces will be changed and each of these interfaces will be down with 
its old area number and then up with its new area number. These interface downs 
and ups will cause service interruptions in general.

For defining zones in an area, users may need less efforts since abstracting a 
zone to a single pseudo node is smooth without any interface down.



Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.



BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to a 
single pseudo node.

In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo node, 
and a zone in an IS-IS area to a single pseudo node.



There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i 
found it confusing to have this document also talking about TTZ for OSPF; is it 
redefining it, updating it, just referring to it?



[HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for 
abstracting a zone to the zone edges full mess. This document proposes a new 
solution for abstracting a zone to a single pseudo node. The new solution 
re-uses some of RFC 8099, to which are referred. The new extensions to OSPF for 
the new solution are defined in the document.

Thanks,
Chris.
[chair hat]


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

Re: [Lsr] Request WG adoption of TTZ

[tony . li]

Hi Aijun,

Subdividing an existing area is entirely possible with Area Proxy.  You just 
have to split the area and then apply Area Proxy.  ;-)

Tony


> On Jul 7, 2020, at 7:36 PM, Aijun Wang  wrote:
> 
> Hi, Les:
> 
> Using TTZ to sub divide the existing area seems more attractive. It seems TTZ 
> can accomplish all the functions Area Proxy can provide, but area proxy can’t 
> cover the scenarios that TTZ can solve.
> Why don’t we prefer to TTZ?
> 
> Aijun Wang
> China Telecom
> 
>> On Jul 8, 2020, at 08:53, Les Ginsberg (ginsberg) 
>>  wrote:
>> 
>> 
>> Huaimo –
>>  
>> Sorry for ascribing area merging properties to zones... As the base protocol 
>> mechanism in IS-IS can be used both to split and merge areas I was thinking 
>> zones could be used the same way, but I see on closer reading that you have 
>> restricted a zone to be a subset of an area (which could also be the area 
>> itself).
>>  
>> I think this does not detract from the main point I am trying to make – 
>> which is that unless there is reason to believe that operators would prefer 
>> to use zones rather than split an area (when necessary), this does not serve 
>> as a significant differentiator between TTZ and area-proxy.
>> I think you need a more compelling differentiator to justify proceeding with 
>> both drafts.
>>  
>> In this regard I am agreeing with the points made by other folks (notably 
>> Chris and Tony), that the introduction of zones may well be adding unneeded 
>> complexity.
>>  
>> Just my opinion of course…
>>  
>>    Les
>>  
>>  
>> From: Huaimo Chen  
>> Sent: Tuesday, July 07, 2020 12:42 PM
>> To: Les Ginsberg (ginsberg) ; Christian Hopps 
>> 
>> Cc: lsr@ietf.org; lsr-cha...@ietf.org
>> Subject: Re: [Lsr] Request WG adoption of TTZ
>>  
>> Hi Les,
>>  
>> > I think what you are highlighting is that w TTZ an operator could apply 
>> > the solution to a subset of an area (which you call a zone) – or to a set 
>> > of areas (which you also call a zone). This presumes that it is expected 
>> > that a customer would want to operate in a mode where the interconnections 
>> > do not follow area boundaries. It isn’t clear to me that this is a 
>> > compelling requirement. If there are operators who feel otherwise I would 
>> > appreciate them speaking up and educating us on the requirements.
>>  
>> How do you get that TTZ could be used to a set of areas (which you also call 
>> a zone)? 
>> A zone is a piece or block of an area.  In an area, we can define one or 
>> more zones. All these zones are within this area. For a set of areas, we can 
>> define one or more zones in each of these areas.. But we can not define a 
>> zone crossing multiple areas.
>>  
>> Best Regards,
>> Huaimo
>> From: Les Ginsberg (ginsberg) > <mailto:ginsb...@cisco.com>>
>> Sent: Tuesday, July 7, 2020 3:29 PM
>> To: Huaimo Chen > <mailto:huaimo.c...@futurewei.com>>; Christian Hopps > <mailto:cho...@chopps.org>>
>> Cc: lsr@ietf.org <mailto:lsr@ietf.org> mailto:lsr@ietf.org>>; 
>> lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org> > <mailto:lsr-cha...@ietf.org>>
>> Subject: RE: [Lsr] Request WG adoption of TTZ
>>  
>> Huaimo –
>>  
>> I think what you are highlighting is that w TTZ an operator could apply the 
>> solution to a subset of an area (which you call a zone) – or to a set of 
>> areas (which you also call a zone). This presumes that it is expected that a 
>> customer would want to operate in a mode where the interconnections do not 
>> follow area boundaries. It isn’t clear to me that this is a compelling 
>> requirement. If there are operators who feel otherwise I would appreciate 
>> them speaking up and educating us on the requirements.
>>  
>> Absent that, it seems if you want to differentiate TTZ from Area-Proxy you 
>> should be focusing on things other than the flexibility of zones over areas.
>>  
>>Les
>>  
>>  
>> From: Huaimo Chen > <mailto:huaimo.c...@futurewei.com>> 
>> Sent: Tuesday, July 07, 2020 11:13 AM
>> To: Les Ginsberg (ginsberg) > <mailto:ginsb...@cisco.com>>; Christian Hopps > <mailto:cho...@chopps.org>>
>> Cc: lsr@ietf.org <mailto:lsr@ietf.org>; lsr-cha...@ietf.org 
>> <mailto:lsr-cha...@ietf.org>
>> Subject: Re: [Lsr] Request WG adoption of TTZ
>>  
>> Hi Les,
>>  
>> Thank you very much for your comments.
>>  

Re: [Lsr] Request WG adoption of TTZ

[Aijun Wang]

Hi, Les:

Using TTZ to sub divide the existing area seems more attractive. It seems TTZ 
can accomplish all the functions Area Proxy can provide, but area proxy can’t 
cover the scenarios that TTZ can solve.
Why don’t we prefer to TTZ?

Aijun Wang
China Telecom

> On Jul 8, 2020, at 08:53, Les Ginsberg (ginsberg) 
>  wrote:
> 
> 
> Huaimo –
>  
> Sorry for ascribing area merging properties to zones.. As the base protocol 
> mechanism in IS-IS can be used both to split and merge areas I was thinking 
> zones could be used the same way, but I see on closer reading that you have 
> restricted a zone to be a subset of an area (which could also be the area 
> itself).
>  
> I think this does not detract from the main point I am trying to make – which 
> is that unless there is reason to believe that operators would prefer to use 
> zones rather than split an area (when necessary), this does not serve as a 
> significant differentiator between TTZ and area-proxy.
> I think you need a more compelling differentiator to justify proceeding with 
> both drafts.
>  
> In this regard I am agreeing with the points made by other folks (notably 
> Chris and Tony), that the introduction of zones may well be adding unneeded 
> complexity.
>  
> Just my opinion of course…
>  
>Les
>  
>  
> From: Huaimo Chen  
> Sent: Tuesday, July 07, 2020 12:42 PM
> To: Les Ginsberg (ginsberg) ; Christian Hopps 
> 
> Cc: lsr@ietf.org; lsr-cha...@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
>  
> Hi Les,
>  
> > I think what you are highlighting is that w TTZ an operator could apply the 
> > solution to a subset of an area (which you call a zone) – or to a set of 
> > areas (which you also call a zone). This presumes that it is expected that 
> > a customer would want to operate in a mode where the interconnections do 
> > not follow area boundaries. It isn’t clear to me that this is a compelling 
> > requirement. If there are operators who feel otherwise I would appreciate 
> > them speaking up and educating us on the requirements.
>  
> How do you get that TTZ could be used to a set of areas (which you also call 
> a zone)? 
> A zone is a piece or block of an area.  In an area, we can define one or more 
> zones. All these zones are within this area. For a set of areas, we can 
> define one or more zones in each of these areas.. But we can not define a 
> zone crossing multiple areas.
>  
> Best Regards,
> Huaimo
> From: Les Ginsberg (ginsberg) 
> Sent: Tuesday, July 7, 2020 3:29 PM
> To: Huaimo Chen ; Christian Hopps 
> 
> Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
> Subject: RE: [Lsr] Request WG adoption of TTZ
>  
> Huaimo –
>  
> I think what you are highlighting is that w TTZ an operator could apply the 
> solution to a subset of an area (which you call a zone) – or to a set of 
> areas (which you also call a zone). This presumes that it is expected that a 
> customer would want to operate in a mode where the interconnections do not 
> follow area boundaries. It isn’t clear to me that this is a compelling 
> requirement. If there are operators who feel otherwise I would appreciate 
> them speaking up and educating us on the requirements.
>  
> Absent that, it seems if you want to differentiate TTZ from Area-Proxy you 
> should be focusing on things other than the flexibility of zones over areas..
>  
>Les
>  
>  
> From: Huaimo Chen  
> Sent: Tuesday, July 07, 2020 11:13 AM
> To: Les Ginsberg (ginsberg) ; Christian Hopps 
> 
> Cc: lsr@ietf.org; lsr-cha...@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
>  
> Hi Les,
>  
> Thank you very much for your comments.
>  
> There are still some differences between Area Proxy and TTZ regarding to 
> IS-IS with smooth area splitting and merging. 
>  
> At first, the operations/configurations are different. 
> Using Area Proxy, two steps are needed. One step is to split an IS-IS 
> area to multiple areas through some configurations. The other step is to 
> abstract an existing IS-IS area to a single pseudo node through another set 
> of configurations. 
> Using TTZ, only one step is needed, which is to abstract a zone to a 
> single pseudo node.
> From operations' point of view, TTZ seems simpler.
>  
> Secondly, TTZ provides smooth transferring between a zone and its single 
> pseudo node. That is that a zone can be smoothly transferred to a single 
> pseudo node, and the pseudo node can be smoothly rolled back to the zone.  
> Smooth IS-IS area splitting and merging can not be used for abstracting an 
> existing IS-IS area to a single pseudo node in Area Proxy. 
>  
> Best Regards,
> Huaimo
> F

Re: [Lsr] Request WG adoption of TTZ

[Huaimo Chen]

Hi Chris,

Thank you very much for your comments.
My answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo

From: Christian Hopps
Sent: Tuesday, July 7, 2020 9:21 PM
To: Huaimo Chen
Cc: Christian Hopps; Acee Lindem (acee); lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



> On Jul 7, 2020, at 8:42 PM, Huaimo Chen  wrote:
>
> Hi Acee and Chris,
>
> Thank you very much for your comments.
>
> > I agree with Chris – when the IS-IS TTZ draft adopted the approach of 
> > having the area/zone leader originate a single LSP abstracting the 
> > zone/area last Oct, the main differentiation between the two approaches is 
> > the zone/area terminology. The other substantive difference is the fact 
> > that the Area Proxy draft includes a much more comprehensive specification 
> > of the protocol mechanisms required for area/zone abstraction. I have no 
> > doubt that the Area Proxy details could also be amended from area proxy to 
> > TTZ, but that is exactly Chris’s point with which I agree – there 
> > essentially isn’t a difference.
>
> Thanks,
> Acee
>
> There are really some differences between TTZ and Area Proxy, which are 
> listed below for OSPF and IS-IS:
> Differences between OSPF TTZ and OSPF Area Proxy (note: assume that OSPF 
> Area Proxy is similar to IS-IS Area Proxy even though OSPF Area Proxy is not 
> defined in the Area Proxy draft) include:
> 1).  It seems that OSPF Area Proxy can not be amended to OSPF TTZ. OSPF 
> TTZ abstracts a zone to a single pseudo node. This abstraction is supported 
> by the extensions to OSPF, and some of these extensions are not defined in 
> OSPF Area Proxy. For example, the extensions for the edge nodes of the zone 
> are not defined in OSPF Area Proxy.
> 2).  OSPF Area Proxy abstracts an existing OSPF area to a single pseudo 
> node.  OSPF TTZ abstracts a zone to a single pseudo node. A zone is a piece 
> or block of an OSPF area. An OSPF area is different from a zone in general.
> 3). The ways in which they are applied to an OSPF area for scalability 
> are different. When an OSPF area becomes bigger and bigger, we may have 
> scalability issues. Using OSPF TTZ, we can abstract one or a few zones in the 
> OSPF area to one or few pseudo nodes smoothly without any interface down. 
> Using OSPF Area Proxy, we need split the existing OSPF area into multiple 
> OSPF areas, and then abstract one or a few OSPF areas to one or few pseudo 
> nodes. Some people may like the one step operation in OSPF TTZ. Others may 
> like the two step operations in OSPF Area Proxy.
> 4). The user experiences are different. For splitting an existing OSPF 
> area into multiple OSPF areas, users may need put more efforts since it 
> causes service interruptions in general. While splitting an OSPF area into 
> multiple OSPF areas, the area numbers configured on some interfaces will be 
> changed and each of these interfaces will be down with its old area number 
> and then up with its new area number.. These interface downs and ups will 
> cause service interruptions in general.. For defining zones in an OSPF area, 
> users may need less efforts since abstracting a zone to a single pseudo node 
> is smooth without any interface down.
> 5). OSPF TTZ provides smooth transferring between a zone and its single 
> pseudo node. That is that a zone can be smoothly transferred to a single 
> pseudo node, and the pseudo node can be smoothly rolled back to the zone..

I think the fact that the above is mixing terms (e.g., OSPF Area Proxy, which 
doesn't exist, and OSPF doesn't have pseudo-nodes) is really highlighting the 
fact that, as Acee pointed out, perhaps its not a good idea to be trying to 
update/modify OSPF TTZ (RFC8099), and at the same time introduce something new 
to IS-IS. It's very confusing right now to have these things all mixed together 
like this.

[HC]: OSPF Area Proxy does not exist and it seems that Tony is not interested 
in it. In this case, I think that abstracting a zone to a single node should be 
moved forward.  It should extends RFC 8099, not update/modify RFC 8099.
For IS-IS TTZ, it just needs two new TLVs now, which can be reduced to one. It 
seems there is not much confusing. I think that it should be moved forward too.
For the terms such as pseudo nodes, they can be easily changed if they are not 
good.

Thanks,
Chris.
[As WG member]

>
> Differences between IS-IS TTZ and IS-IS Area Proxy are similar to
> the above 1). 2). 3). and 5) between OSPF TTZ and OSPF Area Proxy.
>
> Best Regards,
> Huaimo
> From: Acee Lindem (acee) 
> Sent: Tuesday, July 7, 2020 3:41 PM
> To: Huaimo Chen ; Christian Hopps 
> 
> Cc: lsr@ietf.

Re: [Lsr] Request WG adoption of TTZ

[Huaimo Chen]

Hi Tony and Chris,

Thank you very much for your comments.

Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.
This strikes me as the important difference from area proxy. It certainly adds 
complexity to things, I wonder if it's worth it?
It is worth it because it reduces service interruption and improves 
customer experiences.

When users plan to do these operations on a network, they will select a 
maintenance window. During this window, there should be minimum service traffic 
being transported in the network. However, there is still some live traffic in 
the network even during this window in general. If we do not provide smooth 
transferring between a zone/area and its single pseudo node, some live traffic 
will be lost even during this window while doing the transferring.

There are some challenges for providing smooth transferring between a zone 
and its single pseudo node. I believe that we will be able to have a good 
enough solution. We have had a prototype implementation of smooth transferring 
a zone to the zone edges' full mess in OSPF. The testing shows that a zone 
(block of an OSPF area) is smoothly transferred to its edges’ full mess without 
any routing disruptions.  In addition, we have spent lots of time and efforts 
on smooth transferring between a zone and its single pseudo node. Moreover, we 
may get suggestions from the experts in IETF, especially in LSR WG.

Best Regards,
Huaimo


From: Tony Li  on behalf of tony...@tony.li 

Sent: Tuesday, July 7, 2020 3:08 PM
To: Christian Hopps 
Cc: Huaimo Chen ; lsr@ietf.org ; 
lsr-cha...@ietf.org 
Subject: Re: [Lsr] Request WG adoption of TTZ

Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.

This strikes me as the important difference from area proxy. It certainly adds 
complexity to things, I wonder if it's worth it?


FWIW, we looked at this quite seriously a while ago. Turning abstraction on and 
off is simply not a daily occurrence. Doing it properly requires careful 
thought and planning.
Where are the boundaries? What prefixes will be advertised and with what 
metrics? How will the affect traffic flow?

The corner cases that happen when you are in this transition are large. We have 
to deal with the issue of the metrics that are abstracted away.  We chose to go 
down the path
of intra-area vs. inter-area metrics, exactly as OSPF does. But if you do this, 
then you have an issue: the metrics are different when abstraction is enabled 
or disabled and
different nodes will compute different paths depending on which LSPs have 
propagated to them. This seemed like a wonderful opportunity for forwarding 
loops. This
is especially problematic when abstraction is enabled, as there is now an 
entire area’s worth of LSPs that need to age out before you can be assured of 
consistency.
Yes, you can try to purge them, but purges aren’t the most reliable thing in 
the world.

Net net, we felt that the complexity exceeded the benefit. Yes, there is 
benefit there, but from the pragmatic viewpoint of making it work in 
production, the risks and costs seemed very high.
We expect that operators would want to make the change in a maintenance window 
anyway, and as long as you’re having a maintenance window, you might as well do 
things the
simpler way.

Regards,
Tony

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

Re: [Lsr] Request WG adoption of TTZ

[Christian Hopps]

> On Jul 7, 2020, at 8:42 PM, Huaimo Chen  wrote:
> 
> Hi Acee and Chris,
> 
> Thank you very much for your comments.
> 
> > I agree with Chris – when the IS-IS TTZ draft adopted the approach of 
> > having the area/zone leader originate a single LSP abstracting the 
> > zone/area last Oct, the main differentiation between the two approaches is 
> > the zone/area terminology. The other substantive difference is the fact 
> > that the Area Proxy draft includes a much more comprehensive specification 
> > of the protocol mechanisms required for area/zone abstraction. I have no 
> > doubt that the Area Proxy details could also be amended from area proxy to 
> > TTZ, but that is exactly Chris’s point with which I agree – there 
> > essentially isn’t a difference.
> 
> Thanks,
> Acee
> 
> There are really some differences between TTZ and Area Proxy, which are 
> listed below for OSPF and IS-IS:
> Differences between OSPF TTZ and OSPF Area Proxy (note: assume that OSPF 
> Area Proxy is similar to IS-IS Area Proxy even though OSPF Area Proxy is not 
> defined in the Area Proxy draft) include:
> 1).  It seems that OSPF Area Proxy can not be amended to OSPF TTZ. OSPF 
> TTZ abstracts a zone to a single pseudo node. This abstraction is supported 
> by the extensions to OSPF, and some of these extensions are not defined in 
> OSPF Area Proxy. For example, the extensions for the edge nodes of the zone 
> are not defined in OSPF Area Proxy.
> 2).  OSPF Area Proxy abstracts an existing OSPF area to a single pseudo 
> node.  OSPF TTZ abstracts a zone to a single pseudo node. A zone is a piece 
> or block of an OSPF area. An OSPF area is different from a zone in general.
> 3). The ways in which they are applied to an OSPF area for scalability 
> are different. When an OSPF area becomes bigger and bigger, we may have 
> scalability issues. Using OSPF TTZ, we can abstract one or a few zones in the 
> OSPF area to one or few pseudo nodes smoothly without any interface down. 
> Using OSPF Area Proxy, we need split the existing OSPF area into multiple 
> OSPF areas, and then abstract one or a few OSPF areas to one or few pseudo 
> nodes. Some people may like the one step operation in OSPF TTZ. Others may 
> like the two step operations in OSPF Area Proxy.
> 4). The user experiences are different. For splitting an existing OSPF 
> area into multiple OSPF areas, users may need put more efforts since it 
> causes service interruptions in general. While splitting an OSPF area into 
> multiple OSPF areas, the area numbers configured on some interfaces will be 
> changed and each of these interfaces will be down with its old area number 
> and then up with its new area number.. These interface downs and ups will 
> cause service interruptions in general.. For defining zones in an OSPF area, 
> users may need less efforts since abstracting a zone to a single pseudo node 
> is smooth without any interface down.
> 5). OSPF TTZ provides smooth transferring between a zone and its single 
> pseudo node. That is that a zone can be smoothly transferred to a single 
> pseudo node, and the pseudo node can be smoothly rolled back to the zone..

I think the fact that the above is mixing terms (e.g., OSPF Area Proxy, which 
doesn't exist, and OSPF doesn't have pseudo-nodes) is really highlighting the 
fact that, as Acee pointed out, perhaps its not a good idea to be trying to 
update/modify OSPF TTZ (RFC8099), and at the same time introduce something new 
to IS-IS. It's very confusing right now to have these things all mixed together 
like this.

Thanks,
Chris.
[As WG member]

> 
> Differences between IS-IS TTZ and IS-IS Area Proxy are similar to
> the above 1). 2). 3). and 5) between OSPF TTZ and OSPF Area Proxy.
> 
> Best Regards,
> Huaimo
> From: Acee Lindem (acee) 
> Sent: Tuesday, July 7, 2020 3:41 PM
> To: Huaimo Chen ; Christian Hopps 
> 
> Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> Speaking as WG member:
> 
> I agree with Chris – when the IS-IS TTZ draft adopted the approach of having 
> the area/zone leader originate a single LSP abstracting the zone/area last 
> Oct, the main differentiation between the two approaches is the zone/area 
> terminology. The other substantive difference is the fact that the Area Proxy 
> draft includes a much more comprehensive specification of the protocol 
> mechanisms required for area/zone abstraction. I have no doubt that the Area 
> Proxy details could also be amended from area proxy to TTZ, but that is 
> exactly Chris’s point with which I agree – there essentially isn’t a 
> difference.
> 
> Thanks,
> Acee
> From: Lsr  on behalf of Huaimo Chen 

Re: [Lsr] Request WG adoption of TTZ

[Tony Li]

Hi Huaimo,

> Differences between OSPF TTZ and OSPF Area Proxy (note: assume that OSPF 
> Area Proxy is similar to IS-IS Area Proxy even though OSPF Area Proxy is not 
> defined in the Area Proxy draft) include:


That’s an unfortunate assumption.  We have not defined OSPF Area Proxy because 
it’s frankly well outside of our expertise.

The hierarchical structures of OSPF and IS-IS are intrinsically different.  
While legacy IS-IS allows L2 traffic to transit an L1L2 area, my understanding 
is that when OSPF traffic leaves Area 0, it won’t be coming 
back.  While I don’t particularly like this aspect of the OSPF architecture, 
it’s NOT what we were out to fix.  

So, please don’t assume anything about OSPF Area Proxy.  

Tony

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

Re: [Lsr] Request WG adoption of TTZ

[Les Ginsberg (ginsberg)]

Huaimo -

Sorry for ascribing area merging properties to zones. As the base protocol 
mechanism in IS-IS can be used both to split and merge areas I was thinking 
zones could be used the same way, but I see on closer reading that you have 
restricted a zone to be a subset of an area (which could also be the area 
itself).

I think this does not detract from the main point I am trying to make - which 
is that unless there is reason to believe that operators would prefer to use 
zones rather than split an area (when necessary), this does not serve as a 
significant differentiator between TTZ and area-proxy.
I think you need a more compelling differentiator to justify proceeding with 
both drafts.

In this regard I am agreeing with the points made by other folks (notably Chris 
and Tony), that the introduction of zones may well be adding unneeded 
complexity.

Just my opinion of course...

   Les


From: Huaimo Chen 
Sent: Tuesday, July 07, 2020 12:42 PM
To: Les Ginsberg (ginsberg) ; Christian Hopps 

Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Les,

> I think what you are highlighting is that w TTZ an operator could apply the 
> solution to a subset of an area (which you call a zone) - or to a set of 
> areas (which you also call a zone). This presumes that it is expected that a 
> customer would want to operate in a mode where the interconnections do not 
> follow area boundaries. It isn't clear to me that this is a compelling 
> requirement. If there are operators who feel otherwise I would appreciate 
> them speaking up and educating us on the requirements.

How do you get that TTZ could be used to a set of areas (which you also call a 
zone)?
A zone is a piece or block of an area.  In an area, we can define one or more 
zones. All these zones are within this area. For a set of areas, we can define 
one or more zones in each of these areas. But we can not define a zone crossing 
multiple areas.

Best Regards,
Huaimo

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Tuesday, July 7, 2020 3:29 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org> 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] Request WG adoption of TTZ


Huaimo -



I think what you are highlighting is that w TTZ an operator could apply the 
solution to a subset of an area (which you call a zone) - or to a set of areas 
(which you also call a zone). This presumes that it is expected that a customer 
would want to operate in a mode where the interconnections do not follow area 
boundaries. It isn't clear to me that this is a compelling requirement. If 
there are operators who feel otherwise I would appreciate them speaking up and 
educating us on the requirements.



Absent that, it seems if you want to differentiate TTZ from Area-Proxy you 
should be focusing on things other than the flexibility of zones over areas..



   Les





From: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Sent: Tuesday, July 07, 2020 11:13 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; 
Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Les,



Thank you very much for your comments.



There are still some differences between Area Proxy and TTZ regarding to 
IS-IS with smooth area splitting and merging.



At first, the operations/configurations are different.

Using Area Proxy, two steps are needed. One step is to split an IS-IS area 
to multiple areas through some configurations. The other step is to abstract an 
existing IS-IS area to a single pseudo node through another set of 
configurations.

Using TTZ, only one step is needed, which is to abstract a zone to a single 
pseudo node.

From operations' point of view, TTZ seems simpler.



Secondly, TTZ provides smooth transferring between a zone and its single 
pseudo node. That is that a zone can be smoothly transferred to a single pseudo 
node, and the pseudo node can be smoothly rolled back to the zone.

Smooth IS-IS area splitting and merging can not be used for abstracting an 
existing IS-IS area to a single pseudo node in Area Proxy.



Best Regards,

Huaimo



From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Tuesday, July 7, 2020 12:52 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org> 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] Request WG adoption of

Re: [Lsr] Request WG adoption of TTZ

[Huaimo Chen]

Hi Acee and Chris,

Thank you very much for your comments.


> I agree with Chris – when the IS-IS TTZ draft adopted the approach of having 
> the area/zone leader originate a single LSP abstracting the zone/area last 
> Oct, the main differentiation between the two approaches is the zone/area 
> terminology. The other substantive difference is the fact that the Area Proxy 
> draft includes a much more comprehensive specification of the protocol 
> mechanisms required for area/zone abstraction. I have no doubt that the Area 
> Proxy details could also be amended from area proxy to TTZ, but that is 
> exactly Chris’s point with which I agree – there essentially isn’t a 
> difference.



Thanks,

Acee


There are really some differences between TTZ and Area Proxy, which are 
listed below for OSPF and IS-IS:
Differences between OSPF TTZ and OSPF Area Proxy (note: assume that OSPF 
Area Proxy is similar to IS-IS Area Proxy even though OSPF Area Proxy is not 
defined in the Area Proxy draft) include:
1).  It seems that OSPF Area Proxy can not be amended to OSPF TTZ. OSPF TTZ 
abstracts a zone to a single pseudo node. This abstraction is supported by the 
extensions to OSPF, and some of these extensions are not defined in OSPF Area 
Proxy. For example, the extensions for the edge nodes of the zone are not 
defined in OSPF Area Proxy.
2).  OSPF Area Proxy abstracts an existing OSPF area to a single pseudo 
node.  OSPF TTZ abstracts a zone to a single pseudo node. A zone is a piece or 
block of an OSPF area. An OSPF area is different from a zone in general.
3). The ways in which they are applied to an OSPF area for scalability are 
different. When an OSPF area becomes bigger and bigger, we may have scalability 
issues. Using OSPF TTZ, we can abstract one or a few zones in the OSPF area to 
one or few pseudo nodes smoothly without any interface down. Using OSPF Area 
Proxy, we need split the existing OSPF area into multiple OSPF areas, and then 
abstract one or a few OSPF areas to one or few pseudo nodes. Some people may 
like the one step operation in OSPF TTZ. Others may like the two step 
operations in OSPF Area Proxy.
4). The user experiences are different. For splitting an existing OSPF area 
into multiple OSPF areas, users may need put more efforts since it causes 
service interruptions in general. While splitting an OSPF area into multiple 
OSPF areas, the area numbers configured on some interfaces will be changed and 
each of these interfaces will be down with its old area number and then up with 
its new area number. These interface downs and ups will cause service 
interruptions in general. For defining zones in an OSPF area, users may need 
less efforts since abstracting a zone to a single pseudo node is smooth without 
any interface down.
5). OSPF TTZ provides smooth transferring between a zone and its single 
pseudo node. That is that a zone can be smoothly transferred to a single pseudo 
node, and the pseudo node can be smoothly rolled back to the zone.

Differences between IS-IS TTZ and IS-IS Area Proxy are similar to
the above 1). 2). 3). and 5) between OSPF TTZ and OSPF Area Proxy.

Best Regards,
Huaimo

From: Acee Lindem (acee) 
Sent: Tuesday, July 7, 2020 3:41 PM
To: Huaimo Chen ; Christian Hopps 

Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
Subject: Re: [Lsr] Request WG adoption of TTZ


Speaking as WG member:



I agree with Chris – when the IS-IS TTZ draft adopted the approach of having 
the area/zone leader originate a single LSP abstracting the zone/area last Oct, 
the main differentiation between the two approaches is the zone/area 
terminology. The other substantive difference is the fact that the Area Proxy 
draft includes a much more comprehensive specification of the protocol 
mechanisms required for area/zone abstraction. I have no doubt that the Area 
Proxy details could also be amended from area proxy to TTZ, but that is exactly 
Chris’s point with which I agree – there essentially isn’t a difference.



Thanks,
Acee

From: Lsr  on behalf of Huaimo Chen 

Date: Tuesday, July 7, 2020 at 12:01 PM
To: Christian Hopps 
Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" 
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Chris,



Thank you very much for your questions.

My answers/explanations are inline below with prefix [HC].



Best Regards,

Huaimo



From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?



[HC]: There are some differences even though they looks similar.

At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.

Area Proxy abstracts an existing area to a single pseudo

Re: [Lsr] Request WG adoption of TTZ

[Acee Lindem (acee)]

Speaking as WG member:

Hi Huaimo,

Independent of the major issue with Area Proxy differentiation, I have a couple 
other issues that I didn’t want to include in the same Email thread.


  1.  You can’t describe IS-IS protocol details and then just include OSPF 
encodings and expect the readers to intuit the OSPF specific details. These 
area abstraction drafts modify basic protocol mechanisms and OSPF details would 
be better specified in an update to RFC 8099 then just adding encodings to this 
IS-IS TTZ draft.
  2.  The draft uses the term IS-IS Pseudo-node yet this is defined in IS-IS as 
a specific LSP to represent a multi-access network. I don’t know if the usage 
of the terminology was meant to differentiate the mechanisms from Area Proxy 
but I find the repurposing of the term pseudo-node in the context of IS-IS very 
confusing.
  3.  The document keeps referring to  “edges full mess” and I believe you mean 
“edges full mesh”.


Thanks,
Acee

From: Lsr  on behalf of Huaimo Chen 

Date: Tuesday, July 7, 2020 at 12:01 PM
To: Christian Hopps 
Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" 
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Chris,

Thank you very much for your questions.
My answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo

From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?

[HC]: There are some differences even though they looks similar.
At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.
Area Proxy abstracts an existing area to a single pseudo node.
TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.
An area is different from a zone in general.

Secondly, the ways in which they are applied to an area for scalability are 
different.
When an area becomes bigger and bigger, we may have scalability issues. Using 
TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes 
smoothly without any interface down. Using Area Proxy, we need split the 
existing area into multiple areas, and then abstract one or a few areas to one 
or few pseudo nodes.
These differences will produce different user experiences.
For splitting an existing area into multiple areas, users may need put more 
efforts since it causes service interruptions in general. While splitting an 
area such as an OSPF area into multiple areas, the area numbers configured on 
some interfaces will be changed and each of these interfaces will be down with 
its old area number and then up with its new area number. These interface downs 
and ups will cause service interruptions in general.
For defining zones in an area, users may need less efforts since abstracting a 
zone to a single pseudo node is smooth without any interface down.

Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.

BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to a 
single pseudo node.
In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo node, 
and a zone in an IS-IS area to a single pseudo node.


There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i 
found it confusing to have this document also talking about TTZ for OSPF; is it 
redefining it, updating it, just referring to it?

[HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for 
abstracting a zone to the zone edges full mess. This document proposes a new 
solution for abstracting a zone to a single pseudo node. The new solution 
re-uses some of RFC 8099, to which are referred. The new extensions to OSPF for 
the new solution are defined in the document.

Thanks,
Chris.
[chair hat]


> On 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 bec

Re: [Lsr] Request WG adoption of TTZ

[Huaimo Chen]

Hi Les,

> I think what you are highlighting is that w TTZ an operator could apply the 
> solution to a subset of an area (which you call a zone) – or to a set of 
> areas (which you also call a zone). This presumes that it is expected that a 
> customer would want to operate in a mode where the interconnections do not 
> follow area boundaries. It isn’t clear to me that this is a compelling 
> requirement. If there are operators who feel otherwise I would appreciate 
> them speaking up and educating us on the requirements.

How do you get that TTZ could be used to a set of areas (which you also call a 
zone)?
A zone is a piece or block of an area.  In an area, we can define one or more 
zones. All these zones are within this area. For a set of areas, we can define 
one or more zones in each of these areas. But we can not define a zone crossing 
multiple areas.

Best Regards,
Huaimo

From: Les Ginsberg (ginsberg) 
Sent: Tuesday, July 7, 2020 3:29 PM
To: Huaimo Chen ; Christian Hopps 

Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
Subject: RE: [Lsr] Request WG adoption of TTZ


Huaimo –



I think what you are highlighting is that w TTZ an operator could apply the 
solution to a subset of an area (which you call a zone) – or to a set of areas 
(which you also call a zone). This presumes that it is expected that a customer 
would want to operate in a mode where the interconnections do not follow area 
boundaries. It isn’t clear to me that this is a compelling requirement. If 
there are operators who feel otherwise I would appreciate them speaking up and 
educating us on the requirements.



Absent that, it seems if you want to differentiate TTZ from Area-Proxy you 
should be focusing on things other than the flexibility of zones over areas..



   Les





From: Huaimo Chen 
Sent: Tuesday, July 07, 2020 11:13 AM
To: Les Ginsberg (ginsberg) ; Christian Hopps 

Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Les,



Thank you very much for your comments.



There are still some differences between Area Proxy and TTZ regarding to 
IS-IS with smooth area splitting and merging.



At first, the operations/configurations are different.

Using Area Proxy, two steps are needed. One step is to split an IS-IS area 
to multiple areas through some configurations. The other step is to abstract an 
existing IS-IS area to a single pseudo node through another set of 
configurations.

Using TTZ, only one step is needed, which is to abstract a zone to a single 
pseudo node.

From operations' point of view, TTZ seems simpler.



Secondly, TTZ provides smooth transferring between a zone and its single 
pseudo node. That is that a zone can be smoothly transferred to a single pseudo 
node, and the pseudo node can be smoothly rolled back to the zone.

Smooth IS-IS area splitting and merging can not be used for abstracting an 
existing IS-IS area to a single pseudo node in Area Proxy.



Best Regards,

Huaimo



From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Tuesday, July 7, 2020 12:52 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org> 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] Request WG adoption of TTZ



Huaimo –



In regards to merging/splitting areas, IS-IS base protocol provides a way to do 
this hitlessly (this was discussed some years ago when IS-IS TTZ draft was 
first introduced).

So if the major difference/advantage between area-proxy and ttz is the ability 
to use zones to handle area merging/splitting this does not add much value in 
IS-IS.



Please consider this in your responses.



Thanx.



Les





From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Huaimo Chen
Sent: Tuesday, July 07, 2020 9:00 AM
To: Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Chris,



Thank you very much for your questions.

My answers/explanations are inline below with prefix [HC].



Best Regards,

Huaimo



From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?



[HC]: There are some differences even though they looks similar.

At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.

Area Proxy abstracts an existing area to a single pseudo no

Re: [Lsr] Request WG adoption of TTZ

[Acee Lindem (acee)]

Speaking as WG member:

I agree with Chris – when the IS-IS TTZ draft adopted the approach of having 
the area/zone leader originate a single LSP abstracting the zone/area last Oct, 
the main differentiation between the two approaches is the zone/area 
terminology. The other substantive difference is the fact that the Area Proxy 
draft includes a much more comprehensive specification of the protocol 
mechanisms required for area/zone abstraction. I have no doubt that the Area 
Proxy details could also be amended from area proxy to TTZ, but that is exactly 
Chris’s point with which I agree – there essentially isn’t a difference.

Thanks,
Acee
From: Lsr  on behalf of Huaimo Chen 

Date: Tuesday, July 7, 2020 at 12:01 PM
To: Christian Hopps 
Cc: "lsr@ietf.org" , "lsr-cha...@ietf.org" 
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Chris,

Thank you very much for your questions.
My answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo

From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?

[HC]: There are some differences even though they looks similar.
At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.
Area Proxy abstracts an existing area to a single pseudo node.
TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.
An area is different from a zone in general.

Secondly, the ways in which they are applied to an area for scalability are 
different.
When an area becomes bigger and bigger, we may have scalability issues. Using 
TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes 
smoothly without any interface down. Using Area Proxy, we need split the 
existing area into multiple areas, and then abstract one or a few areas to one 
or few pseudo nodes.
These differences will produce different user experiences.
For splitting an existing area into multiple areas, users may need put more 
efforts since it causes service interruptions in general. While splitting an 
area such as an OSPF area into multiple areas, the area numbers configured on 
some interfaces will be changed and each of these interfaces will be down with 
its old area number and then up with its new area number. These interface downs 
and ups will cause service interruptions in general.
For defining zones in an area, users may need less efforts since abstracting a 
zone to a single pseudo node is smooth without any interface down.

Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.

BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to a 
single pseudo node.
In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo node, 
and a zone in an IS-IS area to a single pseudo node.


There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i 
found it confusing to have this document also talking about TTZ for OSPF; is it 
redefining it, updating it, just referring to it?

[HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for 
abstracting a zone to the zone edges full mess. This document proposes a new 
solution for abstracting a zone to a single pseudo node. The new solution 
re-uses some of RFC 8099, to which are referred. The new extensions to OSPF for 
the new solution are defined in the document.

Thanks,
Chris.
[chair hat]


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

Re: [Lsr] Request WG adoption of TTZ

[Les Ginsberg (ginsberg)]

Huaimo -

I think what you are highlighting is that w TTZ an operator could apply the 
solution to a subset of an area (which you call a zone) - or to a set of areas 
(which you also call a zone). This presumes that it is expected that a customer 
would want to operate in a mode where the interconnections do not follow area 
boundaries. It isn't clear to me that this is a compelling requirement. If 
there are operators who feel otherwise I would appreciate them speaking up and 
educating us on the requirements.

Absent that, it seems if you want to differentiate TTZ from Area-Proxy you 
should be focusing on things other than the flexibility of zones over areas..

   Les


From: Huaimo Chen 
Sent: Tuesday, July 07, 2020 11:13 AM
To: Les Ginsberg (ginsberg) ; Christian Hopps 

Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Les,

Thank you very much for your comments.

There are still some differences between Area Proxy and TTZ regarding to 
IS-IS with smooth area splitting and merging.

At first, the operations/configurations are different.
Using Area Proxy, two steps are needed. One step is to split an IS-IS area 
to multiple areas through some configurations. The other step is to abstract an 
existing IS-IS area to a single pseudo node through another set of 
configurations.
Using TTZ, only one step is needed, which is to abstract a zone to a single 
pseudo node.
From operations' point of view, TTZ seems simpler.

Secondly, TTZ provides smooth transferring between a zone and its single 
pseudo node. That is that a zone can be smoothly transferred to a single pseudo 
node, and the pseudo node can be smoothly rolled back to the zone.
Smooth IS-IS area splitting and merging can not be used for abstracting an 
existing IS-IS area to a single pseudo node in Area Proxy.

Best Regards,
Huaimo

From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Tuesday, July 7, 2020 12:52 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org> 
mailto:lsr-cha...@ietf.org>>
Subject: RE: [Lsr] Request WG adoption of TTZ


Huaimo -



In regards to merging/splitting areas, IS-IS base protocol provides a way to do 
this hitlessly (this was discussed some years ago when IS-IS TTZ draft was 
first introduced).

So if the major difference/advantage between area-proxy and ttz is the ability 
to use zones to handle area merging/splitting this does not add much value in 
IS-IS.



Please consider this in your responses.



Thanx.



Les





From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Huaimo Chen
Sent: Tuesday, July 07, 2020 9:00 AM
To: Christian Hopps mailto:cho...@chopps.org>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Chris,



Thank you very much for your questions.

My answers/explanations are inline below with prefix [HC].



Best Regards,

Huaimo



From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?



[HC]: There are some differences even though they looks similar.

At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.

Area Proxy abstracts an existing area to a single pseudo node.

TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.

An area is different from a zone in general.



Secondly, the ways in which they are applied to an area for scalability are 
different.

When an area becomes bigger and bigger, we may have scalability issues. Using 
TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes 
smoothly without any interface down. Using Area Proxy, we need split the 
existing area into multiple areas, and then abstract one or a few areas to one 
or few pseudo nodes.

These differences will produce different user experiences.

For splitting an existing area into multiple areas, users may need put more 
efforts since it causes service interruptions in general. While splitting an 
area such as an OSPF area into multiple areas, the area numbers configured on 
some interfaces will be changed and each of these interfaces will be down with 
its old area number and then up with its new area number. These interface downs 
and ups will cause service interruptions in general.

For defining zones in an area, users may need less efforts since abstracting a 
zone to a single pseu

Re: [Lsr] Request WG adoption of TTZ

[tony . li]

>> Moreover, TTZ provides smooth transferring between a zone and its single 
>> pseudo node. That is that a zone can be smoothly transferred to a single 
>> pseudo node, and the pseudo node can be smoothly rolled back to the zone.
> 
> This strikes me as the important difference from area proxy. It certainly 
> adds complexity to things, I wonder if it's worth it?


FWIW, we looked at this quite seriously a while ago. Turning abstraction on and 
off is simply not a daily occurrence. Doing it properly requires careful 
thought and planning. 
Where are the boundaries? What prefixes will be advertised and with what 
metrics? How will the affect traffic flow?

The corner cases that happen when you are in this transition are large. We have 
to deal with the issue of the metrics that are abstracted away.  We chose to go 
down the path
of intra-area vs. inter-area metrics, exactly as OSPF does. But if you do this, 
then you have an issue: the metrics are different when abstraction is enabled 
or disabled and 
different nodes will compute different paths depending on which LSPs have 
propagated to them. This seemed like a wonderful opportunity for forwarding 
loops. This
is especially problematic when abstraction is enabled, as there is now an 
entire area’s worth of LSPs that need to age out before you can be assured of 
consistency.
Yes, you can try to purge them, but purges aren’t the most reliable thing in 
the world.  

Net net, we felt that the complexity exceeded the benefit. Yes, there is 
benefit there, but from the pragmatic viewpoint of making it work in 
production, the risks and costs seemed very high. 
We expect that operators would want to make the change in a maintenance window 
anyway, and as long as you’re having a maintenance window, you might as well do 
things the
simpler way.

Regards,
Tony

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

Re: [Lsr] Request WG adoption of TTZ

[Christian Hopps]

> On Jul 7, 2020, at 12:00 PM, Huaimo Chen  wrote:
> 
> Hi Chris,
> 
> Thank you very much for your questions.
> My answers/explanations are inline below with prefix [HC].
> 
> Best Regards,
> Huaimo
> From: Christian Hopps
> Sent: Tuesday, July 7, 2020 8:08 AM
> To: Huaimo Chen
> Cc: Christian Hopps; lsr@ietf.org; lsr-cha...@ietf.org
> Subject: Re: [Lsr] Request WG adoption of TTZ
> 
> Hi Huaimo,
> 
> Can you speak to the differences of this with Area Proxy? They are similar 
> solutions, right?
> 
> [HC]: There are some differences even though they looks similar.
> At first, the target to be abstracted in Area Proxy is different from that in 
> TTZ.
> Area Proxy abstracts an existing area to a single pseudo node.
> TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of 
> an area.
> An area is different from a zone in general.

[As wg member]

If the operator needed a subset of an area abstracted they could split the area 
and then use area proxy on the subset though, right? Restricting things to 
exactly the area boundary as area proxy does seems like an elegant KISS 
approach; it has the advantage of harnessing all the existing tools and 
institutional knowledge on how IS-IS areas work. This in turn simplifies 
management and debugability I think. While TTZ adds some extra flexibility 
(cuts out the area split step) I don't know that the added complexity makes 
sense since splitting an area is basically the same operation as configuring a 
zone would be.

> Secondly, the ways in which they are applied to an area for scalability are 
> different.
> When an area becomes bigger and bigger, we may have scalability issues. Using 
> TTZ, we can abstract one or a few zones in the area to one or few pseudo 
> nodes smoothly without any interface down. Using Area Proxy, we need split 
> the existing area into multiple areas, and then abstract one or a few areas 
> to one or few pseudo nodes.
> These differences will produce different user experiences.
> For splitting an existing area into multiple areas, users may need put more 
> efforts since it causes service interruptions in general. While splitting an 
> area such as an OSPF area into multiple areas, the area numbers configured on 
> some interfaces will be changed and each of these interfaces will be down 
> with its old area number and then up with its new area number. These 
> interface downs and ups will cause service interruptions in general.
> For defining zones in an area, users may need less efforts since abstracting 
> a zone to a single pseudo node is smooth without any interface down.
> 
> Moreover, TTZ provides smooth transferring between a zone and its single 
> pseudo node. That is that a zone can be smoothly transferred to a single 
> pseudo node, and the pseudo node can be smoothly rolled back to the zone.

This strikes me as the important difference from area proxy. It certainly adds 
complexity to things, I wonder if it's worth it?

Thanks,
Chris.
[As WG member]

> 
> BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to 
> a single pseudo node.
> In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo 
> node, and a zone in an IS-IS area to a single pseudo node.
> 
> 
> There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so 
> i found it confusing to have this document also talking about TTZ for OSPF; 
> is it redefining it, updating it, just referring to it?
> 
> [HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for 
> abstracting a zone to the zone edges full mess. This document proposes a new 
> solution for abstracting a zone to a single pseudo node. The new solution 
> re-uses some of RFC 8099, to which are referred. The new extensions to OSPF 
> for the new solution are defined in the document.
> 
> Thanks,
> Chris.
> [chair hat]
> 
> 
> > On 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 (I

Re: [Lsr] Request WG adoption of TTZ

[Huaimo Chen]

Hi Les,

Thank you very much for your comments.

There are still some differences between Area Proxy and TTZ regarding to 
IS-IS with smooth area splitting and merging.

At first, the operations/configurations are different.
Using Area Proxy, two steps are needed. One step is to split an IS-IS area 
to multiple areas through some configurations. The other step is to abstract an 
existing IS-IS area to a single pseudo node through another set of 
configurations.
Using TTZ, only one step is needed, which is to abstract a zone to a single 
pseudo node.
From operations' point of view, TTZ seems simpler.

Secondly, TTZ provides smooth transferring between a zone and its single 
pseudo node. That is that a zone can be smoothly transferred to a single pseudo 
node, and the pseudo node can be smoothly rolled back to the zone.
Smooth IS-IS area splitting and merging can not be used for abstracting an 
existing IS-IS area to a single pseudo node in Area Proxy.

Best Regards,
Huaimo

From: Les Ginsberg (ginsberg) 
Sent: Tuesday, July 7, 2020 12:52 PM
To: Huaimo Chen ; Christian Hopps 

Cc: lsr@ietf.org ; lsr-cha...@ietf.org 
Subject: RE: [Lsr] Request WG adoption of TTZ


Huaimo –



In regards to merging/splitting areas, IS-IS base protocol provides a way to do 
this hitlessly (this was discussed some years ago when IS-IS TTZ draft was 
first introduced).

So if the major difference/advantage between area-proxy and ttz is the ability 
to use zones to handle area merging/splitting this does not add much value in 
IS-IS.



Please consider this in your responses.



Thanx.



Les





From: Lsr  On Behalf Of Huaimo Chen
Sent: Tuesday, July 07, 2020 9:00 AM
To: Christian Hopps 
Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Chris,



Thank you very much for your questions.

My answers/explanations are inline below with prefix [HC].



Best Regards,

Huaimo



From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: [Lsr] Request WG adoption of TTZ



Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?



[HC]: There are some differences even though they looks similar.

At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.

Area Proxy abstracts an existing area to a single pseudo node.

TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.

An area is different from a zone in general.



Secondly, the ways in which they are applied to an area for scalability are 
different.

When an area becomes bigger and bigger, we may have scalability issues. Using 
TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes 
smoothly without any interface down. Using Area Proxy, we need split the 
existing area into multiple areas, and then abstract one or a few areas to one 
or few pseudo nodes.

These differences will produce different user experiences.

For splitting an existing area into multiple areas, users may need put more 
efforts since it causes service interruptions in general. While splitting an 
area such as an OSPF area into multiple areas, the area numbers configured on 
some interfaces will be changed and each of these interfaces will be down with 
its old area number and then up with its new area number. These interface downs 
and ups will cause service interruptions in general.

For defining zones in an area, users may need less efforts since abstracting a 
zone to a single pseudo node is smooth without any interface down.



Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.



BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to a 
single pseudo node.

In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo node, 
and a zone in an IS-IS area to a single pseudo node.



There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i 
found it confusing to have this document also talking about TTZ for OSPF; is it 
redefining it, updating it, just referring to it?



[HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for 
abstracting a zone to the zone edges full mess. This document proposes a new 
solution for abstracting a zone to a single pseudo node. The new solution 
re-uses some of RFC 8099, to which are referred. The new extensions to OSPF for 
the new solution are defined in the document.

Thanks,
Chris.
[chair hat]


> On Jun 18, 2020, at 11:38 PM, Huaimo Chen 
> mailto:huaimo.c...@futurewei.com>> wrote:
>
> H

Re: [Lsr] Request WG adoption of TTZ

[Les Ginsberg (ginsberg)]

Huaimo -

In regards to merging/splitting areas, IS-IS base protocol provides a way to do 
this hitlessly (this was discussed some years ago when IS-IS TTZ draft was 
first introduced).
So if the major difference/advantage between area-proxy and ttz is the ability 
to use zones to handle area merging/splitting this does not add much value in 
IS-IS.

Please consider this in your responses.

Thanx.

Les


From: Lsr  On Behalf Of Huaimo Chen
Sent: Tuesday, July 07, 2020 9:00 AM
To: Christian Hopps 
Cc: lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Chris,

Thank you very much for your questions.
My answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo

From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org<mailto:lsr@ietf.org>; 
lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?

[HC]: There are some differences even though they looks similar.
At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.
Area Proxy abstracts an existing area to a single pseudo node.
TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.
An area is different from a zone in general.

Secondly, the ways in which they are applied to an area for scalability are 
different.
When an area becomes bigger and bigger, we may have scalability issues. Using 
TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes 
smoothly without any interface down. Using Area Proxy, we need split the 
existing area into multiple areas, and then abstract one or a few areas to one 
or few pseudo nodes.
These differences will produce different user experiences.
For splitting an existing area into multiple areas, users may need put more 
efforts since it causes service interruptions in general. While splitting an 
area such as an OSPF area into multiple areas, the area numbers configured on 
some interfaces will be changed and each of these interfaces will be down with 
its old area number and then up with its new area number. These interface downs 
and ups will cause service interruptions in general.
For defining zones in an area, users may need less efforts since abstracting a 
zone to a single pseudo node is smooth without any interface down.

Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.

BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to a 
single pseudo node.
In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo node, 
and a zone in an IS-IS area to a single pseudo node.


There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i 
found it confusing to have this document also talking about TTZ for OSPF; is it 
redefining it, updating it, just referring to it?

[HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for 
abstracting a zone to the zone edges full mess. This document proposes a new 
solution for abstracting a zone to a single pseudo node. The new solution 
re-uses some of RFC 8099, to which are referred. The new extensions to OSPF for 
the new solution are defined in the document.

Thanks,
Chris.
[chair hat]


> On Jun 18, 2020, at 11:38 PM, Huaimo Chen 
> mailto:huaimo.c...@futurewei.com>> 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 
> reconst

Re: [Lsr] Request WG adoption of TTZ

[Huaimo Chen]

Hi Chris,

Thank you very much for your questions.
My answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo

From: Christian Hopps
Sent: Tuesday, July 7, 2020 8:08 AM
To: Huaimo Chen
Cc: Christian Hopps; lsr@ietf.org; lsr-cha...@ietf.org
Subject: Re: [Lsr] Request WG adoption of TTZ

Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?

[HC]: There are some differences even though they looks similar.
At first, the target to be abstracted in Area Proxy is different from that in 
TTZ.
Area Proxy abstracts an existing area to a single pseudo node.
TTZ abstracts a zone to a single pseudo node. A zone is a piece or block of an 
area.
An area is different from a zone in general.

Secondly, the ways in which they are applied to an area for scalability are 
different.
When an area becomes bigger and bigger, we may have scalability issues. Using 
TTZ, we can abstract one or a few zones in the area to one or few pseudo nodes 
smoothly without any interface down. Using Area Proxy, we need split the 
existing area into multiple areas, and then abstract one or a few areas to one 
or few pseudo nodes.
These differences will produce different user experiences.
For splitting an existing area into multiple areas, users may need put more 
efforts since it causes service interruptions in general. While splitting an 
area such as an OSPF area into multiple areas, the area numbers configured on 
some interfaces will be changed and each of these interfaces will be down with 
its old area number and then up with its new area number. These interface downs 
and ups will cause service interruptions in general.
For defining zones in an area, users may need less efforts since abstracting a 
zone to a single pseudo node is smooth without any interface down.

Moreover, TTZ provides smooth transferring between a zone and its single pseudo 
node. That is that a zone can be smoothly transferred to a single pseudo node, 
and the pseudo node can be smoothly rolled back to the zone.

BTW, In the Area Proxy draft, Area Proxy abstracts an existing IS-IS area to a 
single pseudo node.
In the TTZ draft, TTZ abstracts a zone in an OSPF area to a single pseudo node, 
and a zone in an IS-IS area to a single pseudo node.


There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i 
found it confusing to have this document also talking about TTZ for OSPF; is it 
redefining it, updating it, just referring to it?

[HC]: Regarding to TTZ for OSPF, OSPF RFC (RFC8099) describes a solution for 
abstracting a zone to the zone edges full mess. This document proposes a new 
solution for abstracting a zone to a single pseudo node. The new solution 
re-uses some of RFC 8099, to which are referred. The new extensions to OSPF for 
the new solution are defined in the document.

Thanks,
Chris.
[chair hat]


> On 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 tran

Re: [Lsr] Request WG adoption of TTZ

[Christian Hopps]

Hi Huaimo,

Can you speak to the differences of this with Area Proxy? They are similar 
solutions, right?

There's an existing experimental track OSPF RFC (RFC8099) already for TTZ so i 
found it confusing to have this document also talking about TTZ for OSPF; is it 
redefining it, updating it, just referring to it?

Thanks,
Chris.
[chair hat]


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



signature.asc
Description: Message signed with OpenPGP
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr