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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 12 Aug 2019 14:33:06 +0000

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

---

From: [email-masked]
Date: Mon, 12 Aug 2019 15:02:55 -0700

Support as co-author.

T

> On Aug 12, 2019, at 7:33 AM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> _______________________________________________
> Lsr mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lsr <https://www.ietf.org/mailman/listinfo/lsr>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 13 Aug 2019 15:40:23 +0200

Support.

However assuming the draft will reach rough consensus of support I do
recommend to change the title during the conversion to WG document. ISIS is
already hierarchical today as even the abstract of the draft clearly says.

Thx,
R.

On Mon, Aug 12, 2019 at 11:57 PM Acee Lindem (acee) <[email-masked]> wrote:

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: [email-masked]
Date: Tue, 13 Aug 2019 07:42:28 -0700

Robert,

Thank you for your support.  What would you suggest?  

Tony

> On Aug 13, 2019, at 6:40 AM, Robert Raszuk <[email-masked]> wrote:
> 
> Support. 
> 
> However assuming the draft will reach rough consensus of support I do recommend to change the title during the conversion to WG document. ISIS is already hierarchical today as even the abstract of the draft clearly says. 
> 
> Thx,
> R.
> 
> On Mon, Aug 12, 2019 at 11:57 PM Acee Lindem (acee) <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 13 Aug 2019 16:48:57 +0200

> What would you suggest?

How about:  draft-ietf-lsr-n-level-isis-00 ?

r.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 13 Aug 2019 14:57:34 +0000

From: Robert Raszuk <[email-masked]>
Date: Tuesday, August 13, 2019 at 10:49 AM
To: Tony Li <[email-masked]>
Cc: Acee Lindem <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

I don’t like this – if we are going to split hairs on terminology, I’d suggest “IS-IS Level 3-8 Hierarchy”.
Thanks,
Acee

r.

On Tue, Aug 13, 2019 at 4:42 PM <[email-masked]<mailto:[email-masked]>> wrote:

Robert,

Tony

On Aug 13, 2019, at 6:40 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Support.

Thx,
R.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 13 Aug 2019 15:04:51 +0000

Current name:  lsr-isis-hierarchical-isis

(which has too many “isis” in it as well)

Proposed name: lsr-isis-extended-hierarchy

   Les

From: Lsr <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Tuesday, August 13, 2019 7:58 AM
To: Robert Raszuk <[email-masked]>; Tony Li <[email-masked]>
Cc: [email-masked]
Subject: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 13, 2019 at 10:49 AM
To: Tony Li <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

r.

Robert,

Tony

Support.

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 13 Aug 2019 17:07:21 +0200

> lsr-isis-extended-hierarchy

 Sounds great !

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 13 Aug 2019 15:08:56 +0000

WFM…

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tuesday, August 13, 2019 at 11:04 AM
To: Acee Lindem <[email-masked]>, Robert Raszuk <[email-masked]>, Tony Li <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

   Les

r.

Robert,

Tony

Support.

Thx,
R.

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 13 Aug 2019 13:18:24 -0700

+1

Cheers,
Jeff

---

From: Sarah Chen <[email-masked]>
Date: Tue, 13 Aug 2019 14:53:42 -0700

Support!

Thanks,
Sarah

---

From: Xiejingrong <[email-masked]>
Date: Wed, 14 Aug 2019 00:59:25 +0000

+1 support of the adoption and the name!

Jingrong

