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

[Les Ginsberg (ginsberg)]

Huaimo –

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

From: Lsr  On Behalf Of tony...@tony.li
Sent: Monday, August 19, 2019 8:37 AM
To: 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


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.


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

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

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.
[Les:] Future revisions of the draft will be more explicit about adjacency 
formation rules – we are still discussing details.

   Les


Tony

___
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

[Susan Hares]

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:lsr-boun...@ietf.org] On Behalf Of Aijun Wang
Sent: Monday, August 19, 2019 5:29 AM
To: Susan Hares
Cc: lsr@ietf.org; tony...@tony.li; Robert Raszuk
Subject: Re: [Lsr] 答复: LSR Working Group Adoption Call for "Hierarchical IS-IS" 
- draft-li-lsr-isis-hierarchical-isis-01

 

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

Ajun:

 

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

 

  
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:lsr-boun...@ietf.org] On Behalf Of Aijun Wang
Sent: Friday, August 16, 2019 2:48 AM
To: tony...@tony.li; 'Robert Raszuk'
Cc: lsr@ietf.org
Subject: [Lsr] 答复: LSR Working Group Adoption Call for "Hierarchical IS-IS" - 
draft-li-lsr-isis-hierarchical-isis-01

 

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

 

 

 

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

 

 

Hi Robert,

 

 

> The hierarchical arrangement of the control plane does NOT imply 

[Lsr] Mirja Kühlewind's No Objection on draft-ietf-ospf-yang-26: (with COMMENT)

[Mirja Kühlewind via Datatracker]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-ospf-yang-26: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/



--
COMMENT:
--

Just two quick questions about references:

- Is there no reference for mtu-ignore (see section 2.4)? If not, can you
further describe what exactly would be disabled?

- Also is there no reference for OSPF Non-Stop Routing (NSR) (see section
2.4)...?

And one more comment:

In the interface-common-config part (p76 and p77) you provide example or
default values for various intervals and delays. Where does those values come
from? Would it be possible to provide a reference/RFC that specifies actual
default values? Especially when you specify something normatively ("The value
MUST be greater than 'hello-interval'.") it would be good to provide a
reference!  Do any specification maybe also specify min and max value? If so,
you should mention them here as well! If not would it make sense to recommend
min and max values? If possible I would strongly support to describe min and
max values as well!


___
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

[tony . li]

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

___
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

[Robert Raszuk]

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

> 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):
>   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  *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
>
___
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]

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

[Lsr] I-D Action: draft-ietf-ospf-te-link-attr-reuse-08.txt

[internet-drafts]

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   : OSPF Link Traffic Engineering (TE) Attribute Reuse
Authors : Peter Psenak
  Les Ginsberg
  Wim Henderickx
  Jeff Tantsura
  John Drake
Filename: draft-ietf-ospf-te-link-attr-reuse-08.txt
Pages   : 18
Date: 2019-08-19

Abstract:
   Various link attributes have been defined in OSPF in the context of
   the MPLS Traffic Engineering (TE) and GMPLS.  Many of these link
   attributes can be used for applications other than MPLS Traffic
   Engineering or GMPLS.  This document defines how to distribute such
   attributes in OSPFv2 and OSPFv3 for applications other than MPLS
   Traffic Engineering or GMPLS.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ospf-te-link-attr-reuse-08
https://datatracker.ietf.org/doc/html/draft-ietf-ospf-te-link-attr-reuse-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-te-link-attr-reuse-08


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:
ftp://ftp.ietf.org/internet-drafts/

___
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

[Aijun Wang]

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  wrote:
> 
> Ajun:
>  
> I’ll let Tony provide his answer to your question.   Let me provide an 
> alternate topology that your example might fit into
>  
> 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:lsr-boun...@ietf.org] On Behalf Of Aijun Wang
> Sent: Friday, August 16, 2019 2:48 AM
> To: tony...@tony.li; 'Robert Raszuk'
> Cc: lsr@ietf.org
> Subject: [Lsr] 答复: LSR Working Group Adoption Call for "Hierarchical IS-IS" - 
> draft-li-lsr-isis-hierarchical-isis-01
>  
> 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
>  
>  
>  
> 发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf..org] 代表 tony...@tony.li
> 发送时间: 2019年8月15日 23:37
> 收件人: Robert Raszuk
> 抄送: lsr@ietf.org; Aijun Wang
> 主题: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - 
> draft-li-lsr-isis-hierarchical-isis-01
>  
>  
> Hi Robert,
>  
>  
> 
> > 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 ? 
>  
>  
> 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
>  
> ___
> 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