Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Huaimo Chen]

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: ginsberg=40cisco@dmarc.ietf.org
Cc: lsr@ietf.org; Jeff Tantsura ; Tony Li 
; acee=40cisco@dmarc.ietf.org
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

I do think it is a good idea in a sense to somehow outline WHAT problem is 
being solved via some write-down or mind-melt

a) I hope it's captured in the meeting notes but otherwise running the danger 
of repeating myself, the problem splits along the line of "directed graphs" 
(basically lattices) which DC topologies are today and generic graphs. In first 
case problem can be solved quite well (Pascal's idea based loosely on MANET in 
RIFT that could be stretched to flat flooding as well), in 2nd it's much harder.
b) Beside pure reduction, aspects like redundancy of the resulting mesh(es), 
minimal-cut properties and load balancing aspects emerge from practical pursuit 
of the problem (let's not even mention the dynamic re-convergence problems no 
matter whether some centralized instance floods or async distributed algorithm 
is run). Hence the scope or scopes of what needs being done seems prudent.
c) ultimately, other things like link properties and resulting meshes play a 
big role (MANET). In sparse networks we lived quite well without reduction but 
MANET/DSR had to deal with it already AFAIR & IP fabric seem to cause a 
different variation of the limitation to rear its head

2c

--- tony

On Wed, Aug 22, 2018 at 11:04 AM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:
In the discussions which led to the creation of LSVR and RIFT WGs, considerable 
interest was expressed in working on enhancements to existing Link State 
protocols. You can peruse the dcrouting mailing list archives.

https://mailarchive.ietf.org/arch/browse/dcrouting/

It is rather befuddling to me that the IETF seems to have decided to move 
forward on two new protocols (no objection from me) but seems to feel there is 
insufficient reason to move forward on proposals to extend existing IGPs.
I think the suggestion that we need to write (yet another)  requirements 
document before doing so is a recipe for delay – not for progress.

Multiple drafts have been presented over the course of the past two years and 
discussed on the list as well.
In the case of two of the drafts:

draft-shen-isis-spine-leaf-ext
draft-li-dynamic-flooding

WG adoption was requested in Montreal..

Please explain why we cannot proceed with “business as usual” as regards these 
drafts.


   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Jeff 
Tantsura
Sent: Wednesday, August 22, 2018 9:43 AM
To: Tony Li mailto:tony1ath...@gmail.com>>
Cc: lsr@ietf.org; Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

+1 Tony

We could start with a document, similar to dc-routing requirements one we did 
in RTGWG before chartering RIFT and LSVR.
Would help to disambiguate requirements from claims and have apple to apple 
comparison.
Doing it on github was a good experience.

Regards,
Jeff

On Aug 22, 2018, at 09:27, Tony Li 
mailto:tony1ath...@gmail.com>> wrote:


At IETF 102, there was no dearth of flooding reduction proposals.  In fact, we 
have so many proposals that there wasn’t agree as how to move forward and we 
agreed to discuss on the list. This Email is to initiate that discussion (which 
I intend to participate in but as a WG member).


Hi Acee,

Perhaps a useful starting point of the discussion is to talk about 
requirements.  There seem to many different perceptions..

Regards,
Tony


___
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] LSR Flooding Reduction Drafts - Moving Forward

[Huaimo Chen]

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. 

Best Regards,
Huaimo
-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
Sent: Friday, August 24, 2018 12:29 PM
To: Tony Przygienda 
Cc: lsr@ietf.org; Jeff Tantsura ; Peter Psenak 
; Acee Lindem (acee) 
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

> a) we are talking any kind of topology for the solution, i.e. generic graph? 


Well, the problem with a topology restriction is that mistakes happen.  If we 
have a solution for a pure bipartite graph (i.e., a leaf-spine topology) and 
someone mistakenly inserts a leaf to leaf link, what happens?  Having the 
entire DC implode would be a Bad Thing, IMHO.


> and then suggestion for IME realistic, operational MUST requirements 
> 
> b) req a): the solution should support distributed and centralized algorithm 
> to compute/signal reduced mesh(es). I personally think distributed is the 
> more practical choice for something like this but it's my 2c from having 
> lived the telephony controller fashion, the distributed fashion and the 
> controller fashion now again ;-)


Well, I did think long and hard about this.

Being distributed would be very nice.  However, that implies that all nodes are 
going to get to the exact same solution. Which implies that they all must 
execute the same algorithm, presumably with the same inputs.

That’s all well and good, but we don’t have an algorithm to really put on the 
table yet.  We need experience with one.  We know we want to tweak things based 
on biconnectivity, performance, and degree because doing it right day one seems 
unlikely.  Changing algorithms is going to be VERY painful if it’s distributed. 
 

However, if it’s centralized, it’s completely trivial.

So, my strong preference is to start centralized.  Iterate on the algorithm 
until we have it where we want it.  And then take it distributed if there’s a 
point to it.  However, at that point, we have something working.  So why fix it?


> c) req b): the solution should include redundancy (i.e. @ least 2 maximally 
> disjoint vertex covers/lifts) to deal with single link failure (unless the 
> link is unavoidably a minimal cut on the graph) 


Not everyone agrees with this, but some do.  This seems like one possible input 
to the algorithm.


> d) req c): the solution should guarantee disruption free flooding in case of 
>   i) single link failure
>  ii) single node failure
>  iii) change in one of the vertex lifts 


Sorry, I don’t understand point iii).


> e) the solution should not lead to "hot-spot" or "minimal-cut" links which 
> will disrupt flooding between two partitions on failure or lead to flood 
> throughput bottlenecks 


Agreed.

> I am agnostic to Tony L's thinking about diameter and so on. It makes sense 
> but is not necessarily easy to pull into the solution. 


It all boils down to the point that Peter just made about performance.  A 
topology with a high diameter is going to require many flooding hops and hurt 
performance.  To be avoided...


> moreover, I observe that IME ISIS is much more robust under such 
> optimizations since the CSNPs catch (@ a somehow ugly delay cost) any corner 
> cases whereas OSPF after IDBE will happily stay out of sync forever if 
> flooding skips something (that may actually become a reason to introduce 
> periodic stuff on OSPF to do CSNP equivalent albeit it won't be trivial in 
> backwards compatible way on my first thought, I was thinking a bit about 
> cut/snapshot consistency check [in practical terms OSPF hellos could carry a 
> checksum on the DB headers] but we never have that luxury on a link-state 
> routing protocol [i.e. we always operate under unbounded epsilon consistency 
> ;-) and in case of BGP stable oscialltions BTW not even that ;^} ]). 

Emacs

Tony


___
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] LSR Flooding Reduction Drafts - Moving Forward

[Huaimo Chen]

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 Shen (naiming)
Sent: Wednesday, August 22, 2018 3:19 PM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org; Jeff Tantsura ; Tony Li 
; Acee Lindem (acee) 
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward


I do think to solve all the data centers (massive or small) requirement,
this discussion is very useful. If we can list all the requirements and see
what technical approaches we can do to achieve them.

But incremental improvements on existing protocols is useful also. They may not
solve the complete set of “requirements”, but they do help data center
and also non-data center deployments to improve their operations.

I would think this group can proceed with both approaches.

Regards,
- Naiming

On Aug 22, 2018, at 11:02 AM, Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
 wrote:

In the discussions which led to the creation of LSVR and RIFT WGs, considerable 
interest was expressed in working on enhancements to existing Link State 
protocols. You can peruse the dcrouting mailing list archives.

https://mailarchive.ietf.org/arch/browse/dcrouting/

It is rather befuddling to me that the IETF seems to have decided to move 
forward on two new protocols (no objection from me) but seems to feel there is 
insufficient reason to move forward on proposals to extend existing IGPs.
I think the suggestion that we need to write (yet another)  requirements 
document before doing so is a recipe for delay – not for progress.

Multiple drafts have been presented over the course of the past two years and 
discussed on the list as well.
In the case of two of the drafts:

draft-shen-isis-spine-leaf-ext
draft-li-dynamic-flooding

WG adoption was requested in Montreal.

Please explain why we cannot proceed with “business as usual” as regards these 
drafts.


   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Jeff 
Tantsura
Sent: Wednesday, August 22, 2018 9:43 AM
To: Tony Li mailto:tony1ath...@gmail.com>>
Cc: lsr@ietf.org; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

+1 Tony

We could start with a document, similar to dc-routing requirements one we did 
in RTGWG before chartering RIFT and LSVR.
Would help to disambiguate requirements from claims and have apple to apple 
comparison.
Doing it on github was a good experience.

Regards,
Jeff

On Aug 22, 2018, at 09:27, Tony Li 
mailto:tony1ath...@gmail.com>> wrote:




At IETF 102, there was no dearth of flooding reduction proposals.  In fact, we 
have so many proposals that there wasn’t agree as how to move forward and we 
agreed to discuss on the list. This Email is to initiate that discussion (which 
I intend to participate in but as a WG member).


Hi Acee,

Perhaps a useful starting point of the discussion is to talk about 
requirements.  There seem to many different perceptions.

Regards,
Tony


___
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] LSR Flooding Reduction Drafts - Moving Forward

[Huaimo Chen]

Hi John,

Two drafts are presented in just two IETFs. For centralized mode and 
distributed one, one very important part is the their efficiency. It is better 
to give some time for others to propose some new or more efficient solutions. 
If one solution (say A) is much more efficient than 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 Psenak 
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi,

I think we have circled back to the implicit point of my original email, viz, 
why do we need two drafts that solve the same problem in more or less the same 
way, especially given that one is much more robust and complete than the other?

Yours Irrespectively,

John

From: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Sent: Tuesday, September 4, 2018 11:24 AM
To: John E Drake mailto:jdr...@juniper.net>>; Robert Raszuk 
mailto:rob...@raszuk.net>>
Cc: tony...@tony.li<mailto:tony...@tony.li>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>; Peter Psenak 
mailto:ppse...@cisco.com>>
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi John,

See my comments inline below.

Best Regards,
Huaimo
From: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Sent: Tuesday, September 4, 2018 9:50 AM
To: John E Drake mailto:jdr...@juniper.net>>; Robert Raszuk 
mailto:rob...@raszuk.net>>
Cc: tony...@tony.li<mailto:tony...@tony.li>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>; Peter Psenak 
mailto:ppse...@cisco.com>>
Subject: RE: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi John,

> I have reviewed both of the flood reduction drafts and the draft referenced 
> below, draft-cc-ospf-flooding-reduction-02, seems to me to be a derivative 
> document inferior in >quality to the draft, draft-li-dynamic-flooding-05, 
> from which it is derived.  For example, the referenced draft fails to include 
> a description of the message used to deliver the >flooding topology when 
> using centralized mode, it neglects to include any analysis of error 
> conditions, and it neglects to include any description of the interactions 
> with down->level nodes.
It seems that your word “derivative” is not correct. Our draft originally 
focuses on distributed solution, Tony’s on centralized one. It is not 
reasonable to say that a distributed solution is a derivative from a 
centralized one.

[JD]  Both discuss centralized and distributed
[HC] Both drafts talk about both now. It is not reasonable to say one is a 
derivative of another.

Regarding to missing message for centralized mode in our draft as you 
mentioned, it is for new ones to be added. We will fill this gap.

[JD] Please see:   
https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-5<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Ddynamic-2Dflooding-2D05-23section-2D5=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=OtsOoYoplgrllQAM3IzPelpEFY22UOyVbTeCEZVKvfs=G1nxMx0mq-ML451DGEvEZ_QClKB6lWjXE6LJrkmxnds=>

Regarding to missing analysis of error conditions, we will consider and add it.

[JD] Please see:   
https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-4.6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Ddynamic-2Dflooding-2D05-23section-2D4.6=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=OtsOoYoplgrllQAM3IzPelpEFY22UOyVbTeCEZVKvfs=BXGDgpp4d36n9mToUIVYpJ1jK70LFDdWv_G35532MtU=>
[HC] For this, our draft talks about it. We will add more in details.

Regarding to interactions with down-level nodes, can you give more details?

[JD]  Please see:   
https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-4<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Ddynamic-2Dflooding-2D05-23section-2D4=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE=OtsOoYoplgrllQAM3IzPelpEFY22UOyVbTeCEZVKvfs=cQTQjUmBdJJJXLwNJuuICHOYwE09AmYdvM3tdz6JP5A=>,
 
https://tools.ietf.org/html/draft-li-dynamic-flooding-05#section-4.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dli-2Ddynamic-2Dflooding-2D05-23section-2D4.1=DwMGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=CR

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Huaimo Chen]

Hi John,

> I have reviewed both of the flood reduction drafts and the draft referenced 
> below, draft-cc-ospf-flooding-reduction-02, seems to me to be a derivative 
> document inferior in >quality to the draft, draft-li-dynamic-flooding-05, 
> from which it is derived.  For example, the referenced draft fails to include 
> a description of the message used to deliver the >flooding topology when 
> using centralized mode, it neglects to include any analysis of error 
> conditions, and it neglects to include any description of the interactions 
> with down->level nodes.
It seems that your word “derivative” is not correct. Our draft originally 
focuses on distributed solution, Tony’s on centralized one. It is not 
reasonable to say that a distributed solution is a derivative from a 
centralized one.
Regarding to missing message for centralized mode in our draft as you 
mentioned, it is for new ones to be added. We will fill this gap.
Regarding to missing analysis of error conditions, we will consider and add it.
Regarding to interactions with down-level nodes, can you give more details?

>Yours Irrespectively,
>
>John

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Huaimo Chen
Sent: Thursday, August 30, 2018 11:01 AM
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: tony...@tony.li<mailto:tony...@tony.li>; Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>; Peter Psenak 
mailto:ppse...@cisco.com>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi Robert,

>> draft-cc-ospf-flooding-reduction-02 allows operators to select distributed 
>> mode, centralized one or static one smoothly.
>Aside from static approach can you summarize in purely technical points 
>advantages your draft proposes over draft-li-dynamic-flooding-05 ?
Initially, our draft focused on distributed solution for flooding reduction, 
and Tony’s on centralized way. This should be one advantage. Distributed 
solution is more practical.
In addition, we proposed the followings during the progress of our draft:

1)A method to allow flooding topology to be lean and to allow multiple 
failures in an area;

2)A procedure for establishing a new adjacency between a (new) node and  an 
existing node supporting flooding reduction;

3)A way in which one touch (or command) to enable flooding reduction in a 
whole area within a short time;

4)A way in which one touch (or command) to rollback flooding reduction to 
normal flooding in a whole area smoothly;

5)A TLV for distributing the priority of a node to become a leader;

6)Three algorithms for building a flooding topology.
Distributed solution for flooding reduction is stable 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, Huaimo Chen 
mailto:huaimo.c...@huawei.com>> wrote:
Hi Robert,

>Leader election happens automatically and procedures for that are to be vastly 
>similar to today's DR or DIS election. So with this in mind one may observe 
>that both OSPF and ISIS are pretty centralized on multiaccess networks today :)

Today’s DR or DIS election is local to a special interface/network such as a 
broadcast interface. Leader election in a network is global. Every node in the 
network depends on it (its flooding topology). These two seems different.

>Btw I don't think there is any problem here ... The text added to -05 version 
>allows very seamless choice of centralized vs distributed topology computation 
>by signalling either zero or non zero value in the added to version -05 area 
>leader sub-tlv.
>
>In other words I don't see any problem or room for debate .. adopting and 
>implementing -05 allows use of centralized or distributed optimal flooding 
>computation at the operator's discretion.

draft-cc-ospf-flooding-reduction-02 allows operators to select distributed 
mode, centralized one or static one smoothly.

Best Regards,
Huaimo

From: Robert Raszuk [mailto:rob...@raszuk.net<mailto:rob...@raszuk.net>]
Sent: Monday, August 27, 2018 11:31 AM
To: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Cc: tony...@tony.li<mailto:tony...@tony.li>; lsr@ietf.org<mailto:lsr@ietf.org>; 
Jeff Tantsura mailto:jefftant.i...@gmail.com>>; Acee 
Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>; Peter 
Psenak mailto:ppse...@cisco.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi Huaimo,

> Introducing centralized featu

Re: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

[Huaimo Chen]

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 presented at 2 
IETFs and it is one of the more exciting developments in LSR (I’m sure there 
are other WGs that are feeling insecure based on the power and flexibility of 
this enhancement ;^).

Speaking as WG Co-Chair – I think it would be great to combine the drafts. The 
normative sections on SPF computation are common to both OSPF and IS-IS.

Thanks,
Acee

From: Lsr > on behalf of Acee 
Lindem >
Date: Tuesday, April 17, 2018 at 10:44 AM
To: "lsr@ietf.org" >
Subject: [Lsr] LSR Working Group Adoption Poll for Flex Algorithm Drafts

This begins a two-week adoption poll for the following Flex Algorithm drafts:

https://datatracker.ietf.org/doc/draft-hegdeppsenak-isis-sr-flex-algo/
https://datatracker.ietf.org/doc/draft-ppsenak-ospf-sr-flex-algo/

The adoption poll will end at 12:00 AM EST on May 2nd, 2018. Please indicate 
your support of opposition of the drafts.

Additionally, the authors are amenable to combining the drafts into a single 
draft. If you have an opinion, please state that as well.

Thanks,
Acee



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

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Huaimo Chen]

Hi Robert,

>> draft-cc-ospf-flooding-reduction-02 allows operators to select distributed 
>> mode, centralized one or static one smoothly.
>Aside from static approach can you summarize in purely technical points 
>advantages your draft proposes over draft-li-dynamic-flooding-05 ?
Initially, our draft focused on distributed solution for flooding reduction, 
and Tony’s on centralized way. This should be one advantage. Distributed 
solution is more practical.
In addition, we proposed the followings during the progress of our draft:

1)A method to allow flooding topology to be lean and to allow multiple 
failures in an area;

2)A procedure for establishing a new adjacency between a (new) node and  an 
existing node supporting flooding reduction;

3)A way in which one touch (or command) to enable flooding reduction in a 
whole area within a short time;

4)A way in which one touch (or command) to rollback flooding reduction to 
normal flooding in a whole area smoothly;

5)A TLV for distributing the priority of a node to become a leader;

6)Three algorithms for building a flooding topology.
Distributed solution for flooding reduction is stable 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, Huaimo Chen 
mailto:huaimo.c...@huawei.com>> wrote:
Hi Robert,

>Leader election happens automatically and procedures for that are to be vastly 
>similar to today's DR or DIS election. So with this in mind one may observe 
>that both OSPF and ISIS are pretty centralized on multiaccess networks today :)

Today’s DR or DIS election is local to a special interface/network such as a 
broadcast interface. Leader election in a network is global. Every node in the 
network depends on it (its flooding topology). These two seems different.

>Btw I don't think there is any problem here ... The text added to -05 version 
>allows very seamless choice of centralized vs distributed topology computation 
>by signalling either zero or non zero value in the added to version -05 area 
>leader sub-tlv.
>
>In other words I don't see any problem or room for debate .. adopting and 
>implementing -05 allows use of centralized or distributed optimal flooding 
>computation at the operator's discretion.

draft-cc-ospf-flooding-reduction-02 allows operators to select distributed 
mode, centralized one or static one smoothly.

Best Regards,
Huaimo

From: Robert Raszuk [mailto:rob...@raszuk.net<mailto:rob...@raszuk.net>]
Sent: Monday, August 27, 2018 11:31 AM
To: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Cc: tony...@tony.li<mailto:tony...@tony.li>; lsr@ietf.org<mailto:lsr@ietf.org>; 
Jeff Tantsura mailto:jefftant.i...@gmail.com>>; Acee 
Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>; Peter 
Psenak mailto:ppse...@cisco.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi Huaimo,

> Introducing centralized feature into IGP will break IGP's distributed nature

That clearly proves that word "centralized" has been significantly overloaded 
here.  To many indeed "centralized" means a controller (like OpenFlow or SDN) 
and that such device added to a network is to push information - typically 1RU 
linux blade -  here optimized flooding graph. But this never was the plan with 
this proposal from its start ie. -00 version.

Centralized means that optimized flooding graph comes from single redundant 
node.

Leader election happens automatically and procedures for that are to be vastly 
similar to today's DR or DIS election. So with this in mind one may observe 
that both OSPF and ISIS are pretty centralized on multiaccess networks today :)

To your point of multi-vendor networks true - and that is precisely why upgrade 
network wide to a release containing consistent algorithm from more then a 
single vendor (and even for single vendor) is practically a very time consuming 
and difficult process.

Btw I don't think there is any problem here ... The text added to -05 version 
allows very seamless choice of centralized vs distributed topology computation 
by signalling either zero or non zero value in the added to version -05 area 
leader sub-tlv.

In other words I don't see any problem or room for debate .. adopting and 
implementing -05 allows use of centralized or distributed optimal flooding 
computation at the operator's discretion.

Thx,
R.

On Mon, Aug 27, 2018 at 5:10 PM, Huaimo Chen 
mailto:huaimo.c...@huawei.com>> wrote:
>> I think distributed is more practical too.
>I would appreciate more detailed insights as to why you (and others) feel this 
>way.  It is not at all obvio

Re: [Lsr] New Version Notification for draft-cc-ospf-flooding-reduction-04.txt

[Huaimo Chen]

Hi Everyone,

A new encoding (called block encoding) for flooding topology is added in 
this version,
which uses a single structure to encode a block (or part) of topology (maybe 
whole topology).
It seems much more efficient than others. For example, for 63 nodes flooding 
topology
of a binary tree, block encoding for this whole flooding topology uses about 
100 bytes.
Encoding it through paths uses about 438 bytes. 438/100 = 4.38.

Best Regards,
Huaimo
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Thursday, September 20, 2018 3:25 PM
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:   draft-cc-ospf-flooding-reduction
Revision:   04
Title:  LS Flooding Reduction
Document date:  2018-09-20
Group:  Individual Submission
Pages:  42
URL:
https://www.ietf.org/internet-drafts/draft-cc-ospf-flooding-reduction-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-cc-ospf-flooding-reduction/
Htmlized:   https://tools.ietf.org/html/draft-cc-ospf-flooding-reduction-04
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-cc-ospf-flooding-reduction
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-cc-ospf-flooding-reduction-04

Abstract:
   This document proposes an approach to flood link states on a topology
   that is a subgraph of the complete topology per underline physical
   network, so that the amount of flooding traffic in the network is
   greatly reduced, and it would reduce convergence time with a more
   stable and optimized routing environment.  The approach can be
   applied to any network topology in a single area.





Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

Re: [Lsr] New Version Notification for draft-cc-ospf-flooding-reduction-03.txt

[Huaimo Chen]

Hi Everyone,

This version contains:
•   A new centralized solution, which seems much more efficient. For 63 
nodes network, if flooding topology is a binary tree, this new solution uses 
about 120 bytes for flooding topology, the existing solution uses about 438 
bytes. 438/120 = 3.65.
•   An incremental solution for flooding topology changes, which further 
improves the efficiency of the centralized solution. When there are some 
changes on the flooding topology, we can flood only these changes, and we do 
not need to flood the whole flooding topology.
•   A solution for backup flooding topology split, which makes flooding 
topology more tolerant to failures (thus the flooding topology may be slim),  
and quickly flood link states to every live node when multiple failures split 
the flooding topology.
•   Support for selecting N leaders.
In addition, we have 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 
cheng ; Mehmet Toy 
Subject: New Version Notification for draft-cc-ospf-flooding-reduction-03.txt


A new version of I-D, draft-cc-ospf-flooding-reduction-03.txt
has been successfully submitted by Huaimo Chen and posted to the IETF 
repository.

Name:   draft-cc-ospf-flooding-reduction
Revision:   03
Title:  LS Flooding Reduction
Document date:  2018-09-12
Group:  Individual Submission
Pages:  39
URL:
https://www.ietf.org/internet-drafts/draft-cc-ospf-flooding-reduction-03.txt
Status: 
https://datatracker.ietf.org/doc/draft-cc-ospf-flooding-reduction/
Htmlized:   https://tools.ietf.org/html/draft-cc-ospf-flooding-reduction-03
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-cc-ospf-flooding-reduction
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-cc-ospf-flooding-reduction-03

Abstract:
   This document proposes an approach to flood link states on a topology
   that is a subgraph of the complete topology per underline physical
   network, so that the amount of flooding traffic in the network is
   greatly reduced, and it would reduce convergence time with a more
   stable and optimized routing environment.  The approach can be
   applied to any network topology in a single area.





Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

Re: [Lsr] Open issues with Dynamic Flooding

[Huaimo Chen]

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 [mailto:lsr-boun...@ietf.org] On Behalf Of tony...@tony.li
Sent: Monday, April 1, 2019 1:38 PM
To: lsr@ietf.org
Subject: Re: [Lsr] Open issues with Dynamic Flooding


Hi all,

I hope that everyone had a safe and uneventful trip home from Prague and that 
no one else had the seat right in front of the screaming baby.  ;-)

I would like to re-open the discussion on the mailing list. Based on the 
off-line discussions that I had with folks, I believe that we’re leaning 
towards including the LANs in the signaling and rate limiting link addition 
during repair.

Dissent? Discussion?

Tony


> On Mar 4, 2019, at 9:54 AM, tony...@tony.li wrote:
> 
> 
> Hello,
> 
> There are still two issues that need to be discussed and I was hoping that we 
> could make progress on the mailing list before Prague.
> 
> 1) Temporary additions to the flooding topology
> 
>There are several cases where we would like to make temporary additions to 
> the flooding topology: repairing a partition of the flooding topology or 
> adding a node to the base topology for the first time. We can:
> 
>(a) Temporarily add all of the links that would appear to remedy the 
> partition. This has the advantage that it is very likely to heal the 
> partition and will do so in the minimal amount of convergence time.
> 
>(b) For each node adjacent to the partition, add no more than a single 
> link across the partition.  If that does not repair the partition in a while 
> (LSP propagation time + SPF time), then add another link.  
> Iterate as necessary. This has the advantage that it minimizes the 
> risk of creating a cascade failure.
> 
> 2) Inclusion of pseduonodes in the System IDs TLV
> 
>In the general case, a topology can include LANs. If a LAN is in parallel 
> with a P2P link, the Area Leader cannot currently distinguish between the two 
> links. This can be of importance if there are other 
>systems also on the LAN that should be using their LAN interface for 
> flooding.
> 
>We propose to change the System IDs TLV to include a pseudo-node ID as 
> well as the system ID.  It would also make sense to rename the TLV to be the 
> “IS-IS Area Node IDs TLV”.
> 
>Behaviorally, we should add a requirement that if the Area Leader includes 
> a pseudonode in the flooding topology, then all systems with an adjacency on 
> that LAN should use the LAN as part of the 
>flooding topology, whether or not they are explicitly listed as adjacent 
> to the LAN in the Flooding Path TLV.
> 
> Thoughts? Comments? Flames?
> 
> Regards,
> Tony
> 

___
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] Min Links for Multiple Failures on Flooding Topology