From: Lsr [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Wednesday, August 14, 2019 4:18 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: [email-masked]; Tony Li <[email-masked]>; Acee Lindem (acee) <[email-masked]>
Subject: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

+1

Cheers,
Jeff

 Sounds great !

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 13 Aug 2019 19:37:30 -0700

Support 

Regards,
Jeff

> On Aug 13, 2019, at 13:18, Jeff Tantsura <[email-masked]> wrote:
> 
> +1
> 
> Cheers,
> Jeff

---

From: <[email-masked]>
Date: Wed, 14 Aug 2019 11:38:37 +0200

+1
Regards
Simone
>>> Xiejingrong <[email-masked]> Mercoledì 14 Agosto 2019 >>>
 
Jingrong
 
From: Lsr [mailto:[email-masked]]On Behalf Of Jeff Tantsura
 
+1
 
Cheers, 
Jeff

 Sounds great !

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 15 Aug 2019 15:10:54 +0800

Some comments on this draft:

1. The size of network is increasing, but it is becoming more flat. Is it the right direction to make the network more hierarchical? 

2. More hierarchical network means the traffic will also be traversed in hierarchical way, is it more efficient?

3. Is there any other methods to scale out the IS-IS deployment?

Best Regards.

Aijun Wang

China Telecom

发件人: [email-masked] [mailto:[email-masked]] 代表 Acee Lindem (acee)
发送时间: 2019年8月12日 22:33
收件人: [email-masked]
主题: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

Thanks,

Acee

---

From: [email-masked]
Date: Thu, 15 Aug 2019 07:40:37 -0700

Hi Aijun,

> 1. The size of network is increasing, but it is becoming more flat. Is it the right direction to make the network more hierarchical? 

Well, given that we’re talking a link state protocol running SPF over a database in O(n log n) time, it’s pretty clear that we don’t want to scale the size of an area indefinitely. While modern processors are amazing (especially to those of us that started off with KHz 8080’s), it’s pretty clear that Moore’s law is over and that we cannot expect infinite compute power anytime in the future.  The alternative is to partition the network in some way.  Once partitioned, hierarchical arrangement seems like a natural fit. It’s been said that the only real tool that we have over scale is hierarchy.  Divide and conquer.

> 2. More hierarchical network means the traffic will also be traversed in hierarchical way, is it more efficient?

The hierarchical arrangement of the control plane does NOT imply that the data plane is necessarily hierarchical.

> 3. Is there any other methods to scale out the IS-IS deployment?

If you’ve been following along, Dynamic Flooding (https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-03 <https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-03>) allows us to address the limitations that we have with flooding, allowing us to scale the size of an area. However, it does not address the O(n log n) cost of SPF that will still ultimately bound the growth of areas and in turn necessitate more hierarchy.

Regards,
Tony

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 15 Aug 2019 16:56:38 +0200

Hi Tony,

> The hierarchical arrangement of the control plane does NOT imply that the
data plane is necessarily hierarchical.

Since Aijun posted his question I was trying to think of such model, but
failed.

While it is easy to envision this with DV protocols say BGP - do you have
any pointer to a link state protocol architecture where data plane is non
hierarchical (links do not belong to upper levels) while control plane used
traverses multiple levels ?

Thx,
R.

On Thu, Aug 15, 2019 at 4:40 PM <[email-masked]> wrote:

>
> Hi Aijun,
>
> 1. The size of network is increasing, but it is becoming more flat. Is it
> the right direction to make the network more hierarchical?
>
>
>
> Well, given that we’re talking a link state protocol running SPF over a
> database in O(n log n) time, it’s pretty clear that we don’t want to scale
> the size of an area indefinitely. While modern processors are amazing
> (especially to those of us that started off with KHz 8080’s), it’s pretty
> clear that Moore’s law is over and that we cannot expect infinite compute
> power anytime in the future.  The alternative is to partition the network
> in some way.  Once partitioned, hierarchical arrangement seems like a
> natural fit. It’s been said that the only real tool that we have over scale
> is hierarchy.  Divide and conquer.
>
>
> If you’ve been following along, Dynamic Flooding (
> https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-03) allows us
> to address the limitations that we have with flooding, allowing us to scale
> the size of an area. However, it does not address the O(n log n) cost of
> SPF that will still ultimately bound the growth of areas and in turn
> necessitate more hierarchy.
>
> Regards,
> Tony
>
>

---

From: [email-masked]
Date: Thu, 15 Aug 2019 08:37:00 -0700

Hi Robert,

> Since Aijun posted his question I was trying to think of such model, but failed. 
> 
> While it is easy to envision this with DV protocols say BGP - do you have any pointer to a link state protocol architecture where data plane is non hierarchical (links do not belong to upper levels) while control plane used traverses multiple levels ? 

Consider any topology where two peer areas intersect.  At the intersection, traffic can transition between the areas without entering the parent level.

While I’m at it, I should also point out that the existence of hierarchy for the control plane does not mandate its use. This is another tool in the toolbox. Use the right tool for the job at hand.

Tony

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 16 Aug 2019 14:48:17 +0800

Hi, Tony:

Would you like to elaborate this in more detail to show how you design the control plane hierarchically but the traffic can be transported horizontally? Let’s consider the following graph:

If, as you stated,  we connect R1 and R7 via one link(although we will not do so, if we design the network hierarchically), how you flood the link information hierarchically but let the traffic between the two connected L1 area bypass the L2 area?

Best Regards.

Aijun Wang

China Telecom

发件人: [email-masked] [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2019年8月15日 23:37
收件人: Robert Raszuk
抄送: [email-masked]; Aijun Wang
主题: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

Hi Robert,

 

Tony

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 16 Aug 2019 10:23:12 -0400

Ajun:

I’ll let Tony provide his answer to your question.   Let me provide an alternate topology that your example might fit into

 <https://datatracker.ietf.org/doc/draft-hares-lsr-grid-ring-convergence/> draft-hares-lsr-grid-ring-convergence-00.txt describes a problem with IGP convergence for the grid-ring phone topology that may be deployed in some 5G networks.  One way to solve the convergence problem is to provide an alternate fast convergence topology that uses hierarchy to provide shorter paths through the Grid portion of the grid-ring topology.  

Suppose in this topology, the regular IGP (ISIS) algorithm keeps the 2 level hierarchy.  

The alternate fast convergence algorithm uses a multiple level hierarchy in order to provide faster convergence.   The multiple levels provide “short-cut” paths for the IGP in a virtual topology in the Grid topology.  As discussions on this forum have indicated, the fast convergence topologies run in parallel with the normal IGP forwarding providing an alternate forwarding path.   If you would like me to explain how the hierarchy can provide faster convergence for a grid, I can provide that explanation to you (online or offline).    

Forwarding on the node needs to handle the multiple IGP routes.  Since  the fast convergence topologies provide early notification of forwarding problems in the normal IGP, the forward processing in the nodes might check this alternate topology for unknown routes.   Other ways of merging the two forwarding RIBs generated by the two IGPs also exist.  Since (per your example) R1 and R7 since the this link would be known to the regular IGP, the traffic could flow over this path. 

I hope this helps… 

Sue Hares 

PS – I would refresh the draft-hares-lsr-grid-ring-convergence-00.txt, but the draft submission seems to have a problem this morning.  This draft is still a rough draft. Some feedback I received indicates I should update sections.  

From: Lsr [mailto:[email-masked]] On Behalf Of Aijun Wang
Sent: Friday, August 16, 2019 2:48 AM
To: [email-masked]; 'Robert Raszuk'
Cc: [email-masked]
Subject: [Lsr] 答复: LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

Hi, Tony:

 

Best Regards.

Aijun Wang

China Telecom

 

Hi Robert,

 

Tony

---

From: [email-masked]
Date: Fri, 16 Aug 2019 09:03:50 -0700

Hi Aijun,

> If, as you stated,  we connect R1 and R7 via one link(although we will not do so, if we design the network hierarchically), how you flood the link information hierarchically but let the traffic bet…

The link between R1 and R7 needs to belong to either the top area or the bottom area.  R1 or R7 needs to participate in two areas and leak routes between the two areas.

Tony

---

From: Andrew Gray <[email-masked]>
Date: Fri, 16 Aug 2019 10:54:23 -0600

Support.

> On Aug 12, 2019, at 8:33 AM, Acee Lindem (acee) <[email-masked]> wrote:
>

---

From: [email-masked]
Date: Fri, 16 Aug 2019 11:00:47 -0700

Hi Aijun,

Les kindly points out that what I’ve suggested here is completely non-standard and requires multiple IS-IS instances.

Tony

> On Aug 16, 2019, at 9:03 AM, [email-masked] wrote:
> 
> Hi Aijun,
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 16 Aug 2019 18:07:46 +0000

To expand on this a bit, the point of the draft extensions is to add additional levels of hierarchy and use existing mechanisms (leaking, summarization) to have traffic flow up/down the hierarchy.
The intent is NOT to bypass the hierarchy.

People can use multiple instances and redistribution to do whatever they may wish. In that context two instances of IS-IS are no different then one instance of two different protocols.
But this is decidedly NOT the intent of the draft.

   Les

From: Lsr <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, August 16, 2019 11:01 AM
To: Tony Li <[email-masked]>
Cc: [email-masked]; Aijun Wang <[email-masked]>; Robert Raszuk <[email-masked]>
Subject: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

Hi Aijun,

Tony

On Aug 16, 2019, at 9:03 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi Aijun,

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 16 Aug 2019 21:16:32 +0200

Hey Les,

Of course the objective of the draft is clear and I do not think anyone is
questioning that. There was however topic of data and control plane
congruence requirement and I think we all agreed by now that this is rather
required in link state protocol as it is defined today.

As to the overall direction which I think initial Aijun's mail brought up
was if hierarchy is actually best answer to scale a protocol.

Divide and conquer is great strategy, but as such it could be realized with
flat levels interconnected by ISIS LSP reflectors as pure control plane
scaling solution (still reusing most of today's machinery - leaking,
summarization etc ...) Some form of DIS analogy except here to interconnect
many flat levels.

So I think the overall point to the WG is if building additional data and
control plane levels is the most optimal solution to scale link state
protocols up. Sure it can be done and it will be one more optional tool in
the toolbox, but is this the right/best tool for the job ?

Thx,
R.

On Fri, Aug 16, 2019 at 8:08 PM Les Ginsberg (ginsberg) <[email-masked]>
wrote:

> To expand on this a bit, the point of the draft extensions is to add
> additional levels of hierarchy and use existing mechanisms (leaking,
> summarization) to have traffic flow up/down the hierarchy.
>
> People can use multiple instances and redistribution to do whatever they
> may wish. In that context two instances of IS-IS are no different then one
> instance of two different protocols.
>
> *From:* Lsr <[email-masked]> *On Behalf Of * [email-masked]
> *Sent:* Friday, August 16, 2019 11:01 AM
> *To:* Tony Li <[email-masked]>
> *Cc:* [email-masked]; Aijun Wang <[email-masked]>; Robert Raszuk
> <[email-masked]>
> *Subject:* Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical
> IS-IS" - draft-li-lsr-isis-hierarchical-isis-01
>
>
>
>
>
> Hi Aijun,
>
>
>
> Les kindly points out that what I’ve suggested here is completely
> non-standard and requires multiple IS-IS instances.
>
>
>
> Tony
>
>
>
>
>
>
>
> If, as you stated,  we connect R1 and R7 via one link(although we will not
> do so, if we design the network hierarchically), how you flood the link
> information hierarchically but let the traffic between the two connected L1
> area bypass the L2 area?
>
>
>
>
>
> The link between R1 and R7 needs to belong to either the top area or the
> bottom area.  R1 or R7 needs to participate in two areas and leak routes
> between the two areas.
>
>
>
> Tony
>
>
>
>
>

---

From: [email-masked]
Date: Fri, 16 Aug 2019 12:42:47 -0700

Hi Robert,

> Of course the objective of the draft is clear and I do not think anyone is questioning that. There was however topic of data and control plane congruence requirement and I think we all agreed by now that this is rather required in link state protocol as it is defined today. 
> 
> As to the overall direction which I think initial Aijun's mail brought up was if hierarchy is actually best answer to scale a protocol. 

It’s the best answer that we have today.

> Divide and conquer is great strategy, but as such it could be realized with flat levels interconnected by ISIS LSP reflectors as pure control plane scaling solution (still reusing most of today's machinery - leaking, summarization etc ...) Some form of DIS analogy except here to interconnect many flat levels. 

If you have a number of areas all at a single level, you need to have some mechanism for computing paths between the areas.  You suggest ‘LSP reflectors’ which might suggest carrying all LSPs from one area and putting them into another area.  That approach has the same scalability properties as just running one single, giant area. I would not recommend this.  

If I take a less literal interpretation of ‘LSP reflectors’, then you are performing summarization, not reflection, at area boundaries. If no further information about the inter-area topology is known, then this devolves to a distance-vector like approach, where summaries circulate between areas and cumulative metric information is used to select the optimal path.  Effectively, you’re running RIP for your level 2 protocol, with all of the benefits and deficiencies of RIP.

If you would like an incremental improvement, you could carry path information with your summaries, and perform a path vector based path selection.  Effectively, you’re running BGP as your level 2 protocol, with all of the benefits and deficiencies of BGP.

And, of course, if you would like to carry full topology information in level 2, you could have the properties of a link-state protocol at level 2. IMHO, this is optimal at this time.

Now, if someone wants to come along and provide an entirely new concept in routing protocols, they could certainly do so, but we really haven’t made significant progress in this area for 25 years, so waiting would seem to well over everyone’s retirement event horizon.

> So I think the overall point to the WG is if building additional data and control plane levels is the most optimal solution to scale link state protocols up. Sure it can be done and it will be one more optional tool in the toolbox, but is this the right/best tool for the job ? 

I submit that the question is largely irrelevant to the matter of working group adoption.  We are not obligated to select only the best, if only because that can change over time. Further, we have no other proposals on the table.  Our proposal is the natural and logical extension of the two-level hierarchy that was originally conceived for IS-IS. From the perspective of getting to ‘running code’ it is the obvious choice because almost all of the code written for level 2 can be trivially abstracted for other levels. We have demonstrated significant working group interest already, so we should move forward so that we can enable people to use this tool if they choose to.

Regards,
Tony

---

From: Aijun Wang <[email-masked]>
Date: Mon, 19 Aug 2019 17:28:52 +0800

Hi, Susan:
It seems better to introduce one new draft to introduce your “virtual topology” solution, especially the control plane and forward plane behavior, how it interact with the deployed level 1/2 solutions.

I think to improve the convergence performance in large network such as 5G/IP RAN network is one attractive topic but we need to select/make the solutions being deployed easily and smoothly.

Aijun Wang
China Telecom

> On Aug 16, 2019, at 22:23, Susan Hares <[email-masked]> wrote:
> 
> Ajun:
>  
> draft-hares-lsr-grid-ring-convergence-00.txt describes a problem with IGP convergence for the grid-ring phone topology that may be deployed in some 5G networks.  One way to solve the convergence problem is to provide an alternate fast convergence topology that uses hierarchy to provide shorter paths through the Grid portion of the grid-ring topology. 
>

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 19 Aug 2019 14:27:32 +0000

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 <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Monday, August 12, 2019 10:33 AM
To: [email-masked]
Subject: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

Thanks,
Acee

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 19 Aug 2019 17:06:42 +0200

Hi Huaimo,

Ad 1 - Let me observe that constructing hierarchy is not always driven by
number of nodes in a given level can safely support. One could indeed build
a global flat link state network in single level/area if only looking at
number of nodes. But in number of cases benefits from hierarchy could be
seen in reduced flooding radius and enforced summarization. Hint:  me why
my routers in Sydney have to be aware about link flap in POP in Toronto ?

Ad 6 - Interesting .. I asked the same question to authors offline :)

Thx,
R.

On Mon, Aug 19, 2019 at 4:27 PM Huaimo Chen <[email-masked]>
wrote:

>    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):
>       1. 2 new PDU Types for ‘’Level n LSP”, where n is 3, and 4
>       2. 2 new PDU Types for ‘’Level n CSNP”, where n is 3, and 4
>       3. 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
>       1. 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 <[email-masked]> *On Behalf Of *Acee Lindem (acee)
> *Sent:* Monday, August 12, 2019 10:33 AM
> *To:* [email-masked]
> *Subject:* [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS"
> - draft-li-lsr-isis-hierarchical-isis-01
>
>
>

---

From: [email-masked]
Date: Mon, 19 Aug 2019 08:37:14 -0700

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

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

> 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

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, thank you, yes, we overlooked that.

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

Agreed, but we were not planning on being explicit about restating all of the rules for each level.  We should be more explicit and say that all behaviors of level 2 are replicated upwards.

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

This was intentionally not precluded and thus supported.  Again please note that as are only defining the behavior for contiguous levels at this time.

Tony

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 19 Aug 2019 14:14:38 -0400

Aijun:

It is certainly useful to introduce a new draft for a virtual topology solution for 5G/IPRAN topologies.   However, I awaited two things prior to releasing that draft:  a) additional feedback on the problem statement from some key people and b) the hierarchical ISIS adoption. 

