Subject: [Isis-wg] Subsecond holding time for IS-IS?

From: Radia Perlman <[email-masked]>
Date: Mon, 05 Jan 2009 15:52:16 -0800

It might be nice to allow subsecond holding times for adjacencies.

There was an ancient draft

http://www.watersprings.org/pub/id/draft-parker-short-isis-hold-times-01.txt

that seems to have expired, unless it got turned into an RFC that I 
couldn't find.

It seems noncontroversial. It's a new TLV for expressing holding times 
in milliseconds. If a neighbor N1 doesn't support
this TLV, it just means that N2, who wants to send hellos every 
millisecond, will be sending lots more hellos than
necessary to keep the adjacency from N1-N2 up, since N1 will be assuming 
a holding timer of 1 second.

What ever happened with this?

Thanks,

Radia
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Ramesh Yeevani-Srinivas <[email-masked]>
Date: Mon, 5 Jan 2009 16:11:50 -0800

Radia,
Network admins are using BFD to address sub second detections across wide range of links. Also using common infrastructure like BFD will help reduce control traffic rather than using per protocol detection, so I am not sure how useful is this functionality in current networks.

Thanks
Ramesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Radia Perlman
Sent: Monday, January 05, 2009 3:52 PM
To: [email-masked]
Subject: [Isis-wg] Subsecond holding time for IS-IS?

Thanks,

Radia

---

From: Danny McPherson <[email-masked]>
Date: Mon, 5 Jan 2009 17:23:41 -0700

On Jan 5, 2009, at 5:11 PM, Ramesh Yeevani-Srinivas wrote:

> Radia,
> Network admins are using BFD to address sub second detections across  
> wide range of links. Also using common infrastructure like BFD will  
> help reduce control traffic rather than using per protocol  
> detection, so I am not sure how useful is this functionality in  
> current networks.

Yep, MARP, BFD and more general purpose solutions
were put in place to address the problem and so we
let it expire.

If there's some specific application that's not being
addressed, or that can't employ BFD protocols, and
general consensus it's a good idea, would be happy to
consider revamping, as it is rather trivial.

-danny

---

From: "Jeff Parker" <[email-masked]>
Date: Mon, 5 Jan 2009 19:22:08 -0500

I am having trouble remembering what happened to this proposal.
It seems too early to be overtaken by the BFD protocol proposals.

I bet there was a discussion about melt downs in the past, and an
unwillingness to pick it up.  There doesn't appear to have been enough
interest for a second draft.

- jeff parker

On 1/5/09, Radia Perlman <[email-masked]> wrote:
>  It seems noncontroversial. It's a new TLV for expressing holding times in
> milliseconds. If a neighbor N1 doesn't support
>  necessary to keep the adjacency from N1-N2 up, since N1 will be assuming a
> holding timer of 1 second.
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 5 Jan 2009 16:48:22 -0800

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Danny McPherson
> Sent: Monday, January 05, 2009 4:24 PM
> To: Perlman Radia; Ramesh Yeevani-Srinivas
> Cc: [email-masked]
> Subject: Re: [Isis-wg] Subsecond holding time for IS-IS?
> 
> 

I think we need to be careful here. As stated in the old draft in
Section 8:

"Short hold times cannot be used without careful thought and
engineering."

This is well said - and the draft does a good job of discussing the
decidedly non-trivial implementation issues. All of this is relevant to
BFD - and the BFD protocol and its implementations (at least those that
can claim to be reliable and scalable) have taken a good amount of care
in addressing those issues.

It is also relevant to note that the earlier statement by Radia to the
effect that it really doesn't matter if your neighbor doesn't support
this option since you will simply be sending hellos faster than
necessary glosses over the impact that the increased incoming IIHs will
have on the neighbor's performance. This is why BFD made sure that
timers were negotiated and can always be limited by the receiver.

If there is a good reason to revive this draft (and I haven't heard it
yet) - we should recognize that doing so is decidedly NOT trivial.

   Les

---

