Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

[Les Ginsberg (ginsberg)]

Uma –

I think I have addressed this in my previous reply on this thread, but just to 
be sure nothing is left unaddressed…

The bis document is introducing planned restart signaling – so the helper 
router now has the opportunity to react to topology changes while waiting for 
the restarting router to come back to life.
We have chosen to leave the decision of when to bring down the adjacency to 
implementations for a number of reasons:


1.   There is no interoperability issue if different helpers use different 
policies

2.   Specifying an optimal behavior that applies to all scenarios would be 
difficult and unnecessarily constraining

3.   With Acee’s feedback that at least some implementations of OSPF GR 
have chosen not to follow a prescriptive behavior I think we have validation of 
this choice

   Les


From: Uma Chunduri 
Sent: Wednesday, May 29, 2019 7:12 PM
To: Acee Lindem (acee) 
Cc: Les Ginsberg (ginsberg) ; lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

Hi Acee,

On Wed, May 29, 2019 at 7:06 AM Acee Lindem (acee) 
mailto:a...@cisco.com>> wrote:
Hi Les, Uma,

Excuse the top-post but Outlook doesn’t do well with inline response for 
messages such as this one. AFAIK, no implementation defaulted to aborting 
graceful restart due to any topology change as recommended by RFC 3623.

Np. For IS-IS/RFC 5306  (base) yes no implementation defaulted to aborting GR 
due to topology changes. If one wants to capture topology changes  during 
restart yes they have to do beyond GR(NSR?).
However, in the bis document with planned restart indication this is being 
introduced (i.e., exiting GR if "any" topology change is detected by the 
neighbor of restating router).

Thank you!
--
Uma C.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

[Les Ginsberg (ginsberg)]

Uma –

Hopefully we are making progress this time.
Replies inline. Look for [Les2:]

From: Uma Chunduri 
Sent: Wednesday, May 29, 2019 6:56 PM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

Les,

Replies in-line [Uma1]:


On Tue, May 28, 2019 at 6:01 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Uma -



Newly added Section 2.2.3 a says this:

   The "remaining time" transmitted according to (b)
   below MUST reflect the actual time after which the adjacency will
   now expire.

The above is same for section 2.2.1 a, which talks about RR and RA.
This is the reason, I asked, what is the implication of same timer value here 
for PR/PA.
For example, what are the implications of this new timer times out before the 
value specified in RA (as PR is obviously initiated before) ? Also see my 
original question.


[Les:] Tx timers do NOT apply to the neighbors of the restarting router – and 
they are the only routers whose control plane is alive while the restarting 
router is reloading.

[Uma1]: Yes. Who said it's otherwise?
[Les2:]  Well you have repeatedly asked about T3 in the context of  PA – and I 
have repeatedly said “not relevant”.
But as you indicate you get that, let’s agree to move on.

  You are simply not answering what I was asking.  I have been 
taking about restarting router when it receives PA with hold time set as 
specified in 2.2.3 (re-read my original question).
  OK, let me ask this differently:
  You added the first 2 events to the 5306 table in section 3.2 as 
shown below. But I didn't see "RX PA" event. Perhaps you need to specify what 
you would do based on the newly added text in 2.2.3.
   Also specify:
   What is the impact on restarting router when the hold time value 
received in PA and RA are the same/different values?
   Unlike receiving RA would cause T3 to be set to prepare for the 
worst; describe the actions of a restarting router has to when receiving PA.
   You ought to be doing something with hold time you received with 
PA, what is it?
[Les2:] OK – now I understand your question.

RA is associated with post-restart activities. The restarting router has 
rebooted and is attempting to reestablish adjacency/LSPDB synchronization in a 
modest amount of time – which is constrained by the Remaining Holdtime sent by 
the helper router along w RA. That is then used by the restarting router to 
bound T3 because we want to complete LSPDB synchronization before the helper 
router times out the adjacency.