As to virtual topologies … As you indicated virtual topologies are carried in IGPs MT-ISIS (RFC5120).   These virtual topologies could utilize the hierarchical ISIS extension.   These virtual topologies could also use the alternate fast convergence algorithms.    

I noticed that MT-ISIS MT IDs #3996-4096 are development, experimental, and proprietary features.  Perhaps deployment of the hierarchy for MT-ISIS might prove an good way for a network operations staff to get confidence that the hierarchy does not have an operational problem.     Alternatively,  you could define a standard MT topology which specific rules for hierarchical MT-ISIS.  Are you suggesting an standard MT topology be defined for hierarchical  ISIS?      

Susan Hares 

From: Lsr [mailto:[email-masked]] On Behalf Of Aijun Wang
Sent: Monday, August 19, 2019 5:29 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]; Robert Raszuk
Subject: Re: [Lsr] 答复: LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

Hi, Susan:

Aijun Wang

China Telecom

Ajun:

I hope this helps… 

Sue Hares 

 

Hi, Tony:

 

Best Regards.

Aijun Wang

China Telecom

 

Hi Robert,

 

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 20 Aug 2019 05:20:14 +0000

Huaimo –

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

From: Lsr <[email-masked]> On Behalf Of [email-masked]
Sent: Monday, August 19, 2019 8:37 AM
To: Huaimo Chen <[email-masked]>
Cc: [email-masked]; Acee Lindem (acee) <[email-masked]>
Subject: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

