Hi Tony,
Regarding to the issues/problems you mentioned for flooding reduction
(using distributed algorithm), can you give some more details?
Best Regards,
Huaimo
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Tony Przygienda
Sent: Wednesday, August 22, 2018 2:59 PM
To:
I think distributed is more practical too.
For computing routes, we have been using distributed SPF on every node for many
years.
In fact, we may not need to run the exact algorithm on every node. As long as
the algorithms running on different nodes generate the same result, that would
work.
It is better to have some short discussions about the requirements. Some
requirements were presented and discussed in RTGWG. With some new additions and
discussions , we should have a good set of requirements.
Best Regards,
Huaimo
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Naiming
another one (say B), which
one (A or B) will you select?
Best Regards,
Huaimo
From: John E Drake [mailto:jdr...@juniper.net]
Sent: Tuesday, September 4, 2018 12:02 PM
To: Huaimo Chen ; Robert Raszuk
Cc: tony...@tony.li; Acee Lindem (acee) ;
lsr@ietf.org; Jeff Tantsura ; Tony Przygienda
; Peter
IETFs.
BTW, as a service provider, which mode/solution (distributed or centralized)
will you select to use in an operational network?
Best Regards,
Huaimo
>Many thx,
>R.
On Mon, Aug 27, 2018 at 6:41 PM, Huaimo Chen
mailto:huaimo.c...@huawei.com>> wrote:
Hi Robert,
>
Support.
Best Regards,
Huaimo
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, April 17, 2018 11:24 AM
To: lsr@ietf.org
Subject: Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts
Speaking as WG member, I support draft adoption. It was being
e after we resolve the
issues raised by other experts during the last few IETFs.
BTW, as a service provider, which mode/solution (distributed or centralized)
will you select to use in an operational network?
Best Regards,
Huaimo
>Many thx,
>R.
On Mon, Aug 27, 2018 at 6:41 PM, Huai
To: Huaimo Chen ; Yi Yang ; Dean
cheng ; Mehmet Toy
Subject: New Version Notification for draft-cc-ospf-flooding-reduction-04.txt
A new version of I-D, draft-cc-ospf-flooding-reduction-04.txt
has been successfully submitted by Huaimo Chen and posted to the IETF
repository.
Name
improved the quality of our draft, and addressed the
comments from IETF meetings and the mailing list.
Best Regards,
Huaimo
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Wednesday, September 12, 2018 10:48 PM
To: Huaimo Chen ; Yi Yang ; Dean
Hi Tony,
Can you give some details about: what is the rate limiting link addition
and how does it (the rate limiting link addition) fix or help fix the flooding
topology (FT) split when multiple failures occur on FT?
Best Regards,
Huaimo
-Original Message-
From: Lsr
Hi Everyone,
When multiple (i.e., two or more) failures on the current flooding topology (FT
for short) happen at almost the same time, the FT may be split even though the
real network topology is connected. A solution or procedure for fixing the FT
split is described below. It uses almost the
Some issues with draft-li-lsr-dynamic-flooding-02 not fully addressed are
briefed below.
1) There is no concrete procedure/method for fault tolerance to
multiple failures. When multiple failures happen and split the flooding
topology, the convergence time will be increased
Hi Peter,
>-Original Message-
>From: Peter Psenak [mailto:ppse...@cisco.com]
>Sent: Monday, February 18, 2019 10:39 AM
>To: Huaimo Chen ; Acee Lindem (acee) ;
>Christian
>Hopps ; lsr@ietf.org
>Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
&
Hi Peter,
> -Original Message-
> From: Peter Psenak [mailto:ppse...@cisco.com]
> Sent: Sunday, February 24, 2019 1:47 PM
> To: Huaimo Chen ; Christian Hopps
> ; lsr@ietf.org
> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org
> Subject: Re: [Lsr] WG Adoption Call for
Hi Tony,
>From: Tony Li [mailto:tony1ath...@gmail.com]
>Sent: Thursday, February 21, 2019 12:32 AM
>To: Huaimo Chen
>Cc: Peter Psenak ; Acee Lindem (acee) ;
>Christian Hopps >; lsr@ietf.org
>Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
>
&
Hi Tony,
> From: Tony Li [mailto:tony1ath...@gmail.com]
> Sent: Wednesday, February 27, 2019 2:07 AM
> To: Huaimo Chen
> Cc: Peter Psenak ; Christian Hopps ;
> lsr@ietf.org;
> lsr- cha...@ietf.org; lsr-...@ietf.org
> Subject: Re: [Lsr] WG Adoption Call for draft-li-ls
Hi Peter,
>-Original Message-
>From: Peter Psenak [mailto:ppse...@cisco.com]
>Sent: Thursday, February 14, 2019 2:30 AM
>To: Huaimo Chen ; Acee Lindem (acee) ;
>Christian Hopps ; lsr@ietf.org
>Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
>
Hi Peter,
My explanations/answers are in line below with prefix [HC].
-Original Message-
From: Peter Psenak [mailto:ppse...@cisco.com]
Sent: Wednesday, February 6, 2019 4:58 AM
To: Huaimo Chen ; Acee Lindem (acee) ;
Christian Hopps ; lsr@ietf.org
Subject: Re: [Lsr] Moving Forward
Hi Acee,
I agree with you on keeping the signaling for two modes. The other parts
for the distributed solution need to be removed.
Best Regards,
Huaimo
From: Acee Lindem (acee) [mailto:a...@cisco.com]
Sent: Sunday, February 3, 2019 11:45 AM
To: Huaimo Chen ; Christian Hopps ;
lsr@ietf.org
nodes of the failed link on the FT. When the FT is split
because of this failed link and others, this path fixes the FT split.
Best Regards,
Huaimo
From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Sent: Monday, April 1, 2019 12:50 PM
To: Huaimo Chen
Cc: lsr@ietf.org
FT that is partitioned, 2) the leader to compute and send a
new FT, and 3) the other nodes (i.e., non area leader nodes) receive and build
the new FT.
Best Regards,
Huaimo
From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Sent: Saturday, April 13, 2019 1:09 PM
To: Huaimo Chen
Cc: Sa
Hi Dave,
My explanations are inline below with prefix [HC2].
From: David Allan I [mailto:david.i.al...@ericsson.com]
Sent: Sunday, April 14, 2019 2:33 PM
To: Huaimo Chen
Cc: lsr@ietf.org
Subject: RE: [Lsr] Min Links for Multiple Failures on Flooding Topology
Hi Huaimo:
Replies are in line
Hi Dave,
Thank you for your observations.
My explanations are inline below with prefix [HC].
>From: David Allan I [mailto:david.i.al...@ericsson.com]
>Sent: Friday, April 12, 2019 8:57 AM
>To: Huaimo Chen ; tony...@tony.li
>Cc: lsr@ietf.org
>Subject: RE: [Lsr] Min Links for Mu
: Thursday, April 11, 2019 2:29 PM
To: Huaimo Chen
Cc: tony...@tony.li; lsr@ietf.org
Subject: Re: [Lsr] Min Links for Multiple Failures on Flooding Topology
Hi, Huaimo,
Why do we need to compute a whole backup path and enable flooding at each hop?
In your example, when R0-R2 and R3-R9 fail, R0
temporarily.
In section 5.1.5 or section 5.2.7, it seems that there is no details on
negotiations.
Best Regards,
Huaimo
From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Sent: Tuesday, May 14, 2019 4:31 PM
To: Huaimo Chen
Cc: lsr@ietf.org
Subject: Re: Flooding Negotiation bit
Hi Tony,
Two enhancements for the flooding topology encoding using Path TLVs, and
another flooding topology encoding using Block TLVs are described below for
discussions.
In one current encoding, Path TLVs are used to encode the flooding topology. A
Path TLV represents a path on the
= 2996 (bytes)
For N = 1000 and OSPF, the saving is (1000-1)*8 - 1000 = 6992 (bytes)
Best Regards,
Huaimo
From: Tony Li on behalf of tony...@tony.li
Sent: Friday, May 24, 2019 4:56 PM
To: Huaimo Chen
Cc: lsr@ietf.org
Subject: Re: Enhancement related to Area Leader
Hi Peter,
Thank you very much.
After it is included in draft-ietf-lsr-dynamic-flooding, we can work
together to reduce the side effect.
Best Regards,
Huaimo
From: Peter Psenak
Sent: Friday, May 24, 2019 5:35 AM
To: Huaimo Chen; Tony Li; lsr@ietf.org
,
the saving is (1000-1)*8 - 1000 = 6992 (bytes).
When only one node advertises a priority, (N – 1) bytes more is used.
Best Regards,
Huaimo
From: Les Ginsberg (ginsberg)
Sent: Tuesday, May 28, 2019 11:19 AM
To: Huaimo Chen; tony...@tony.li
Cc: lsr@ietf.org
Hi Tony,
A possible enhancement on LSDB re-synchronization is described below for
discussions.
The current method: Whenever an existing link/adjacency L is added to the
flooding topology (FT for short), a full LSDB re-synchronization is requested
and executed over link L. Even though
Leader Sub-TLVs, the space
used for advertising Area Leader Sub-TLVs by these nodes before moving should
be saved.
Best Regards,
Huaimo
From: Tony Li on behalf of tony...@tony.li
Sent: Tuesday, May 28, 2019 11:20 AM
To: Huaimo Chen
Cc: lsr@ietf.org
Subject: Re
Hi Tony,
Thank you for your comments!
My explanations are inline below.
Best Regards,
Huaimo
From: Tony Li on behalf of tony...@tony.li
Sent: Wednesday, May 29, 2019 11:20 AM
To: Huaimo Chen
Cc: lsr@ietf.org
Subject: Re: Enhancements on flooding
Support.
Best Regards,
Huaimo
-Original Message-
From: Lsr On Behalf Of Christian Hopps
Sent: 12 June 2019 17:35
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; Christian Hopps ;
draft-ginsberg-lsr-isis-invalid-...@ietf.org
Subject: [Lsr] WG Adoption Call:
Hi Tony,
For the case you described below, in order to add one or a limited number of
links to the flooding topology temporarily, a new bit, called Flooding
Negotiation bit (FN bit for short), should be defined and used. In OSPF, the FN
bit is defined in Extended Options and Flag (EOF) TLV in
Hi Tony,
Two possible procedures (Procedure A and B) for the migration are listed below
for discussions.
In the beginning, the IGP running in a network area does the normal flooding.
The migration from the normal flooding to the flooding reduction (either
centralized mode or distributed
Hi Les,
Thank you very much for adding the LEEF bit into the draft based on the FT
bit for a link. The bit advertised by one end node of the link indicates
whether the link is on the flooding topology.
Would you mind adding the behavior below for checking and handling the
inconsistency
for
distributed mode, which is used in draft-ietf-lsr-dynamic-flooding.
Best Regards,
Huaimo
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Monday, May 20, 2019 4:39 PM
To: Huaimo Chen ; tony...@tony.li
Cc: lsr@ietf.org
Subject: RE: [Lsr] Migration between normal flooding and flooding reduction
...@tony.li
Sent: Saturday, May 18, 2019 1:17 PM
To: Huaimo Chen
Cc: lsr@ietf.org
Subject: Re: [Lsr] Migration between normal flooding and flooding reduction
Hi Huaimo,
Before we get into your procedure, I have to ask an important question: why is
any process necessary?
In our experience, It Just
allows us to signal which ones should be enabled.
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Friday, May 17, 2019 2:02 PM
To: Huaimo Chen ; tony...@tony.li
Cc: lsr@ietf.org
Subject: RE: Flooding Negotiation bit
Huaimo –
It seems to me from your description that you are trying
Hi Tony,
My explanations are inline below with prefix [HC].
From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Sent: Monday, April 15, 2019 11:37 AM
To: Huaimo Chen
Cc: lsr@ietf.org
Subject: Re: [Lsr] Min Links for Multiple Failures on Flooding Topology
Hi Huaimo
Hi Tony,
Thank you for your description. It helped me to learn more about your “rate
limiting” algorithm.
Best Regards,
Huaimo
From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Sent: Thursday, April 25, 2019 4:08 PM
To: Huaimo Chen
Cc: lsr@ietf.org
Subject: Re: [Lsr
Hi Les,
Thanks much.
I have defined a deterministic solution.
Best Regards,
Huaimo
-Original Message-
From: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com]
Sent: Tuesday, April 9, 2019 11:51 AM
To: Huaimo Chen ; tony...@tony.li; lsr@ietf.org
Subject: RE: [Lsr] Fwd: Open
Hi Les,
For "add temporary flooding in a rate limited manner", can you give some
details about how does the rate limit manner work for fixing a FT split? how
does each node get the rate limit? Will every node add temporary flooding on a
given number of links independently? If so, there are
in enabling flooding on (R3, R6) and on (R5, R2), (R2, R9), (R9, R8).
Per the existing algorithm, the temporary additions would be (R3, R6) and (R2,
R9). As it has less flooding, this seems like a better solution.
Regards,
Tony
On Apr 25, 2019, at 7:26 AM, Huaimo Chen
mailto:huaimo.c
Support and have the following comments:
1. It seems not necessary to have 8 levels of hierarchies. 3 or at most 4
levels of hierarchies should be enough. IS-IS with 3 levels of hierarchies may
support a network with 1k*1k*1k nodes, which is about 10^9 = 1 billion nodes.
IS-IS with 4
Hi Les,
Thank you for your response.
Some of my explanations are inline below with prefix [HC].
Best Regards,
Huaimo
From: Les Ginsberg (ginsberg)
Sent: Tuesday, August 20, 2019 1:20 AM
To: tony...@tony.li; Huaimo Chen
Cc: lsr@ietf.org; Acee Lindem (acee)
Subject: RE: [Lsr] LSR Working Group
Hi Aijun,
My understanding of your draft
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
as follows:
After the ABR originates the Extended Prefix Opaque LSA, which contains a
prefix and its originator (i.e., the router originating the prefix), it will
Support.
Best Regards,
Huaimo
From: Lsr on behalf of Christian Hopps
Date: Thursday, January 23, 2020 at 3:25 PM
To: "lsr@ietf.org"
Cc: "draft-li-lsr-ospfv3-srv6-extensi...@ietf.org"
, "lsr-...@ietf.org"
, Christian Hopps , "Acee Lindem (acee)"
Subject: [Lsr] WG Adoption Call for
Support.
Best Regards,
Huaimo
> On Jan 22, 2020, at 1:14 AM, Christian Hopps wrote:
>
> This begins a 2 week WG Last Call, ending after Feb 4, 2020, for
> draft-ietf-lsr-isis-srv6-extensions
>
>
>
Support.
Best Regards,
Huaimo as co-author
From: Lsr on behalf of Acee Lindem (acee)
Sent: Friday, May 15, 2020 3:39 PM
To: lsr@ietf.org
Subject: [Lsr] Flooding Topology Computation Algorithm -
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
Hi Acee,
Yes. I am aware of IPRs that apply to this draft, which have been disclosed
in compliance with IETF IPR rules.
Best Regards,
Huaimo
From: Acee Lindem (acee)
Sent: Friday, May 15, 2020 3:47 PM
To: draft-cc-lsr-flooding-reduct...@ietf.org
Cc:
Hi Gyan,
Thanks much for your questions. My answers are inline below with [HC].
Best Regards,
Huaimo
From: Gyan Mishra
Sent: Wednesday, May 20, 2020 11:14 AM
To: Huaimo Chen
Cc: Acee Lindem (acee) ; lsr@ietf.org
Subject: Re: [Lsr] Flooding Topology
Hi Gyan,
Thank you very much for your questions and support.
This Flooding Topology Computation algorithm can be used in the Dynamic
Flooding on Dense Graphs to compute the flooding topologies for the data center
clos dense meshed topologies with many ECMP paths. It can be used by the
nce in the draft.
Best Regards,
Huaimo
From: Gyan Mishra
Sent: Thursday, May 21, 2020 1:51 PM
To: Huaimo Chen
Cc: Acee Lindem (acee) ; lsr@ietf.org
Subject: Re: [Lsr] Flooding Topology Computation Algorithm -
draft-cc-lsr-flooding-reduction-08 Working Group Adopt
Hi Robert,
My answers/explanations to your questions/comments are inline below with
prefix [HC2].
Best Regards,
Huaimo
From: Robert Raszuk
Sent: Thursday, September 3, 2020 4:43 AM
To: Huaimo Chen
Cc: tony...@tony.li ; Les Ginsberg (ginsberg)
; Les
egards,
Huaimo
From: Les Ginsberg (ginsberg)
Sent: Tuesday, August 18, 2020 6:52 PM
To: Huaimo Chen ; Les Ginsberg (ginsberg)
; Acee Lindem (acee)
; lsr@ietf.org
Subject: RE: LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" -
draft-chen
Hi Henk,
It seems that IS-IS TTZ should not be complex. The prototype implementation
of OSPF TTZ seems simple and easy to operate. The complexity of IS-IS TTZ is
similar to that of OSPF TTZ. In addition, we will try our best to reduce its
complexity further.
IS-IS TTZ is one of a few
of the two areas. These corresponds
to step 1) and 3) for using Areas.
Best Regards,
Huaimo
From: Tony Li on behalf of tony...@tony.li
Sent: Wednesday, September 2, 2020 12:09 AM
To: Huaimo Chen
Cc: Les Ginsberg ; Les Ginsberg (ginsberg)
; Acee Lindem (acee)
; lsr
; and
4) delete the old area address from the routers in Area A12.
Using TTZ is simpler than using Areas.
Best Regards,
Huaimo
From: Tony Li on behalf of tony...@tony.li
Sent: Tuesday, September 1, 2020 11:01 AM
To: Huaimo Chen
Cc: Les Ginsberg ; Les Ginsberg
11:18 AM
To: Huaimo Chen
Cc: Les Ginsberg (ginsberg) ; Les Ginsberg
(ginsberg) ; lsr@ietf.org ; Acee Lindem
(acee)
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" -
draft-chen-isis-ttz-11.txt
[HC]: IS-IS TTZ or say Zone is one of a few drafts which
raft.
Best Regards,
Huaimo
From: Robert Raszuk
Sent: Wednesday, September 2, 2020 5:03 AM
To: Gengxuesong (Geng Xuesong)
Cc: tony...@tony.li ; Les Ginsberg (ginsberg)
; Les Ginsberg ;
Huaimo Chen ; lsr@ietf.org ; Acee
Lindem (acee)
Subject: Re: [Lsr] LSR WG Adoption Poll for "
ber 2, 2020 11:02 AM
To: Tony Li
Cc: Gengxuesong (Geng Xuesong) ; Les Ginsberg
(ginsberg) ; Les Ginsberg
; Huaimo Chen ; lsr@ietf.org
; Acee Lindem (acee)
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" -
draft-chen-isis-ttz-11.txt
> - The transition mec
h/msg/lsr/NxNJRUulSnGaR5PNBJv5x1kxUTw/
Best Regards,
Huaimo
From: Robert Raszuk
Sent: Wednesday, September 2, 2020 4:53 AM
To: Huaimo Chen
Cc: tony...@tony.li ; Les Ginsberg (ginsberg)
; Les Ginsberg ;
lsr@ietf.org ; Acee Lindem (acee)
Subject: Re: [Lsr] LSR WG Adop
Hi Authors,
I have the following comments/questions:
In a network, can we use other methods to define VTNs while MTs are used as
VTNs?
If so, other methods may be used to define VTNs in addition to using MTs as
VTNs in the same network. The draft says that MT-ID could be used as
Hi Authors,
I have the following comments/questions on the draft.
In section 2 "Advertisement of SR VTN Topology Attribute",
for the last sentence "..., the Flex-Algo identifier could be reused
as the identifier of the VTN in control plane.",
How do you reuse the Flex-Algo
Hi Les,
> I see no need for “abstraction at arbitrary boundaries”. Areas work just fine.
> IS-IS already has smooth transition capability for merging/splitting areas.
[HC]: The smooth transition capability for merging/splitting areas in IS-IS
will not reduce the service interruption while an
ore this abstraction
and will not reduce the service interruption during the abstraction.
Best Regards,
Huaimo
From: Les Ginsberg (ginsberg)
Sent: Tuesday, August 18, 2020 5:59 PM
To: Huaimo Chen ; Les Ginsberg (ginsberg)
; Acee Lindem (acee)
; lsr@ietf.org
Subject: RE: LSR
I am not aware of any IPR for this document other than those disclosed.
Best Regards,
Huaimo
From: Acee Lindem (acee)
Sent: Tuesday, August 18, 2020 10:24 AM
To: draft-chen-isis-...@ietf.org
Cc: lsr@ietf.org
Subject: LSR WG IPR Poll for "IS-IS
Support.
Best Regards,
Huaimo as a co-author
From: Lsr on behalf of Acee Lindem (acee)
Sent: Tuesday, August 18, 2020 10:16 AM
To: lsr@ietf.org
Subject: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" -
draft-chen-isis-ttz-11.txt
Based on
able from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Link State Routing WG of the IETF.
>
> Title : IS-IS Topology-Transparent Zone
> Authors : Huaimo Chen
>
y, May 24, 2020 6:29 PM
To: Sarah Chen ; tony...@tony.li
Cc: Acee Lindem (acee) ; Huaimo Chen
; lsr@ietf.org
Subject: Re: [Lsr] Flooding Topology Computation Algorithm -
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
Hi Acee
Do you know if the dynamic flooding algorithm discus
Hi Gyan,
Thanks much for your questions. My answers/explanations are inline below.
Best Regards,
Huaimo
From: Gyan Mishra
Sent: Friday, May 22, 2020 8:41 PM
To: Huaimo Chen
Cc: Acee Lindem (acee) ; lsr@ietf.org
Subject: Re: [Lsr] Flooding Topology
t Regards,
Huaimo
From: Gyan Mishra
Sent: Thursday, May 21, 2020 10:36 AM
To: Huaimo Chen
Cc: Acee Lindem (acee) ; lsr@ietf.org
Subject: Re: [Lsr] Flooding Topology Computation Algorithm -
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
On Wed, May
Hi Xuesong,
Thank you very much for your support and comments.
We will add more explanations in “Appendix A. FT Computation Details
through Example ” and brief the relation to other work.
Best Regards,
Huaimo
From: Lsr on behalf of Gengxuesong (Geng
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
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
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
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
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
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
: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 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
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
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
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)
Hi Acee,
Thank you very much for your valuable comments.
My answers/explanations are inline below.
Best Regards,
Huaimo
From: Lsr on behalf of Acee Lindem (acee)
Sent: Friday, June 5, 2020 12:52 PM
To: lsr@ietf.org
Subject: Re: [Lsr] Flooding Topology
Hi Yingzhen,
Thank you very much for your support and comment.
My answer/explanation is inline below.
Best Regards,
Huaimo
From: Yingzhen Qu
Sent: Friday, June 5, 2020 3:37 PM
To: Acee Lindem (acee) ; lsr@ietf.org
; Huaimo Chen
Subject: Re: [Lsr
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
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.
Hi Authors,
The draft describes extensions to IGP for a node to distribute
capabilities of its links. The capability information about
all the links in a network may be used by another entity such as
a controller.
I have following comments:
1). In section 3, the capabilities of a link or a
Support its adoption.
Best Regards,
Huaimo
From: Lsr on behalf of Christian Hopps
Sent: Sunday, May 2, 2021 4:39 AM
To: lsr@ietf.org
Cc: lsr-...@ietf.org ; cho...@chopps.org ;
draft-acee-lsr-ospf-transport-insta...@ietf.org
Subject: [Lsr] WG adoption call
Hi Everyone,
I read through the document and support its adoption.
Best Regards,
Huaimo
From: Lsr on behalf of Acee Lindem (acee)
Sent: Tuesday, March 2, 2021 6:27 PM
To: lsr@ietf.org
Subject: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT)
Hi Adrian,
Thank you very much for your further valuable comment.
I will add some text accordingly in the next version of the document.
Best Regards,
Huaimo
From: Adrian Farrel
Sent: Wednesday, February 24, 2021 9:32 AM
To: Huaimo Chen ; 'lsr'
Cc: draft
Hi Adrian,
Thank you very much for your valuable comments.
My answers/explanations are inline below with prefix [HC].
Best Regards,
Huaimo on behalf of authors
From: Adrian Farrel
Sent: Saturday, February 13, 2021 3:34 PM
To: 'lsr'
Cc: draft-ietf-lsr-isis-...@ietf.org
Subject: A
Hi Acee,
We have been working on addressing all the valuable comments from Adrian.
Hi Adrian,
Thank you very much for your time, good and thorough review.
Best Regards,
Huaimo
From: Acee Lindem (acee)
Sent: Monday, February 15, 2021 12:42 PM
To:
) ; Acee Lindem
(acee) ; Huaimo Chen ; Christian
Hopps ; Hannes Gredler
Cc: lsr@ietf.org ; Alvaro Retana
Subject: RE: Early Allocation for IS-IS TTZ
FYI –
This has been approved by the DEs and IANA has updated the registry.
Les
From: Lsr On Behalf Of Les Ginsberg (ginsberg)
Sent
Hi Les,
I agree with you. It is legitimate for the IGP to advertise both a summary
and changes to the reachability of individual destinations covered by the
summary.
Best Regards,
Huaimo
From: Lsr on behalf of Les Ginsberg (ginsberg)
Sent: Wednesday,
Hi Everyone,
I read the draft and support its adoption.
Best Regards,
Huaimo
From: Lsr on behalf of Christian Hopps
Sent: Tuesday, January 4, 2022 1:58 AM
To: lsr@ietf.org
Cc: lsr-cha...@ietf.org ; lsr-...@ietf.org
; cho...@chopps.org ;
Hi Les,
In last IETF, you presented/stated that Backwards compatibility is not
possible. This seems not true. The solution proposed in
draft-chen-lsr-isis-big-tlv is backwards compatible. Can you give your
definition of backwards compatibility?
In this IETF and last IETF, the slides states
e same new information for using the new information, the
nodes supporting the capability can use the new information, the nodes not
supporting the capability ignore the new information.
Best Regards,
Huaimo
From: Les Ginsberg (ginsberg)
Sent: Sunday, November 5, 2023 10:30 PM
To: Huaimo Chen
1 - 100 of 118 matches
Mail list logo