PA is associated with pre-restart activities. Once received, the restarting 
router knows that the helper router is aware of the planned restart and the 
restarting router knows it is safe to actually do the restart. The value of the 
Remaining Holdtime that came along w the RA is only to be able to 
confirm/report how long the helper router will allow the restarting router to 
come back to life. This value can’t be used by the Restarting Router (e.g., 
IS-IS obviously cannot alter how long it takes for the router to reload) – but 
it might be useful as a debug mechanism in cases where some flapping occurs 
associated with the restart.

I think there are a few things that could be clarified in the text:

1)State what I have written above
2)Add Receive PA into the state machine diagram (as you suggested)
3)We failed to mention that when sending the PR the restarting router should 
set the Remaining Holdtime to a value large enough to allow for the router 
reload to occur. This will serve as the value the helper router should use to 
maintain the adjacency in the absence of hellos while the restarting router is 
reloading

I will spin a new version with those changes.

3.2.  Restarting Router

  Event  | Restarting | ADJ Seen  | ADJ Seen  | SPF Wait
 ||RA |   CSNP|
 ===
  Restart| Send PR|   |   |
planned  ||   |   |
 ++---+---+
  Planned| Send PR clr|   |   |
   restart   ||   |   |
canceled ||   |   |
 ++---+---+
  Router | Send IIH/RR|   |   |
   restarts  | ADJ Init   |   |   |
 | Start T1,T2,T3 |   |   |
 ++---+---+
  RX RR  | Send RA|   |   |
 ++---+---+
  RX RA  | Adjust T3  |   | Cancel T1 |
 | Goto ADJ Seen RA   |   

Re: [Lsr] Enhancements on flooding topology encoding

[Huaimo Chen]

Hi Tony,


Thank you for your comments!

My explanations are inline below.


Best Regards,
Huaimo

From: Tony Li  on behalf of tony...@tony.li 

Sent: Wednesday, May 29, 2019 11:20 AM
To: Huaimo Chen
Cc: lsr@ietf.org
Subject: Re: Enhancements on flooding topology encoding


Hi Huaimo,

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

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

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

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

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

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

Regards,
Tony



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

Hi Tony,


For the three encodings below,

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

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

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



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

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


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





Hi Huaimo,





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





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



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





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






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

Re: [Lsr] 回复： Status of draft-ietf-isis-encapsulation-cap

[Susan Hares]

Xiaohu:

 

The draft-ietf-idr-tunnel-encaps-12 is in a WG review of the final changes 
until June 7th.  After this the draft will be sent to the IESG.  You may want 
to review this final draft. 

 

Cheerily, Sue 

 

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of ???(??)
Sent: Sunday, April 14, 2019 11:21 PM
To: adrian; lsr
Subject: Re: [Lsr] 回复： Status of draft-ietf-isis-encapsulation-cap

 

Both the OSPF and ISIS drafts have heavy dependency on the BGP counterpart 
(https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-11) which has not 
been published yet since it was adopted almost 4 years ago.

 

Best regards,

Xiaohu

 

 

 

 

 

--

From:Adrian Farrel 

Send Time:2019年4月14日(星期日) 01:09

To:徐小虎(义先) ; lsr 

Subject:Re: [Lsr] 回复： Status of draft-ietf-isis-encapsulation-cap

 

Thanks Xiaohu,

That at least indicates that you would like to see an RFC published.

 

But I wonder whether the WG has given up on this work? Two years is a long time 
to make no advances and to have no demands for publication.

I wonder why no one has cared in the interim.

 

Best,

Adrian

 

From: 徐小虎(义先)  
Sent: 13 April 2019 17:56
To: adr...@olddog.co.uk; lsr@ietf.org
Subject: 回复：[Lsr] Status of draft-ietf-isis-encapsulation-cap

 

I will update the ISIS draft soon.

Xiaohu





来自钉钉专属商务邮箱

--
发件人：Adrian Farrel
日　期：2019年04月13日 23:59:05
收件人：
主　题：[Lsr] Status of draft-ietf-isis-encapsulation-cap

Hi,

Any clues?

https://datatracker.ietf.org/doc/draft-ietf-isis-encapsulation-cap/ shows
expired in October 2017, so I guess that is good and dead.

