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

[Acee Lindem (acee)]

Authors,
The LSR Working Group Adoption Call has ended and there is sufficient support 
and interest in working on this draft here in LSR.
Please republish the draft as draft-ietf-lsr-isis-extended-hierarchy-00.txt as 
we agreed during the discussion initiated by Robert Raszuk during the adoption 
call. I will update the draft meta-data to assure there is traceability to the 
current draft.
Thanks,
Acee

From: Lsr  on behalf of Acee Lindem 
Date: Monday, August 12, 2019 at 5:58 PM
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

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

[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

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

[tony . li]

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


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

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) 
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.
>
> 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  *On Behalf Of * tony...@tony.li
> *Sent:* Friday, August 16, 2019 11:01 AM
> *To:* Tony Li 
> *Cc:* lsr@ietf.org; Aijun Wang ; Robert Raszuk
> 
> *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
>
>
>
>
>
>
>
> On Aug 16, 2019, at 9:03 AM, tony...@tony.li wrote:
>
>
>
> 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 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
>
>
>
>
>
___
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

[Les Ginsberg (ginsberg)]

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  On Behalf Of tony...@tony.li
Sent: Friday, August 16, 2019 11:01 AM
To: Tony Li 
Cc: lsr@ietf.org; Aijun Wang ; Robert Raszuk 

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




On Aug 16, 2019, at 9:03 AM, tony...@tony.li<mailto:tony...@tony.li> wrote:

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


___
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 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, tony...@tony.li wrote:
> 
> 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 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
> 

___
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

[Andrew Gray]

Support.

> On Aug 12, 2019, at 8:33 AM, Acee Lindem (acee)  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
> ___
> 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

[tony . li]

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

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

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

[Simone.Colombo]

+1
Regards
Simone
>>> Xiejingrong  Mercoledì 14 Agosto 2019 >>>
+1 support of the adoption and the name!
 
Jingrong
 
From: Lsr [mailto:lsr-boun...@ietf.org]On Behalf Of Jeff Tantsura
Sent: Wednesday, August 14, 2019 4:18 AM
To: Les Ginsberg (ginsberg) ; Robert Raszuk 

Cc: lsr@ietf.org; Tony Li ; Acee Lindem (acee) 

Subject: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - 
draft-li-lsr-isis-hierarchical-isis-01
 
+1
 
Cheers, 
Jeff
On Aug 13, 2019, 8:07 AM -0700, Robert Raszuk , wrote:



> lsr-isis-extended-hierarchy 
 
 Sounds great !
 
___
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

[Jeff Tantsura]

Support 

Regards,
Jeff

> On Aug 13, 2019, at 13:18, Jeff Tantsura  wrote:
> 
> +1
> 
> Cheers,
> Jeff
>> On Aug 13, 2019, 8:07 AM -0700, Robert Raszuk , wrote:
>> > lsr-isis-extended-hierarchy 
>> 
>>  Sounds great !
>> 
>> ___
>> 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

[Xiejingrong]

+1 support of the adoption and the name!

Jingrong

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Wednesday, August 14, 2019 4:18 AM
To: Les Ginsberg (ginsberg) ; Robert Raszuk 

Cc: lsr@ietf.org; Tony Li ; Acee Lindem (acee) 
Subject: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - 
draft-li-lsr-isis-hierarchical-isis-01

+1

Cheers,
Jeff
On Aug 13, 2019, 8:07 AM -0700, Robert Raszuk 
mailto:rob...@raszuk.net>>, wrote:

> lsr-isis-extended-hierarchy

 Sounds great !

___
Lsr mailing list
Lsr@ietf.org<mailto: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

[Sarah Chen]

Support!

Thanks,
Sarah

On Tue, Aug 13, 2019 at 1:19 PM Jeff Tantsura 
wrote:

