Subject: fast protocol hellos

From: Kireeti Kompella <[email-masked]>
Date: Wed, 30 Oct 2002 11:24:17 -0800 (PST)

Hi All,

I have a proposal for fast protocol keepalives, PLP.  Essentially, a
keepalive captures the liveness state of a number of protocols as
a bit vector: the keepalive is small and can be processed quickly,
hence can be sent fairly often.  A key point is that existing
protocols (ISIS, OSPF, ...) need not be modified except to accept
PLP triggers regarding the liveness of a neighbor.

The details are in draft-kompella-rag-plp-00.txt, which should be
in the repository now.

Comments would be lovely.

Kireeti.

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: "Naidu, Venkata" <[email-masked]>
Date: Wed, 30 Oct 2002 17:08:40 -0500

Kireeti,

  Here are my comments. As the protocol - PLP - is new, most of
  my thinking whenever I read a sentence will be - " WHY ? "
  No need to answer every "why?" but that will help us to improve
  the protocol. :-)

 1. First of all, 10,000 ft view, before I even went into details,
    won't LMP protocol solve all the benefits we get from PLP ?
    My understanding of LMP is, it can be used to do the stuff
    exactly the way you described in PLP. Previously to LMP, there
    were proprietary implementations to inform about a link status
    to the *registered* protocols.

 2. 1000 ft view, if we go into details and compare the *part of LMP*
    with PLP, I would say:

    - every interested protocol in a router makes a *registration*
      with LMP module for link-status callbacks.

    - LMP hellos are exactly same as you described, very granular 
      and quick. Ofcourse, you took the ISIS approach and LMP took 
      OSPF approach (thanks for that)

    - When ever link goes down, LMP protocol informs all the
      registered protocols about the link-status.

    - Protocols will take appropriate action. It is fast & quick.

 3. Now the 100 ft view. The only stuff which is not in LMP but in 
    PLP is the "Protocol Information". That is, what are the
    protocols are active on the link. Do we really need that info ?
    It is internal to the routers, adjacent routers know what 
    are the protocols active on a *link*. If a *link* goes down, 
    then it is up to a routers internal matter (no interoperable 
    issues) that how fast it detects and informs the active 
    protocols on *that* link.

 4. Umm!! I don't know how to describe this - let me try - the 
    granularity of message on the wire some times significantly
    carry only a single protocol PLP messages. For example,
    between 2 BGP peers, all the PLP message between them will
    have only BGP bit set. If that is the case, for most of the
    adjacencies (either directly connected or not) the amount/%
    of PLP messages carried over such adjacencies will be
    very high (even in a short time scale) when compare to 
    protocol-independent-link-management-protocol like LMP.

 5. 10 ft view - minor PLP protocol concerns.
   
    - How does PLP knows whether the adjacent router is directly
      connected or not ? User configuration ?

    - Does PLP support neighbor discovery ? If not, the other
      side of the link address must be configured. If the 
      neighbor/peer is not directly connected then it must need
      a neighbor address configured.

    - Protocol Registry/Status fields are very small to accommodate
      large number of protocols. 32-bits will hold for 32 protocols.
      PLP is generic enough for past/present/future all types
      protocols. So try to increase the space for protocol registry.

    - LMP is missing in the references :)

  Overall, the idea is good. But just my thoughts to improve the
  protocol usefulness by comparative analysis. :-)

  Thank you.

--
Venkata.

-> Hi All,
-> 
-> I have a proposal for fast protocol keepalives, PLP.  Essentially, a
-> keepalive captures the liveness state of a number of protocols as
-> a bit vector: the keepalive is small and can be processed quickly,
-> hence can be sent fairly often.  A key point is that existing
-> protocols (ISIS, OSPF, ...) need not be modified except to accept
-> PLP triggers regarding the liveness of a neighbor.
-> 
-> The details are in draft-kompella-rag-plp-00.txt, which should be
-> in the repository now.
-> 
-> Comments would be lovely.
-> 
-> Kireeti.
-> 
-> _______________________________________________
-> routing-discussion mailing list
-> [email-masked]
-> https://www1.ietf.org/mailman/listinfo/routing-discussion
-> 
_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: "David Allan" <[email-masked]>
Date: Thu, 31 Oct 2002 10:04:39 -0500

Brian/Kireeti