[Huaimo Chen]

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 minimum number of links, and is 
triggered by the multiple failures.
When the multiple failures on the FT occur, a backup path for each of the 
failures is computed, wherein the links on the backup path are not on the FT. 
The links on the backup path are temporarily added to the FT (i.e., the 
temporary flooding is enabled on the links on the backup path). Thus the split 
FT is connected by the backup paths.
When any node N detects the multiple failures on the FT, it computes a backup 
path for each of the failures. If it (i.e., node N) is on the backup path, it 
adds its local links (e.g., local link L1 and L2) on the backup path to the FT 
temporarily; otherwise, it does not do anything.
For a failure on the FT, the backup path computed by any node N needs to be the 
same. Suppose that the two end nodes of a failed link L on the FT is A and B, 
and A's ID is smaller than B's.  Node N computes a path from A to B with 
minimum hops and whose links are not on the FT. This path is a backup path for 
link L. When every node on the backup path computes a backup path in this way 
in parallel, the same backup path is obtained, and used to fix the FT split.

Best Regards,
Huaimo
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

[Huaimo Chen]

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 significantly without fault 
tolerance. The longer the convergence time, the more the traffic lose.



2)   The extensions to Hello protocols for enabling "temporary 
flooding" over a new link is not needed.



3)   The extensions to Hello protocols for requesting/signaling 
"temporary flooding" for a connection does not work.



In addition, for signaling the distributed solution/mode or the centralized 
solution/mode, a user/operator needs to configure or select a solution/mode on 
a node via CLI or other approach first. Which node should the user/operator use 
to configure/select a mode?  If the user/operator can only use the leader node 
in the area to configure, then it is neither convenient nor reasonable. The 
leader node in the area is dynamically generated. But in the distributed 
mode/solution, there is no leader selection (i.e., no leader should be 
generated).



draft-cc-lsr-flooding-reduction-01 contains solutions for some of the above 
issues, which should be merged based on technical merits.



Best Regards,

Huaimo



-Original Message-

From: Lsr  On Behalf Of Christian Hopps

Sent: 11 February 2019 16:15

To: lsr@ietf.org

Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org

Subject: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.





Hi Folks,



We are starting a 2 week adoption call on draft-li-lsr-dynamic-flooding-02.



The aim of this document is to describe the problem space and standardize a way 
to signal dynamic flooding information. It does not standardize any specific 
algorithm for flooding topology creation.



Authors please respond indicating if you are aware of any IPR related to this 
work.



We also have another draft (draft-cc-lsr-flooding-reduction-01) that started as 
a distributed flooding topology algorithm and morphed into that plus competing 
ideas on signaling of flooding topology information. The intent after adoption 
of draft-li-lsr-dynamic-flooding-02 is two-fold. One, the WG can discuss adding 
any signaling ideas from this work to the adopted signaling draft (with proper 
attribution given as appropriate), and two, for the authors of 
draft-cc-lsr-flooding-reduction-01 to publish a new document without the 
signaling portion and instead focus on their flooding topology algorithm. This 
new focused document can be considered in parallel along with the other 
algorithm work that has been proposed.



Flooding topology creation is seen as a hard problem for which we don't expect 
a one-size-fits-all solution. Taking the steps outlined above will help us move 
forward on the solutions.



Thanks,

Chris & Acee.

LSR WG Chairs.



___

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] Moving Forward [Re: Flooding Reduction Draft Redux]

[Huaimo Chen]

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 Huaimo,
>
>On 18/02/2019 16:28 , Huaimo Chen wrote:
>> 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 Huaimo,
>>>
>>> On 13/02/2019 22:50 , Huaimo Chen wrote:
>>>> 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 [Re: Flooding Reduction Draft 
>>>> Redux]
>>>>
>>>> Hi Huaimo,
>>>>
>>>> On 03/02/2019 17:58 , Huaimo Chen wrote:
>>>>> Hi Acee,
>>>>>
>>>>>
>>>>>
>>>>> I agree with you on keeping the signaling for two modes. The 
>>>>> other parts for the distributed solution need to be removed.
>>>
>>> optimized flooding is not only about algorithm to calculate the 
>>> flooding topology and the way it is distributed/computed. It is also about 
>>> local rules to make sure the flooding remains consistent.
>>> These are _independent_ of centralized/distributed modes. And it make 
>>> no sense to specify these rules in two drafts.
>>
>> [HC] The rules/procedures/behaviors that are common to both the 
>> centralized and distributed solution/mode should be in one document. These 
>> common parts will be used by both solutions/modes.
>> They are described in the two drafts and should be merged based on technical 
>> merits.
>>
>> In addition to the common parts, there are still some 
>> rules/procedures/behaviors that are different from one mode to another 
>> mode. For example, the rule/procedure for fault tolerance to failures 
>> used in the centralized solution/mode will be different from that used in 
>> the distributed solution/mode.

>I don't think there is any significant difference needed. And I believe these 
>local rules for both 
>modes should reside in a single document as most of them are applicable to 
>both modes.

The way in which the flooding topology converges in the centralized 
mode/solution is different from 
that in the distributed mode/solution. In the former, after receiving the link 
states for the failures,
the leader computes a new flooding topology and floods it to every other node, 
which receives
and installs the new flooding topology. The working load on every non leader 
node is light. It has more 
processing power for a procedure/method for fault tolerance to failures.
However, in the latter, every node computes and installs a new flooding 
topology after receiving 
the link states for the failures. It has less processing power for a 
procedure/method for fault tolerance.
It is better to let each of the two modes use its own procedure/method for 
fault tolerance to failures,
which is more appropriate to it.

>> In the distributed solution/mode, there will be a set of 
>> rules/procedures/behaviors that are common to the algorithms for 
>> computing flooding topology and specific to the distributed 
>> solution/mode. For example, a specific procedure for scheduling an algorithm 
>> to compute a flooding topology will be used on every node for the 
>> distributed solution/mode.

>scheduling a distributed versus centralized computation is not something that 
>makes the 
>behavior different. Sure, you can put a scheduling details for a particular 
>algorithm in the 
>document that describes the distributed algorithm itself.

In the centralized solution/mode, scheduling an algorithm to compute flooding 
topology happens 
only on the leader, and then on the backup leader after the leader fails. The 
parameters for 
scheduling on the leader may be different from those for scheduling on the 
backup leader. 
However, in the distributed solution/mode, scheduling an algorithm to compute 
flooding topology
occurs on every node. T

Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

[Huaimo Chen]

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 draft-li-lsr-dynamic-flooding-02 + 
> IPR poll.
>
> Huaimo,
>
> On 24/02/2019 06:34 , Huaimo Chen wrote:
> > 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
> > significantly without fault tolerance. The longer the convergence
> > time, the more the traffic lose.
>
> there is a solution for multiple failures - see section 6.7.11.
>

Section 6.7.11 just briefly mentions that the edges of split parts will 
determine and repair the split after the split of the flooding topology 
happens. However, there is not any details or description on how to determine 
or repair the split. This is not useful for implementers.

> >
> >
> >
> > 2)   The extensions to Hello protocols for enabling "temporary
> flooding" over a new link is not needed.
>
> not if you do flooding on every link that comes up. If you want to be 
> smarter, then you need to
> selectively enable flooding only under specific conditions and that must be 
> done from both sides of
> the new link.

There are only a limited number of conditions (or cases).  In each 
condition/case, it is deterministic whether we need to enable "temporary 
flooding" for a new link when it is up.  Thus there is no need for any 
extensions to Hello protocols for enabling "temporary flooding" on a new link.

For example, suppose that we have a current flooding topology containing all 
live nodes in an area, when a new link comes up, we may just have two 
conditions/cases. One condition/case is that the new link is attached to a new 
node not on the current flooding topology. In this condition/case, the new link 
needs to be enabled for "temporary flooding" after it is up. The other 
condition/case is that the new link is attached to nodes on the current 
flooding topology. In this condition/case, there is no need to enable 
"temporary flooding" on the link.

> >
> >
> > 3)   The extensions to Hello protocols for requesting/signaling
> > "temporary flooding" for a connection does not work.
>
> sorry, but if you see a problem, please provide details, saying above is
> simply unproductive.

"The nodes ... will try to repair the flooding topology locally by enabling 
temporary flooding towards the nodes that they consider disconnected from the 
flooding topology ..."

The above quoted text is from draft-li-lsr-dynamic-flooding-02, where "enabling 
temporary flooding towards the nodes" is to request/signal "temporary flooding" 
for a connection to connect partitioned/disconnected flooding topology into one 
through the extensions to Hello protocols described in 
draft-li-lsr-dynamic-flooding-02. Right?

The extensions to Hello protocols for requesting/signaling "temporary flooding" 
for a connection to connect partitioned/disconnected flooding topology into one 
does not work since the connection may have two or more hops and a Hello packet 
may get lost.

> >
> >
> >
> > In addition, for signaling the distributed solution/mode or the
> > centralized solution/mode, a user/operator needs to configure or select
> > a solution/mode on a node via CLI or other approach first. Which node
> > should the user/operator use to configure/select a mode?  If the
> > user/operator can only use the leader node in the area to configure,
> > then it is neither convenient nor reasonable. The leader node in the
> > area is dynamically generated. But in the distributed mode/solution,
> > there is no leader selection (i.e., no leader should be generated).
>
> there is an area leader in both modes. In distributed mode the area
> leader is the one that advertises the algorithm that is used by all
> nodes that participates in dynamic flooding.
>

It is not convenient for a user/operator to configure on an area leader since 
the leader is dynamically selected. How do you address this?

After the user/operator does some configurations on the (designated) leader, 
will the backup leader takes over the configurations after the designated 
leader is down?

Best Regards,
Huaimo

> regards,
> Peter

>
>
>
> draft-cc-lsr-flooding-reduction-01 contains solutions for some of the
> above i

Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

[Huaimo Chen]

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 Huaimo,
>
>>The way in which the flooding topology converges in the centralized 
>>mode/solution is different
>>from that in the distributed mode/solution. In the former, after receiving 
>>the link states for the failures,
>>the leader computes a new flooding topology and floods it to every other 
>>node, which receives
>>and installs the new flooding topology. The working load on every non leader 
>>node is light. It has more
>>processing power for a procedure/method for fault tolerance to failures.
>>However, in the latter, every node computes and installs a new flooding 
>>topology after receiving
>>the link states for the failures. It has less processing power for a 
>>procedure/method for fault tolerance.
>>It is better to let each of the two modes use its own procedure/method for 
>>fault tolerance to failures,
>>which is more appropriate to it.
>
>It’s true that a distributed solution will call more on an average node than a 
>centralized
>solution will. However, that is not the steady state for either. In the
>steady state, the flooding topology has been computed and has been put in 
>place already.
>Thus, the impact of the topology computation at the time of the
>topology change is nil.
>
>In addition, the amount of work to temporarily amend the flooding topology 
>should also
>be minimal, and by that, I mean O(log n).  The decision should only
>be whether or not to temporarily add a link to flooding, and the only 
>information that a node
>needs to do that is to determine if the node is already on the
>flooding topology. That should be a lookup in a tree that represents the nodes 
>on the topology,
>and that lookup should be O(log n). In other words, it’s fast
>and efficient and not a significant drain on resources.
>

When multiple failures happen, the current flooding topology changes, the 
procedure for fault tolerance to failures is triggered to run, and a new 
flooding topology is to be computed. We need to have a converged flooding 
topology as soon as possible.
In the distributed solution/mode, if a procedure for fault tolerance, which is 
not appropriate to it, is used, then we will have a converged flooding topology 
in a longer time.
For example, after multiple failures occur, one procedure (in rough idea) for 
fault tolerance includes: 1) determine whether the current flooding topology 
splits, 2) compute backup paths to connect the split flooding topology, 3) 
enable/request the temporary flooding on the backup paths through extensions to 
Hello protocol. We can see that this procedure for fault tolerance takes a 
longer time than the algorithm computes a new flooding topology. This procedure 
will delay the convergence of flooding topology, which is not appropriate to 
the distributed solution/mode.
So it is better for the distributed solution/mode to use a procedure for fault 
tolerance, which is more appropriate to it.

>>In the centralized solution/mode, scheduling an algorithm to compute flooding 
>>topology happens
>>only on the leader, and then on the backup leader after the leader fails. The 
>>parameters for
>>scheduling on the leader may be different from those for scheduling on the 
>>backup leader.
>>However, in the distributed solution/mode, scheduling an algorithm to compute 
>>flooding topology
>>occurs on every node. The parameters for scheduling on all the nodes need to 
>>be the same.
>
>
>Actually, that’s not true.  An implementation is free to do its own internal 
>scheduling
>however it chooses, regardless of whether it implements a
>distributed or centralized implementation.
>
>
>>The procedure for achieving this is specific to the distributed mode/solution.
>
>More accurately, it is specific to a given implementation.
>
>
>>If every particular algorithm for computing flooding topology in the 
>>distributed solution/mode
>>describes a procedure for scheduling in details itself, there will be 
>>duplicated descriptions of
>>the same procedure in multiple algorithms, one of which is selected to 
>>compute flooding
>>topology on every node. It is better for the same scheduling procedure for 
>>multiple algorithms
>>to be described in one document.
>
>
>Actually, since the IETF should not be specifying the details of scheduling as 
>it is an
>implementation detail, as they do not affect the behavior of the protocol, it 
>should not be
>d

Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

[Huaimo Chen]

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-lsr-dynamic-flooding-02 + 
> IPR poll.
>
>
> Hi Huaimo,
>
> > > 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
> > > significantly without fault tolerance. The longer the convergence
> >>  time, the more the traffic lose.
> >
> > there is a solution for multiple failures - see section 6.7.11.
> >

> > Section 6.7.11 just briefly mentions that the edges of split parts will 
> > determine
> > and repair the split after the split of the flooding topology happens. 
> > However,
> > there is not any details or description on how to determine or repair the 
> > split.
> > This is not useful for implementers.


> I’m sorry that you don’t find it useful. Determining the split is trivial: 
> when you receive an IIH,
> it has a system ID of the another system in it. If that other system is not 
> currently part of the
> flooding topology, then it is quite clear that it is disconnected from the 
> flooding topology.
> Repairing the split is done by enabling temporary flooding on the new link.

For an adjacency between two nodes is up, the Hello packets exchanged between 
them will not change node/system IDs in them.
How do you determine that other system is not currently part of the flooding 
topology?


> There is an issue here that we have not yet resolved, which is the rate that 
> new links should be
> temporarily added to the flooding topology.  Some believe that adding any new 
> link is the
> correct thing to do as it minimizes the recovery time. Others feel that 
> enabling too many links
> could cause a flooding collapse, so link addition should be highly 
> constrained. We are still
> discussing this and invite the WG’s opinions.

The issue is resolved by the solutions in draft-cc-lsr-flooding-reduction.
One solution is below, where the given distance can be adjusted/configured.
If we want every node to flood on all its links, we let the given
distance to a big number. If we want the nodes within 2 hops to a failure
to flood on all their links, we set the given distance to 2.
   “In one way, when two or more failures on the current flooding
   topology occur almost in the same time, each of the nodes within a
   given distance (such as 3 hops) to a failure point, floods the link
   state (LS) that it receives to all the links (except for the one from
   which the LS is received) until a new flooding topology is built.”

Another solution is just adding minimum links temporarily on the flooding
topology to repair the split flooding topology until a new flooding topology
is built.

> > > 2)   The extensions to Hello protocols for enabling “temporary
> > flooding” over a new link is not needed.
> >
> > not if you do flooding on every link that comes up. If you want to be 
> > smarter, then you need to
> > selectively enable flooding only under specific conditions and that must be 
> > done from both sides of
> > the new link.

> > There are only a limited number of conditions (or cases).  In each 
> > condition/case, it is
> > deterministic whether we need to enable “temporary flooding” for a new link 
> > when it
> > is up.  Thus there is no need for any extensions to Hello protocols for 
> > enabling
> > “temporary flooding” on a new link.


> We know of only two cases: (1) the neighbor is not part of the flooding 
> topology and we feel
> that we can add more temporary flooding. (2) The neighbor is not part of the 
> flooding topology
> and we cannot add more temporary flooding.

> Obviously, in the case where we want to add temporary flooding, that TLV is 
> needed in the IIH.


> > For example, suppose that we have a current flooding topology containing 
> > all live
> > nodes in an area, when a new link comes up, we may just have two 
> > conditions/cases.
> > One condition/case is that the new link is attached to a new node not on 
> > the current
> > flooding topology. In this condition/case, the new link needs to be enabled 
> > for
> > “temporary flooding” after it is up.


> Agreed, which is why we need the TLV.

The link can be enabled for “temporary flooding” by the node without using any 
TLV or Hello with the TLV.

> >The other condition/case is that the new link is attached to nodes on the 
> >

Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

[Huaimo Chen]

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 Huaimo,
>
>On 13/02/2019 22:50 , Huaimo Chen wrote:
>> 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 [Re: Flooding Reduction Draft Redux]
>>
>> Hi Huaimo,
>>
>> On 03/02/2019 17:58 , Huaimo Chen wrote:
>>> Hi Acee,
>>>
>>>
>>>
>>> I agree with you on keeping the signaling for two modes. The 
>>> other parts for the distributed solution need to be removed.
>
>optimized flooding is not only about algorithm to calculate the flooding 
>topology and the way 
>it is distributed/computed. It is also about local rules to make sure the 
>flooding remains consistent. 
>These are _independent_ of centralized/distributed modes. And it make no sense 
>to specify 
>these rules in two drafts.

[HC] The rules/procedures/behaviors that are common to both the centralized and 
distributed 
solution/mode should be in one document. These common parts will be used by 
both solutions/modes. 
They are described in the two drafts and should be merged based on technical 
merits.  

In addition to the common parts, there are still some 
rules/procedures/behaviors that are 
different from one mode to another mode. For example, the rule/procedure for 
fault tolerance 
to failures used in the centralized solution/mode will be different from that 
used in the distributed 
solution/mode.  In the distributed solution/mode, there will be a set of 
rules/procedures/behaviors 
that are common to the algorithms for computing flooding topology and specific 
to the 
distributed solution/mode. For example, a specific procedure for scheduling an 
algorithm 
to compute a flooding topology will be used on every node for the distributed 
solution/mode.

>>
>> There are no "other" parts specific for the distributed solution.
>>
>> [HC] Some behaviors for the distributed solution/mode are described in 
>> draft-li-dynamic-flooding. 
>>For example, there are a few of places from page 27 to 30, which define the 
>>behaviors specific 
>>for the distributed solution/mode.
>
>I strongly disagree. The fact that we say in centralized mode area leader 
>recomputes and in distributed 
>mode all nodes recompute make no difference in behavior.

[HC] It seems better for some of them to be more general. 

Best Regards,
Huaimo

>thanks,
>Peter

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

Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

[Huaimo Chen]

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 [Re: Flooding Reduction Draft Redux]

Hi Huaimo,

On 03/02/2019 17:58 , Huaimo Chen wrote:
> Hi Acee,
>
>
>
> I agree with you on keeping the signaling for two modes. The other 
> parts for the distributed solution need to be removed.

There are no "other" parts specific for the distributed solution.

[HC] Some behaviors for the distributed solution/mode are described in 
draft-li-dynamic-flooding. For example, there are a few of places from page 27 
to 30, which define the behaviors specific for the distributed solution/mode.

draft-li-dyanmic-flooding defines:

1. the signalling that is common and used by both modes 2. distribution of the 
flooding-topology, which is specific to centralized mode 3. common behavior of 
the nodes that support the extension, which is independent of the mode of 
operation.

[HC] In addition to these, draft-cc-lsr-flooding-reduction defines more, 
including concrete protections, operations, and algorithms for computing a 
flooding topology.

Best Regards,
Huaimo

thanks,
Peter


>
>
>
> 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
> *Subject:* Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft 
> Redux]
>
>
>
> Hi Huaimo,
>
>
>
> See inline.
>
>
>
> *From: *Lsr mailto:lsr-boun...@ietf.org>> on 
> behalf of Huaimo Chen  <mailto:huaimo.c...@huawei.com>>
> *Date: *Saturday, February 2, 2019 at 12:27 AM
> *To: *Christian Hopps mailto:cho...@chopps.org>>, 
> "lsr@ietf.org <mailto:lsr@ietf.org>"  <mailto:lsr@ietf.org>>
> *Subject: *Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft 
> Redux]
>
>
>
> Hi Everyone,
>
>
>
> We proposed the distributed solution first, and Tony proposed the 
> centralized solution first. Tony added the distributed solution 
> (except for the algorithms to compute flooding topology) into his 
> draft. And then we added the centralized solution into our draft. The 
> latest versions of the two drafts have largely converged at least at 
> the high level to a solution for solving the same problem.
>
>
>
> Our draft has multiple key technical advantages over Tony's draft as 
> we described in our email to the LSR list, which are summarized below:
>
> 1.   It uses a fraction of flooding resource (i.e., it is multiple
> times more efficient in flooding topology encoding);
>
> 2.   It provides fault tolerance to multiple failures, minimizing
> impact on network convergence, thus minimizing traffic lose; and
>
> 3.   It is simpler and needs less processing time (i.e., faster and
> more efficient) in multiple scenarios.
>
> Based on the technical merits, our draft should be moved forward.
> However, Chair proposed to move Tony's draft forward and have us work 
> on a distributed algorithm as we started with.
>
>
>
> I think that the distributed solution in Tony's draft needs to be 
> removed and they work on the centralized solution. We remove the 
> centralized solution from our draft and work on the distributed solution.
>
>
>
> I'm against "cutting the baby in half" given that the signaling for 
> the distributed solution is a proper subset of what is required for 
> the centralized solution. It is undesirable to have different 
> signaling for the two modes. For the distributed algorithm you are 
> proposing, do see problems with the signaling?
>
>
>
> Thanks,
>
> Acee
>
>
>
> Best Regards,
>
> Huaimo
>
>
>
> -Original Message-
>
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
>
> Sent: Friday, February 1, 2019 7:26 AM
>
> To: lsr@ietf.org <mailto:lsr@ietf.org>
>
> Cc: cho...@chopps.org <mailto:cho...@chopps.org>
>
> Subject: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]
>
>
>
>
>
> Summary of where we are at with dynamic flooding reduction:
>
>
>
> - We have a well written original work that came first and described 
> the problems as well as a TLVs to allow for a centralized solution 
> (draft-li-dyanmic-flooding). We do not need to standardize the 
> centralized algorithm.
>
>
>
> - A small change to this work allowed for distributed algorithms and 
> for outside work on distributed algorithms to continue in parallel.

Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

[Huaimo Chen]

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
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

Hi Huaimo,

See inline.

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
Huaimo Chen mailto:huaimo.c...@huawei.com>>
Date: Saturday, February 2, 2019 at 12:27 AM
To: Christian Hopps mailto:cho...@chopps.org>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]


Hi Everyone,



We proposed the distributed solution first, and Tony proposed the centralized 
solution first. Tony added the distributed solution (except for the algorithms 
to compute flooding topology) into his draft. And then we added the centralized 
solution into our draft. The latest versions of the two drafts have largely 
converged at least at the high level to a solution for solving the same problem.



Our draft has multiple key technical advantages over Tony’s draft as we 
described in our email to the LSR list, which are summarized below:

1.   It uses a fraction of flooding resource (i.e., it is multiple times 
more efficient in flooding topology encoding);

2.   It provides fault tolerance to multiple failures, minimizing impact on 
network convergence, thus minimizing traffic lose; and

3.   It is simpler and needs less processing time (i.e., faster and more 
efficient) in multiple scenarios.

Based on the technical merits, our draft should be moved forward. However, 
Chair proposed to move Tony’s draft forward and have us work on a distributed 
algorithm as we started with.



I think that the distributed solution in Tony’s draft needs to be removed and 
they work on the centralized solution. We remove the centralized solution from 
our draft and work on the distributed solution.



I’m against “cutting the baby in half” given that the signaling for the 
distributed solution is a proper subset of what is required for the centralized 
solution. It is undesirable to have different signaling for the two modes. For 
the distributed algorithm you are proposing, do see problems with the signaling?



Thanks,

Acee



Best Regards,

Huaimo



-Original Message-

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps

Sent: Friday, February 1, 2019 7:26 AM

To: lsr@ietf.org<mailto:lsr@ietf.org>

Cc: cho...@chopps.org<mailto:cho...@chopps.org>

Subject: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]





Summary of where we are at with dynamic flooding reduction:



- We have a well written original work that came first and described the 
problems as well as a TLVs to allow for a centralized solution 
(draft-li-dyanmic-flooding). We do not need to standardize the centralized 
algorithm.



- A small change to this work allowed for distributed algorithms and for 
outside work on distributed algorithms to continue in parallel.



- We have another original work that started primarily as a distributed 
algorithm

   (draft-cc-ospf-flooding-reduction)



- Finally we also have:

   - Cross-pollination of ideas.

   - Failed attempts at merging.

   - An authors list "Arms-Race".



Moving forward:



- During IETF 103 I proposed we have no conflict if we:



   1) adopt draft-li-lsr-dyanmic-flooding as the base WG document.

   2) have authors of draft-cc-lsr-flooding-reduction work on a distributed 
algorithm as they started with.



- Acee agreed during the meeting (as chair) that this was the best way forward. 
We had some agreement form the floor as well..



- Any good ideas regarding the distribution of a centralized topology can be 
debated and added (with appropriate attribution) to the base document after we 
adopt one.



- This is what happens when we adopt a document as WG work, we work on it.



- The original authors of the distributed solution can continue to work on 
their distributed algorithm in a separate document which would also need 
standardization.



Does anyone see a serious problem with this path forward?



Thanks,

Chris & Acee.

LSR Chairs.



Christian Hopps mailto:cho...@chopps.org>> writes:



> We've had the authors of the individual conflicting drafts take a shot at 
> merging their work.

>

>This has failed.

>

> Here is the full history (which I also summarized during IETF103 as well). I 
> will send a second email discussing this.

>

> - Jan 2, 2018 Publication: draft-li-dynamic-flooding and 
> drfat-li-dynamic-flooding-isis

>   published centralized solution.

>

> - Mar 5, 2018 Publication: draft-cc-isis-flooding-reduction and 
> draft-cc-ospf-flooding-reduction

>   published dis

Re: [Lsr] Min Links for Multiple Failures on Flooding Topology

[Huaimo Chen]

Hi Tony,

The algorithm/procedure proposed is to determine the exact links on a backup 
path for a failure on the FT.
For example, for the failure of a link between node A and node B on the FT, the 
backup path for the link computed is deterministic and the same even though 
there are many links attached to every node. The start point and end point of 
the backup path are deterministic, and are the node with smaller ID and the 
node with larger ID respectively. The backup path is the path with minimum 
number of hops from the start point to the end point, wherein whose links are 
not on the FT. When there  are multiple paths with the same minimum number of 
hops, only one of them is selected deterministically.
Since the nodes on the backup path for the failed link get this same backup 
path and enable the temporary flooding over the links on the path,  this path 
connects the two end 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
Subject: Re: [Lsr] Min Links for Multiple Failures on Flooding Topology


Hi Huaimo,

Thank you for your note.  I have many questions, please see inline.



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 minimum number of links, and is 
triggered by the multiple failures.
When the multiple failures on the FT occur, a backup path for each of the 
failures is computed, wherein the links on the backup path are not on the FT. 
The links on the backup path are temporarily added to the FT (i.e., the 
temporary flooding is enabled on the links on the backup path). Thus the split 
FT is connected by the backup paths.
When any node N detects the multiple failures on the FT, it computes a backup 
path for each of the failures. If it (i.e., node N) is on the backup path, it 
adds its local links (e.g., local link L1 and L2) on the backup path to the FT 
temporarily; otherwise, it does not do anything.