From: Danny McPherson <[email-masked]>
Date: Mon, 5 Jan 2009 17:54:49 -0700

> yet) - we should recognize that doing so is decidedly NOT trivial.

Fair enough.  I'm starting to better recollect the
discussions we had on this topic in 2001-02..

-danny

---

From: mike shand <[email-masked]>
Date: Tue, 06 Jan 2009 12:05:59 +0000

Yes, I would be very reluctant to resurrect this. BFD is a much better 
solution.

The other issue with fast IS-IS hellos that has only been hinted at thus 
far is the fact that IS-IS hellos actually perform two functions.

1. Adjacency formation and information passing
2. adjacency maintenance

The consequence of (1) is that the hellos contain a lot of baggage which 
is really only needed at adjacency formation, or at most infrequently. 
Sending this information at millisecond intervals is both inefficient, 
and more importantly imposes a load on the receiver which has to parse 
and verify a considerable amount of information. This can become 
particularly onerous when considering systems with large numbers of 
interfaces, perhaps in the 100s.

It was for these reasons that BFD was invented to provide a very simple 
"fast hello" for the sole purpose of adjacency maintenance, leaving the 
normal IS-IS hello to handle formation etc. at a MUCH less frequent 
interval.

The other advantage of BFD which has already been mentioned is its 
ability to perform adjacency maintenance for multiple protocols with a 
single message, thus avoiding the compounding of the problem which would 
occur if multiple protocols adopted the millisecond hello approach.

    Mike

---

From: "Tony Li" <[email-masked]>
Date: Tue, 6 Jan 2009 10:52:03 -0800

+1 

|-----Original Message-----
|From: [email-masked] 
|[mailto:[email-masked]] On Behalf Of mike shand
|Sent: Tuesday, January 06, 2009 4:06 AM
|To: Danny McPherson
|Cc: Les Ginsberg (ginsberg); [email-masked]
|Subject: Re: [Isis-wg] Subsecond holding time for IS-IS?
|
|Yes, I would be very reluctant to resurrect this. BFD is a much better 
|solution.
|
|The other issue with fast IS-IS hellos that has only been 
|hinted at thus 
|far is the fact that IS-IS hellos actually perform two functions.
|
|1. Adjacency formation and information passing
|2. adjacency maintenance
|
|The consequence of (1) is that the hellos contain a lot of 
|baggage which 
|is really only needed at adjacency formation, or at most infrequently. 
|Sending this information at millisecond intervals is both inefficient, 
|and more importantly imposes a load on the receiver which has to parse 
|and verify a considerable amount of information. This can become 
|particularly onerous when considering systems with large numbers of 
|interfaces, perhaps in the 100s.
|
|It was for these reasons that BFD was invented to provide a 
|very simple 
|"fast hello" for the sole purpose of adjacency maintenance, 
|leaving the 
|normal IS-IS hello to handle formation etc. at a MUCH less frequent 
|interval.
|
|The other advantage of BFD which has already been mentioned is its 
|ability to perform adjacency maintenance for multiple protocols with a 
|single message, thus avoiding the compounding of the problem 
|which would 
|occur if multiple protocols adopted the millisecond hello approach.
|
|    Mike
|
|
|Danny McPherson wrote:
|>>
|>>
|>> It is also relevant to note that the earlier statement by 
|Radia to the
|>> effect that it really doesn't matter if your neighbor 
|doesn't support
|>> this option since you will simply be sending hellos faster than
|>> necessary glosses over the impact that the increased 
|incoming IIHs will
|>> have on the neighbor's performance. This is why BFD made sure that
|>> timers were negotiated and can always be limited by the receiver.
|>>
|>> If there is a good reason to revive this draft (and I 
|haven't heard it
|>> yet) - we should recognize that doing so is decidedly NOT trivial.
|>
|> Fair enough.  I'm starting to better recollect the
|> discussions we had on this topic in 2001-02..
|>
|> -danny
|> _______________________________________________
|> Isis-wg mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/isis-wg
|>
|
|_______________________________________________
|Isis-wg mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/isis-wg
|