On the other hand,
https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/ found
its way onto the RFC Editor Queue at around the same date and has languished
there ever since.

Did the ISIS work get replaced by some other draft without the "replaced by"
link being set up?
Was it deemed unnecessary in ISIS?

Thanks,
Adrian (who is trying to get draft-ietf-mpls-sr-over-ip through the IESG and
finds a reference to this draft)
--
Fairy tales from North Wales for adults of all ages
https://www.feedaread.com/profiles/8604/
Available from your favourite online bookseller.
Or contact me to receive a signed copy by mail.

___
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] draft-ietf-lsr-isis-rfc5306bis-01

[Uma Chunduri]

Hi Acee,

On Wed, May 29, 2019 at 7:06 AM Acee Lindem (acee)  wrote:

> Hi Les, Uma,
>
>
>
> Excuse the top-post but Outlook doesn’t do well with inline response for
> messages such as this one. AFAIK, no implementation defaulted to aborting
> graceful restart due to any topology change as recommended by RFC 3623.
>
>
> Np. For IS-IS/RFC 5306  (base) yes no implementation defaulted to aborting
GR due to topology changes. If one wants to capture topology changes
during restart yes they have to do beyond GR(NSR?).
However, in the bis document with planned restart indication this is being
introduced (i.e., exiting GR if "any" topology change is detected by the
neighbor of restating router).

Thank you!
--
Uma C.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Adoption Call for "IS-IS Extensions to Support Routing over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

[Susan Hares]

Acee: 

 

Support.  Important for SRV6 dataplane.  IDR draft has adopted  
draft-ietf-idr-bgpls-srv6-ext-06. 

 

Sue

 

PS -  It past May 25th at 2019, but I did not see an announcement yet. 

 

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 9, 2019 9:50 AM
To: lsr@ietf.org
Subject: [Lsr] Working Group Adoption Call for "IS-IS Extensions to Support 
Routing over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

 

We been holding off WG adoption until the base SRv6 draft was adopted in 
SPRING. Now that 
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/ 
has been adopted, we are starting a two week LSR WG adoption poll for the 
subject draft. Please register your support or objection prior to 12:00 AM UTC, 
on May 25th, 2019.

 

For your convenience, here is a URL for the draft:

 

https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6-extensions/

 

Thanks,

Acee

 

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

Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

[Uma Chunduri]

Les,

Replies in-line [Uma1]:


On Tue, May 28, 2019 at 6:01 PM Les Ginsberg (ginsberg) 
wrote:

Uma -
>

>
>

>
Newly added Section 2.2.3 a says this:
>

>
*   The "remaining time" transmitted according to (b)*
>
*below MUST reflect the actual time after which the adjacency will*
>
*now expire. *
>

>
The above is same for section 2.2.1 a, which talks about RR and RA.
>
This is the reason, I asked, what is the implication of same timer value
> here for PR/PA.
>
For example, what are the implications of this new timer times out before
> the value specified in RA (as PR is obviously initiated before) ? Also see
> my original question.
>

>

>
*[Les:] Tx timers do NOT apply to the neighbors of the restarting router –
> and they are the only routers whose control plane is alive while the
> restarting router is reloading.*
>

>
[Uma1]: Yes. Who said it's otherwise?

  You are simply not answering what I was asking.  I have been
taking about restarting router when it receives PA with hold time set as
specified in 2.2.3 (re-read my original question).
  OK, let me ask this differently:
  You added the first 2 events to the 5306 table in section 3.2
as shown below. But I didn't see "RX PA" event. Perhaps you need to specify
what you would do based on the newly added text in 2.2.3.

   Also specify:
   What is the impact on restarting router when the hold time
value received in PA and RA are the same/different values?

   Unlike receiving RA would cause T3 to be set to prepare for
the worst; describe the actions of a restarting router has to when
receiving PA.

   You ought to be doing something with hold time you received
with PA, what is it?