What you seem to be suggesting here is a distributed algorithm. Each node is 
going to do this computation independently.  In a dense network, there are 
going to be many possible ways of repairing the flooding topology.  For 
example, if the base topology is a complete graph (e.g., a full mesh), then 
every node in the graph can provide at least one link that will help restore 
the flooding topology.  Which ones should be used?

We agree that some links should be enabled, and that’s what’s currently in the 
draft.

We do not today have a constructive algorithm to select exactly which links to 
enable. If you have such an algorithm, that would be a welcome contribution.

A centralized algorithm for this is hard because the FT is partitioned. While 
we could do some computation, we could only easily communicate that to one 
partition of the FT.

A distributed algorithm that does not enable unnecessary links also seems hard. 
How do all nodes make this same decision?

Even a first order approximation to a solution would be an improvement.  But we 
very much need specifics. And the algorithm needs to address general topologies.


For a failure on the FT, the backup path computed by any node N needs to be the 
same. Suppose that the two end nodes of a failed link L on the FT is A and B, 
and A's ID is smaller than B's.  Node N computes a path from A to B with 
minimum hops and whose links are not on the FT. This path is a backup path for 
link L. When every node on the backup path computes a backup path in this way 
in parallel, the same backup path is obtained, and used to fix the FT split.

In most dense topologies, we should be able to repair the FT with the addition 
of a single link. Thus, we have many single hop candidates.  Which one do we 
select?

Since we have had at least a double failure, we know that two links have 
failed. Without loss of generality, suppose that these were the links AB and 
CD.  Suppose that there are no other paths between A and B that are not on the 
FT already, but that the link AD would repair things.  How do we find and agree 
on that link?

Tony

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

Re: [Lsr] Min Links for Multiple Failures on Flooding Topology

[Huaimo Chen]

Hi Tony,

Computing a whole backup path between two end nodes of a failure and enabling 
temporary flooding at each hop of the path will guarantee that these two end 
nodes are connected on the FT, thus the FT partition caused by multiple 
failures is fixed.


The backup path is not a guarantee.  Consider the case of other link or node 
failures along the backup path.  In particular, consider the case when the 
destination node failed.  There will be no working backup path.  In fact, 
everything along the computed backup path may have failed.

Consider the case that the multiple failures occur at almost the same time and 
there is no other failure following these multiple failures shortly. In this 
case, the backup paths will connect the live end nodes of the failures on the 
FT, and the FT partition is fixed. Note that we assume that the real network 
topology is not split. So there will be working backup paths that connect the 
FT partitions.

For the case that the multiple failures occur at almost the same time and then 
other failures happen following the (old) multiple failures shortly, we can 
consider all these failures (i.e., the old multiple failures and the other 
failures including destination node failure) as new multiple failures. For 
these new multiple failures, the backup paths for all these failures will 
connect the live end nodes of the failures on the FT, and the FT partition is 
fixed.


Enabling temporary flooding on a link attached to one or each of the two end 
nodes may not connect the two end nodes of the failure on the FT in some cases 
when the backup path has multiple hops, thus may not fix the FT partition 
created by multiple failures.


It’s true that just adding one link may not heal the partition.  This is 
exactly why we feel we need to iterate.  Each iteration increases the size of 
the partition (or decreases the cut set, depending on how you want to look at 
it) and because the graph is finite, we are guaranteed to converge.

The convergence in this way may take a long time.
Each iteration takes a time Ti. If we need n (n > 1) iterations, then the total 
time for convergence is n times Ti. For centralized flooding reduction, Ti is 
the time including three parts: 1) for the link states (i.e., LSPs or LSAs) 
representing some of the multiple failures to travel to the area leader in the 
network over the 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: Sarah Chen ; lsr@ietf.org
Subject: Re: [Lsr] Min Links for Multiple Failures on Flooding Topology


Hi Huaimo,


Computing a whole backup path between two end nodes of a failure and enabling 
temporary flooding at each hop of the path will guarantee that these two end 
nodes are connected on the FT, thus the FT partition caused by multiple 
failures is fixed.


The backup path is not a guarantee.  Consider the case of other link or node 
failures along the backup path.  In particular, consider the case when the 
destination node failed.  There will be no working backup path.  In fact, 
everything along the computed backup path may have failed.



Enabling temporary flooding on a link attached to one or each of the two end 
nodes may not connect the two end nodes of the failure on the FT in some cases 
when the backup path has multiple hops, thus may not fix the FT partition 
created by multiple failures.


It’s true that just adding one link may not heal the partition.  This is 
exactly why we feel we need to iterate.  Each iteration increases the size of 
the partition (or decreases the cut set, depending on how you want to look at 
it) and because the graph is finite, we are guaranteed to converge.

Partition repair in the face of imperfect and insufficient information is a 
hard problem. We shouldn’t be expecting a closed form solution.

Tony

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

Re: [Lsr] Min Links for Multiple Failures on Flooding Topology

[Huaimo Chen]

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….prefaced with DA>


1)  The alternate backup path would appear to also require the criteria of 
being link diverse with the FT if the goal is to protect against multiple 
failures.

[HC]: Can you give some more details about this?
[DA] There is a bit of a chain of logic I did not well elucidate…
If we have an FT sufficient to be complete in the presence of any single 
failure, AND if we have a multiple failures situation such that the FT has been 
partitioned, and the information at any node is incomplete, then IMO the 
heuristic to attempt a blind repair with the highest probability of success is 
to
a)   Assume any observed failure is the worst possible class of failure 
(e.g. node, as if the FT is severed the surrounding nodes will only see one or 
some of the LSAs associated with the node failure).
b)  Attempt to restore using links that are not part of the FT as if I 
assume the probability of multiple failures decreases exponentially in 
proportion to the number of simultaneous failures, it has a higher probability 
of success….
On reflection ‘b’ seems too simplistic, and does not reflect that some 
knowledge of what parts of the FT survive in the partition the node 
contemplating restoration is in, would be available for decision making.  And 
the fact that the concept of path as a response to the failure scenario being 
discussed IMO is not realistic (I elaborate a bit below).

[HC2]: Consider the case that there are failures of two links and these two 
links are on the FT and the FT is split by these two failures and no other 
failures follow shortly. In this case, every node has the information about the 
normal/real network topology before the failures, and the indications about 
these two failures. Based on this information, the backup paths for these two 
failures can be computed and enabled for temporary flooding. Thus the FT 
partition is fixed.
If the backup path for one failure on the FT does not share any link with the 
backup path for the other failure on the FT (Note that this can be achieved 
through using diverse links when computing backup paths), the backup paths can 
also survive the failure of any other link that is not on the FT and happens at 
almost the same time as the two failures of the two links on the FT.
Consider the case that there is another failure of one link on the FT in 
addition to these two failures. This failure is on one partition of the FT and 
not on the other partition. In this case, the information about the other 
failure will flood through the backup paths. Moreover, the backup path for the 
other failure is computed and enabled for temporary flooding in its partition. 
The information about the two failures will food through this backup path. Thus 
the topology is converged quickly.
In order to speed up the convergence further, we may increase the connectivity 
on the FT when there are failures on the FT to let every node have more 
information about failures. In one way, when a link attached to a node fails 
and the link is on the FT, we find another link attached to the node and not on 
the FT, and add it to the FT temporarily. In another way, only after two or 
more failures on the FT happen, for a link attached to a node that is on the FT 
and fails, we find another link attached to the node and not on the FT, and add 
it to the FT temporarily.


2)  If node failures are considered, I’m not sure what criteria is used to 
deem a backup path as useful…..

[HC]: Regarding to the failure of a node X on the FT, suppose that there are 
multiple (i.e., two or more) nodes that were connected to the failed node X 
through the links on the FT. For each pair of these multiple nodes, a backup 
path between this pair is computed and enabled for temporary flooding. Thus the 
backup paths will connect these multiple nodes on the FT, and the FT partition 
caused by multiple failures including the failure of node X is fixed through 
the backup paths for the failed node X and the backup paths for the other 
failures.

For example, if the failed node X was connected to two nodes Ri and Rj (assume 
that Ri’s ID < Rj’s ID) by the links on the FT before node X fails, there is 
only one pair of nodes: (Ri, Rj). A unique backup path from Ri to Rj is 
computed and enabled for temporary flooding. This backup path will connect Ri 
and Rj on the FT and fix the FT partition caused by multiple failures with the 
backup paths for the other failures.

In another example, if the failed node X was connected to three nodes Ri, Rj 
and Rk (assume that Ri’s ID < Rj’s ID < Rk’s ID) by the links on the FT before 
node X fails, there are three pairs of nodes: (Ri, 

Re: [Lsr] Min Links for Multiple Failures on Flooding Topology

[Huaimo Chen]

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 Multiple Failures on Flooding Topology
>
>Hi
>
>A couple of quick observations….
>
1)  The alternate backup path would appear to also require the criteria of 
being link diverse with the FT if the goal is to protect against multiple 
failures.

[HC]: Can you give some more details about this?

2)  If node failures are considered, I’m not sure what criteria is used to 
deem a backup path as useful…..

[HC]: Regarding to the failure of a node X on the FT, suppose that there are 
multiple (i.e., two or more) nodes that were connected to the failed node X 
through the links on the FT. For each pair of these multiple nodes, a backup 
path between this pair is computed and enabled for temporary flooding. Thus the 
backup paths will connect these multiple nodes on the FT, and the FT partition 
caused by multiple failures including the failure of node X is fixed through 
the backup paths for the failed node X and the backup paths for the other 
failures.

For example, if the failed node X was connected to two nodes Ri and Rj (assume 
that Ri’s ID < Rj’s ID) by the links on the FT before node X fails, there is 
only one pair of nodes: (Ri, Rj). A unique backup path from Ri to Rj is 
computed and enabled for temporary flooding. This backup path will connect Ri 
and Rj on the FT and fix the FT partition caused by multiple failures with the 
backup paths for the other failures.

In another example, if the failed node X was connected to three nodes Ri, Rj 
and Rk (assume that Ri’s ID < Rj’s ID < Rk’s ID) by the links on the FT before 
node X fails, there are three pairs of nodes: (Ri, Rj), (Ri, Rk) and (Rj, Rk). 
A unique backup path from Ri to Rj, a unique backup path from Ri to Rk, and a 
unique backup path from Rj to Rk are computed and enabled for temporary 
flooding. These three backup paths will connect three nodes Ri, Rj and Rk on 
the FT, and fix the FT partition caused by multiple failures with the backup 
paths for the other failures.

Best Regards,
Huaimo

>Hope this helps
>Dave
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Min Links for Multiple Failures on Flooding Topology

[Huaimo Chen]

Hi Sarah,

Computing a whole backup path between two end nodes of a failure and enabling 
temporary flooding at each hop of the path will guarantee that these two end 
nodes are connected on the FT, thus the FT partition caused by multiple 
failures is fixed. Enabling temporary flooding on a link attached to one or 
each of the two end nodes may not connect the two end nodes of the failure on 
the FT in some cases when the backup path has multiple hops, thus may not fix 
the FT partition created by multiple failures.

Best Regards,
Huaimo
From: Sarah Chen [mailto:sarahc...@arista.com]
Sent: 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 (and R3) will find out that its 
neighbor R1 (and R2) are no longer on the FT. R0 (and R3) will then enable 
temporary flooding on R0-R1 (and R3-R2), which fixes the partition.

Thanks,
Sarah

On Thu, Apr 11, 2019 at 10:41 AM Huaimo Chen 
mailto:huaimo.c...@huawei.com>> wrote:
Hi Tony,

Thank you for your questions and comments.

An enhancement to the algorithm/procedure (described in my previous email) is 
proposed to reduce the number of links to be added to the FT temporarily for 
fixing possible FT split by multiple failures on the FT happening at almost the 
same time.

An example with Figures for the enhanced algorithm/procedure is shown in the 
file attached.

During the computation of a unique backup path for a failure on the FT (e.g., 
for the failure of the link R0-R2, assume that R0’s ID < R2’s ID, a unique 
backup path from R0 to R2 is to be computed), for each candidate path from the 
source (e.g., from R0), a new variable HC-FT (which is short for hop count on 
the FT) is used to record the number hops of the candidate path that are on the 
FT. The backup path computation with the enhancement is described as follows 
(note that the enhancement is underlined below):


1.Obtaining all the minimum hop count paths from the source to the 
destination (e.g., from R0 to R2), wherein each minimum hop count path has a 
HC-FT value;

2.   If there is only one minimum hop count path that has the maximum HC-FT 
value, then this path is the unique backup path; otherwise, from multiple 
backup paths that have the maximum HC-FT value, selecting the one with the 
links having smaller or smallest remote node ID along the direction from the 
destination to the source.

Best Regards,
Huaimo
From: Tony Li [mailto:tony1ath...@gmail.com<mailto:tony1ath...@gmail.com>] On 
Behalf Of tony...@tony.li<mailto:tony...@tony.li>
Sent: Wednesday, April 10, 2019 10:00 PM
To: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Min Links for Multiple Failures on Flooding Topology


Hi Huaimo,

Thank you for the example, this helps a lot.  It’s clearer and I think it will 
help illuminate many things.  Of course, it also generates more questions.

In your algorithm you’re computing the full backup path to provide connectivity 
between the previously connected nodes (e.g., R0 - R2) and not just between the 
partitioned pieces of the FT.  In this case, you would enable both R1-R2 and 
R2-R9.  Yet, all of those nodes are still connected on the FT.  Isn’t this 
inefficient?  Moreover, since we’re enabling more flooding than is necessary, 
isn’t this somewhat risky?

If we look at we’re proposing in the draft, each of R0, R1, R2, and R3 would 
recognize that they have a neighbor that is not part of their partition.  They 
would then enable temporary flooding on R0 - R1 and R2 - R3.
Either link would seem to be sufficient.  Adding both is of course more risky, 
but without global coordination, it would be difficult to optimize further.

The latter approach still seems like a simpler and more efficient solution.

Regards,
Tony


On Apr 10, 2019, at 1:29 PM, Huaimo Chen 
mailto:huaimo.c...@huawei.com>> wrote:

Hi Tony,

Thank you very much for your comments and questions.

An example with Figures for computing a unique backup path for each failure on 
FT and enabling temporary flooding on the backup path is illustrated in the 
file attached.

The algorithm/procedure is triggered when two or more failures on the FT happen 
at almost the same time.

At first, for each of the failures, a deterministic backup path is computed. 
For example, if the link between R0 and R2, and the link between R3 and R9 on 
the FT failed at almost the same time, a backup path for link R0-R2 and a 
backup path for link R3-R9 are computed.

And then, temporary flooding over the links on these backup paths are enabled. 
These backup paths fix the FT split.

(Note: In this case, one of the backup paths may be redundant. This may be 
optimized in the future if needed.)

For a failure o

Re: [Lsr] Flooding Negotiation bit

[Huaimo Chen]

Hi Tony,

There are two different cases in which a link is to be added to the FT 
temporarily.
In one case, a negotiation is needed to be done before a link is to be added to 
the FT temporarily.
In the other case, no negotiation is needed. It is determined that a link is 
added to the FT 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 Huaimo,

If I understand you correctly, this seems to have almost the same semantics as 
the Flooding Request TLV (section 5.1.5) or the Flooding Request Bit (section 
5.2.7).

If I’m not understanding you, could you please clarify the differences and why 
the current mechanisms are insufficient.

Tony



On May 14, 2019, at 1:09 PM, Huaimo Chen 
mailto:huaimo.c...@huawei.com>> wrote:

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 OSPF Hello. In IS-IS, 
the FN bit is defined in the new TLV used for FR bit.

When a node N (with 1000 interfaces/links for example) reboots, , each (node X) 
of the nodes connected to node N will establish an adjacency with node N. 
During the process of the adjacency establishment between node X and node N, 
node X sends a FN-bit set to one in its Hello to node N, node N selects one 
link/node (or a limited number of links) for temporarily flooding and sends 
only to this selected node a FN-bit set to one in its Hello. Node N adds the 
selected link/node to the FT temporarily after receiving the FT bit set to one 
from the selected node. After receiving the FN bit set to one from node N, the 
selected node adds the link (connected to node N) to the FT temporarily.
In other words, a node Y connected to node N adds the link to node N to the FT 
temporarily after it sends and receives the FT bit set to one to/from node N; 
node N adds a selected link to the FT temporarily after it receives and sends 
the FT bit set to one from/to node Y.

Best Regards,
Huaimo

 A case from Tony on 3/6 
If the node that rebooted has 1000 interfaces, which interfaces should be 
temporarily added?  Adding all of them is likely to trigger a cascade failure.  
The TLV allows us to signal which ones should be enabled.

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

[Lsr] Enhancements on flooding topology encoding

[Huaimo Chen]

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 flooding topology. The value field of a Path 
TLV contains the indexes of the nodes on the path in order from one end of the 
path to the other end of the path. The size of the index in the TLV is 16 bits. 
This may be optimized in a couple of ways.



In one way, a TLV called Node Index Size TLV is defined. Its value field of one 
octet contains an index size (i.e., a number of bits). When this TLV is 
included in an LSP/LSA containing Path TLVs, all the node indexes in the Path 
TLVs are represented using the number of bits given by the index size in the 
Node Index Size TLV. The index size is the minimum number of bits needed to 
represent the maximum node index in the Path TLVs.



In another way, 5 bits of the Reserved field in the IS-IS Area System IDs TLV 
and OSPF Area Node IDs TLV with L set to one indicates the index size that is 
used for all the node indexes in all the Path TLVs included in every LSP/LSA. 
The index size is the minimum number of bits needed to represent the maximum 
node index in the area.



In another encoding, Block TLVs are used to encode the flooding topology. A 
Block TLV represents a block of the flooding topology.  The value field of a 
Block TLV starts with 5 bits to indicate the index size, which is followed by 
the index of a local node, the number of adjacent nodes (in 3 bits), and the 
indexes of the adjacent/remote nodes of the local node. This part is similar to 
the one in a router LSA to represent the part of the topology from the local 
node to the adjacent nodes of the local node, which can be considered as a 
block of the topology in one level. This block can be extended to multiple 
levels. Each of the adjacent nodes has an extension flag bit E.  An 
adjacent/remote node with E = 1 is considered as a new local node, and its 
adjacent nodes are added. This encoding seems more efficient.



Best Regards,

Huaimo

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

Re: [Lsr] Enhancement related to Area Leader Sub-TLV

[Huaimo Chen]

Hi Tony,


Thank you for your explanations.

After moving one byte for the priority from Area Leader Sub-TLV to Dynamic 
Flooding Sub-TLV, only one Area Leader Sub-TLV is advertised. For an area with 
N nodes supporting both centralized and distributed mode, my understanding is 
below.

Before moving, each of N nodes may advertise an Area Leader Sub-TLV and a 
Dynamic Flooding Sub-TLV. After moving, only the leader node advertises a 
(Updated) Area Leader Sub-TLV. Thus (N - 1) Area Leader Sub-TLVs are saved, 
which use space of (N-1)*S1 bytes, where S1 is the size of Area Leader Sub-TLV. 
Each of N nodes may advertise a (Updated) Dynamic Flooding Sub-TLV, which has 
one extra byte for the priority. Thus N bytes are used.

The saving on space after moving should be (N-1)*S1 - N. S1 is 4 in IS-IS; 
S1 is 8 in OSPF.
For N = 1000 and IS-IS, the saving is (1000-1)*4 - 1000 = 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 Sub-TLV


Hi Huaimo,

Thank you for your proposal.

The area leader sub-tlv is only advertised by systems that are willing to be 
area leader.  Presumably, that’s not necessarily all of the ones who support 
dynamic flooding.  Thus, what you’re proposing moves one byte from one TLV into 
another TLV that will be more commonly used. So your proposal actually consumes 
more LSP space.

The intention here is that the candidates for area leader advertise the Area 
Leader Sub-TLV.  All nodes that support dynamic flooding would advertise the 
Dynamic Flooding Sub-TLV.
Since the priority is part of the Area Leader election, it makes sense for it 
to be part of the Area Leader Sub-TLV.

Regards,
Tony

p.s. IS-IS does not depend on word-alignment, so we typically do not leave 
reserved bytes in our TLV formats. OSPF is a different kettle of fish… :-)


On May 24, 2019, at 1:44 PM, Huaimo Chen 
mailto:hc...@futurewei.com>> wrote:

Hi Tony,

 An enhancement related to Area Leader Sub-TLV is briefed below for 
discussions.  A .pdf file is attached in the case that the formats below are 
messed up.


The leader of an area advertises an Area Leader Sub-TLV to indicate/instruct 
whether centralized or distributed mode is to be used by all the nodes in the 
area (Algorithm = 0: centralized mode; Algorithm = N (N>0): distributed mode 
and N is the algorithm to be used by every node to compute flooding topology).



Currently for IS-IS, IS-IS Area Leader Sub-TLV below is used by each of the 
nodes to advertise its priority for becoming the leader
0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type  | Length| Priority  |   Algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 (Current) IS-IS Area Leader Sub-TLV



It seems hard to understand that every node uses an Area Leader Sub-TLV to 
advertise its priority for becoming the leader, and at the same time to 
indicate/instruct whether centralized or distributed mode is to be used by all 
the nodes in the area.



When every node advertises an Area Leader Sub-TLV, only one for 
indication/instruction for flooding reduction mode is used, and all the others 
are not used, which consume space and processing time.



An enhancement is to let every node advertise its priority for becoming the 
leader and the algorithms that it supports though using a Dynamic Flooding 
Sub-TLV, and only the leader advertise the indication for the flooding 
reduction mode. To achieve this, some changes to the two Sub-TLVs and the texts 
related to the Sub-TLVs should be made.



For IS-IS, IS-IS Area Leader Sub-TLV is updated as follows (Priority is removed)
0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type  | Length| Reserved  |   Algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   (Updated) IS-IS Area Leader 
Sub-TLV



The Priority is added into IS-IS Dynamic Flooding Sub-TLV. The current IS-IS 
Dynamic Flooding Sub-TLV
0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type  | Length| Algorithm...  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   (Current) IS-IS Dynamic Flooding Sub-TLV



is changed 

Re: [Lsr] Enhancements on encoding of router IDs and DR IDs

[Huaimo Chen]

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
Subject: Re: [Lsr] Enhancements on encoding of router IDs and DR IDs

Hi Huaimo,

thanks for the suggestion, I think it's good one to include.

One side effect of your proposal is that when the new ID or DR ID is
inserted, it may cause other IDs/DR IDs to change their index, as you
can not assume you can simply add to the end of the list anymore.

thanks,
Peter


On 23/05/2019 20:47 , Huaimo Chen wrote:
> Hi Tony,
>
>
> Enhancements on encoding the IDs are described below for
> discussions.  A .pdf file is attached in the case that the formats below
> are messed up.
>
>
> Currently for OSPFv2, OSPFv2 Area Router IDs TLVs are used to represent
> a sequence of router IDs or DR IDs (addresses). Each of IDs is encoded
> as an OSPFv2 Router IDs TLV Entry of 8 bytes.
>
> 0   1   2   3
>
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>|  Conn Type|Reserved   |
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>| Originating Router ID/DR Address (4 bytes)|
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>  (Current) OSPFv2 Router IDs TLV Entry
>
>
>
> To represent N router IDs or DR addresses, we need N entries, which
> occupies 8*N bytes in the OSPFv2 Area Router IDs TLVs.  Each entry
> represents just only one router ID or DR address.
>
>
>
> An enhancement below is to allow one entry to represent a number of
> router IDs or a number of DR addresses. This can be achieved by using
> two bytes of the Reserved field to indicate the number M of router IDs
> or a number of DR addresses contained in the entry.  The value of the
> two bytes can be the number of IDs/Addresses (i.e., M) or the number of
> octets used (i.e., 4*M). The former is preferred.
>
>
>
> 0   1   2   3
>
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>|  Conn Type|  NumberOfIDs (M)  |   Reserved|
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>|   1st Originating Router ID/DR Address (4 bytes)  |
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>|   2nd Originating Router ID/DR Address (4 bytes)  |
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>|   |
>
>~. . . . . .~
>
>|   |
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>|   M-th Originating Router ID/DR Address (4 bytes) |
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>   (Enhanced) OSPFv2 Router IDs TLV Entry
>
>
>
> To represent N router IDs or N DR addresses using the enhanced entry, we
> need just one or a few entries. Using X entries occupies 4*(N + X) bytes
> in the OSPFv2 Area Router IDs TLVs.
>
>
>
> Consider the case where there are 1000 routers in an area. To represent
> 1000 router IDs,
>
> Using the current OSPFv2 Router IDs TLV Entries occupies 8*1000 = 8000
> bytes;
>
> Using the enhanced OSPFv2 Router IDs TLV Entries occupies 4*(1000 + 1) =
> 4004 bytes.
>
> 8000/4004 = 1..998. The saving on space is about 50% in this case.
>
>
>
> Similarly for OSPFv3, OSPFv3 Area Router IDs TLVs are used to represent
> a sequence of router IDs or DR IDs. Each of router IDs is encoded as an
> OSPFv3 Router IDs TLV Entry of 8 bytes.  Each of DR IDs is encoded as an
> OSPFv3 Router IDs TLV Entry of 12 bytes.
>
>
>
>0   1   2   3
>
>0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>   | 

Re: [Lsr] Enhancement related to Area Leader Sub-TLV

[Huaimo Chen]

Hi Les,


It seems that it is OK for only the leader advertises Area Leader sub-TLV. 
After the old/current leader is down, a new leader will be elected and the new 
leader will advertises Area Leader sub-TLV.


After moving priority (one byte) from Area Leader sub-TLV to Dynamic 
Flooding Sub-TLV, the saving on space when every node advertises a priority is 
(N-1)*S1 – N, where N is the number of nodes in the area, S1 is the size of 
Area Leader Sub-TLV. S1 is 4 in IS-IS; S1 is 8 in OSPF.  For N = 1000 and 
IS-IS, the saving is (1000-1)*4 - 1000 = 2996 (bytes). For N = 1000 and OSPF, 
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
Subject: RE: Enhancement related to Area Leader Sub-TLV


Huaimo –



It is highly undesirable that there only be one Area Leader sub-TLV 
advertisement. The latest version of the draft (V2) highlights this. Please see 
https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-02#section-6.8.10<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-lsr-dynamic-flooding-02%23section-6.8.10=02%7C01%7Chchen%40futurewei.com%7C87445d2f426045f3417a08d6e37fd84a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636946535570312948=QxjYmBay0G6mMHqaxUWARJDcpkOsv1tTphJCze%2FcwJs%3D=0>



You have also not responded to Tony’s point that we do not expect ALL nodes to 
advertise Area Leader Sub-TLV – which means the savings you calculate below 
isn’t real.



   Les





From: Lsr  On Behalf Of Huaimo Chen
Sent: Monday, May 27, 2019 7:50 PM
To: tony...@tony.li
Cc: lsr@ietf.org
Subject: Re: [Lsr] Enhancement related to Area Leader Sub-TLV



