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
t 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 si
age-
> 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
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 broade
ly 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 pro
ng 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,
: 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
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 wr
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
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]
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
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.
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
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
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
; 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 Irrespec
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
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
e 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
...@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 anot
tian 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 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:
ng 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 adopt
; 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.
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
: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 hampe
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
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
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
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
: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
I support adoption of the IS-IS TTZ draft.
Mehmet
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
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
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,
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
> 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
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 adopti
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
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
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
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
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
...@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 Ac
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
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 – w
...@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
rd 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
(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 Hopp
@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
> &g
...@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
r 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: [
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
...
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
> so
nt: 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 sing
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,
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
– 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 muc
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
>> 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.
20 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
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
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
...@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
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,
64 matches
Mail list logo