Hi Huaimo,

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

  1.

[Les:] Please see https://tools.ietf.org/html/draft-li-lsr-isis-hierarchical-isis-01#section-5 . 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.

This was intentionally not precluded and thus supported.  Again please note that as are only defining the behavior for contiguous levels at this time.
[Les:] Future revisions of the draft will be more explicit about adjacency formation rules – we are still discussing details.

   Les

Tony

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 26 Aug 2019 19:18:15 +0000

Hi Les,

Thank you for your response.
Some of my explanations are inline below with prefix [HC].

Best Regards,
Huaimo
From: Les Ginsberg (ginsberg) <[email-masked]>
Sent: Tuesday, August 20, 2019 1:20 AM
To: [email-masked]; Huaimo Chen <[email-masked]>
Cc: [email-masked]; Acee Lindem (acee) <[email-masked]>
Subject: RE: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

Huaimo –

Thanx for your support.

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, August 19, 2019 8:37 AM
To: Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

Hi Huaimo,

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

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

  1.

[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&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Cfb1a92e407244a396c9908d7252e178c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637018752215524711&sdata=jp8E5Ej4OhjEAO20r0RQuRQJ84J0zeNkbWEcgbdU6Yo%3D&reserved=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.

   Les

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 26 Aug 2019 19:29:39 +0000

Huaimo –

In regards to:

<snip>

<end snip>

This is a point I feel quite strongly about.
RFC 7356 addresses a number of protocol limitations – which include:

a)Carrying capacity of an LSP set – expanding that from 256 LSPs to 65536 LSPs
b)TLV length limitation of 255 bytes

Both of these limitations are applicable to all levels – including the new ones introduced by draft-li-lsr-isis-hierarchical-isis.
I do not want to define extensions to the hierarchy and then have to revisit that and find a way to address the above limitations in some future draft.

Given that we need to introduce new PDUs, the extensions are NOT backwards compatible. Therefore requiring folks to implement RFC 7356 in order to support extended hierarchy does not make the task any more difficult.

   Les

From: Huaimo Chen <[email-masked]>
Sent: Monday, August 26, 2019 12:18 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Cc: [email-masked]; Acee Lindem (acee) <[email-masked]>
Subject: RE: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

Hi Les,

Best Regards,
Huaimo
From: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, August 20, 2019 1:20 AM
To: [email-masked]<mailto:[email-masked]>; Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

Huaimo –

Thanx for your support.

Hi Huaimo,

  1.

   Les

Tony