I was also going to point towards FLIP. IMHO it had a lot of well thought
out stuff in it.

I agree that increasing use of control plane restart and the number of
protocols used on an adjacency means a separate and decoupled livliness test
makes a lot of sense. Bundling in some local supervisory information on
protocol daemons I'd have some questions about as I merely have more ways to
know the same thing, and the plurality of mechanisms may provide conflicting
information that hampers interoperability. At the same time, not all
exchange is with a directly connected peer so presumably protocols need to
retain some degree of livliness when PLP is deployed (e.g. I doubt it would
use it with an RR). IMHO Nothing beats actual message exchange between
protocol peers for ensuring things are working. 

If control plane protocols are not expected to stunt double for fast
livliness as well their normal function, they should be just fine. Seems to
me you just scale the restart timers according to some reasonable frequency
of protocol exchange.

cheers
Dave

---

From: "David Allan" <[email-masked]>
Date: Thu, 31 Oct 2002 10:04:39 -0500

Brian/Kireeti

cheers
Dave

---

From: "Naidu, Venkata" <[email-masked]>
Date: Thu, 31 Oct 2002 10:39:25 -0500

Kireeti,

  Some e2e arguments w.r.t PLP.

  1. For example, MPLS TE (with/without diffserv) applied to layer 4
     flows. In other words, UDP and TCP flows can be separated 
     into different tunnels (to differentiate flows for better QoS).
     Using PLP we are trying to synchronize TCP users/applications
     (for example, BGP and targeted-LDP) using UDP based fast hellos.
  
     If by chance UDP flows are congested, the impact on TCP 
     applications should be well understood. After all, protocol
     should not toggle even in rare/corner cases. PLP should be
     defined in such a way that even mis-configuration of PLP hello
     timers should not impact protocol robustness that much.
     (May be I am looking too much into future, but it is valid).

     (The above situation may not have any impact on protocols using
     raw IP - even in non-directly connected cases - for example,
     RSVP with some non-RSVP capable routers in between and OSPF
     virtual links etc).

  2. Congestion Control - PLP hellos MUST be given very very high
     priority to avoid unnecessary protocol toggling. The situation
     is very simple to reproduce, a simple *burst* in traffic
     can clog a part of network for very short period of time. This
     is a very common situation in core IP networks. If the 
     congestion avoidance time is little longer than PLP hello dead
     timer, then protocols toggle unnecessarily. Make sure this should
     not happen by giving high priority to PLP hellos.

-> >  3. Now the 100 ft view. The only stuff which is not in LMP but in
-> >     PLP is the "Protocol Information". That is, what are the
-> >     protocols are active on the link. Do we really need that info ?
-> 
-> If individual protocols go down, or are de-configured, or whatever,
-> PLP can say so.
->
-> >     protocol-independent-link-management-protocol like LMP.

   Got your point. What I meant by *protocol-independent* is that, PLP
   carries some bits (state information) of protocols on a router.  
   Where as a self-driven protocol (for example, LMP) won't carry any
   information of other protocols on a router. Protocols can *infer*
   other end peer-protocol status using LMP link connectivity.

   Yes! by carrying *protocol state* information in PLP, we get some
   advantage (after all, PLP is protocol liveness). 

   Thanks!

---

From: "Naidu, Venkata" <[email-masked]>
Date: Thu, 31 Oct 2002 10:39:25 -0500

Kireeti,

  

   Thanks!

---

From: "Don Fedyk" <[email-masked]>
Date: Thu, 31 Oct 2002 14:54:50 -0500

Kireeti

You wrote: 
> On Wed, 30 Oct 2002, Naidu, Venkata wrote:
> 
> "Why"s are good questions.  I'll do my best to answer.
> 
> No.  LMP is for Link Management.  Link management in the LMP 
> context does not mean link up/down-ness; rather, when you 
> have multiple links between two entities, assigning 
> consistent port ids to the links, bundling them correctly 
> into TE links, assigning/verifying link properties, assigning 
> control channels to the TE links, etc.
> 
> One usually doesn't have multiple router-to-router links; one 
> never has separate control and data interfaces router-to-router.
> 
> Furthermore, the control channel management in LMP does way 
> more than what is needed here -- parameter negotiation, 
> alternative control channels, state machine, ....  All PLP 
> wants is protocol liveness.
> 
>
Kireeti