> +1
>
> Cheers,
> Jeff
> On Aug 13, 2019, 8:07 AM -0700, Robert Raszuk , wrote:
>
> > lsr-isis-extended-hierarchy
>
>  Sounds great !
>
> ___
> 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 Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

[Jeff Tantsura]

+1

Cheers,
Jeff
On Aug 13, 2019, 8:07 AM -0700, Robert Raszuk , wrote:
> > lsr-isis-extended-hierarchy
>
>  Sounds great !
>
> ___
> 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

[Acee Lindem (acee)]

WFM…

From: "Les Ginsberg (ginsberg)" 
Date: Tuesday, August 13, 2019 at 11:04 AM
To: Acee Lindem , Robert Raszuk , Tony Li 

Cc: "lsr@ietf.org" 
Subject: RE: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - 
draft-li-lsr-isis-hierarchical-isis-01

Current name:  lsr-isis-hierarchical-isis

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

Proposed name: lsr-isis-extended-hierarchy

   Les


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

From: Robert Raszuk mailto:rob...@raszuk.net>>
Date: Tuesday, August 13, 2019 at 10:49 AM
To: Tony Li mailto:tony...@tony.li>>
Cc: Acee Lindem mailto:a...@cisco.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - 
draft-li-lsr-isis-hierarchical-isis-01


> What would you suggest?

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

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 mailto:tony...@tony.li>> wrote:

Robert,

Thank you for your support.  What would you suggest?

Tony


On Aug 13, 2019, at 6:40 AM, Robert Raszuk 
mailto:rob...@raszuk.net>> 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.
___
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]

> lsr-isis-extended-hierarchy

 Sounds great !
___
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

[Les Ginsberg (ginsberg)]

Current name:  lsr-isis-hierarchical-isis

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

Proposed name: lsr-isis-extended-hierarchy

   Les


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

From: Robert Raszuk mailto:rob...@raszuk.net>>
Date: Tuesday, August 13, 2019 at 10:49 AM
To: Tony Li mailto:tony...@tony.li>>
Cc: Acee Lindem mailto:a...@cisco.com>>, 
"lsr@ietf.org<mailto:lsr@ietf.org>" mailto:lsr@ietf.org>>
Subject: Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - 
draft-li-lsr-isis-hierarchical-isis-01


> What would you suggest?

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

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 mailto:tony...@tony.li>> wrote:

Robert,

Thank you for your support.  What would you suggest?

Tony


On Aug 13, 2019, at 6:40 AM, Robert Raszuk 
mailto:rob...@raszuk.net>> 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.
___
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

[Acee Lindem (acee)]

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


> What would you suggest?

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

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 mailto:tony...@tony.li>> wrote:

Robert,

Thank you for your support.  What would you suggest?

Tony



On Aug 13, 2019, at 6:40 AM, Robert Raszuk 
mailto:rob...@raszuk.net>> 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.
___
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]

> What would you suggest?

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

r.


On Tue, Aug 13, 2019 at 4:42 PM  wrote:

>
> Robert,
>
> Thank you for your support.  What would you suggest?
>
> Tony
>
>
> On Aug 13, 2019, at 6:40 AM, Robert Raszuk  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.
>
>
___
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]

Robert,

Thank you for your support.  What would you suggest?  

Tony


> On Aug 13, 2019, at 6:40 AM, Robert Raszuk  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)  > 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
> 
> ___
> 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 Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

[Robert Raszuk]

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

[Susan Hares]

 

Support. 

 

Susan  Hares 

From: Lsr  on behalf of Acee Lindem 
Date: Monday, August 12, 2019 at 5:58 PM
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

[Acee Lindem (acee)]

Speaking as WG member:

Support adoptions.

Thanks,
Acee

From: Lsr  on behalf of Acee Lindem 
Date: Monday, August 12, 2019 at 5:58 PM
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

[tony . li]

Support as co-author.

T


> On Aug 12, 2019, at 7:33 AM, Acee Lindem (acee)  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
> ___
> 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] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

[Acee Lindem (acee)]

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