Hi Tony,



Thank you for your explanations.



After moving one byte for the priority from Area Leader Sub-TLV to Dynamic 
Flooding Sub-TLV, only one Area Leader Sub-TLV is advertised. For an area with 
N nodes supporting both centralized and distributed mode, my understanding is 
below.



Before moving, each of N nodes may advertise an Area Leader Sub-TLV and a 
Dynamic Flooding Sub-TLV. After moving, only the leader node advertises a 
(Updated) Area Leader Sub-TLV. Thus (N - 1) Area Leader Sub-TLVs are saved, 
which use space of (N-1)*S1 bytes, where S1 is the size of Area Leader Sub-TLV. 
Each of N nodes may advertise a (Updated) Dynamic Flooding Sub-TLV, which has 
one extra byte for the priority. Thus N bytes are used.



The saving on space after moving should be (N-1)*S1 - N. S1 is 4 in IS-IS; 
S1 is 8 in OSPF.

For N = 1000 and IS-IS, the saving is (1000-1)*4 - 1000 = 2996 (bytes)

For N = 1000 and OSPF, the saving is (1000-1)*8 - 1000 = 6992 (bytes)

Best Regards,

Huaimo



From: Tony Li mailto:tony1ath...@gmail.com>> on behalf 
of tony...@tony.li<mailto:tony...@tony.li> 
mailto:tony...@tony.li>>
Sent: Friday, May 24, 2019 4:56 PM
To: Huaimo Chen
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: Enhancement related to Area Leader Sub-TLV





Hi Huaimo,



Thank you for your proposal.



The area leader sub-tlv is only advertised by systems that are willing to be 
area leader.  Presumably, that’s not necessarily all of the ones who support 
dynamic flooding.  Thus, what you’re proposing moves one byte from one TLV into 
another TLV that will be more commonly used. So your proposal actually consumes 
more LSP space.



The intention here is that the candidates for area leader advertise the Area 
Leader Sub-TLV.  All nodes that support dynamic flooding would advertise the 
Dynamic Flooding Sub-TLV.

Since the priority is part of the Area Leader election, it makes sense for it 
to be part of the Area Leader Sub-TLV.



Regards,

Tony



p.s. IS-IS does not depend on word-alignment, so we typically do not leave 
reserved bytes in our TLV formats. OSPF is a different kettle of fish… :-)





On May 24, 2019, at 1:44 PM, Huaimo Chen 
mailto:hc...@futurewei.com>> wrote:



Hi Tony,



 An enhancement related to Area Leader Sub-TLV is briefed below for 
discussions.  A .pdf file is attached in the case that the formats below are 
messed up.



The leader of an area advertises an Area Leader Sub-TLV to indicate/instruct 
whether centralized or distributed mode is to be used by all the nodes in the 
area (Algorithm = 0: centralized mode; Algorithm = N (N>0): distributed mode 
and N is the algorithm to be used by every node to compute flooding topology).



Currently for IS-IS, IS-IS Area Leader Sub-TLV below is used by each of the 
nodes to advertise its priority for becoming the leader

0   1   2   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[Lsr] Enhancement on LSDB re-synchronization in Flooding Reduction

[Huaimo Chen]

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 the adjacency between two end nodes over 
link L is already there and their LSDBs are the same in most of situations, the 
full LSDB re-synchronization is executed, which consumes the power for 
processing IGP messages and the link bandwidth for transferring IGP messages. 
This may cause some issues if some links are added to the FT frequently.

Considering the cases where the LSDBs may be out of synchronization around 
the time period from a link on the current FT down to link L added to the FT 
for some reason such as a new FT computation. This period should be short in 
general.

Method A: Let one end node of link L send the other end node the LSP/LSAs 
that are changed during the time period.

In general, the LSDBs are mostly synchronized among some nodes (i.e., the 
number of LSP/LSAs changed is mostly zero) when link L not on the FT is added 
to the FT. In this case, Method A almost does nothing, i.e., there is no link 
state with changes that needs the end node to send its adjacent node over link 
L.

Method B: Combine the current method with Method A. If the number of 
LSP/LSAs that are changed is small, then use Method A; otherwise, use the 
current method.

Best Regards,
Huaimo

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

Re: [Lsr] Enhancement related to Area Leader Sub-TLV

[Huaimo Chen]

Hi Tony,


After moving, it seems OK for only the leader advertises a (Updated) Area 
Leader Sub-TLV. After the old/current leader dies, a new leader will be elected 
and the new leader will advertises a (Updated) Area Leader Sub-TLV.


Since the other nodes do not advertise any Area 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: Enhancement related to Area Leader Sub-TLV


Hi Huaimo,


Before moving, each of N nodes may advertise an Area Leader Sub-TLV and a 
Dynamic Flooding Sub-TLV. After moving, only the leader node advertises a 
(Updated) Area Leader Sub-TLV.


The Area Leader sub-TLV should be advertised by all nodes that are candidates 
to being Area Leader.  Strictly speaking, you could choose only one, but that 
would become a single point of failure.  For simple redundancy, two seems a 
practical minimum, however it still seems somewhat risky due to the possible 
loss of an Area Leader after a multi-failure partition. Thus, it is likely that 
all N nodes will continue to advertise the Area Leader sub-TLV.

Since no sub-TLVs are withdrawn, there is no space savings.

Tony

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

Re: [Lsr] Enhancements on flooding topology encoding

[Huaimo Chen]

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 topology encoding


Hi Huaimo,

Thank you for the interesting numbers, but without some understanding of the 
experiment that you’re performing, we have no way of understanding the point 
that you’re trying to make.

If we are to make a change, we need to all understand and agree that there is 
an improvement and that the improvement is worthwhile in terms of complexity 
vs. gain.

The block encoding that you have proposed seems to require at least one TLV for 
every other node in a path and thus seems like an extremely inefficient way of 
encoding a topology. If you have ways of using this efficiently, please explain.

[HC] There is no such requirement. A block of FT (maybe a whole FT) can be 
encoded in a Block TLV. A path can be considered as a special block of FT and 
encoded in a Block TLV.

Compressing the path TLV into a bit stream (similar to encoding B) has been 
proposed, but to date we have not bit off on that complexity.  As noted, the 
savings that you get decrease with scale, which is unfortunate because at scale 
is when we need it.  So far, the consensus seems to be that this is not worth 
the effort.

[HC] It seems that there is no issue on scale.

Regards,
Tony



On May 29, 2019, at 8:05 AM, Huaimo Chen 
mailto:hc...@futurewei.com>> wrote:

Hi Tony,


For the three encodings below,

  *   Encoding A: Plain Path TLVs, where each node index uses 2 bytes,
  *   Encoding B: Compact Path TLVs, where each of node indexes in Path TLVs 
has the same size given by a field in the Area Node IDs TLV with L set to one, 
which is the size (in bits) of the maximum node index value,
  *   Encoding C:  Block TLVs,

it seems that C is more efficient than A and B in general, B is more efficient 
than A.
For example, for representing 63 nodes flooding topology (FT for short) of a 
binary tree in IS-IS, some comparisons among three encodings are listed in the 
table below (In case that the formats may be messed up, a .pdf file is 
attached).

Encoding
Bytes used
Comparisons
A (Plain Path TLVs)
248
179/248 = 0.72 (72%)
B (Compact Path TLVs)
179
121/179 = 0.68 (68%)
C (Block TLVs)
121
121/248 = 0.49 (49%)



From the table, we can see that 248, 179 and 121 bytes are used for 
representing the FT by A, B and C respectively. 121/248 = 0.49 (49%) means that 
C uses about 49% of the flooding resource that A uses. 121/179 = 0.68 (68%) 
means that C uses about 68% of the flooding resource that B uses. 179/248=0.72 
(72%) means that B uses about 72% of the flooding resource that A uses.

From this example, we can see that C is more efficient than A and B, and B 
is more efficient than A.


Best Regards,
Huaimo
From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of 
tony...@tony.li<mailto:tony...@tony.li>
Sent: Wednesday, May 15, 2019 11:55 AM
To: Huaimo Chen 
Cc: lsr@ietf.org
Subject: Re: Enhancements on flooding topology encoding





Hi Huaimo,





In one way, a TLV called Node Index Size TLV is defined. Its value field of one 
octet contains an index size (i.e., a number of bits). When this TLV is 
included in an LSP/LSA containing Path TLVs, all the node indexes in the Path 
TLVs are represented using the number of bits given by the index size in the 
Node Index Size TLV. The index size is the minimum number of bits needed to 
represent the maximum node index in the Path TLVs.





Yes, Tony P. also made this suggestion quite some time ago in a private 
communication.  We also observed that no separate signaling of the size is 
actually needed, as each node can look at the number of indices listed in the 
Node Id TLV and take ceil(log2(# nodes)) and use that many bits for each index.



In another way, 5 bits of the Reserved field in the IS-IS Area System IDs TLV 
and OSPF Area Node IDs TLV with L set to one indicates the index size that is 
used for all the node indexes in all the Path TLVs included in every LSP/LSA. 
The index size is the minimum number of bits needed to represent the maximum 
node index in the area.





Yes, you could do that too.  That’s for ‘free’, assuming that you agree that 
the L bit is required.






In another encoding, Block TLVs are used to encode the flooding topology. A 
Block TLV represents a block of the flooding topology.  The value field of a 
Block TLV starts with 5 bits to indicate the index size, which is followed by 
the index of a local node, the number of adjacent nodes (in 3 bits), and the 
indexes of the adjacent/remote nodes of the local node. This part is similar to 
the one in a router LSA to represent the part of the topology from the local 
node to the adjacent nodes of the local node, which can be considered as a 
block of the topology 

Re: [Lsr] WG Adoption Call: draft-ginsberg-lsr-isis-invalid-tlv

[Huaimo Chen]

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: draft-ginsberg-lsr-isis-invalid-tlv

This begins a 2 week WG adoption call for draft-ginsberg-lsr-isis-invalid-tlv.

https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ginsberg-lsr-isis-invalid-tlv%2Fdata=02%7C01%7Chuaimo.chen%40futurewei.com%7C88eb42ba71024bb7e13c08d6f49d99ad%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636965355070363476sdata=hk3vvtIpbb%2Fn3V7xz3935WueTXM1jUlUprXNFk9bpMI%3Dreserved=0

Please express your support or non-support.

Authors: Please indicate your knowledge of any IPR related to this work to the 
list as well.

Thanks,
Chris & Acee.


___
Lsr mailing list
Lsr@ietf.org
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsrdata=02%7C01%7Chuaimo.chen%40futurewei.com%7C88eb42ba71024bb7e13c08d6f49d99ad%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636965355070363476sdata=UJfU1d2EuftancUgOqf9nNGtQ4F6orO0qcFCtqj6%2FGo%3Dreserved=0

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

[Lsr] Flooding Negotiation bit

[Huaimo Chen]

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 OSPF Hello. In IS-IS, 
the FN bit is defined in the new TLV used for FR bit.

When a node N (with 1000 interfaces/links for example) reboots, , each (node X) 
of the nodes connected to node N will establish an adjacency with node N. 
During the process of the adjacency establishment between node X and node N, 
node X sends a FN-bit set to one in its Hello to node N, node N selects one 
link/node (or a limited number of links) for temporarily flooding and sends 
only to this selected node a FN-bit set to one in its Hello. Node N adds the 
selected link/node to the FT temporarily after receiving the FT bit set to one 
from the selected node. After receiving the FN bit set to one from node N, the 
selected node adds the link (connected to node N) to the FT temporarily.
In other words, a node Y connected to node N adds the link to node N to the FT 
temporarily after it sends and receives the FT bit set to one to/from node N; 
node N adds a selected link to the FT temporarily after it receives and sends 
the FT bit set to one from/to node Y.

Best Regards,
Huaimo

 A case from Tony on 3/6 
If the node that rebooted has 1000 interfaces, which interfaces should be 
temporarily added?  Adding all of them is likely to trigger a cascade failure.  
The TLV allows us to signal which ones should be enabled.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Migration between normal flooding and flooding reduction

[Huaimo Chen]

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 mode) or in reverse (i.e., roll back from the 
flooding reduction to the normal flooding) may follow a procedure of a few 
steps. One of the two procedures below may be used.



Procedure A:



1.   For each node that is eligible to become a leader for flooding 
reduction in centralized mode, a priority for the leader election is configured 
on the node. (This step is called "Priority Configuration").

2.   Every node advertises its priority for the leader election and the 
algorithms that it supports for computing flooding topology for distributed 
mode. (This step is called "Priority and Algorithms Distribution"). Note that 
this step and the step above may be considered as one step. After a priority is 
configured on a node, the node will advertises its priority and algorithms.

3.   On the node that will be elected as the leader, "Start Leader 
Election" is configured. The node does the leader election after obtaining 
"Start Leader Election". It also advertises this to all the other nodes in the 
area. Each of them will do the leader election after receiving this. (This step 
is called "Leader Election"). Note that this step may be removed. Without this 
step, the leader election may occur multiple times until the leader with the 
highest priority and highest node ID is elected if we want that the leader is 
the node that has the highest priority and highest node ID in the area.

4.   On the node that is elected as the leader, centralized mode or 
distributed mode is configured. (This step is called "Flooding Reduction Mode 
Configuration").

For centralized mode (i.e., when centralized mode is configured),

1)  the leader advertises "Flooding Reduction" in the centralized mode to 
all the other nodes;

2)  the leader computes the flooding topology and advertises the flooding 
topology to the other nodes;

3)  each node floods the link states using the flooding topology after it 
receives/has the whole flooding topology.

For distributed mode (i.e., when distributed mode is configured), an algorithm 
is also configured to be used by every node to compute flooding topology

1)  the leader advertises "Flooding Reduction" in the distributed mode 
including the algorithm to all the other nodes;

2)  each node computes its flooding topology and floods the link states 
using the flooding topology.

At this point, the IGP running in the network area has migrated from the normal 
flooding to the flooding reduction (either centralized mode or distributed 
mode).



In centralized mode, configuring distributed mode (or changing the centralized 
mode to distributed mode through configuration) will transfer from centralized 
mode to distributed mode. In addition to step 1) and 2) above for the 
distributed mode, each node uses the centralized flooding reduction (i.e.., 
floods the link states over its local links on the flooding topology computed 
by the leader of the area) until the distributed flooding reduction is fully 
functional for a given time such as 5 seconds. After this time, the node stops 
its centralized flooding reduction. The leader stops computing the flooding 
topology, advertising it to all the other routers, and using this flooding 
topology to flood the link states. Each of the other nodes stops receiving and 
building the flooding topology computed by the leader.



In distributed mode, configuring centralized mode (or changing the distributed 
mode to centralized mode through configuration) will transfer from distributed 
mode to centralized mode. In addition to step 1), 2) and 3) above for the 
centralized mode, each node uses the distributed flooding reduction (i.e., 
floods the link states over its local links on the flooding topology computed 
and built by itself) until the centralized flooding reduction is fully 
functional for a given time such as 5 seconds.
For the migration (or say roll back) from the flooding reduction to the normal 
flooding,

a.   on the leader node, "Roll Back to Normal Flooding" is configured; 
(This step is called "Roll Back to Normal Flooding Configuration").

b.   the leader advertises "Roll Back to Normal Flooding" to all the other 
nodes; (This step is called "Roll Back to Normal Flooding Distribution").

c.   every node rolls back to the normal flooding after obtaining the 
instruction for rolling back to the normal flooding. Every node will floods 
link states using all its local links instead of the local links on the 
flooding topology. (This step is called "Stop Using Flooding Topology").

For the centralized mode, after rolling back to normal flooding, the leader of 
the area stops computing and advertising the 

[Lsr] LEEF bit behavior) RE: I-D Action: draft-ietf-lsr-dynamic-flooding-01.txt

[Huaimo Chen]

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 of the flooding topology through using this bit?

For a link L between node A and node B, if the LEEF bit for link L advertised 
by node A is different from the one advertised by node B, then the flooding 
topology is inconsistent, the node receiving the LEEF bit set to one for link L 
from the other node adds link L on the flooding topology temporarily.

If one of the two nodes receives the LEEF bit set to one for link L from the 
other, but advertises the LEEF bit set to zero for link L for a given time such 
as 5 seconds, then a warning is issued or logged.


Best Regards,

Huaimo

-Original Message-

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)

Sent: Tuesday, May 21, 2019 1:56 PM

To: lsr@ietf.org

Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-dynamic-flooding-01.txt



Folks -



Major changes in this version include:



1)Added support for LANs as part of the flooding tropology



2)Added support for advertising what links are enabled for flooding at each 
node. This is based on a proposal in draft-cc-lsr-flooding-reduction (the FT 
bit) but we have defined it to be advertised associated with a link rather than 
in hellos. This is to allow management tools to more easily verify correctness 
of the flooding topology on each node. It does NOT change operational state in 
any way.



3)Added some text around rate limiting temporary flooding when attempting to 
repair a partitioned flooding topology.



Les

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

Re: [Lsr] Migration between normal flooding and flooding reduction

[Huaimo Chen]

Hi Les,

Consider the following options to transfer all nodes in an area from 
flooding reduction to normal flooding or from normal flooding to flooding 
reduction:
Option A: Go to all the nodes (if there are thousands of nodes, go to all of 
them), execute “disable flooding reduction” or “enable flooding reduction” on 
all of them.
Option B: Go to the leader (even if there are thousands of nodes, just go to 
the leader), execute “roll back to normal flooding” or “transfer to flooding 
reduction” on the leader.

Option B should be supported. Option B provides a simpler and quicker way to 
transfer between flooding reduction and normal flooding.

It seems that Option A is similar to going to all the nodes and configuring an 
algorithm to compute the FT for distributed mode; and Option B is similar to 
going to the leader and configuring an algorithm to compute the FT 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

Huaimo –

I, like Tony, am wondering what problem you are trying to solve.

Note that updated LSPs/LSAs which are received on an interface which the 
receiving node believes is NOT part of the flooding topology are NEVER 
discarded. They are processed and flooded on those interfaces which the 
receiver believes are part of the flooding topology.  So there is no need for 
the coordination you propose. The network can transition from no flooding 
optimizations to flooding optimizations – or vice versa – simply by 
enabling/disabling optimizations.

The speed at which the migration occurs is not critical. What is critical is 
that correct flooding is not compromised during the migration and (as Tony has 
noted) based on testing that works without any issues.

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Huaimo Chen
Sent: Monday, May 20, 2019 12:53 PM
To: tony...@tony.li<mailto:tony...@tony.li>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Migration between normal flooding and flooding reduction

Hi Tony,

For the case that the IGP running in an area has been doing the flooding 
reduction, in order to let the IGP on every node in the area roll back to the 
normal flooding quickly and easily, a procedure for migrating from the flooding 
reduction to normal flooding is needed. After back to normal flooding, if we 
want to let the IGP on every node do flooding reduction some time later, the 
procedure should be able to migrate from normal flooding to the flooding 
reduction quickly and easily.

Best Regards,
Huaimo
From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of 
tony...@tony.li<mailto:tony...@tony.li>
Sent: Saturday, May 18, 2019 1:17 PM
To: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Cc: lsr@ietf.org<mailto: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 Works.

You turn on dynamic flooding and the nodes with the feature start complying 
with the flooding topology.  Those that are not enabled perform legacy 
flooding. Obviously you don’t get the flooding reduction yet, but it grows 
incrementally as nodes are enabled.

What problem are you solving?

Tony



On May 18, 2019, at 8:15 AM, Huaimo Chen 
mailto:huaimo.c...@huawei.com>> wrote:

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 mode) or in reverse (i.e., roll back from the 
flooding reduction to the normal flooding) may follow a procedure of a few 
steps. One of the two procedures below may be used.

Procedure A:

1.   For each node that is eligible to become a leader for flooding 
reduction in centralized mode, a priority for the leader election is configured 
on the node. (This step is called “Priority Configuration”).
2.   Every node advertises its priority for the leader election and the 
algorithms that it supports for computing flooding topology for distributed 
mode. (This step is called “Priority and Algorithms Distribution”). Note that 
this step and the step above may be considered as one step. After a priority is 
configured on a node, the node will advertises its priority and algorithms.
3.   On the node that will be elected as the leader, “Start Leader 
Election” is configured. The node does the leader election after obtaining 
“Start Leader Election”. It also advertises this to all the other nodes in the 
area. Each of them will do the leader

Re: [Lsr] Migration between normal flooding and flooding reduction

[Huaimo Chen]

Hi Tony,

For the case that the IGP running in an area has been doing the flooding 
reduction, in order to let the IGP on every node in the area roll back to the 
normal flooding quickly and easily, a procedure for migrating from the flooding 
reduction to normal flooding is needed. After back to normal flooding, if we 
want to let the IGP on every node do flooding reduction some time later, the 
procedure should be able to migrate from normal flooding to the flooding 
reduction quickly and easily.

Best Regards,
Huaimo
From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@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 Works.

You turn on dynamic flooding and the nodes with the feature start complying 
with the flooding topology.  Those that are not enabled perform legacy 
flooding. Obviously you don’t get the flooding reduction yet, but it grows 
incrementally as nodes are enabled.

What problem are you solving?

Tony




On May 18, 2019, at 8:15 AM, Huaimo Chen 
mailto:huaimo.c...@huawei.com>> wrote:

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 mode) or in reverse (i.e., roll back from the 
flooding reduction to the normal flooding) may follow a procedure of a few 
steps. One of the two procedures below may be used.

Procedure A:

1.   For each node that is eligible to become a leader for flooding 
reduction in centralized mode, a priority for the leader election is configured 
on the node. (This step is called “Priority Configuration”).
2.   Every node advertises its priority for the leader election and the 
algorithms that it supports for computing flooding topology for distributed 
mode. (This step is called “Priority and Algorithms Distribution”). Note that 
this step and the step above may be considered as one step. After a priority is 
configured on a node, the node will advertises its priority and algorithms.
3.   On the node that will be elected as the leader, “Start Leader 
Election” is configured. The node does the leader election after obtaining 
“Start Leader Election”. It also advertises this to all the other nodes in the 
area. Each of them will do the leader election after receiving this. (This step 
is called “Leader Election”). Note that this step may be removed. Without this 
step, the leader election may occur multiple times until the leader with the 
highest priority and highest node ID is elected if we want that the leader is 
the node that has the highest priority and highest node ID in the area.
4.   On the node that is elected as the leader, centralized mode or 
distributed mode is configured. (This step is called “Flooding Reduction Mode 
Configuration”).
For centralized mode (i.e., when centralized mode is configured),
1)  the leader advertises “Flooding Reduction” in the centralized mode to 
all the other nodes;
2)  the leader computes the flooding topology and advertises the flooding 
topology to the other nodes;
3)  each node floods the link states using the flooding topology after it 
receives/has the whole flooding topology.
For distributed mode (i.e., when distributed mode is configured), an algorithm 
is also configured to be used by every node to compute flooding topology
1)  the leader advertises “Flooding Reduction” in the distributed mode 
including the algorithm to all the other nodes;
2)  each node computes its flooding topology and floods the link states 
using the flooding topology.
At this point, the IGP running in the network area has migrated from the normal 
flooding to the flooding reduction (either centralized mode or distributed 
mode).

In centralized mode, configuring distributed mode (or changing the centralized 
mode to distributed mode through configuration) will transfer from centralized 
mode to distributed mode. In addition to step 1) and 2) above for the 
distributed mode, each node uses the centralized flooding reduction (i.e., 
floods the link states over its local links on the flooding topology computed 
by the leader of the area) until the distributed flooding reduction is fully 
functional for a given time such as 5 seconds. After this time, the node stops 
its centralized flooding reduction. The leader stops computing the flooding 
topology, advertising it to all the other routers, and using this flooding 
topology to flood the link states. Each of the other nodes stops receiving and 
building the flooding topology computed by the leader.


In distributed mode, configuring centralize

Re: [Lsr] Flooding Negotiation bit

[Huaimo Chen]

Hi Les,

The problem/case is raised by Tony on 3/6.

I think that it needs to be addressed too from flooding reduction’s 
perspective.  After a node with 1K links reboots and has 1K adjacencies up to 
full states,  we should not add 1K links to the FT temporarily. “Adding all of 
them is likely to trigger a cascade failure. “ from Tony.

To address this problem, we should have a Flooding Negotiation bit. Through 
using this bit, we can add one or just a few links (from 1K links) to the FT 
temporarily after 1K adjacencies are fully formed.

It seems that the various methods you mentioned do the work and are for 
reducing the load before 1K adjacencies are fully formed.

Best Regards,
Huaimo
 A case from Tony on 3/6 
If the node that rebooted has 1000 interfaces, which interfaces should be 
temporarily added?  Adding all of them is likely to trigger a cascade failure.  
The TLV 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 to deal with the 
startup case where a node reboots, has a large number of neighbors which need 
to be formed, and if this is done all simultaneously there will be a lot of 
redundant flooding between the new node and each of its neighbors.

If so, this is a well known problem which has nothing to do with optimizing 
flooding across the network. Clever implementers have already devised 
strategies wherein neighbors are not all brought up in parallel and the use of 
various protocol mechanisms (OL bit, max-metric, the SA bit from RFC 5306) are 
used to prevent the rebooting router from being used as a transit router until 
it has fully synced with all of its neighbors.

This has nothing whatever to do with the problem being addressed in the 
flooding optimizations draft – and there are no protocol extensions required to 
address the issue. I don’t think what you propose is needed – and if it were 
needed I do not think it would belong in flooding optimizations draft.

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Huaimo Chen
Sent: Wednesday, May 15, 2019 8:07 AM
To: tony...@tony.li<mailto:tony...@tony.li>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Flooding Negotiation bit

Hi Tony,

There are two different cases in which a link is to be added to the FT 
temporarily.
In one case, a negotiation is needed to be done before a link is to be added to 
the FT temporarily.
In the other case, no negotiation is needed. It is determined that a link is 
added to the FT 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<mailto:tony...@tony.li>
Sent: Tuesday, May 14, 2019 4:31 PM
To: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: Flooding Negotiation bit


Hi Huaimo,

If I understand you correctly, this seems to have almost the same semantics as 
the Flooding Request TLV (section 5.1.5) or the Flooding Request Bit (section 
5.2.7).

If I’m not understanding you, could you please clarify the differences and why 
the current mechanisms are insufficient.

Tony


On May 14, 2019, at 1:09 PM, Huaimo Chen 
mailto:huaimo.c...@huawei.com>> wrote:

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 OSPF Hello. In IS-IS, 
the FN bit is defined in the new TLV used for FR bit.

When a node N (with 1000 interfaces/links for example) reboots, , each (node X) 
of the nodes connected to node N will establish an adjacency with node N. 
During the process of the adjacency establishment between node X and node N, 
node X sends a FN-bit set to one in its Hello to node N, node N selects one 
link/node (or a limited number of links) for temporarily flooding and sends 
only to this selected node a FN-bit set to one in its Hello. Node N adds the 
selected link/node to the FT temporarily after receiving the FT bit set to one 
from the selected node. After receiving the FN bit set to one from node N, the 
selected node adds the link (connected to node N) to the FT temporarily.
In other words, a node Y connected to node N adds the link to node N to the FT 
temporarily after it sends and receives the FT bit set to one to/from node N; 
node N adds a selected link to the FT temporarily after it receives and sends 
the FT bit set to one from/to node Y.