3.2.  Restarting Router


  Event  | Restarting | ADJ Seen  | ADJ Seen  | SPF Wait

 ||RA |   CSNP|

 ===

  Restart| Send PR|   |   |

planned  ||   |   |

 ++---+---+

  Planned| Send PR clr|   |   |

   restart   ||   |   |

canceled ||   |   |

 ++---+---+

  Router | Send IIH/RR|   |   |

   restarts  | ADJ Init   |   |   |

 | Start T1,T2,T3 |   |   |

 ++---+---+

  RX RR  | Send RA|   |   |

 ++---+---+

  RX RA  | Adjust T3  |   | Cancel T1 |

 | Goto ADJ Seen RA   |   | Adjust T3 |

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





*No offense intended – but your question is bizarre – I really don’t
> understand what logic leads you to ask it. **J*
>

>

[Uma1]: You said an obvious statement above that "Tx timers do not apply to
neighbors of the restarting routers.." while I am asking about restarting
router who received PA with holding timer value set.  No offence intended,
but it's the bizarre response I never expected from you! :)



*We could have been more prescriptive – similar to
> https://tools.ietf.org/html/rfc3623#section-3.2
>  – but I think that is
> sub-optimal. It is possible for a topology change to occur which does not
> affect forwarding via the restarting node – in which case it isn’t helpful
> to bring the adjacency down.*
>

[Uma1]: Precisely. This is what I am looking for and I am not sure why
describing this won't help to have a consistent behavior  on neighboring
node implementing this feature..  You gave a very good example where it is
described (no sub-optimal).



*Rather than try to detail all possible cases, we have left it as an
> implementation decision as to how “smart” an implementation wants to be. *
>

[Uma1]: There is no rocket  science here; any implementation should avoid
bringing down the ADJ for unrelated topology changes in a remote place
which has no bearing or involvement of the restating router. For the
record, IMO this need to be  clarified (but that's up to you if you choose
not to specify and keep this for only smart implementations!).


Cheers!

--

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

Re: [Lsr] Enhancements on flooding topology encoding

[tony . li]

Hi Huaimo,

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

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

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

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

Regards,
Tony