If I understand this you are proposing the liveness of protocols to be
constantly pulsed out to neighbor nodes. 

What I struggle with is: Is it the fast detection of protocol adjacency; or
the loss of neighbor adjacency you are trying to determine? To me it seems
neighbor adjacency is the primary knowledge and protocol adjacency is a time
delayed function since protocols may recover independent of forwarding
state. If a protocol goes down is it critical to know on a neighbor switch?
If the forwarding plane is intact I would think the hello interval would
suffice. If the forwarding plane is not intact then the links should be
taken down. What additional value do you get know the protocol is down?

The other way to achieve a similar scheme is to constantly run heartbeats
for the state of links (or link bundles to neighbors) and assume that
protocols are up unless the neighbor heartbeat dies.  This means that the
slower individual protocol hellos would have to be used to determine that an
instance of the neighbor protocol was down, but for true link failures or
loss of neighbor you could achieve fast detection. The advantage of piggy
baking this heartbeat on LMP would be that lower level restoration or
protection state could also be introduced allowing protection coordination.
No sense detecting a 1+1 or N+1 recovery of a lower layer. 

To my recollection that was the whole purpose for including Flip. (Fast
Liveness protocol in LMP). It seems to me each link should have some fast
liveness detection. Then these functions should be summarized for protocols,
be they routing or TE. There are different actions for the bundled links and
the individual links. 

Don

---

From: [email-masked]
Date: Fri, 1 Nov 2002 00:21:42 +0100

Hi Kireeti,
lately I've been wondering about the fact that FLIP disappeared or 
"sorta went into LMP" as Brian Haberman put it. So I was happy to 
see your PLP proposal which to me seems to (at least in part) have 
the same goal as FLIP; a lightweight adjacency keepalive mechanism. 
I have some questions about it, maybe you can put me straight?

PLP seems to be a very elegant design where negotiation has been left
to whatever protocol PLP is supporting with the added functionality 
(compared to FLIP) of supporting alarms from several protocols and 
protocol sessions which are not topologically adjacent. I guess, though, 
that such things come at a cost? 

Lack of negotiation means that there is a dependency on other protocols 
to trigger PLP when they have negotiated. Isn't there a certain value 
to not having this dependency when implementing PLP in routers? For 
example, if all we really want to implement is an adjacency keepalive 
mechanism (protocol number 31, layer-2) then don't we still have to 
implement the ability to trigger PLP in our routing protocols?
 
A neighbour that does not support PLP or the PLP dead interval 
announced will simply discard our hello packets. Doesn't this make the 
PLP session slightly difficult to monitor? Since we don't have the 
expectation of an actual session forming I guess it would be difficult 
to get an alarm if it doesn't form?

If I've understood the receivers processing correctly a protocol session 
should be regarded as down if the protocol status is changed to down in 
one packet. This would mean that a single bit error would cause the 
restart of a protocol session. (?)  

Cheers,
	Henrik Villfor.

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: den 30 oktober 2002 20:24
> To: [email-masked]
> Cc: Kireeti Kompella
> Subject: fast protocol hellos
>
>
> Hi All,
>

---

From: [email-masked]
Date: Fri, 1 Nov 2002 00:21:42 +0100

Hi Kireeti,

 

Cheers,
	Henrik Villfor.

---

From: "Naidu, Venkata" <[email-masked]>
Date: Thu, 31 Oct 2002 18:42:12 -0500

Curtis,

-> Note that a slow reciever can consider the dead interval to 
-> be longer.
-> The sender is only indicating that it can send regularly at 
-> the higher
-> interval.
-> 
-> It still might be worth having a "slower please" message to indicate
-> that while the sender can put out one packet per microsecond the
-> receiver would have trouble processing the load and it would do no
-> good to send faster than some specified rate.

  To be frank, I don't think adding messages to do *flow control* is
  necessary. Keep the protocol simple and fast - as simple as
  as to implement in line cards.

  If we keep adding such messages for *binary on/off flow control*
  mechanisms then some "state machine" is also required. How much
  slow is slow to the receiver ? All such questions require
  some statistical data (as TCP guys did over years).

  Though your suggestion solves some issues, possibly, unnecessary
  packet loss of hellos if the senders rate is higher than
  receiver's processing speed, but I don't think that solve
  any practical problems in practical networks (apart from corner
  cases).

  Comments are welcome. Thanks You.