Best Regards,
Huaimo

 A case from Tony on 3/6 
If the node that rebooted has 1000 interfaces, which interf

Re: [Lsr] Min Links for Multiple Failures on Flooding Topology

[Huaimo Chen]

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,

Consider the case that the multiple failures occur at almost the same time and 
there is no other failure following these multiple failures shortly. In this 
case, the backup paths will connect the live end nodes of the failures on the 
FT, and the FT partition is fixed. Note that we assume that the real network 
topology is not split. So there will be working backup paths that connect the 
FT partitions.


I don’t think you can just assume that the network topology is not damaged in 
some way.  After all, the FT partitioned because of real failures.  Your 
algorithm for computing backup paths relies on old information about the 
topology of other partitions.  That information may be out of date and 
incorrect. This can lead to the paths not being viable.

[HC]: In general, using the backup paths for the failures to repair the FT 
partition works well to some extend even though the nodes in one partition have 
some information about the topology that the nodes in another partition do not 
have.

At first, it can survive two or more failures. For example, it can repair the 
FT partition created by the failures of any two links on the FT. It can also 
repair the FT partition caused by the failures of any two links on the FT and 
the failure of any other link if the algorithm for computing backup paths is 
enhanced to consider using diverse links (i.e., the backup paths are computed 
in such a way that one backup path does not share any link with the other 
backup paths if possible).

Secondly, it helps the convergence. The backup paths for a failure are created 
by the nodes close (or say local) to the failure and connect the two 
partitions. After this local repair of the FT partition, the link states in the 
two partitions are synchronized, and the topology is converged. Locally 
repairing the FT partition is faster than the repairing by the area leader.

Moreover, if one extra backup path for a failure is computed and enabled for 
temporary flooding, the FT partition created by one more failure can be 
repaired.

The network topology is damaged.  This is considered in the algorithm for 
computing backup paths.  Every node uses its LSDB for computing backup paths if 
needed. The FT is portioned, but the real network topology is not, and is used. 
For the information about a failure that is on one partition and not on another 
partition, if the part damaged by this failure is not used in any other backup 
paths, then there is no problem; otherwise (i.e., it is used in some backup 
paths), if the damaged part is used only in one backup path, the backup paths 
can survive the damaged part if that one backup path does not share any link 
with the other backup paths.

For the case that the multiple failures occur at almost the same time and then 
other failures happen following the (old) multiple failures shortly, we can 
consider all these failures (i.e., the old multiple failures and the other 
failures including destination node failure) as new multiple failures. For 
these new multiple failures, the backup paths for all these failures will 
connect the live end nodes of the failures on the FT, and the FT partition is 
fixed.


Again, how can you consider any new failures in the computation of the backup 
paths? You have no way of getting information since the FT partitioned.

[HC]: The information about the new failures will flood through the backup 
paths for the old failures if the backup paths are created. Refer to the 
explanation above.

It’s true that just adding one link may not heal the partition.  This is 
exactly why we feel we need to iterate.  Each iteration increases the size of 
the partition (or decreases the cut set, depending on how you want to look at 
it) and because the graph is finite, we are guaranteed to converge.

The convergence in this way may take a long time.


Agreed.  However, the alternatives that we have on the table right now are (a) 
take several iterations, or (b) turn on many links and risk a cascade failure.



Each iteration takes a time Ti. If we need n (n > 1) iterations, then the total 
time for convergence is n times Ti. For centralized flooding reduction, Ti is 
the time including three parts: 1) for the link states (i.e., LSPs or LSAs) 
representing some of the multiple failures to travel to the area leader in the 
network over the 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.


We agree that it is linear in the time taken to add new nodes to the topology.  
However, due to rate limiting, I suspect that the overall time is more 
constrained by the rate limit

Re: [Lsr] Min Links for Multiple Failures on Flooding Topology

[Huaimo Chen]

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] Min Links for Multiple Failures on Flooding Topology


Hi Huaimo,


What is “the existing algorithm” that you have?
Is it the “rate limiting”? If so, can you describe the “rate limiting” 
algorithm in details?


Yes.  We haven’t described it very formally, so let me see if I can be more 
precise:

On each node, in parallel:
On a topology change:
For each adjacency:
Is there a path to the adjacent node via 
the flooding topology?
If not, add it to a set of candidates.
While the set of candidates is not empty:
Remove one candidate from the set.
Temporarily add it to the flooding topology
Delay (amount is implementation defined)
If there has been another topology change:
Clear the candidate set
Restart the algorithm


Does this help?

Tony


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

Re: [Lsr] Fwd: Open issues with Dynamic Flooding

[Huaimo Chen]

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 issues with Dynamic Flooding

Huaimo -

I am aware of the other thread and the discussion you are having with Tony.
My reading of it is that you have not yet defined a deterministic solution to 
this problem - you have only defined the goal. If you do define a deterministic 
solution, that would be most welcome and we can then incorporate it in the 
Dynamic Flooding draft.

Please continue the thread w Tony.

Thanx.

   Les


> -Original Message-
> From: Huaimo Chen 
> Sent: Tuesday, April 09, 2019 8:47 AM
> To: Les Ginsberg (ginsberg) ; tony...@tony.li; 
> lsr@ietf.org
> Subject: RE: [Lsr] Fwd: Open issues with Dynamic Flooding
> 
> 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 lots of links to be added into the FT temporarily for fixing 
> the FT split. This may cause some issues.
> In another thread "[Lsr] Min Links for Multiple Failures on 
> Flooding Topology", there is a solution for fixing the FT split using 
> almost minimum number of links.
> 
> Best Regards,
> Huaimo
> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg 
> (ginsberg)
> Sent: Tuesday, April 9, 2019 11:09 AM
> To: tony...@tony.li; lsr@ietf.org
> Subject: Re: [Lsr] Fwd: Open issues with Dynamic Flooding
> 
> Tony -
> 
> Here is my take.
> 
> Regarding Issue #2 below, we had a healthy thread on this since Prague 
> and I believe have consensus that we WILL support LANs in the encoding 
> of the flooding topology (centralized mode). Authors need to agree on 
> changes to the draft which we will take offline and then publish an update.
> 
> Regarding Issue #1 below, we did have a thread on this BEFORE Prague 
> and seemed to reach consensus on:
> 
> 
> Let me propose that we add something to sections 6.7.5, 6.7.9, and 
> 6.7.11
> like:
> 
> Addition of temporary flooding should be done with caution, as the 
> addition of excessive connectivity to the flooding topology may 
> trigger unwanted behavior. Routers SHOULD add temporary flooding in a 
> rate limited manner, if not configured otherwise.
> 
> 
> 
> (See attached email)
> 
> Again, authors need to address this in the next draft revision but I 
> believe we have agreement in principle.
> 
> So I think we can consider these matters resolved - pending WG 
> feedback on the updated draft whenever it becomes available.
> 
>Les
> 
> 
> > -Original Message-
> > From: Lsr  On Behalf Of tony...@tony.li
> > Sent: Monday, April 08, 2019 7:27 AM
> > To: lsr@ietf.org
> > Subject: [Lsr] Fwd: Open issues with Dynamic Flooding
> >
> >
> > Hi all,
> >
> > It’s been another week and we’ve had a few more very interesting 
> > conversations, but we seem to have not moved very far.
> >
> > Have we converged?
> >
> > Tony
> >
> >
> >
> > > Hi all,
> > >
> > > I hope that everyone had a safe and uneventful trip home from 
> > > Prague and
> > that no one else had the seat right in front of the screaming baby.
> > ;-)
> > >
> > > I would like to re-open the discussion on the mailing list. Based 
> > > on the off-
> > line discussions that I had with folks, I believe that we’re leaning 
> > towards including the LANs in the signaling and rate limiting link 
> > addition
> during repair.
> > >
> > > Dissent? Discussion?
> > >
> > > Tony
> > >
> > >
> > >> On Mar 4, 2019, at 9:54 AM, tony...@tony.li wrote:
> > >>
> > >>
> > >> Hello,
> > >>
> > >> There are still two issues that need to be discussed and I was 
> > >> hoping that
> > we could make progress on the mailing list before Prague.
> > >>
> > >> 1) Temporary additions to the flooding topology
> > >>
> > >>   There are several cases where we would like to make temporary
> > additions to the flooding topology: repairing a partition of the 
> > flooding topology or adding a node to the base topology for the first time

Re: [Lsr] Fwd: Open issues with Dynamic Flooding

[Huaimo Chen]

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 lots of links to be added 
into the FT temporarily for fixing the FT split. This may cause some issues.
In another thread "[Lsr] Min Links for Multiple Failures on Flooding 
Topology", there is a solution for fixing the FT split using almost minimum 
number of links. 

Best Regards,
Huaimo
-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, April 9, 2019 11:09 AM
To: tony...@tony.li; lsr@ietf.org
Subject: Re: [Lsr] Fwd: Open issues with Dynamic Flooding

Tony -

Here is my take.

Regarding Issue #2 below, we had a healthy thread on this since Prague and I 
believe have consensus that we WILL support LANs in the encoding of the 
flooding topology (centralized mode). Authors need to agree on changes to the 
draft which we will take offline and then publish an update.

Regarding Issue #1 below, we did have a thread on this BEFORE Prague and seemed 
to reach consensus on:


Let me propose that we add something to sections 6.7.5, 6.7.9, and 6.7.11 like:

Addition of temporary flooding should be done with caution, as the addition of 
excessive connectivity to the flooding topology may trigger unwanted behavior. 
Routers SHOULD add temporary flooding in a rate limited manner, if not 
configured otherwise.



(See attached email)

Again, authors need to address this in the next draft revision but I believe we 
have agreement in principle.

So I think we can consider these matters resolved - pending WG feedback on the 
updated draft whenever it becomes available.

   Les


> -Original Message-
> From: Lsr  On Behalf Of tony...@tony.li
> Sent: Monday, April 08, 2019 7:27 AM
> To: lsr@ietf.org
> Subject: [Lsr] Fwd: Open issues with Dynamic Flooding
> 
> 
> Hi all,
> 
> It’s been another week and we’ve had a few more very interesting 
> conversations, but we seem to have not moved very far.
> 
> Have we converged?
> 
> Tony
> 
> 
> 
> > Hi all,
> >
> > I hope that everyone had a safe and uneventful trip home from Prague 
> > and
> that no one else had the seat right in front of the screaming baby.  
> ;-)
> >
> > I would like to re-open the discussion on the mailing list. Based on 
> > the off-
> line discussions that I had with folks, I believe that we’re leaning 
> towards including the LANs in the signaling and rate limiting link addition 
> during repair.
> >
> > Dissent? Discussion?
> >
> > Tony
> >
> >
> >> On Mar 4, 2019, at 9:54 AM, tony...@tony.li wrote:
> >>
> >>
> >> Hello,
> >>
> >> There are still two issues that need to be discussed and I was 
> >> hoping that
> we could make progress on the mailing list before Prague.
> >>
> >> 1) Temporary additions to the flooding topology
> >>
> >>   There are several cases where we would like to make temporary
> additions to the flooding topology: repairing a partition of the 
> flooding topology or adding a node to the base topology for the first time. 
> We can:
> >>
> >>   (a) Temporarily add all of the links that would appear to remedy 
> >> the
> partition. This has the advantage that it is very likely to heal the 
> partition and will do so in the minimal amount of convergence time.
> >>
> >>   (b) For each node adjacent to the partition, add no more than a 
> >> single
> link across the partition.  If that does not repair the partition in a 
> while (LSP propagation time + SPF time), then add another link.
> >>Iterate as necessary. This has the advantage that it 
> >> minimizes the risk
> of creating a cascade failure.
> >>
> >> 2) Inclusion of pseduonodes in the System IDs TLV
> >>
> >>   In the general case, a topology can include LANs. If a LAN is in 
> >> parallel
> with a P2P link, the Area Leader cannot currently distinguish between 
> the two links. This can be of importance if there are other
> >>   systems also on the LAN that should be using their LAN interface 
> >> for
> flooding.
> >>
> >>   We propose to change the System IDs TLV to include a pseudo-node 
> >> ID
> as well as the system ID.  It would also make sense to rename the TLV 
> to be the “IS-IS Area Node IDs TLV”.
> >>
> >>   Behaviorally, we should add a requirement that if the Area Leader
> includes a pseudonode in the flooding topology, then all systems with 
> an adjacency on that LAN should use the LAN as part of the
> >>   flooding topology, whether or not they are explicitly listed as 
> >> adjacent to
> the LAN in the Flooding Path TLV.
> >>
> >> Thoughts? Comments? Flames?
> >>
> >> Regards,
> >> Tony
> >>
> >
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing 

Re: [Lsr] Min Links for Multiple Failures on Flooding Topology

[Huaimo Chen]

Hi Tony,

What is “the existing algorithm” that you have?
Is it the “rate limiting”? If so, can you describe the “rate limiting” 
algorithm in details?

Best Regards,
Huaimo
From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
Sent: Thursday, April 25, 2019 12:37 PM
To: Huaimo Chen 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Min Links for Multiple Failures on Flooding Topology


Hi Huaimo,

Thank you, this is very clear.

It leaves me with one question: how is this better than what we have?

You’ve computed the backup paths: [R4, R3, R6, R7] and [R5, R2, R9, R8].  This 
results 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...@huawei.com>> wrote:

Hi Tony,

Considering the different information about the link states in the different FT 
partitions caused by failures, attached (5 pages) contain an example with 
Figures, which illustrate and explain almost every step in details for 
computing a unique backup path for each of the two failures on the FT and 
enabling temporary flooding on the backup path. Would you mind indicating if 
any thing missing or incorrect?

In this example, the failures of two links R4-R7 and R5-R8 on the FT happen at 
the same time and split the FT into two partitions: partition A and partition 
B. Partition A contains R0, R1, R2, R3, R4, and R5. Partition B has R6, R7, R8, 
R9, R10, R11, and R12. Refer to Fig. 1.

Every node in partition A receives the link state (LS) from R4 indicating link 
from R4 to R7 down and the LS from R5 indicating link from R5 to R8 down. It 
has the FT and the real topology, shown in Fig. 2. There are two 
uni-directional links: link from R7 to R4, and link from R8 to R5. These 
uni-directional links will not be used in backup path computations.

Similarly in partition B, every node receives the LS from R7 indicating link 
from R7 to R4 down and the LS from R8 indicating link from R8 to R5 down. It 
has the FT and the real topology, shown in Fig. 3. There are two 
uni-directional links: link from R4 to R7, and link from R5 to R8. These 
uni-directional links will not be used in backup path computations. Note that 
Fig. 2 and Fig. 3 are equivalent if the uni-directional links are not used.

A unique backup path for link R4-R7 is computed and then enabled for temporary 
flooding.

In this example, the basic part of the algorithm below for computing a backup 
path is used, which is to obtain the minimum hop count path from Ri to Rj for 
link Ri-Rj. Like SPF, any link used in the path must be bi-directional.

At first, for the failure of a link Ri-Rj on the FT, a unique backup path for 
link Ri-Rj (assume Ri’s ID < Rj’s ID) is computed by each node in following 
steps:

  1.  Obtaining all the minimum hop count paths from Ri to Rj, wherein each 
minimum hop count path has a HC-FT value.
  2.  From the multiple paths that have the maximum HC-FT value if any, 
selecting the one with the links having smaller or smallest remote node ID 
along direction from destination Rj to source Ri.
And then, the backup path for link Ri-Rj is enabled for temporary flooding by 
node Rk on the path as follows:
Rk adds its local links on the backup path to the FT temporarily if they are 
not on the FT.



The backup path for link R4-R7 is R4-R3-R6-R7 (refer to Fig. 4). It is computed 
by R4, R3, R6 and R7 and other nodes. R3 and R4 in partition A compute the 
backup path using the topology in Fig. 2. R6 and R7 in partition B compute the 
backup path using the topology in Fig. 3.

The backup path for link R4-R7 is enabled for temporary flooding by R4,R3,R6 
and R7 that are on the backup path. R3 adds link R3-R6; and R6 adds link R6-R3 
to the FT temporarily. Note that link R4-R3 is already on the FT, R4 and R3 
will not add it to the FT again; link R6-R7 is already on the FT, R6 and R7 
will not add it to the FT again. Refer to Fig. 4.

Similarly, a unique backup path for link R5-R8 is computed and then enabled for 
temporary flooding.

The backup path for link R5-R8 is R5-R2-R9-R8 (refer to Fig. 5). It is computed 
by R5, R2, R9 and R8 and other nodes.

The backup path for link R5-R8 is enabled for temporary flooding by R5,R2,R9 
and R8 (refer to Fig. 5).

A unique backup path for link R4-R7, and a unique backup path for link R5-R8 
are computed and then enabled for temporary flooding.

The FT split is repaired. Refer to Fig. 6, FT partition A and partition B 
are connected by the links added to the FT temporarily.

Best Regards,
Huaimo
From: Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of 
tony...@tony.li<mailto:tony...@tony.li>
Sent: Friday, April 19, 2019 1:20 PM
To: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Min Links for Mu

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

[Huaimo Chen]

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 levels of hierarchies may support a network with 1k*1k*1k*1k 
nodes, which is about 10^12 = 1 trillion nodes.
  2.  For PDU type, section 2.2 of the draft proposes to use 8 bits (all three 
reserved bits plus the 5 bits for the existing PDU type). It seems better to 
use 6 bits (one reserved bit plus the 5 bits for the existing PDU type). Adding 
one reserved bit into the PDU Type allows people to define 32 new PDU types, 
which is enough for the new PDU types needed for new hierarchies.
  3.  Section 3 “Additional PDUs” of the draft, defines 6 new PDU Types for 
’Level n LAN IS to IS hello PDU’ (Ln-LAN-HELLO-PDU), where n is 3, 4, 5, 6, 7, 
and 8. In addition, the following new PDU Types should be defined (considering 
at most 4 levels of hierarchies):
 *   2 new PDU Types for ‘’Level n LSP”, where n is 3, and 4
 *   2 new PDU Types for ‘’Level n CSNP”, where n is 3, and 4
 *   2 new PDU Types for ‘’Level n PSNP”, where n is 3, and 4
  4.  On a broadcast interface, Level 1 LSPs are multicast through MAC 
0x0180.c200.0014 (which is called AllL1ISs), and Level 2 LSPs are multicast 
through MAC 0x0180.c200.0015 (which is called AllL2ISs). It seems that Level n 
LSPs should be multicast through AllLnISs, where n is 3, and 4 (considering at 
most 4 levels of hierarchies), thus
 *   2 new MAC should be assigned to AllLnISs, where n is 3, and 4.
  5.  The existing DIS for a broadcast interface periodically multicast through 
AllL1ISs and AllL2ISs a Complete SNP (CSNP). It seems that the DIS should be 
extended to periodically multicast a CSNP through AllLnISs, where n is 1, 2, 3, 
and 4 (considering at most 4 levels of hierarchies).
  6.  When there may be 3 or more levels of hierarchies, is it allowed to have 
3 or more levels (consecutive) configured on an interface? It seems that there 
is no description about this in the draft.

Best Regards,
Huaimo

From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Monday, August 12, 2019 10:33 AM
To: lsr@ietf.org
Subject: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - 
draft-li-lsr-isis-hierarchical-isis-01

This begins a two week LSR Working Group Adoption Poll for the "Hierarchical 
IS-IS" - draft-li-lsr-isis-hierarchical-isis-01. The poll will end at 12:00 AM 
UTC on August 27th, 2019. Please indicate your support of objection on this 
list prior to the end of the adoption poll.

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

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

[Huaimo Chen]

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 Adoption Call for "Hierarchical IS-IS" - 
draft-li-lsr-isis-hierarchical-isis-01

Huaimo –

Thanx for your support.
A few additional comments on top of Tony’s remarks.
Inline.

From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
tony...@tony.li<mailto:tony...@tony.li>
Sent: Monday, August 19, 2019 8:37 AM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Acee Lindem (acee) 
mailto:a...@cisco.com>>
Subject: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - 
draft-li-lsr-isis-hierarchical-isis-01


Hi Huaimo,


Support and have the following comments:


Thank you for your support and comments.

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 levels of hierarchies may support a network with 1k*1k*1k*1k nodes, 
which is about 10^12 = 1 trillion nodes.


This is correct.  It’s not absolutely necessary. However, as Robert mentioned, 
it does give the network designer flexibility to create the hierarchy that 
matches the needs of his network.  The cost of the additional levels is very 
small, given that we’re considering adding any levels at all, so it seemed 
sensible to define all of the levels at once.

“From an architectural point of view, if a number isn’t obviously too large, 
then it’s probably too small.”  — Ross Callon

[Les:] I would also add that we do not want to have to do this “again” – which 
might happen if we did as you suggest and support 4 levels – and then someone 
comes up w a deployment case for 5 levels.. 8 levels is likely more than is 
needed – but it is fits nicely into the current PDU format i.e., a number of 
fields are 8 bits.

[HC] It seems that the chance for someone to use level 5 to 8 is very low. It 
may take lots of time and efforts for someone to plan splitting existing areas 
into more areas with minimum service interruption. It may take even more time 
and efforts for someone to plan splitting existing levels into more levels.
For PDU type, section 2.2 of the draft proposes to use 8 bits (all three 
reserved bits plus the 5 bits for the existing PDU type). It seems better to 
use 6 bits (one reserved bit plus the 5 bits for the existing PDU type). Adding 
one reserved bit into the PDU Type allows people to define 32 new PDU types, 
which is enough for the new PDU types needed for new hierarchies.


Agreed, it’s more than necessary.  Since we’re opening the issue, it seemed 
useful to make use of the space.

[HC] It seems better to keep the first two bits as its current R (Reserved). 
Every bit in the header is a rare resource.

Section 3 “Additional PDUs” of the draft, defines 6 new PDU Types for ’Level n 
LAN IS to IS hello PDU’ (Ln-LAN-HELLO-PDU), where n is 3, 4, 5, 6, 7, and 8. In 
addition, the following new PDU Types should be defined (considering at most 4 
levels of hierarchies):

  1.

 *   2 new PDU Types for ‘’Level n LSP”, where n is 3, and 4
 *   2 new PDU Types for ‘’Level n CSNP”, where n is 3, and 4
 *   2 new PDU Types for ‘’Level n PSNP”, where n is 3, and 4

[Les:] Please see 
https://tools.ietf.org/html/draft-li-lsr-isis-hierarchical-isis-01#section-5<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-lsr-isis-hierarchical-isis-01%23section-5=02%7C01%7Chuaimo.chen%40futurewei.com%7Cfb1a92e407244a396c9908d7252e178c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637018752215524711=jp8E5Ej4OhjEAO20r0RQuRQJ84J0zeNkbWEcgbdU6Yo%3D=0>
 . SNPs and LSPs for the additional levels use the FS-LSP/FS-CSNP/FS-PSNP PDUs 
defined in RFC 7356 – with the new scopes as defined in this draft.

[HC] This is one option, which seems dependent on RFC 7356. If RFC 7356 is not 
implemented by a vendor, it may take more time and efforts for the vendor to 
implement the isis-hierarchy. The alternative above (i.e., using new PDU Types 
for level n LSP/CSNP/PSNP) seems simpler. It may be easier for a vendor to 
implement it since it does not depend on RFC 7356.


That's a natural consequence of your first point.


On a broadcast interface, Level 1 LSPs are multicast through MAC 
0x0180.c200.0014 (which is called AllL1ISs), and Level 2 LSPs are multicast 
through MAC 0x0180.c200.0015 (which is called AllL2ISs). It seems that Level n 
LSPs should be multicast through AllLnISs, where n is 3, and 4 (considering at 
most 4 levels of hierarchies), thus 2 new MAC should be assigned to AllLnISs, 
where n is 3, and 4.


Good point

[Lsr] Questions on Prefix Unreachable Announcement

[Huaimo Chen]

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 
announce that the prefix is unreachable when it can not reach the prefix (i.e., 
the prefix becomes unreachable from reachable from the ABR's perspective).
 Is my understanding right?

Should the ABR remove the prefix from the Extended Prefix Opaque LSA after 
it announces the prefix unreachable for a give period of time? After a router 
in another area receives the unreachable announcement of the prefix, it 
installs a black hole route to the prefix, and then removes the black hole 
route after a configurable time. After the black hole route derived from the 
unreachable announcement of the prefix is removed, it seems better to remove 
the unreachable prefix from the LSA.

 Can the ABR just remove the prefix (i.e., the TLV for the prefix) from the 
Extended Prefix Opaque LSA when it can not reach the prefix?


Best Regards,
Huaimo
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Call for draft-li-lsr-ospfv3-srv6-extensions

[Huaimo Chen]

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 draft-li-lsr-ospfv3-srv6-extensions



Hi LSR WG and Draft Authors,



The authors originally requested adoption back @ 105; however, some comments 
were received and new version was produced. Moving forward...



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



  
https://datatracker.ietf.org/doc/draft-li-lsr-ospfv3-srv6-extensions/

Please indicate your support or objection by Feb 6, 2020.



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



Thanks,

Chris & Acee.

___

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] WG Last Call draft-ietf-lsr-isis-srv6-extensions

[Huaimo Chen]

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
>
>  
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-isis-srv6-extensions%2Fdata=02%7C01%7Chuaimo.chen%40futurewei.com%7C5e71fc305dc84bee96f208d7a0d3d604%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637154704013184727sdata=d%2BFN9%2BxhMfAP06%2FelMEoIYbn3dnKfNcCOKkspuI8DBU%3Dreserved=0
>
> Authors please indicate if you aware of any other IPR beyond what is posted:
>
>  
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fipr%2F3796%2Fdata=02%7C01%7Chuaimo.chen%40futurewei.com%7C5e71fc305dc84bee96f208d7a0d3d604%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637154704013184727sdata=TiWrbHt636eWDWePu6ZKi6g5r447kqdh71kh7GYSOPA%3Dreserved=0
>
> Thanks,
> Chris & Acee.
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsrdata=02%7C01%7Chuaimo.chen%40futurewei.com%7C5e71fc305dc84bee96f208d7a0d3d604%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637154704013184727sdata=sUoMkREq%2Bgx1kDEp48P1GJsY8cbmiUC2m83zrhI2Gas%3Dreserved=0

___
Lsr mailing list
Lsr@ietf.org
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsrdata=02%7C01%7Chuaimo.chen%40futurewei.com%7C5e71fc305dc84bee96f208d7a0d3d604%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637154704013184727sdata=sUoMkREq%2Bgx1kDEp48P1GJsY8cbmiUC2m83zrhI2Gas%3Dreserved=0
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Huaimo Chen]

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


This begins a 3 week (due to holidays) WG adoption call for the “Flooding 
Topology Computation Algorithm” draft. Please issue your support or objection 
to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL for your 
convenience.



https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/



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

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 IPR Poll

[Huaimo Chen]

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: lsr@ietf.org 
Subject: Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 IPR Poll


Authors,



