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

[Huaimo Chen <[e-mail]>]

Hi Les,

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

Best Regards,
Huaimo
From: Les Ginsberg (ginsberg) <[e-mail]>
Sent: Tuesday, August 20, 2019 1:20 AM
To: [e-mail]; Huaimo Chen <[e-mail]>
Cc: [e-mail]; Acee Lindem (acee) <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Monday, August 19, 2019 8:37 AM
To: Huaimo Chen <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>
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&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.


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