> On May 29, 2019, at 8:05 AM, Huaimo Chen  wrote:
> 
> Hi Tony,
> 
> For the three encodings below,
> Encoding A: Plain Path TLVs, where each node index uses 2 bytes,
> Encoding B: Compact Path TLVs, where each of node indexes in Path TLVs has 
> the same size given by a field in the Area Node IDs TLV with L set to one, 
> which is the size (in bits) of the maximum node index value,
> Encoding C:  Block TLVs,
> it seems that C is more efficient than A and B in general, B is more 
> efficient than A.
> For example, for representing 63 nodes flooding topology (FT for short) of a 
> binary tree in IS-IS, some comparisons among three encodings are listed in 
> the table below (In case that the formats may be messed up, a .pdf file is 
> attached).
> 
> Encoding
> Bytes used
> Comparisons
> A (Plain Path TLVs)
> 248
> 179/248 = 0.72 (72%)
> B (Compact Path TLVs)
> 179
> 121/179 = 0.68 (68%)
> C (Block TLVs)
> 121
> 121/248 = 0.49 (49%)
>  
> From the table, we can see that 248, 179 and 121 bytes are used for 
> representing the FT by A, B and C respectively. 121/248 = 0.49 (49%) means 
> that C uses about 49% of the flooding resource that A uses. 121/179 = 0.68 
> (68%) means that C uses about 68% of the flooding resource that B uses. 
> 179/248=0.72 (72%) means that B uses about 72% of the flooding resource that 
> A uses.
> 
> From this example, we can see that C is more efficient than A and B, and 
> B is more efficient than A.
> 
> Best Regards,
> Huaimo
> From: <> Tony Li [mailto:tony1ath...@gmail.com] On Behalf Of tony...@tony.li
> Sent: Wednesday, May 15, 2019 11:55 AM
> To: Huaimo Chen 
> Cc: lsr@ietf.org
> Subject: Re: Enhancements on flooding topology encoding
>  
>  
> Hi Huaimo,
>  
>  
> In one way, a TLV called Node Index Size TLV is defined. Its value field of 
> one octet contains an index size (i.e., a number of bits). When this TLV is 
> included in an LSP/LSA containing Path TLVs, all the node indexes in the Path 
> TLVs are represented using the number of bits given by the index size in the 
> Node Index Size TLV. The index size is the minimum number of bits needed to 
> represent the maximum node index in the Path TLVs.
>  
>  
> Yes, Tony P. also made this suggestion quite some time ago in a private 
> communication.  We also observed that no separate signaling of the size is 
> actually needed, as each node can look at the number of indices listed in the 
> Node Id TLV and take ceil(log2(# nodes)) and use that many bits for each 
> index.
>  
> In another way, 5 bits of the Reserved field in the IS-IS Area System IDs TLV 
> and OSPF Area Node IDs TLV with L set to one indicates the index size that is 
> used for all the node indexes in all the Path TLVs included in every LSP/LSA. 
> The index size is the minimum number of bits needed to represent the maximum 
> node index in the area.
>  
>  
> Yes, you could do that too.  That’s for ‘free’, assuming that you agree that 
> the L bit is required.
>  
>  
> 
> In another encoding, Block TLVs are used to encode the flooding topology. A 
> Block TLV represents a block of the flooding topology.  The value field of a 
> Block TLV starts with 5 bits to indicate the index size, which is followed by 
> the index of a local node, the number of adjacent nodes (in 3 bits), and the 
> indexes of the adjacent/remote nodes of the local node. This part is similar 
> to the one in a router LSA to represent the part of the topology from the 
> local node to the adjacent nodes of the local node, which can be considered 
> as a block of the topology in one level. This block can be extended to 
> multiple levels. Each of the adjacent nodes has an extension flag bit E.  An 
> adjacent/remote node with E = 1 is considered as a new local node, and its 
> adjacent nodes are added. This encoding seems more efficient.
>  
>  
> A bold claim.  Do you have any proof for this?  It seems counter-intuitive, 
> as for a bi-connected node, it would seem that its index must appear at least 
> twice, once per link.  
>  
> 

Re: [Lsr] Link State Routing (lsr) WG Virtual Meeting: 2019-05-30

[Acee Lindem (acee)]

Reminder - Virtual Interim tomorrow. 
Please read: https://www.ietf.org/id/draft-ietf-lsr-dynamic-flooding-02.txt 
beforehand. 


On 5/21/19, 3:54 PM, "Lsr on behalf of IESG Secretary"  wrote:

The Link State Routing (lsr) Working Group will hold
a virtual interim meeting on 2019-05-30 from 07:00 to 09:00 
America/Los_Angeles.

Agenda:
-  Changes to Dynamic Flooding Draft since IETF 104 – Tony Li

-  Open proposed items – Huaimo Chen

-  Discussion – All

-  Next Steps – All


Information about remote participation:
https://ietf.webex.com/meet/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] draft-ietf-lsr-isis-rfc5306bis-01

[Acee Lindem (acee)]

Hi Les, Uma,

Excuse the top-post but Outlook doesn’t do well with inline response for 
messages such as this one. AFAIK, no implementation defaulted to aborting 
graceful restart due to any topology change as recommended by RFC 3623.

Thanks,
Acee
From: Lsr  on behalf of "Les Ginsberg (ginsberg)" 

Date: Tuesday, May 28, 2019 at 9:02 PM
To: Uma Chunduri 
Cc: "lsr@ietf.org" 
Subject: Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

Uma -

From: Uma Chunduri 
Sent: Tuesday, May 28, 2019 5:09 PM
To: Les Ginsberg (ginsberg) 
Cc: lsr@ietf.org
Subject: Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01

Les,


[Les:] The timers (T1, T2, T3) are NOT relevant to PR/PA.
PR is sent BEFORE a router does a restart to alert the neighbors that the 
signaling router’s control plane is going away for a time.
RR/RA are associated with what happens AFTER the router has restarted and now 
wants to reacquire adjacencies/LSDB.

Thx. Yes, I got that.


I do not know what text in the draft suggests to you that there is any relation 
between PR/PA and RR/RA.


Newly added Section 2.2.3 a says this:

   The "remaining time" transmitted according to (b)
   below MUST reflect the actual time after which the adjacency will
   now expire.

The above is same for section 2.2.1 a, which talks about RR and RA.
This is the reason, I asked, what is the implication of same timer value here 
for PR/PA.
For example, what are the implications of this new timer times out before the 
value specified in RA (as PR is obviously initiated before) ? Also see my 
original question.


[Les:] Tx timers do NOT apply to the neighbors of the restarting router – and 
they are the only routers whose control plane is alive while the restarting 
router is reloading.

No offense intended – but your question is bizarre – I really don’t understand 
what logic leads you to ask it. ☺

[Les:] What constitutes a topology change significant enough to trigger 
bringing down the adjacency is an implementation decision.
Definition of the conditions is NOT an interoperability issue and therefore 
does not fall within the scope of the draft.



I would have agreed with the above statement if this is the guidance for the 
restarting router. Here the topology change is detected by the neighboring 
router (see your text below)  and you do want a consistent behavior from 
neighboring node from any vendor.  No?
[Les:] The neighbor is free at any time to declare adjacency to the restarting 
as down. Obviously, if it does so, this will affect forwarding in the network. 
Whether the neighbor is making the “optimal choice” based on the topology 
change is an implementation decision and it is up to the customers to judge 
whether they are happy w the implementation choice or not. It does not affect 
interoperability.

We could have been more prescriptive – similar to 
https://tools.ietf.org/html/rfc3623#section-3.2 – but I think that is 
sub-optimal. It is possible for a topology change to occur which does not 
affect forwarding via the restarting node – in which case it isn’t helpful to 
bring the adjacency down.
Rather than try to detail all possible cases, we have left it as an 
implementation decision as to how “smart” an implementation wants to be. Given 
that the neighbor will send an updated LSP of its own reflecting the down 
adjacency in such a case, the rest of the network will know that there is no 
longer a path via the restarting router.

It simply isn’t necessary to mandate a behavior.

   Les



Section 2.2.3
"  While a control plane restart is in progress it is expected that the
   restarting router will be unable to respond to topology changes.  It
   is therefore useful to signal a planned restart (if the forwarding
   plane on the restarting router is maintained) so that the neighbors
   of the restarting router can determine whether it is safe to maintain
   the adjacency if other topology changes occur prior to the completion
   of the restart. "


--
Uma C.


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

Re: [Lsr] 答复: 答复: Option B from "Migration between normal flooding and flooding reduction"

[Acee Lindem (acee)]

Hi Aijun, 
The current machinery supports a model where you can have as many area leader 
candidates as you believe you need for redundancy. It is deployment dependent 
on how many you have. We really want the same machinery to handle both failure 
or the area leader or changes to the configuration of the flooding algorithm. 
However, I'd expect the latter to be a rare event. 
Thanks,
Acee

On 5/28/19, 9:44 PM, "Lsr on behalf of Aijun Wang"  wrote:

Hi, Peter:

Under the current mechanism, only all the candidate area leaders stop 
advertise this sub-TLV, then the network will be back to normal flooding?
Is it more efficient that only one area leader indicates(according to the 
command from NMS) explicitly then the network will be back to normal flooding?

For the number of candidate area leaders, I support we should have more 
than one for consideration of redundancy.

-邮件原件-
发件人: Peter Psenak [mailto:ppse...@cisco.com] 
发送时间: 2019年5月28日 15:34
收件人: Aijun Wang; 'Tony Li'; 'Robert Raszuk'
抄送: lsr@ietf.org
主题: Re: [Lsr] 答复: Option B from "Migration between normal flooding and 
flooding reduction"

Aijun,

On 28/05/2019 08:15, Aijun Wang wrote:
> Hi, Tony:
>
> How the receiver judge the leader has stopped advertising the Area Leader 
sub-TLV? Do you need some timers?

no timer needed, all event driven. Area Leader sub-TLV is removed from the 
LSP.

thanks,
Peter

>>From the current discussion, I think the explicit instruction that 
proposed by Huaimo is more acceptable.
>
>
> Best Regards.
>
> Aijun Wang
> Network R and Operation Support Department China Telecom Corporation 
> Limited Beijing Research Institute,Beijing, China.
>
> -邮件原件-
> 发件人: Tony Li [mailto:tony1ath...@gmail.com]
> 发送时间: 2019年5月27日 12:20
> 收件人: Robert Raszuk
> 抄送: lsr@ietf.org
> 主题: Re: [Lsr] Option B from "Migration between normal flooding and 
flooding reduction"
>
>
> Hi Robert,
>
>> The current draft is pretty robust in terms of area leader election. It 
also says that  "Any node that is capable MAY advertise its eligibility to 
become Area Leader”
>
>
> Correct.  This can be all systems. It can be one. For redundancy, a few 
would be sensible.
>
>
>> With that can you confirm the procedure to "resign" as area leader ?
>
>
> Stop advertising the Area Leader sub-TLV.  It’s that simple.
>
>
>> Especially that under those circumstances just having active area leader 
to resign clearly is not enough to change given flooding scheme.
>
>
> If there are multiple potential area leaders, then all of them would have 
to resign.
>
>
>> In some deployments all eligible nodes may advertise such capability 
which in turn the "resign" procedure would require NMS action to disable such 
capability by configuration and re-flooding it. Not that I am advocating it nor 
see need for complex migration procedures, but just would like to better 
understand the "resign" part.
>
>
> Correct, this is rightfully an NMS operation.
>
> Tony
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>

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


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

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

[Acee Lindem (acee)]

Huaimo,

There have been various proposals for reducing DB synchronization over the 
years. This is not a new idea and let’s not mix it with dynamic flooding. As 
Tony replied, the IS-IS and OSPF mechanisms only specify the LSP/LSA headers to 
determine what has changed. Unless you do something similar, you don’t know how 
to “send the other end node the LSP/LSAs that are changed during the time 
period.”.

Note that while there have been many proposals, AFAIK, this optimization is the 
only one that was standardized - https://datatracker.ietf.org/doc/rfc5243/

This is out of scope for dynamic flooding. If you wish to pursue this as a 
independent item, please look the previous proposals and list discussion before 
retreading old ground.

Thanks,
Acee

From: Lsr  on behalf of Huaimo Chen 
Date: Wednesday, May 29, 2019 at 1:27 AM
To: Tony Li , "lsr@ietf.org" 
Subject: [Lsr] Enhancement on LSDB re-synchronization in Flooding Reduction


Hi Tony,



A possible enhancement on LSDB re-synchronization is described below for 
discussions.


The current method: Whenever an existing link/adjacency L is added to the 
flooding topology (FT for short), a full LSDB re-synchronization is requested 
and executed over link L. Even though the adjacency between two end nodes over 
link L is already there and their LSDBs are the same in most of situations, the 
full LSDB re-synchronization is executed, which consumes the power for 
processing IGP messages and the link bandwidth for transferring IGP messages. 
This may cause some issues if some links are added to the FT frequently.

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

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

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

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

Best Regards,
Huaimo

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

Re: [Lsr] 答复: 答复: Option B from "Migration between normal flooding and flooding reduction"

[Peter Psenak]

Hi Robert,

On 29/05/2019 10:31, Robert Raszuk wrote:

Hey Peter,

 > Is it more efficient that only one area leader
indicates(according to the command from NMS) explicitly then the
network will be back to normal flooding?

yes and we have that in the draft:

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


Two little questions ...

- I think to avoid potential ambiguity in implementations it would be 
worth clarifying what "does not advertise" means ... does it mean that 
Area Node IDs TLV is not present all together or does it mean that it


yes, Area Node IDs TLV is not present.


MAY be present but it is sufficient that it does not contain any Node ID 
.. or both ?


- how does this apply to distributed mode if flooding topology is to be 
used only in centralized mode ? Isn't the quoted text from section 6.4 a 
bit incorrect and requires a fix ?


algo 0 + no topology advertised equals to legacy flooding.

thanks,
Peter



Thx,
R.


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

Re: [Lsr] 答复: 答复: Option B from "Migration between normal flooding and flooding reduction"

[Robert Raszuk]

Hey Peter,


> > Is it more efficient that only one area leader indicates(according to
> the command from NMS) explicitly then the network will be back to normal
> flooding?
>
> yes and we have that in the draft:
>
> "When the Area Leader advertises algorithm 0 in its Area Leader Sub-
> TLV and does not advertise a flooding topology, Dynamic Flooding is
> disabled for the area.  Note this applies whether the Area Leader
> intends to operate in centralized mode or in distributed mode."
>

Two little questions ...

- I think to avoid potential ambiguity in implementations it would be worth
clarifying what "does not advertise" means ... does it mean that Area Node
IDs TLV is not present all together or does it mean that it MAY be present
but it is sufficient that it does not contain any Node ID .. or both ?

- how does this apply to distributed mode if flooding topology is to be
used only in centralized mode ? Isn't the quoted text from section 6.4 a
bit incorrect and requires a fix ?

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

Re: [Lsr] 答复: 答复: Option B from "Migration between normal flooding and flooding reduction"

[Peter Psenak]

Hi Aijun,

On 29/05/2019 03:43, Aijun Wang wrote:

Hi, Peter:

Under the current mechanism, only all the candidate area leaders stop advertise 
this sub-TLV, then the network will be back to normal flooding?


no.


Is it more efficient that only one area leader indicates(according to the 
command from NMS) explicitly then the network will be back to normal flooding?


yes and we have that in the draft:

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


For the number of candidate area leaders, I support we should have more than 
one for consideration of redundancy.


sure.

thanks,
Peter


-邮件原件-
发件人: Peter Psenak [mailto:ppse...@cisco.com]
发送时间: 2019年5月28日 15:34
收件人: Aijun Wang; 'Tony Li'; 'Robert Raszuk'
抄送: lsr@ietf.org
主题: Re: [Lsr] 答复: Option B from "Migration between normal flooding and flooding 
reduction"

Aijun,

On 28/05/2019 08:15, Aijun Wang wrote:

Hi, Tony:

How the receiver judge the leader has stopped advertising the Area Leader 
sub-TLV? Do you need some timers?


no timer needed, all event driven. Area Leader sub-TLV is removed from the LSP.

thanks,
Peter


>From the current discussion, I think the explicit instruction that proposed by 
Huaimo is more acceptable.


Best Regards.

Aijun Wang
Network R and Operation Support Department China Telecom Corporation
Limited Beijing Research Institute,Beijing, China.

-邮件原件-
发件人: Tony Li [mailto:tony1ath...@gmail.com]
发送时间: 2019年5月27日 12:20
收件人: Robert Raszuk
抄送: lsr@ietf.org
主题: Re: [Lsr] Option B from "Migration between normal flooding and flooding 
reduction"


Hi Robert,


The current draft is pretty robust in terms of area leader election. It also says 
that  "Any node that is capable MAY advertise its eligibility to become Area 
Leader”



Correct.  This can be all systems. It can be one. For redundancy, a few would 
be sensible.



With that can you confirm the procedure to "resign" as area leader ?



Stop advertising the Area Leader sub-TLV.  It’s that simple.



Especially that under those circumstances just having active area leader to 
resign clearly is not enough to change given flooding scheme.



If there are multiple potential area leaders, then all of them would have to 
resign.



In some deployments all eligible nodes may advertise such capability which in turn the 
"resign" procedure would require NMS action to disable such capability by configuration 
and re-flooding it. Not that I am advocating it nor see need for complex migration procedures, but 
just would like to better understand the "resign" part.



Correct, this is rightfully an NMS operation.

Tony

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

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








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