Are you aware of any IPR that applies to 
draft-cc-lsr-flooding-reduction-08..txt.



If so, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for more details).



If you are listed as a document author or contributor please respond

to this email regardless of whether or not you are aware of any

relevant IPR. *The response needs to be sent to the LSR WG mailing

list.* The document will not advance to the next stage until a

response has been received from each author and contributor.



If you are on the LSR WG email list but are not listed as an author or

contributor, then please explicitly respond only if you are aware of

any IPR that has not yet been disclosed in conformance with IETF rules.



Thanks,

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

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Huaimo Chen]

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 Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

Huaimo

This is a much needed feature that operators have been needing for densely 
meshed topologies that commonly exist in data centers to accommodate very high 
bandwidth E-W traffic.
[HC]: Thank you very much.

Below is link from Cisco which has introduced feature for dynamic flooding in 
clos high density ECMP data center topologies.

Please look at the feature description and it does seem to be exactly the same 
as this draft.  Please confirm.
[HC]: It seems different.

There maybe other vendors due to industry demand have to get the feature 
deployed before it reaches standards vendor consensus with the IETF.

https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-743015.html<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cisco.com%2Fc%2Fen%2Fus%2Fproducts%2Fcollateral%2Fswitches%2Fnexus-9000-series-switches%2Fwhite-paper-c11-743015.html=02%7C01%7Chuaimo.chen%40futurewei.com%7Caf6069f07e9c4b9b881508d7fcd08b26%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637255844949669307=9nLFlmBSFxBQayL0fCiq864Ylvzyksk3U0GmZPbhPts%3D=0>

We are testing this feature and planning to deploy but wanted to ensure that 
this is the same as the draft on the standards track.
[HC]: The feature appears implemented draft "Dynamic Flooding on Dense Graphs", 
which does not include any flooding topology computation algorithm.

Kind regards

Gyan


On Tue, May 19, 2020 at 11:52 PM Huaimo Chen 
mailto:huaimo.c...@futurewei.com>> wrote:
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 area 
leader in the centralized mode to compute the flooding topology.

Best Regards,
Huaimo

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Gyan 
Mishra mailto:hayabusa...@gmail.com>>
Sent: Tuesday, May 19, 2020 2:39 AM
To: Yanhe Fan mailto:y...@casa-systems.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>; Acee 
Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call


I support WG adoption and have a few questions related to the draft.

Does this flooding algorithm use the dynamic flooding algorithm used in data 
center clos dense meshed topologies with many ECMP paths where the flood is 
decoupled from the physical topology.  In the dynamic flooding algorithm 
mentioned in centralized mode the flooding is computed by the area leader and 
distributed to all nodes.  In distributed mode each mode the area leader 
determines the algorithm and then each node computes the flooding topology 
based on the algorithm.

This dynamic algorithm for optimized flood reduction would reduce the amount of 
redundant flooding in highly densely meshed ospf or Isis topologies.  So this 
optimization of flooding would improving overall link state routing protocol 
convergence.

Gyan

On Mon, May 18, 2020 at 3:37 PM Yanhe Fan 
mailto:y...@casa-systems.com>> wrote:

Support it as a co-author.



Thanks,

Yanhe



From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Friday, May 15, 2020 3:40 PM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call



This begins a 3 week (due to holidays) WG adoption call for the “Flooding 
Topology Computation Algorithm” draft. Please issue your support or objection 
to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL for your 
convenience.



https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf..org%2Fdoc%2Fdraft-cc-lsr-flooding-reduction%2F=02%7C01%7Chuaimo.chen%40futurewei.com%7Caf6069f07e9c4b9b881508d7fcd08b26%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637255844949679298=08cwC5X8u06cotUPxaWyOq3euYKGK9Pfh0pieb7Tqf0%3D=0>



Thanks,
Acee

___
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%7Chuaimo.chen%40futurewei.com%7Caf606

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Huaimo Chen]

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 area 
leader in the centralized mode to compute the flooding topology.

Best Regards,
Huaimo

From: Lsr  on behalf of Gyan Mishra 

Sent: Tuesday, May 19, 2020 2:39 AM
To: Yanhe Fan 
Cc: lsr@ietf.org ; Acee Lindem (acee) 

Subject: Re: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call


I support WG adoption and have a few questions related to the draft.

Does this flooding algorithm use the dynamic flooding algorithm used in data 
center clos dense meshed topologies with many ECMP paths where the flood is 
decoupled from the physical topology.  In the dynamic flooding algorithm 
mentioned in centralized mode the flooding is computed by the area leader and 
distributed to all nodes.  In distributed mode each mode the area leader 
determines the algorithm and then each node computes the flooding topology 
based on the algorithm.

This dynamic algorithm for optimized flood reduction would reduce the amount of 
redundant flooding in highly densely meshed ospf or Isis topologies.  So this 
optimization of flooding would improving overall link state routing protocol 
convergence.

Gyan

On Mon, May 18, 2020 at 3:37 PM Yanhe Fan 
mailto:y...@casa-systems.com>> wrote:

Support it as a co-author.



Thanks,

Yanhe



From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Friday, May 15, 2020 3:40 PM
To: lsr@ietf.org
Subject: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call



This begins a 3 week (due to holidays) WG adoption call for the “Flooding 
Topology Computation Algorithm” draft. Please issue your support or objection 
to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL for your 
convenience.



https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/



Thanks,
Acee

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

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

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

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Huaimo Chen]

Hi Gyan,

Thanks much for your suggestion.

Gyan> It maybe a good idea for both documents to reference each other as to 
how they play together or  in some respects if any provide a homogeneous 
complete holistic solution for flooding problem being solved.

[HC]: I will add the reference 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 Adoption Call



On Thu, May 21, 2020 at 11:01 AM Huaimo Chen 
mailto:huaimo.c...@futurewei.com>> wrote:
Hi Gyan,

Thanks much for your questions.

 Gyan> How does this draft compare to the WG LC draft for flood reduction.  
Would they be two eventual standard options in the operators toolbox  or 
competing features for optimized flood reduction. Would having two flood 
reduction features standardized versus one default IGP flood reduction feature 
be confusing for operators.  Just as it was confusing to me.
https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf..org%2Fdoc%2Fdraft-ietf-lsr-dynamic-flooding%2F=02%7C01%7Chuaimo.chen%40futurewei.com%7Ce0f4766963da47bb3ba608d7fdaf9134%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256802824693892=4vWmUdR%2BbXWXgjyBAw62Ig%2BxUyKPuq6uucKbrfbNv5w%3D=0>

[HC]: This draft plus the draft for flooding reduction can provide two 
modes of flooding reductions (i.e., centralized mode and distributed mode). The 
latter describes the two modes, but does not include any flooding topology 
computation algorithm for the distributed mode. The former proposes a flooding 
topology computation algorithm to be used in the distributed mode.

   Gyan> It maybe a good idea for both documents to reference each other as to 
how they play together or  in some respects if any provide a homogeneous 
complete holistic solution for flooding problem being solved.

In my opinion it may not be a bad idea even to combine both drafts so the 
solution is complete and holistic.  This will also make the overall 
specification flow nicely.

I know that efforts were made by LSR to have a common IGP solution, however 
there are many inherent differences between ISIS and OSPF that from IGP Link 
state protocol perspective you can treat like apples to apples but really it’s 
apples and oranges.  Maybe it might we wise to have separate draft for both and 
have references linking together as the same algorithm concept and 
mathematically however the actual code implementation would vary as the LSDB 
link state data structures are completely different.

Later = Dynamic flooding = 2 modes Centralized leader based and distributed

https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf..org%2Fdoc%2Fdraft-ietf-lsr-dynamic-flooding%2F=02%7C01%7Chuaimo.chen%40futurewei.com%7Ce0f4766963da47bb3ba608d7fdaf9134%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256802824693892=4vWmUdR%2BbXWXgjyBAw62Ig%2BxUyKPuq6uucKbrfbNv5w%3D=0>

This later draft per section excerpt provides both centralized and distributed 
algorithm see below


6.4<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr-dynamic-flooding-05%23section-6.4=02%7C01%7Chuaimo.chen%40futurewei.com%7Ce0f4766963da47bb3ba608d7fdaf9134%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256802824703852=FvMPjTxl622QWR0mgEZFUlnwM5rGlRKKdTWSTjPXcBs%3D=0>.
  Area Leader Responsibilities

   If the Area Leader operates in centralized mode, it MUST advertise
   algorithm 0 in its Area Leader Sub-TLV.  In order for Dynamic
   Flooding to be enabled it also MUST compute and advertise a flooding
   topology for the area.  The Area Leader may update the flooding
   topology at any time, however, it should not destabilize the network
   with undue or overly frequent topology changes.  If the Area Leader
   operates in centralized mode and needs to advertise a new flooding
   topology, it floods the new flooding topology on both the new and old
   flooding topologies.

   If the Area Leader operates in distributed mode, it MUST advertise a
   non-zero algorithm in its Area Leader Sub-TLV.

   When the Area Leader advertises algorithm 0 in its Area Leader Sub-
   TLV and does not advertise a flooding topology, Dynamic Flooding is
   disabled for the area.  Note this applies whether the Area Leader
   intends to operate in centralized mode or in distributed mode.

   Note that once Dynamic Flooding is enabled, disabling it risks
   destabilizing the network.

6.5<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr-dynamic-flooding-05

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Huaimo Chen]

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

Hi Huaimo,

> Users can define a zone (a block of an area) and the zone can be any block of 
> the area that users decide. Thus, using TTZ seems simpler than using Areas 
> for scalability. It uses less planning effort and less configurations.

Q1 - Can zones overlap ? IE. can any node be in the same time in multiple zones 
?
[HC2]: Yes.

Q2 - Can zones be nested ?
[HC2]: No for now.

Q3 - Can zone boundary span across two or more areas ?
[HC2]: No.

> [HC]:  The requirement for flooding of host routes domain wide is considered 
> in section 4.1.3 of TTZ draft.

Well all it says that loopbacks can be included. That in no way addresses the 
scalability aspect if those loopbacks are to be flooded domain wide anyway.
[HC2]: We will work on improving it.

Thx,
R.

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

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Huaimo Chen]

Hi Les,

> The question I and others have asked is “what can we do with zones that 
> cannot be done with areas?”.
[HC]: IS-IS TTZ or say Zone is one of a few drafts which experiment/explore 
new ways for scalability. These new ways may be simpler and have some other 
features.

Best Regards,
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-isis-ttz-11.txt


Huaimo –



The question I and others have asked is “what can we do with zones that cannot 
be done with areas?”.



>From the day several years ago when IS-IS TTZ was first presented,  your 
>answer has been “with zones you can hitlessly alter the topological 
>boundaries”.

My response has consistently been “we can already do that with areas”.

If you want to justify zones, you then need to provide some other use case that 
either cannot be done using areas or cannot be done hitlessly.

Continuing to focus on something that can already be done with areas isn’t 
helping you.



   Les





From: Huaimo Chen 
Sent: Tuesday, August 18, 2020 3:18 PM
To: Les Ginsberg (ginsberg) ; Les Ginsberg (ginsberg) 
; Acee Lindem (acee) 
; lsr@ietf.org
Subject: Re: LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt



Hi Les,



> It is possible to merge/split areas without adjacency flaps.

[HC]: While an existing area or zone is being abstracted as a single node 
or vice versa, there are the adjacency ups and downs. The areas 
merging/splitting without adjacency flaps has been done before this abstraction 
and will not reduce the service interruption during the abstraction.



Best Regards,

Huaimo



From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>
Sent: Tuesday, August 18, 2020 5:59 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>
Subject: RE: LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt



Huaimo –



It is possible to merge/split areas without adjacency flaps.

The technique has been known for many years.

It requires careful planning – but it is quite feasible and has been done.



You cannot justify the need for zones on this basis.



   Les





From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Huaimo Chen
Sent: Tuesday, August 18, 2020 2:33 PM
To: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>;
 Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt



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 existing area or zone is 
being abstracted as a single node because the adjacency ups and downs.



> Given both of the points above, I see no value in “smooth transition to/from 
> zone abstraction”.



[HC]:  The "smooth transition to/from zone abstraction" will reduce the service 
interruption while an existing area or zone is being abstracted as a single 
node and vice versa.



Best Regards,

Huaimo



From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Les 
Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Sent: Tuesday, August 18, 2020 5:06 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt



I see no need for “abstraction at arbitrary boundaries”. Areas work just fine.



IS-IS already has smooth transition capability for merging/splitting areas.



Given both of the points above, I see no value in “smooth transition to/from 
zone abstraction”.



If these are the principal distinguishing characteristics of TTZ as compared to 
area proxy (and I would agree they are), then I see no reason why this solution 
should be pursued as well.



I am therefore opposed to WG adoption of TTZ.



   Les







From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, August 18, 2020 7:17 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: [Lsr] L

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Huaimo 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 proposals/drafts which explore/experiment new 
ways for scalability.

Best Regards,
Huaimo

From: Lsr  on behalf of Henk Smit 
Sent: Wednesday, August 19, 2020 12:08 PM
To: Acee Lindem (acee) 
Cc: lsr@ietf.org 
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt

I object the introduction of a new major concept, called "zone".
It adds nothing to solve problems we can not already solve.
It just adds unnecessary complexity and technical debt.

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

henk.


Acee Lindem (acee) schreef op 2020-08-18 16:16:
> Based on the discussions in the last meeting and on the mailing list
> regarding draft-chen-isis-ttz-11, the chairs feel that there are
> enough differences with draft-ietf-lsr-isis-area-proxy-03 and in the
> community to consider advancing it independently on the experimental
> track.
>
> These differences include abstraction at arbitrary boundaries and
> IS-IS extensions for smooth transition to/from zone abstraction.
>
> We are now starting an LSR WG adoption call for
> draft-chen-isis-ttz-11.txt. Please indicate your support or objection
> to adoption prior to Tuesday, September 2nd, 2020.
>
> Thanks,
>
> Acee and Chris
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsrdata=02%7C01%7Chuaimo.chen%40futurewei.com%7C1eebe40e2ab34d2ed03c08d8445a297c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637334501365871305sdata=7Al1Hk%2FnR%2B19cbAigxEopXaX4x4bAneLMphQCjZw6c0%3Dreserved=0

___
Lsr mailing list
Lsr@ietf.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsrdata=02%7C01%7Chuaimo.chen%40futurewei.com%7C1eebe40e2ab34d2ed03c08d8445a297c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637334501365881301sdata=DMbOGdYQyEK9Abyc6TpFaP5P4iU5D7SeMDl69SUMVzY%3Dreserved=0
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Huaimo Chen]

Hi Tony,

It seems that splitting L1 area A1 into two L1 areas A11 and A12 cannot be 
automated without people's planning. Some people need to spend their time in 
deciding where is the boundary between the two areas and selecting a router in 
the backbone domain for Attach bit for one 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@ietf.org 
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


Hi Huaimo,

Assume that a big L1 area (say Area A1) is connected to backbone domain.
Let us compare TTZ and Areas for scalability.

Using TTZ, we need two steps below:
1) configure a piece of Area A1, named P1, as a zone; and
2) transfer P1 to a virtual node using one command or two.

Using Areas, we need four steps below to split Area A1 into two L1 areas 
A11 and A12:
1) configure the edges between A11 and A12 as L2/L1 to backbone domain;
2) add/configure a new area address on the routers in target Area A12;
3) configure Attach bit for A11 or A12; and
4) delete the old area address from the routers in Area A12.

Using TTZ is simpler than using Areas.


I’m not quite sure I follow you.  Are you arguing that simplicity is achieved 
through the minimum number of configuration steps?

If so, I’d like to introduce you to Arista CVP, our management platform, where 
all of this can be easily automated: 1 step.

Tony


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

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Huaimo Chen]

Hi Tony,

Assume that a big L1 area (say Area A1) is connected to backbone domain.
Let us compare TTZ and Areas for scalability.

Using TTZ, we need two steps below:
1) configure a piece of Area A1, named P1, as a zone; and
2) transfer P1 to a virtual node using one command or two.

Using Areas, we need four steps below to split Area A1 into two L1 areas 
A11 and A12:
1) configure the edges between A11 and A12 as L2/L1 to backbone domain;
2) add/configure a new area address on the routers in target Area A12;
3) configure Attach bit for A11 or A12; 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 (ginsberg) 
; Acee Lindem (acee) 
; lsr@ietf.org 
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


Hi Huaimo,

> The question I and others have asked is “what can we do with zones that 
> cannot be done with areas?”.
[HC]: IS-IS TTZ or say Zone is one of a few drafts which experiment/explore 
new ways for scalability. These new ways may be simpler and have some other 
features.


The English language is a remarkable creature. Enormously complex and 
intricate. Maddeningly irregular and inconsistent.

The word “may” is a fine example. It denotes the possibility of a relationship 
between two concepts, but says nothing about the likelihood of the reality. As 
a result, it can be used to
conjoin arbitrary entities.

Trump MAY win the election.

COVID MAY cure cancer.

The world MAY end tomorrow.

Any sentence with the word MAY in it is equally true if you replace “MAY” with 
“MAY NOT”.

Zones MAY be simpler.  Zones MAY NOT be simpler.  It’s up to you to convince us 
that they are simpler, better, or provide some value above and beyond the 
concepts that we have now.
The obligation is on you to make this point.

So far, you haven’t.

Regards,
Tony



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

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Huaimo Chen]

Hi Robert,

There are three LSR drafts that experiment/explore new ways for 
scalability. IS-IS TTZ is one of them. The other two have been adopted as 
experimental.

Best Regards,
Huaimo

From: Lsr  on behalf of Robert Raszuk 
Sent: Tuesday, September 1, 2020 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 experiment/explore 
new ways for scalability. These new ways may be simpler and have some other 
features.

While Tony very well explained the "may" part let me ask the "simpler" part.

Simpler then what ?

Simpler when combined with existing levels of abstraction or when taken alone 
in vaccume ?

The draft in question defines a new abstraction. But I would like to go back to 
a very basic question:

What problem(s) are you solving ?

You say "new ways for scalability" - can you enumerate what is unscalable in 
current areas or levels ?

Many thx,
Robert

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

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Huaimo Chen]

Hi Robert,

> * IGP scalability can be easily solved with the additional levels of current 
> abstraction instead of introducing new types of abstraction into it. Ref: 
> draft-ietf-lsr-isis-extended-hierarchy
[HC]: There are three LSR drafts that experiment/explore the new ways for 
scalability. Two of them have been adopted as experimental. TTZ is one of them 
on Adoption Poll now. It is better to adopt all three as experimental.
https://mailarchive.ietf.org/arch/msg/lsr/KNh_3KAnBRqTEc6e-ziLzpokkZs/ (adopted 
email for draft 1)
https://mailarchive.ietf.org/arch/msg/lsr/mv156bQSOqF6QuD1QHBozfxX590/ (adopted 
email for draft 2)

> * Most scaling aspects I have seen in practical deployments with IGPs are not 
> caused by the suboptimal protocol design. Those are caused by requirements 
> introduced by some transport technologies which (at least originally) 
> required flooding of host routes domain wide for exact match of FECs to 
> prefixes. I do not see how TTZs would address that aspect in any better way 
> than areas can.
[HC]:  The requirement for flooding of host routes domain wide is considered in 
section 4.1.3 of TTZ draft.

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 "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


>  acknowledged problem (IGP scalability)

Great so we see the problem description. This is progress !

Allow me to observe two points:

* IGP scalability can be easily solved with the additional levels of current 
abstraction instead of introducing new types of abstraction into it. Ref: 
draft-ietf-lsr-isis-extended-hierarchy

* Most scaling aspects I have seen in practical deployments with IGPs are not 
caused by the suboptimal protocol design. Those are caused by requirements 
introduced by some transport technologies which (at least originally) required 
flooding of host routes domain wide for exact match of FECs to prefixes. I do 
not see how TTZs would address that aspect in any better way than areas can.

Thx,
R.


On Wed, Sep 2, 2020 at 10:00 AM Gengxuesong (Geng Xuesong) 
mailto:gengxues...@huawei.com>> wrote:

Hi Tony,



My intension was not to talk about math/engineering/marketing or compare the 
size of marketing department. Them are not relevant to this thread.

I want to make clear about IETF process. In my understanding the document does 
not need to be perfect at this stage, as long as it is in the right direction 
to solve some acknowledged problem( IGP scalability). Comments will be helpful 
if it could provide ideas about how to improve.

But IMO the discussion in the mailing list about this draft has gone off the 
rails of technology, including keeping challenging tradeoff between value and 
complexity, which seems reasonable at the first sight, but at this stage, has 
turned out to be a question with no right answer and may bring endless argument.





Thanks

Xuesong



From: Tony Li [mailto:tony1ath...@gmail.com<mailto:tony1ath...@gmail.com>] On 
Behalf Of tony...@tony.li<mailto:tony...@tony.li>
Sent: Wednesday, September 2, 2020 12:07 PM
To: Gengxuesong (Geng Xuesong) 
mailto:gengxues...@huawei.com>>
Cc: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>>; Les 
Ginsberg mailto:ginsb...@cisco.com>>; Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt





Hi Xuesong,



Apologies first if I have missed any history of this discussion. But I’m not 
sure that we have to evaluate whether a method is “optimal” before WG adoption. 
Why not adopt some alternative solutions and leave the choice to 
industry/market?





First off, this is engineering, not theoretical math.  Optimal is not the 
issue. Heck, optimal isn’t even a goal.



What we are looking for is value and value that outweighs the complexity.



Leaving the choice to the market is a bad idea. The market does NOT make sound 
technical decisions. It makes pseudo-random decisions not based on technical 
merits. The canonical example here is VHS vs Betamax. Better technology lost.



Second, the market is unduly influenced by marketing. The size of your 
marketing department exceeds the size of my entire (not tiny) company. And it’s 
still second to that of Cisco.



Marketing does not make good technical and architectural decisions. That’s our 
job.



Tony



___
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr<https://nam11.

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Huaimo Chen]

Hi Robert,

The "transition" means transfer/abstract a zone to a single virtual node 
smoothly and roll the virtual node back to the zone smoothly.
TTZ draft contains a solution for the "transition", which reduces the 
traffic interruption when a zone is abstracted to a node and vice versa.

The values of TTZ include: 1) Less traffic interruption and 2) Simpler 
operations (refer to 
https://mailarchive.ietf.org/arch/msg/lsr/H8muAnPwnxVa9d_8FY7x3rofKLw/)

Best Regards,
Huaimo

From: Robert Raszuk 
Sent: Wednesday, September 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 mechanisms

Hmmm maybe I missed some explanations by authors, but to me concept of zones is 
positioned as an addition to the concept of areas or levels - not a replacement 
of those.

So when you say "transition" means that something existing no longer would be 
in place after successful deployment of a new thing.

Here I am actually not sure if IGP domain could be only constructed with zones 
without areas ?

Of course said all of the above I am still not seeing any value in the proposed 
new abstraction regardless if such abstraction would be positioned to exist in 
parallel to areas/levels or by definition be nested within the area/level.

r.

On Wed, Sep 2, 2020 at 4:48 PM mailto:tony...@tony.li>> wrote:

Hi Xueson,


My intension was not to talk about math/engineering/marketing or compare the 
size of marketing department. Them are not relevant to this thread.


You are the one who suggested we leave it up to the market…


I want to make clear about IETF process. In my understanding the document does 
not need to be perfect at this stage, as long as it is in the right direction 
to solve some acknowledged problem( IGP scalability). Comments will be helpful 
if it could provide ideas about how to improve.


That’s what we’ve been trying to tell you all along:

- If there is a benefit to zones, it’s not clear to us.  You need to do a 
better job articulating that.

- The transition mechanisms seem awkward and painful. Can you reduce the 
complexity?


But IMO the discussion in the mailing list about this draft has gone off the 
rails of technology, including keeping challenging tradeoff between value and 
complexity, which seems reasonable at the first sight, but at this stage, has 
turned out to be a question with no right answer and may bring endless argument.


Technology is all about maximizing benefits while minimizing costs.  This is 
why we don’t wire houses using gold and silver.

Yes, this does seem to be an endless argument.  Welcome to the IETF.

Regards,,
Tony

___
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%7Chuaimo.chen%40futurewei.com%7C71d83d2690d64fd496e108d84f51439b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637346557737088426=a0CeD%2Fa2B6lsHgM7PaHZkQ1l%2FKu704jhY3XvOdXm0uY%3D=0>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Huaimo Chen]

Hi Robert,

>It seems that in TTZ instead of careful planning of your abstractions the plan 
>is to randomly create zones and see what happens - is this right reading of 
>your explanation ?

[HC]: TTZ provides users flexibility to define a zone and abstract the zone to 
a single node for scalability. Users can define a zone (a block of an area) and 
the zone can be any block of the area that users decide. Thus, using TTZ seems 
simpler than using Areas for scalability. It uses less planning effort and less 
configurations.
For example, given a big L1 area (say area A1) connected to backbone, users can 
define a zone in area A1 and abstract it to a node for scalability. When area 
A1 is split into two L1 areas A11 and A12 using Areas, the planning effort 
includes two parts: 1) determining the boundary of A11 and A12 and 2) selecting 
a router for Attach bit. Since users can define any block of area A1 as a zone, 
the block for A11 can be defined as a zone and abstracted to a single node.
The planning effort using TTZ is just the first part of the planning effort 
using Areas, and is less.
For less configurations using TTZ, refer to
https://mailarchive.ietf.org/arch/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 Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


> people need to spend their time in deciding where is the boundary between the 
> two areas

Oh then I perhaps completely missed the value and power of TTZ.

It seems that in TTZ instead of careful planning of your abstractions the plan 
is to randomly create zones and see what happens - is this right reading of 
your explanation ?

Many thx,
R.

On Wed, Sep 2, 2020 at 6:58 AM Huaimo Chen 
mailto:huaimo.c...@futurewei.com>> wrote:
Hi Tony,

It seems that splitting L1 area A1 into two L1 areas A11 and A12 cannot be 
automated without people's planning. Some people need to spend their time in 
deciding where is the boundary between the two areas and selecting a router in 
the backbone domain for Attach bit for one of the two areas. These corresponds 
to step 1) and 3) for using Areas.

Best Regards,
Huaimo

From: Tony Li mailto:tony1ath...@gmail.com>> on behalf 
of tony...@tony.li<mailto:tony...@tony.li> 
mailto:tony...@tony.li>>
Sent: Wednesday, September 2, 2020 12:09 AM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Cc: Les Ginsberg mailto:ginsb...@cisco.com>>; Les Ginsberg 
(ginsberg) 
mailto:40cisco@dmarc.ietf.org>>; Acee 
Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


Hi Huaimo,

Assume that a big L1 area (say Area A1) is connected to backbone domain.
Let us compare TTZ and Areas for scalability.

Using TTZ, we need two steps below:
1) configure a piece of Area A1, named P1, as a zone; and
2) transfer P1 to a virtual node using one command or two.

Using Areas, we need four steps below to split Area A1 into two L1 areas 
A11 and A12:
1) configure the edges between A11 and A12 as L2/L1 to backbone domain;
2) add/configure a new area address on the routers in target Area A12;
3) configure Attach bit for A11 or A12; and
4) delete the old area address from the routers in Area A12.

Using TTZ is simpler than using Areas.


I’m not quite sure I follow you.  Are you arguing that simplicity is achieved 
through the minimum number of configuration steps?

If so, I’d like to introduce you to Arista CVP, our management platform, where 
all of this can be easily automated: 1 step.

Tony


___
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%7Chuaimo.chen%40futurewei.com%7C346e8ba1b8b140e581ab08d84f1db372%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637346336293628016=0f4iui6ePeVSWMnsved8IdE7zKpKkWm0veMoHOcSuZ4%3D=0>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] draft-xie-lsr-isis-sr-vtn-mt-02

[Huaimo Chen]

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 VTN-ID. In 
this case, a block of VTN-IDs must be allocated/reserved specially for using 
MT-IDs as VTN-IDs. It seems better to state something about this in the draft.

An IS-IS MT has the attributes of a VTN, including the specific topology 
and resource. An IS-IS MT can be used as a VTN and MT-ID can be used as a VTN 
ID. Is it possible for an IS-IS MT to be used/shared by two or more VTNs? If 
so, it seems better to have some details about how the multiple VTNs use/share 
the resource in the same one MT.

In section 5 "Scalability Considerations", the draft says that while 
multiple VTNs share the same topology attribute, the same topology is 
identified by multiple different MT-IDs. This seems giving a way to let two or 
more VTNs to use/share one MT if IS-IS MT allows multiple MT-IDs to be used for 
the same one MT. It seems better to move the related text from section 5 to 
some of the previous sections.

Best Regards,
Huaimo
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] draft-zhu-lsr-isis-sr-vtn-flexalgo-01

[Huaimo Chen]

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 identifier?
Does every VTN have a Flex-Algo identifier?
If so, where does the Flex-Algo identifier of every VTN come from?

In section 3 "Advertisement of SR VTN Resource Attribute",
is new flag "V" (Virtual) defined in this draft as an extension to RFC 8668?

If so, should an IANA request/action in section "IANA Considerations"
be added for this extension?

If not (i.e., it is defined in another draft),
it is better to remove the definition of flag "V" from
this draft and add a reference to another draft.
In this case, it seems that there is no IANA request from this draft.
It would be better to change the intended status of the draft from
the standards track to informational.

Some nits:
In section 2, the second sentence of the last paragraph,
should "to used" be changed to "to use"?

In section 3, the first sentence of the second paragraph,
should "was defined to advertise" be changed to
"defines the advertisement of"?

Best Regards,
Huaimo
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Huaimo Chen]

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 existing area or zone is 
being abstracted as a single node because the adjacency ups and downs.

> Given both of the points above, I see no value in “smooth transition to/from 
> zone abstraction”.

[HC]:  The "smooth transition to/from zone abstraction" will reduce the service 
interruption while an existing area or zone is being abstracted as a single 
node and vice versa.

Best Regards,
Huaimo

From: Lsr  on behalf of Les Ginsberg (ginsberg) 

Sent: Tuesday, August 18, 2020 5:06 PM
To: Acee Lindem (acee) ; lsr@ietf.org 

Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


I see no need for “abstraction at arbitrary boundaries”. Areas work just fine.



IS-IS already has smooth transition capability for merging/splitting areas.



Given both of the points above, I see no value in “smooth transition to/from 
zone abstraction”.



If these are the principal distinguishing characteristics of TTZ as compared to 
area proxy (and I would agree they are), then I see no reason why this solution 
should be pursued as well.



I am therefore opposed to WG adoption of TTZ.



   Les







From: Lsr  On Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 18, 2020 7:17 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 the discussions in the last meeting and on the mailing list regarding 
draft-chen-isis-ttz-11, the chairs feel that there are enough differences with 
draft-ietf-lsr-isis-area-proxy-03 and in the community to consider advancing it 
independently on the experimental track.



These differences include abstraction at arbitrary boundaries and IS-IS 
extensions for smooth transition to/from zone abstraction.



We are now starting an LSR WG adoption call for draft-chen-isis-ttz-11.txt. 
Please indicate your support or objection to adoption prior to Tuesday, 
September 2nd, 2020.



Thanks,

Acee and Chris


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

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Huaimo Chen]

Hi Les,

> It is possible to merge/split areas without adjacency flaps.
[HC]: While an existing area or zone is being abstracted as a single node 
or vice versa, there are the adjacency ups and downs. The areas 
merging/splitting without adjacency flaps has been done before 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 WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt


Huaimo –



It is possible to merge/split areas without adjacency flaps.

The technique has been known for many years.

It requires careful planning – but it is quite feasible and has been done..



You cannot justify the need for zones on this basis.



   Les





From: Lsr  On Behalf Of Huaimo Chen
Sent: Tuesday, August 18, 2020 2:33 PM
To: Les Ginsberg (ginsberg) ; Acee Lindem 
(acee) ; lsr@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt



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 existing area or zone is 
being abstracted as a single node because the adjacency ups and downs.



> Given both of the points above, I see no value in “smooth transition to/from 
> zone abstraction”.



[HC]:  The "smooth transition to/from zone abstraction" will reduce the service 
interruption while an existing area or zone is being abstracted as a single 
node and vice versa.



Best Regards,

Huaimo



From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Les 
Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Sent: Tuesday, August 18, 2020 5:06 PM
To: Acee Lindem (acee) 
mailto:acee=40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>
Subject: Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt



I see no need for “abstraction at arbitrary boundaries”. Areas work just fine.



IS-IS already has smooth transition capability for merging/splitting areas.



Given both of the points above, I see no value in “smooth transition to/from 
zone abstraction”.



If these are the principal distinguishing characteristics of TTZ as compared to 
area proxy (and I would agree they are), then I see no reason why this solution 
should be pursued as well.



I am therefore opposed to WG adoption of TTZ.



   Les







From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of Acee 
Lindem (acee)
Sent: Tuesday, August 18, 2020 7:17 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - 
draft-chen-isis-ttz-11.txt





Based on the discussions in the last meeting and on the mailing list regarding 
draft-chen-isis-ttz-11, the chairs feel that there are enough differences with 
draft-ietf-lsr-isis-area-proxy-03 and in the community to consider advancing it 
independently on the experimental track.



These differences include abstraction at arbitrary boundaries and IS-IS 
extensions for smooth transition to/from zone abstraction.



We are now starting an LSR WG adoption call for draft-chen-isis-ttz-11.txt. 
Please indicate your support or objection to adoption prior to Tuesday, 
September 2nd, 2020.



Thanks,

Acee and Chris


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

Re: [Lsr] LSR WG IPR Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz.txt

[Huaimo Chen]

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 Topology-Transparent Zone" - 
draft-chen-isis-ttz.txt


Authors,



The IETF IPRs declarations submitted for draft-chen-isis-ttz are specified here:



https://datatracker.ietf.org/ipr/4029/





Are you aware of any other IPR that applies to draft-chen-isis-ttz?



If so, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for more details).



If you are listed as a document author or contributor please respond

to this email regardless of whether or not you are aware of any

relevant IPR. *The response needs to be sent to the LSR WG mailing

list.* The document will not advance to the next stage until a

response has been received from each author and contributor.



If you are on the LSR WG email list but are not listed as an author or

contributor, then please explicitly respond only if you are aware of

any IPR that has not yet been disclosed in conformance with IETF rules.



Thanks,

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

Re: [Lsr] LSR WG Adoption Poll for "IS-IS Topology-Transparent Zone" - draft-chen-isis-ttz-11.txt

[Huaimo Chen]

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 the discussions in the last meeting and on the mailing list regarding 
draft-chen-isis-ttz-11, the chairs feel that there are enough differences with 
draft-ietf-lsr-isis-area-proxy-03 and in the community to consider advancing it 
independently on the experimental track.



These differences include abstraction at arbitrary boundaries and IS-IS 
extensions for smooth transition to/from zone abstraction.



We are now starting an LSR WG adoption call for draft-chen-isis-ttz-11.txt. 
Please indicate your support or objection to adoption prior to Tuesday, 
September 2nd, 2020.



Thanks,

Acee and Chris


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

Re: [Lsr] Review of draft-ietf-lsr-isis-ttz-00.txt

[Huaimo Chen]

SA
 d3e...@gmail.com

On Mon, Sep 14, 2020 at 1:07 PM  wrote:
>
> A New Internet-Draft is available 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
>   Richard Li
>   Yi Yang
>   Yanhe Fan
>   Ning So
>   Vic Liu
>   Mehmet Toy
>   Lei Liu
>   Kiran Makhijani
> Filename: draft-ietf-lsr-isis-ttz-00.txt
> Pages   : 23
> Date: 2020-09-14
>
> Abstract:
>This document presents a topology-transparent zone in an area.  A
>zone is a block/piece of an area, which comprises a group of routers
>and a number of circuits connecting them.  It is abstracted as a
>virtual entity such as a single virtual node or zone edges mesh.  Any
>router outside of the zone is not aware of the zone.  The information
>about the circuits and routers inside the zone is not distributed to
>any router outside of the zone.
>
>
> The IETF datatracker status page for this draft is:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-isis-ttz%2Fdata=02%7C01%7Chuaimo.chen%40futurewei.com%7Ca33d6822b9cb4fc9e2cb08d85eb76710%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637363489093751808sdata=H0goxD%2FO4Cy%2BqEY5Xl6VFCZtsxdMU%2BCsCXj1DJApjFk%3Dreserved=0
>
> There are also htmlized versions available at:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-lsr-isis-ttz-00data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ca33d6822b9cb4fc9e2cb08d85eb76710%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637363489093751808sdata=rGBezthZM%2FAsQUaSRZVc8KOqwSe%2Fh2gnpTApfu8Ro1A%3Dreserved=0
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr-isis-ttz-00data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ca33d6822b9cb4fc9e2cb08d85eb76710%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637363489093751808sdata=8ZS3onjvxxyZXfIspi9dLIqE8aNB4v84Dh8Me2brmlQ%3Dreserved=0
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2Fdata=02%7C01%7Chuaimo.chen%40futurewei.com%7Ca33d6822b9cb4fc9e2cb08d85eb76710%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637363489093751808sdata=s70XFxS0C7V1wM0eJtmV0YlGXC%2Fnw2T9sSq%2BRTLiQAs%3Dreserved=0

___
Lsr mailing list
Lsr@ietf.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsrdata=02%7C01%7Chuaimo.chen%40futurewei.com%7Ca33d6822b9cb4fc9e2cb08d85eb76710%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637363489093761767sdata=vcKQ2q8oJqtergNZ0BoOrAB9jZagx7HDg5aAjwPG%2FNg%3Dreserved=0

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

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Huaimo Chen]

Hi Gyan,

Gyan> I know we are trying to adopt an flooding algorithm
and from my reading up on all proposed algorithms, the dynamic flooding seems 
to be geared towards Data Center  partial mesh high x ECMP leaf spine 
architecture, where redundant flooding is problematic using either centralized 
area leader or distributed flooding using same dynamic algorithm,  versus the 
call for adoption flood reduction algorithm seems to geared towards full mesh 
but from what I can tell would not be the preferred for clos multi tier DC leaf 
spine topology with high x ECMP paths.

[HC]: The algorithm in the call for adoption is also for (or say, gear towards) 
clos multi tier DC leaf spine topology with high x ECMP paths. In the Appendix 
of the draft, a full mess example topology of 5 nodes is used to illustrate the 
steps of the algorithm in some details. Using this topology is for easily 
"drawing" it and illustrating the steps of the algorithm. "Drawing" a clos 
multi tier DC leaf spine topology high x ECMP paths to illustrate the algorithm 
in details is very hard in the draft.

Best Regards,
Huaimo

From: Gyan Mishra 
Sent: Sunday, 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 discussed during interim ietf by 
Sarah and Toni is the same as the one implemented by Cisco on Nexus platform or 
is Cisco’s Dynamic flooding a proprietary implementation?

Cisco’s flooding algorithm does seem almost identical to dynamic flooding..

Cisco Dynamic flooding - Nexus 9k

https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-743015.html<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cisco.com%2Fc%2Fen%2Fus%2Fproducts%2Fcollateral%2Fswitches%2Fnexus-9000-series-switches%2Fwhite-paper-c11-743015.html=02%7C01%7Chuaimo.chen%40futurewei.com%7C427cee154ea74148fc8f08d80031f917%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637259561920543212=qVG4uwYPelL1syGzMViZSvOodKoWy2dlL1AyZ%2BljmB0%3D=0>


Dynamic Flooding - Arista - Sarah & Toni

https://www.ietf.org/id/draft-chen-lsr-dynamic-flooding-algorithm-00.html<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf..org%2Fid%2Fdraft-chen-lsr-dynamic-flooding-algorithm-00.html=02%7C01%7Chuaimo.chen%40futurewei.com%7C427cee154ea74148fc8f08d80031f917%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637259561920553208=v400uLAa%2Fu3RwJlHfYhplTzR4sXVwMpCZA%2B%2BSM6adgI%3D=0>

Flood reduction- H Chen - WG adoption pending

https://datatracker.ietf.org/doc/html/draft-cc-lsr-flooding-reduction-08<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-cc-lsr-flooding-reduction-08=02%7C01%7Chuaimo.chen%40futurewei.com%7C427cee154ea74148fc8f08d80031f917%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637259561920553208=ZA%2F1DXQYGsbJHynkM5V8bj6Y5VnuwM%2FHftO02nlmzLk%3D=0>


I know we are trying to adopt an flooding algorithm
and from my reading up on all proposed algorithms, the dynamic flooding seems 
to be geared towards Data Center  partial mesh high x ECMP leaf spine 
architecture, where redundant flooding is problematic using either centralized 
area leader or distributed flooding using same dynamic algorithm,  versus the 
call for adoption flood reduction algorithm seems to geared towards full mesh 
but from what I can tell would not be the preferred for clos multi tier DC leaf 
spine topology with high x ECMP paths.

Why would we not want to adopt the best algorithm that is best for both full 
mesh and non full mesh leaf spine topology algorithm that works for all 
physical topologies and adopt that draft.

Unless a one size fits all won’t work I would like to understand why one best 
solution draft we come up with for an FT algorithm for all possible physical 
topologies cannot be picked for WG adoption.

Why would we want to adopt multiple flooding algorithms?

Gyan

On Sat, May 23, 2020 at 4:43 PM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:


On Fri, May 22, 2020 at 9:02 PM mailto:tony...@tony.li>> wrote:

Hi Gyan,

I think with clos spine leaf the mesh is much more intensive and problematic 
with ECMP then a circular topology nodal mesh that results in duplicate 
redundant flooding that slows down convergence.  With spine leaf it’s like an X 
horizontal width axis and then depth is spine to leaf links.  With spine leaf 
as you grow sideways and the spine expand the redundant ECMP grows and 
redundant flooding grows exponentially and is much worse then circular nodal 
mesh.

One very nice thing about dynamic flooding is that it computes a flooding 
topology at the node level.  If the adjacency between A and B is on the 

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Huaimo Chen]

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 Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

Hi Huaimo

Thank you for the slide deck.  That really helps understand the algorithm.

I will let you know if I have any questions.

The goal of the algorithm is to speed up convergence by limiting the 
convergence scope and expanding out 1 link at a time until all nodes and links 
are part of the flood scope.  From the examples in the slide deck I did not see 
mentioned what is done with the dynamic flooding algorithm where when you have 
a meshed network in the slide 5 examples, how do you limit the flooding on 
redundant links duplicate flooding with the many meshed paths as you 
iteratively grow the FT nodes scope Cq().  I believe with the dynamic flooding 
it does a degree of 2 so 2 links between nodes.
[HC]: The slide 5 example illustrates step 4 of the algorithm in section 4.1. 
When the algorithm reaches this step, all the nodes are  on the FT, but some of 
them may have degree of 1 (i.e., one link on the FT connected to the node). 
This step makes sure that every node on the FT has degree of at least 2.  It 
seems that the dynamic flooding expects the FT having its every node with 
degree of at least 2 for redundancy. In the Dynamic Flooding on Dense Graphs, 
link states will be flooded over the links on the FT. For example, for a node 
with degree of N (e.g., 3), when the node receives a link state from one link 
on the FT, it will flood the link state to the other N-1 (e.g., 3-1=2) links on 
the FT.

I think with clos spine leaf the mesh is much more intensive and problematic 
with ECMP then a circular topology nodal mesh that results in duplicate 
redundant flooding that slows down convergence.  With spine leaf it’s like an X 
horizontal width axis and then depth is spine to leaf links.  With spine leaf 
as you grow sideways and the spine expand the redundant ECMP grows and 
redundant flooding grows exponentially and is much worse then circular nodal 
mesh.
[HC]: In the slides, a full mess topology is used to illustrate the algorithm 
in some details. The algorithm can be used to compute FT for any other topology 
such as clos spine leaf. For topology with M (e.g., 100) parallel links between 
any pair of nodes X and Y, the algorithm will just add one link to the FT 
between X and Y, the other M - 1 (e.g., 100-1 = 99) links will not be added to 
the FT. Thus the link states will flood over only this one link between X and Y 
on the FT and will not flood over the other M - 1 (e..g., 100 - 1 = 99) links, 
which are not on the FT.

Thank you

Gyan

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

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Huaimo Chen]

Hi Gyan,

Thanks much for your questions.

 Gyan> How does this draft compare to the WG LC draft for flood reduction.  
Would they be two eventual standard options in the operators toolbox  or 
competing features for optimized flood reduction. Would having two flood 
reduction features standardized versus one default IGP flood reduction feature 
be confusing for operators.  Just as it was confusing to me.
https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf..org%2Fdoc%2Fdraft-ietf-lsr-dynamic-flooding%2F=02%7C01%7Chuaimo.chen%40futurewei.com%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327604003=TGrkecn6m9liviazX7qqPglGqYEWu5Ekg2FRIaDpBZ8%3D=0>

[HC]: This draft plus the draft for flooding reduction can provide two 
modes of flooding reductions (i.e., centralized mode and distributed mode). The 
latter describes the two modes, but does not include any flooding topology 
computation algorithm for the distributed mode. The former proposes a flooding 
topology computation algorithm to be used in the distributed mode.

Best 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 20, 2020 at 11:59 PM Huaimo Chen 
mailto:huaimo.c...@futurewei.com>> wrote:
Hi Gyan,

Thanks much for your questions. My answers are inline below with [HC].

Best Regards,
Huaimo

From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Sent: Wednesday, May 20, 2020 11:14 AM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Cc: Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>; 
lsr@ietf.org<mailto:lsr@ietf.org> mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

Huaimo

This is a much needed feature that operators have been needing for densely 
meshed topologies that commonly exist in data centers to accommodate very high 
bandwidth E-W traffic.
[HC]: Thank you very much.

Below is link from Cisco which has introduced feature for dynamic flooding in 
clos high density ECMP data center topologies.

Please look at the feature description and it does seem to be exactly the same 
as this draft.  Please confirm.
[HC]: It seems different.

There maybe other vendors due to industry demand have to get the feature 
deployed before it reaches standards vendor consensus with the IETF.

https://www.cisco.com/c/en/us/products/collateral/switches/nexus-9000-series-switches/white-paper-c11-743015.html<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cisco.com%2Fc%2Fen%2Fus%2Fproducts%2Fcollateral%2Fswitches%2Fnexus-9000-series-switches%2Fwhite-paper-c11-743015.html=02%7C01%7Chuaimo.chen%40futurewei.com%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327604003=CPEu2451qkfD9440Ihj1bKPWl%2BzH%2BiuYUwuWpfzR%2B0Q%3D=0>

We are testing this feature and planning to deploy but wanted to ensure that 
this is the same as the draft on the standards track.
[HC]: The feature appears implemented draft "Dynamic Flooding on Dense Graphs", 
which does not include any flooding topology computation algorithm.

Gyan> How does this draft compare to the WG LC draft for flood reduction.  
Would they be two eventual standard options in the operators toolbox  or 
competing features for optimized flood reduction. Would having two flood 
reduction features standardized versus one default IGP flood reduction feature 
be confusing for operators.  Just as it was confusing to me.


https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf..org%2Fdoc%2Fdraft-ietf-lsr-dynamic-flooding%2F=02%7C01%7Chuaimo.chen%40futurewei.com%7C60df274544ba4b75447f08d7fd947201%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637256686327604003=TGrkecn6m9liviazX7qqPglGqYEWu5Ekg2FRIaDpBZ8%3D=0>

Kind regards

Gyan


On Tue, May 19, 2020 at 11:52 PM Huaimo Chen 
mailto:huaimo.c...@futurewei.com>> wrote:
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 area 
leader in the centralized mode to compute the flooding topology.

Best Regards,
Huaimo

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of Gyan 
Mishra mailto:hayabusa...@gmail.com>>
Sent: Tuesday, May 19, 2020 2

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Huaimo Chen]

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

Sent: Tuesday, June 2, 2020 8:42 AM
To: Acee Lindem (acee) ; lsr@ietf.org 

Subject: Re: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call


Hi,



I’ve read the draft and I think the draft is useful and ready for WG adoption.

By the way, when reading the draft, I feel a little difficult to understand the 
mathematical symbols in the draft, especially in the “Appendix A.  FT 
Computation Details through Example .” It will be appreciated if the authors 
could add more explanations about this.  And I believe some brief introduction 
about the relationship between this draft and other existing work in the WG 
will also be very helpful.



Best Regards

Xuesong



From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Saturday, May 16, 2020 3:40 AM
To: lsr@ietf.org
Subject: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call



This begins a 3 week (due to holidays) WG adoption call for the “Flooding 
Topology Computation Algorithm” draft. Please issue your support or objection 
to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL for your 
convenience.



https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/



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

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

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

[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

[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

[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

[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

[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

[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

[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

[Lsr] Request WG adoption of TTZ

[Huaimo Chen]

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

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Huaimo Chen]

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 Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call


Speaking as WG Member:



Hi Authors,



I have a couple technical comments on the draft.



  1.  The algorithm only computes a single graph with single path to each node. 
While I-D.ietf-lsr-dynamic-flooding failure and computation of an updated 
flooding topology, many of the other algorithms (both draft and proprietary) 
attempt to compute two or more paths to each node.
[HC]: The flooding topology (or say a graph) computed by the algorithm has at 
least two paths to each node. At step 4 of the algorithm on page 5 of the 
draft, for each node B that has only one path to it on the flooding topology 
(i.e., the Degree of node B is one) , another path is added to it. Thus the 
final flooding topology (or say graph) computed by the algorithm has  two or 
more paths to every node.
  2.  Since this algorithm is slated for use as a distributed algorithm, all 
routers in the area must use the same value for MaxD or they may compute 
different flooding topologies. This is cannot be guaranteed by a single 
algorithm IANA value unless we allow some number of algorithm specific 
parameters to be advertised by the area leader (which might not be a bad idea).
[HC]: You are right. All the routers must use the same value for MaxD. We will 
update the draft for this accordingly. For now, MaxD has an initial value of 3 
(i.e., every router uses this initial value of 3 for MaxD).  The algorithm 
increases MaxD by one and restarts to compute the flooding topology with this 
new MaxD if it can not compute a flooding topology with the old MaxD. After 
some iterations in some cases, the flooding topology is computed. It is a good 
idea to pass some parameters from the area leader to every router when the 
leader advertises the algorithm number to every router.  MaxD can be one of the 
parameters.
  3.   Similarly, the constraints in section 4.2 must be applied uniformly and 
different constraints would require new IANA algorithm allocation.
[HC]: You are right. All the routers must use the same constraints.  A new (or 
different) set of constraints need a new algorithm number. We will update the 
draft for this accordingly.



Thanks,
Acee



From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Friday, May 15, 2020 at 3:40 PM
To: "lsr@ietf.org" 
Subject: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call



This begins a 3 week (due to holidays) WG adoption call for the “Flooding 
Topology Computation Algorithm” draft. Please issue your support or objection 
to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL for your 
convenience.



https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/



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

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

[Huaimo Chen]

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] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call


Hi,



I support adoption of this draft.



Hi Huaimo,



I have a question regarding the draft. At the end of section 3, it says if 
there is any change in the base topology, the flooding topology MUST be 
re-computed. So in case of a link failure in the base topo, it’s possible that 
the link is not part of the flooding topology (e.g. one of the multiple links 
between two nodes), it might be optimal if we can figure it out and save 
recalculation here.

[HC]: This will make sure that the flooding topologies computed by all the 
routers will be the same. If the algorithm does not compute a new flooding 
topology when a link that is not on the current flooding topology fails, we 
need prove that in any sequence of changes in base topology reaching to 
different LSDBs in different times the flooding topology computed by the 
algorithm on one router will be the same as the one computed by the algorithm 
on another router in this way.  After there is a proof, the optimized algorithm 
can be used.



Thanks,

Yingzhen



From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Friday, June 5, 2020 at 10:09 AM
To: "lsr@ietf.org" 
Subject: Re: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call
Resent-From: 



Speaking as WG Member:



Hi Authors,



I have a couple technical comments on the draft.



  1.  The algorithm only computes a single graph with single path to each node. 
While I-D.ietf-lsr-dynamic-flooding failure and computation of an updated 
flooding topology, many of the other algorithms (both draft and proprietary) 
attempt to compute two or more paths to each node.
  2.  Since this algorithm is slated for use as a distributed algorithm, all 
routers in the area must use the same value for MaxD or they may compute 
different flooding topologies. This is cannot be guaranteed by a single 
algorithm IANA value unless we allow some number of algorithm specific 
parameters to be advertised by the area leader (which might not be a bad idea).
  3.   Similarly, the constraints in section 4.2 must be applied uniformly and 
different constraints would require new IANA algorithm allocation.



Thanks,
Acee



From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Friday, May 15, 2020 at 3:40 PM
To: "lsr@ietf.org" 
Subject: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call



This begins a 3 week (due to holidays) WG adoption call for the “Flooding 
Topology Computation Algorithm” draft. Please issue your support or objection 
to this list by 11:59 PM, UTC on June 5th, 2020. Here is a URL for your 
convenience.



https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf..org%2Fdoc%2Fdraft-cc-lsr-flooding-reduction%2F=02%7C01%7Chuaimo.chen%40futurewei.com%7C41eead7b49484332128d08d80987e8b8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637269826621073729=mScDoVdFmFXGhPmKPfq0jG5fgJub4Sb8abZ4%2BVVQzVk%3D=0>



Thanks,
Acee
___
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

[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] New Version for draft-wang-lsr-hbh-process-00

[Huaimo Chen]

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 node is represented
by "Processing Action" (refer to Fig. 1 in the draft). Why do you include
"Max EH Len" in the "Processing Action"? It is not a capability.
2). The text describing the format of "Processing Action"
below seems not consistent with the format in Fig. 1.
"... processing action formed of
a tuple of a 1-octet Extension Header Options identifier and 8-bit
Processing Action Flag."
The above text occurs twice in the draft.
3). It seems that using word "signal" or "signaling" in the draft
is not good. It is better to use another word and rephrase the related text.

Best Regards,
Huaimo

From: Lsr  on behalf of wangyali 
Sent: Thursday, October 29, 2020 9:19 AM
To: lsr@ietf.org 
Subject: [Lsr] New Version for draft-wang-lsr-hbh-process-00

Hello WG,

Considering the Hop-by-Hop Options header has been used for IOAM 
[I-D.ietf-ippm-ioam-ipv6-options], Alternate Marking method 
[I-D.ietf-6man-ipv6-alt-mark], etc., but as specified in RFC8200, the 
Hop-by-Hop Options header is only examined and processed if it is explicitly 
configured. In this case, nodes may be configured to ignore the Hop-by-Hop 
Options header, drop packets containing a Hop-by-Hop Options header, or assign 
packets containing a Hop-by-Hop Options header to a slow processing path. Thus, 
the performance measurement does not account for all links and nodes along a 
path. In addition, packets carrying a Hop-by-Hop Options header may be dropped, 
which gravely deteriorates network performance.

Therefore, we propose a new draft about IGP extensions for signaling Hop-by-Hop 
Options header processing action at node and link granularity. Such 
advertisement is useful for entities (e.g., the centralized controller) to 
gather each router's processing action for achieving the computation of TE 
paths that be able to support a specific service encoded in the Hop-by-Hop 
Options header.

Please let us know your opinion. Questions and comments are very welcome.

Best regards,
Yali


-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Thursday, October 29, 2020 8:42 PM
To: Tianran Zhou ; Huzhibo ; 
wangyali 
Subject: New Version Notification for draft-wang-lsr-hbh-process-00.txt


A new version of I-D, draft-wang-lsr-hbh-process-00.txt has been successfully 
submitted by Yali Wang and posted to the IETF repository.

Name:   draft-wang-lsr-hbh-process
Revision:   00
Title:  IGP Extensions for Advertising Hop-by-Hop Options Header 
Processing Action
Document date:  2020-10-29
Group:  Individual Submission
Pages:  10
URL:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-wang-lsr-hbh-process-00.txtdata=04%7C01%7Chuaimo.chen%40futurewei.com%7C1b6010e28c9345df423708d87c0d5f8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637395744183598793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=tvJH5rnR%2BAj%2FxTTaxxbKJ6z%2F1OKAog3QdCCJnJkKB2I%3Dreserved=0
Status: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-wang-lsr-hbh-process%2Fdata=04%7C01%7Chuaimo.chen%40futurewei.com%7C1b6010e28c9345df423708d87c0d5f8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637395744183598793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=Wt7W0PL8HGI1EaPK8sV92RWIRGXATD0RGx1AhGIH6xk%3Dreserved=0
Htmlized:   
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-wang-lsr-hbh-processdata=04%7C01%7Chuaimo.chen%40futurewei.com%7C1b6010e28c9345df423708d87c0d5f8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637395744183598793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=Zmi3lDpE2aNulJxCiyU%2B9XQzv63EPeMo%2BAWVkatiDRE%3Dreserved=0
Htmlized:   
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-wang-lsr-hbh-process-00data=04%7C01%7Chuaimo.chen%40futurewei.com%7C1b6010e28c9345df423708d87c0d5f8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637395744183598793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=m9Z1uy3W4tT73SQod1DpcT%2BU4malMI25xQtNHTSwkdY%3Dreserved=0


Abstract:
   This document extends Node and Link attribute TLVs to Interior
   Gateway Protocols (IGP) to advertise the Hop-by-Hop Options header
   processing action and supported services (e.g.  IOAM Trace Option and
   Alternate Marking) at node and link granularity.  

Re: [Lsr] WG adoption call for draft-acee-lsr-ospf-transport-instance-02

[Huaimo Chen]

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 for draft-acee-lsr-ospf-transport-instance-02


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


https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-acee-lsr-ospf-transport-instance%2Fdata=04%7C01%7Chuaimo.chen%40futurewei.com%7Ca5078f2677c44f70a6a008d90d46e4f8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637555420448681736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Ikn6KJzPpEt%2BZcBHgM0oVJLWXzqGka85Tr2ztsV%2BHiw%3Dreserved=0

Please indicate your support or objection by May 16th, 2021.

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

Historical Note: The original OSPF transport instance document was adopted by 
the OSPF WG back in 2009, it was last updated in 2014, and then revived as an 
individual submission to LSR in Sep 2020. :)

Thanks,
Chris.

___
Lsr mailing list
Lsr@ietf.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsrdata=04%7C01%7Chuaimo.chen%40futurewei.com%7Ca5078f2677c44f70a6a008d90d46e4f8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637555420448681736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=1NOK2MXK7LXMjpA%2F9z8MA%2FJ%2FvFYGmjcA%2BjjE1MfipdI%3Dreserved=0
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[Huaimo Chen]

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) for 
Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03


This information draft describes how MT could be used for VTN segmentation. The 
authors have asked for WG adoption.



This begins a three week LSR Working Group Adoption Poll for “Using IS-IS 
Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - 
draft-xie-lsr-isis-sr-vtn-mt-03. I’m giving it three weeks due to the IETF next 
week. Please register your support or objection on this list prior to the end 
of the adoption poll on 3/24/2020.



Thanks,

Acee




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

Re: [Lsr] A review of draft-ietf-lsr-isis-ttz

[Huaimo Chen]

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-ietf-lsr-isis-...@ietf.org 
Subject: RE: A review of draft-ietf-lsr-isis-ttz


Hey Huaimo,



Wow! What a lot of work on the new revision. Thanks for the effort and the 
quick turn-around.



The only thing I am struggling with is the metrics in the node abstraction 
case. I still can’t see how the nodes outside the domain correctly compute the 
paths across the virtual node.



You are saying, “Some of the routes may not be optimal after the abstraction.” 
Perhaps this is enough (after all, we don’t achieve multi-AS shortest path 
routing), but it seems a very big change in behavior compared to how the area 
operated without the TTZ. The “suboptimality” may (will?) attract traffic to 
the TTZ and will substantially change the balance of traffic in the network.



This ought, at least, to come with advice to operators that they should 
carefully reconsider all of their metrics after introducing a TTZ.



Cheers,

Adrian





From: Huaimo Chen 
Sent: 24 February 2021 02:02
To: 'lsr' ; adr...@olddog.co.uk
Cc: draft-ietf-lsr-isis-...@ietf.org
Subject: Re: A review of draft-ietf-lsr-isis-ttz



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 mailto:adr...@olddog.co.uk>>

Sent: Saturday, February 13, 2021 3:34 PM

To: 'lsr' mailto:lsr@ietf.org>>

Cc: draft-ietf-lsr-isis-...@ietf.org<mailto:draft-ietf-lsr-isis-...@ietf.org> 
mailto:draft-ietf-lsr-isis-...@ietf.org>>

Subject: A review of draft-ietf-lsr-isis-ttz



Hi all,



Acee leant on me to do a review of this work (so blame him :-)



It's good to see this document adopted and progressing. Particularly

good to see the realistic compromise of making this Experimental.



I have a few comments, below.



Best,

Adrian



===



I have a largish issue with the fact that the document offers a choice

of how to aggregate the zone: virtual node or full mesh. Firstly, it is

not helpful to offer options without guidance about which option to pick

if you're an implementer or a deployer. You also need to specify whether

the choice MUST be a configuration option, and how to handle when some

nodes in the zone think one option and the others think the other

option.

[HC]: Added the advantages and disadvantages of two choices into the

document, which may help an implementer or a deployer.



Possibly you can make this part of the experiment (see below for notes

on the experiment).



I have some pretty strong opinions on the idea of a single node

abstraction. The main challenge comes when there is a partial failure in

the zone such that the zone is partitioned (or the path between two

zone neighbors across the zone is severely degraded). It is not possible

to represent this in the node model since your only options are:

- drop the connection to a neighbor

- move to represent the zone as two nodes

[HC]: To resolve the partition of a zone is challenging. One possible

solution is that when a zone is partitioned, it is abstracted as two

virtual nodes. One (the first) part of the zone is abstracted as one

(the first) virtual node, the other (second) part (which is disconnected

from the first part through zone links) is abstracted as another (second)

virtual node.



In fact, both models (node and mesh) are subject to disruption when

there is a connectivity failure within the zone, but if we think about

the mesh model, it doesn't actually need to be advertised as a full

mesh: partial mesh is easily handled. Nevertheless, the use of a single

zone leader to perform the aggregation has problems if the zone is

partitioned in some way - perhaps this is addressed by the partitioned

zone simply electing two distinct leaders and declaring itself as two

zones.

[HC]: When a partial mesh is used, some of routes may not be optimal

after a zone is abstracted as a partial mesh among the zone edges.

When a zone is abstracted as a full mesh of zone edges, the routes

keep unchanged. The routes that are optimal before the abstraction

are still optimal after the abstraction.

For node model, a zone is abstracted as a single virtual node.

When there is a connectivity failure within the zone, the failure

is not seen from any node outside of the zone. The routes computed

in any node outside of the zone will not change.

For mesh model, a zone is abstracted as a full mesh of zone edges.

Some of the routes will change. The route changes are consistent.



This discussion of faults within the zone seems (to me) to be pretty

important.



I am also struggling with metrics and route computation 

Re: [Lsr] A review of draft-ietf-lsr-isis-ttz

[Huaimo Chen]

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 review of draft-ietf-lsr-isis-ttz

Hi all,

Acee leant on me to do a review of this work (so blame him :-)

It's good to see this document adopted and progressing. Particularly
good to see the realistic compromise of making this Experimental.

I have a few comments, below.

Best,
Adrian

===

I have a largish issue with the fact that the document offers a choice
of how to aggregate the zone: virtual node or full mesh. Firstly, it is
not helpful to offer options without guidance about which option to pick
if you're an implementer or a deployer. You also need to specify whether
the choice MUST be a configuration option, and how to handle when some
nodes in the zone think one option and the others think the other
option.
[HC]: Added the advantages and disadvantages of two choices into the
document, which may help an implementer or a deployer.

Possibly you can make this part of the experiment (see below for notes
on the experiment).

I have some pretty strong opinions on the idea of a single node
abstraction. The main challenge comes when there is a partial failure in
the zone such that the zone is partitioned (or the path between two
zone neighbors across the zone is severely degraded). It is not possible
to represent this in the node model since your only options are:
- drop the connection to a neighbor
- move to represent the zone as two nodes
[HC]: To resolve the partition of a zone is challenging. One possible
solution is that when a zone is partitioned, it is abstracted as two
virtual nodes. One (the first) part of the zone is abstracted as one
(the first) virtual node, the other (second) part (which is disconnected
from the first part through zone links) is abstracted as another (second)
virtual node.

In fact, both models (node and mesh) are subject to disruption when
there is a connectivity failure within the zone, but if we think about
the mesh model, it doesn't actually need to be advertised as a full
mesh: partial mesh is easily handled. Nevertheless, the use of a single
zone leader to perform the aggregation has problems if the zone is
partitioned in some way - perhaps this is addressed by the partitioned
zone simply electing two distinct leaders and declaring itself as two
zones.
[HC]: When a partial mesh is used, some of routes may not be optimal
after a zone is abstracted as a partial mesh among the zone edges.
When a zone is abstracted as a full mesh of zone edges, the routes
keep unchanged. The routes that are optimal before the abstraction
are still optimal after the abstraction.
For node model, a zone is abstracted as a single virtual node.
When there is a connectivity failure within the zone, the failure
is not seen from any node outside of the zone. The routes computed
in any node outside of the zone will not change.
For mesh model, a zone is abstracted as a full mesh of zone edges.
Some of the routes will change. The route changes are consistent.

This discussion of faults within the zone seems (to me) to be pretty
important.

I am also struggling with metrics and route computation when the zone is
viewed from outside the zone.  4.1.5 tells us about route computation,
but it is not until 4.3.1 that we discover:
   The
   metric to the neighbor is the metric of the shortest path to the edge
   node within the zone.
This text applies to the full mesh case, and we don't have anything
about the node model, so we might assume that the metrics on the edge
circuits are unchanged.
[HC]: Added forward pointers accordingly.
For the node model, every node outside of the zone has no change
on the metrics; every node inside the zone sees the metric of a link
outside of the zone is one order of magnitude larger than the metric
of a link inside the zone.

Obviously, this is important, and it feels that something is broken for
the virtual node case. Consider Figure 1.

Without the zone (and assuming link metrics of 1), the cost of the path
R15-R61-R71-R67-R31 is 4, and this route might not be preferred if some
other route R15-x-y-R31 exists with cost 3. However, once we have
introduced the zone using the virtual node approach, there is an
available route R15-Rz-R31 that appears to have a preferable metric of
2. I would say that the route R15-x-y-R31 should still be preferred.
[HC]: Added some text about this.
After a zone is abstracted as a single virtual node, some routes
will be changed since the block of an area (zone) becomes a single
node. Some of the routes may not be optimal after the abstraction.

This point certainly needs to be called out in the text, and maybe this
gives some input to the choice between models. Perhaps the metrics in
the ISN and ESN TLVs are related to this point, but section 4.2.1 

Re: [Lsr] A review of draft-ietf-lsr-isis-ttz

[Huaimo Chen]

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: adr...@olddog.co.uk ; 'lsr' 
Cc: draft-ietf-lsr-isis-...@ietf.org 
Subject: Re: [Lsr] A review of draft-ietf-lsr-isis-ttz

Hi Adrian,
Thanks Much - I think these are all good comments and would greatly improve 
both the completeness and readability of the draft.

Hi Authors,

This is really a good review and I believe all the comments should be 
incorporated. While many of these are sins of omission that will take some 
time, it would be good to at least respond as to your intent to cover in future 
versions of the draft.

Thanks,
Acee

On 2/13/21, 3:35 PM, "Lsr on behalf of Adrian Farrel"  wrote:

Hi all,

Acee leant on me to do a review of this work (so blame him :-)

It's good to see this document adopted and progressing. Particularly
good to see the realistic compromise of making this Experimental.

I have a few comments, below.

Best,
Adrian

===

I have a largish issue with the fact that the document offers a choice
of how to aggregate the zone: virtual node or full mesh. Firstly, it is
not helpful to offer options without guidance about which option to pick
if you're an implementer or a deployer. You also need to specify whether
the choice MUST be a configuration option, and how to handle when some
nodes in the zone think one option and the others think the other
option.

Possibly you can make this part of the experiment (see below for notes
on the experiment).

I have some pretty strong opinions on the idea of a single node
abstraction. The main challenge comes when there is a partial failure in
the zone such that the zone is partitioned (or the path between two
zone neighbors across the zone is severely degraded). It is not possible
to represent this in the node model since your only options are:
- drop the connection to a neighbor
- move to represent the zone as two nodes

In fact, both models (node and mesh) are subject to disruption when
there is a connectivity failure within the zone, but if we think about
the mesh model, it doesn't actually need to be advertised as a full
mesh: partial mesh is easily handled. Nevertheless, the use of a single
zone leader to perform the aggregation has problems if the zone is
partitioned in some way - perhaps this is addressed by the partitioned
zone simply electing two distinct leaders and declaring itself as two
zones.

This discussion of faults within the zone seems (to me) to be pretty
important.

I am also struggling with metrics and route computation when the zone is
viewed from outside the zone.  4.1.5 tells us about route computation,
but it is not until 4.3.1 that we discover:
   The
   metric to the neighbor is the metric of the shortest path to the edge
   node within the zone.
This text applies to the full mesh case, and we don't have anything
about the node model, so we might assume that the metrics on the edge
circuits are unchanged.

Obviously, this is important, and it feels that something is broken for
the virtual node case. Consider Figure 1.

Without the zone (and assuming link metrics of 1), the cost of the path
R15-R61-R71-R67-R31 is 4, and this route might not be preferred if some
other route R15-x-y-R31 exists with cost 3. However, once we have
introduced the zone using the virtual node approach, there is an
available route R15-Rz-R31 that appears to have a preferable metric of
2. I would say that the route R15-x-y-R31 should still be preferred.

This point certainly needs to be called out in the text, and maybe this
gives some input to the choice between models. Perhaps the metrics in
the ISN and ESN TLVs are related to this point, but section 4.2.1 gives
no hint about how to set these values. Actually, I suspect that what is
going on here is that all of the metrics advertised to outside the zone
are controlled by the zone leader and advertised in the ISN/ESN - but I
don't find that actually stated anywhere.

All this said, I find it notable that this document focusses almost
completely (sections 4 and 5 - section 4.3 is a very small section) on
the virtual node model. It would be good to provide an example like
Figure 2, but for the mesh model.

Perhaps rather than deferring this to be an outcome of the experiment,
this document should spend some time comparing the two models *or* it
might even be time to abandon one of the models.

---

Obviously, at some point before this goes forward for publication,
you'll need to reduce to no more than five front-page authors.

---

I 

[Lsr] Renew: Early Allocation for IS-IS TTZ

[Huaimo Chen]

Hi Acee,

Would you mind renewing the Early Allocation for IS-IS TTZ?
The implementation of IS-IS TTZ is in progress.
Thanks much.

Best Regards,
Huaimo

From: Les Ginsberg (ginsberg) 
Sent: Friday, November 20, 2020 1:50 PM
To: Les Ginsberg (ginsberg) ; 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: Wednesday, November 18, 2020 1:45 PM
To: Acee Lindem (acee) ; Huaimo Chen 
; Christian Hopps ; Hannes 
Gredler 
Cc: lsr@ietf.org; Alvaro Retana 
Subject: Re: [Lsr] Early Allocation for IS-IS TTZ



Request noted.



Chris/Hannes/myself will discuss and get back to you.



   Les



From: Acee Lindem (acee) mailto:a...@cisco.com>>
Sent: Wednesday, November 18, 2020 12:21 PM
To: Huaimo Chen mailto:huaimo.c...@futurewei.com>>; 
Christian Hopps mailto:cho...@chopps.org>>; Hannes Gredler 
mailto:han...@gredler.at>>; Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; Alvaro Retana 
mailto:aretana.i...@gmail.com>>
Subject: Re: Early Allocation for IS-IS TTZ



+LSR list and Alvaro for information.



I have no problems with this allocation. This needs to go to IS-IS designated 
experts (Chris, Les, Hannes).



Thanks,

Acee



From: Huaimo Chen mailto:huaimo.c...@futurewei.com>>
Date: Wednesday, November 18, 2020 at 2:34 PM
To: Acee Lindem mailto:a...@cisco.com>>, Christian Hopps 
mailto:cho...@chopps.org>>
Subject: Early Allocation for IS-IS TTZ



Hi Acee and Chris,



We would like to request an early allocation of "IS-IS TLV Codepoints" for 
IS-IS TTZ  
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-ttz/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-isis-ttz%2F=04%7C01%7Chuaimo.chen%40futurewei.com%7C1de5c88bc06c4b09b4d208d88d8538d9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637414950630259311%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=PRWW2Yt%2F8ouJNse%2BHl4NQzEPgnEYaQyB0v1837woVBg%3D=0>



 28 (suggested) - IS-IS Zone ID TLV



Thank you very much for your consideration.



Best Regards,
Huaimo
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR Meeting Minutes

[Huaimo Chen]

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, November 17, 2021 8:08 PM
To: Gyan Mishra ; Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; lsr@ietf.org 
; Christian Hopps ; Acee Lindem (acee) 
; Tony Przygienda 
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes


I think the discussion about using a separate instance is a distraction and we 
shouldn’t be debating that right now.



The legitimate question is whether folks see it as appropriate to have an IGP 
based solution for the problem. How to do it using the IGP is only a meaningful 
question if we are considering using the IGP at all.



In that context…it is clear that it is a legitimate use of the IGP to advertise 
summary addresses.

It is also a legitimate use of the IGPs to advertise all the individual 
prefixes covered by a summary if the network operator chooses not to summarize.

It therefore seems to me to quite legitimate for the IGP to advertise both a 
summary and changes to the reachability of individual destinations covered by 
the summary. This is still a type of prefix reachability advertisement.



It would help me if the folks who think this is NOT a legitimate use of an IGP 
could explain why in the context of the above.



Thanx.



   Les



From: Lsr  On Behalf Of Gyan Mishra
Sent: Wednesday, November 17, 2021 4:32 PM
To: Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; 
lsr@ietf.org; Christian Hopps ; Tony Przygienda 
; Acee Lindem (acee) 
Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR 
Meeting Minutes





With MT separate control plane common data plane or Multi Instance separate 
control plane and separate data plane.



In both transport instance styles peeling the event notification into a 
separate instance or topology how do this discrete transport instance or 
topology interact with the main instance or topology.



The answer is it can’t.



As Aijun as well as Peter have discussed the problem this is an inherent issue 
with use of summarization and these are two solutions to solbe this real world 
issue to make summarization viable for operators.



Gyan

Verizon Inc



On Wed, Nov 17, 2021 at 6:10 PM Aijun Wang 
mailto:wangai...@tsinghua.org.cn>> wrote:

Hi, Christian:

Would you like to describe how to solve the problem via using the transport 
instance? The detail interaction process within the node and the deployment  
overhead analysis?
If there is no such information, it is doubt whether your judgment is correct 
or not, it is also unconvincing. Welcome also Tony gives the explanation before 
making the assertions, as we done for PUAM solution.


Aijun Wang
China Telecom

> On Nov 17, 2021, at 22:59, Christian Hopps 
> mailto:cho...@chopps.org>> wrote:
>
> 
>
>> On Nov 16, 2021, at 10:36 PM, Aijun Wang 
>> mailto:wangai...@tsinghua.org.cn>> wrote:
>>
>> Hi,
>>
>> The followings are the responses for the comments on PUAM 
>> draft(https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08)
>>
>> Les:  The comment I want to make, I think the discussion on the
>>  list highlighted the fact that there's an open question,
>>  independent of whether we use the prefix unreachable
>>  draft or the Event Notification draft, as to whether this
>>  problem should be solved by the IGP or whether it should be
>>  solved by BGP, or in some other way. And I think the logical
>>  way to proceed on this is to get the consensus of the working
>>  group as to whether an IGP solution is desired first, then
>>  after we reach consensus on that, then we can start talking
>>  about which approach is the better approach. Which one
>>  should be adopted?
>> 【WAJ】The problem is occurred due to the summary action by the ABR router in 
>> IGP, it should be solved by IGP itself.
>> As discussed earlier on the list, the possible use case is not limited to 
>> BGP fast convergence.
>> Based on the above considerations, it is not appropriated solved via BGP.
>>
>> Chris H:  Chair hat on. You've been asking for adoption for a while.
>>  The event notification draft is new. I agree with Les that
>>  in a perfect world that would be the case, but asking for
>>  adoption is one way to 

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Huaimo Chen]

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 ; 
draft-wang-lsr-stub-link-attribu...@ietf.org 

Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-wang-lsr-stub-link-attributes%2Fdata=04%7C01%7Chuaimo.chen%40futurewei.com%7Cc8e9ddfed01546ea489408d9cf507442%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637768766727894253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=KDGtq1muOp7w7TzMB2oc8gHF93GFFZJ2U2oArusK7rA%3Dreserved=0

Please indicate your support or objections by January 18th, 2022.

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

Thanks,
Chris.

___
Lsr mailing list
Lsr@ietf.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsrdata=04%7C01%7Chuaimo.chen%40futurewei.com%7Cc8e9ddfed01546ea489408d9cf507442%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637768766727894253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=X1ic6sdRo2naXF2iDvAfbHgyitrwonRhGBmHTh6Kx6o%3Dreserved=0
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] draft-chen-lsr-isis-big-tlv

[Huaimo Chen]

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 that With partial deployment 
behavior is unpredictable. This seems resolved by draft-chen-lsr-isis-big-tlv.
A container TLV is used by a node to contain a piece of new information. The 
nodes that do not support the capability of container TLV will ignore container 
TLVs. This will resolve unpredictable behavior with partial deployment.

Best Regards,
Huaimo
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-chen-lsr-isis-big-tlv

[Huaimo Chen]

Hi Les,

Thank you very much for your responses.

draft-chen-lsr-isis-big-tlv resolves the issue: unpredictable behavior with 
partial deployment, which are stated in both IETF 117 and IETF 118 slides. I 
explained this in detail in my previous email.

For the existing Sub-TLVs in a TLV > 255, the solution in 
draft-chen-lsr-isis-big-tlv is also backwards compatible. For a piece of new 
information in existing Sub-TLVs, when adding this new information into a TLV 
makes the TLV > 255, this new information in existing Sub-TLVs can be put into 
a container TLV. If all the nodes need to have the same new information for 
using the new information, every node needs to check if all the nodes support 
the capability which is distributed by the nodes supporting it. If all nodes 
support it, every node uses the new information. If it is not required that all 
the nodes must have the 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 ; lsr@ietf.org
Subject: RE: draft-chen-lsr-isis-big-tlv

Huaimo -

Thanx for bringing this up. Resolving this before the meeting hopefully will 
save us time during the meeting.

"Backwards compatibility" is possible in situations where new advertisements 
are being introduced and the legacy nodes either:


  *   Don't need to process the new advertisements or
  *   There are existing advertisements (in a different format) that contain 
the same information

Neither is the case here.

The problem being discussed is how to handle cases where the deployment 
requires more than 255 bytes of existing (sic) advertisements about a 
particular object.
For example, there are cases today where the total amount of information about 
a link (link endpoint identifiers, bandwidth, delay, affinity, adjacency-sids, 
etc.) exceeds 255 bytes. This is not because new sub-TLVs are being introduced 
- it is because the sum total of the existing sub-TLVs required in a given 
deployment exceeds 255 bytes.
All nodes in the network have to understand and process all of the sub-TLVs 
being advertised. There is no subset which is sufficient for "legacy nodes" and 
there is no existing way to advertise more than 255 bytes in a single TLV.

This problem therefore cannot be addressed in a backwards compatible way.

The solution defined in draft-pkaneria-lsr-multi-tlv is consistent with 
existing behavior explicitly defined for some TLVs (see  
https://www.ietf.org/archive/id/draft-pkaneria-lsr-multi-tlv-04.html#name-introduction
 ).

Could the problem be addressed by "Big-TLV"? Yes - but there are multiple 
reasons why this is not a good choice:

1)It introduces inconsistency - some TLVs would use multiple native TLVs to 
deal with the issue (as per existing RFCs) - and some TLVs would use a native 
TLV plus Big-TLV. As there is no advantage to Big-TLV this simply adds 
ambiguity with no benefits.

2)There are multiple existing implementations which have already been 
successfully deployed and proven interoperable using the solution discussed in 
draft-pkaneria-lsr-multi-tlv. Declaring that solution as invalid would set the 
industry back and require all implementations to start from scratch since no 
implementation today supports Big-TLV.

3)As BIG-TLV is a generic container TLV, it is inherently less efficient as it 
consumes bytes in the encapsulation.

Your main argument for Big-TLV has been the mistaken claim that it is 
"backwards-compatible". Hopefully you now understand that this is not the case 
and we need not debate this further.

  Les



From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Huaimo Chen
Sent: Sunday, November 5, 2023 11:34 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Subject: [Lsr] draft-chen-lsr-isis-big-tlv

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 that With partial deployment 
behavior is unpredictable. This seems resolved by draft-chen-lsr-isis-big-tlv.
A container TLV is used by a node to contain a piece of new information. The 
nodes that do not support the capability of container TLV will ignore container 
TLVs. This will resolve unpredictable behavior with partial deployment.

Best Regards,
Huaimo
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr