Subject: RE: fast protocol hellos

From: "Naidu, Venkata" <[email-masked]>
Date: Fri, 1 Nov 2002 09:26:26 -0500

-> I didn't mean flow control.  What I meant was a one time message
-> indicating a maximum rate (minimum Dead Interval) that the receiver
-> can (is willing to) tolerate.

  Agreed.

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

---

From: "Naidu, Venkata" <[email-masked]>
Date: Fri, 1 Nov 2002 09:26:26 -0500

Agreed.

---

From: "Konrad Feyerabend (ERA)" <[email-masked]>
Date: Wed, 6 Nov 2002 19:52:43 +0100

Hi Kireeti,

I really like the simplicity of your proposal, which makes the protocol extremely lightweight.

Some comments, anyhow.
1) If I understand the intention of the draft right, multicast is proposed towards directly connected peers to minimize load on the individual hosts and on the link for broadcast media. Again, I like that idea, since that way you could have a very fast router dead indication towards ordinary IP hosts as well. 
I see the need for point-to-point indications of protocol status, however:  
In the current proposal, a router A will judge liveness towards a peer B just by supervising the receiving of PLP hellos from B. There is no acknowledgement of hellos. So  router A does not get feedback on whether peer nodes received it's own hellos as well. If we just loose the transmit direction of A (e.g. a broken fiber from A to a L2 switch), the router will not recognize that the adjacency is lost (at least not immediately by PLP). If we would only have point-to-point PLP, peer router B could toggle the protocol status bits to indicate that it took the adjacency down, thus giving an indirect indication to A that something is wrong. Using multicast messages on a broadcast media, B cannot do so if there is another router C to which B still has contact. Otherwise, a broken fiber or router A to the LAN switch might bring all routers on the LAN down, definitely a unwanted effect. But if the other routers cannot indicate to A that something is wrong, A will have a different v!
iew of the topology than all other routers.
(You could claim that the routing protocol that got the down event should indicate to it's peer about the new status, but not all services that could use PLP provide such functionality. Pure L2 supervision is an example where you don't have an additional protocol)

Thus, I would propose a slightly different protocol structure, where hellos and control are separated: Hellos can be sent continuously, even before the first adjacency is up. They can be sent as multicast, as described in the draft. No protocol registry/protocol status field is present in the hellos. Additionally, a control protocol using handshakes and unicast messages is used to subscribe individual services (routing protocols)  to PLP for individual peers. Then, if a router, which detects that it does no longer receive PLP hellos from a certain peer that is subscribed for a certain protocol, it sends a unicast message to that individual peer to indicate the change in adjacency.

This also has the nice side-effect that we are not limited by the size of the protocol registry in the number of protocols we can support, since the control messages can be much more complex than the hello messages.

2) Again, having in mind that PLP could be useful for link supervision towards hosts as well. e.g. on Ethernet, I would propose to have two multicast addresses: ALL-PLP-ROUTERS and ALL-PLP-HOSTS. That way, hosts can subscribe to their default and backup routers for link supervision (by the mechanism proposed in comment 1). The routers can send their hellos to ALL-PLP-HOSTS, so that the hosts can supervise liveness of their default router, whereas hosts only send their hellos to ALL-PLP-ROUTERS. That way, routers that may implement handling of PLP hellos in hardware will see all the hellos and may support supervision towards 100s of hosts, whereas hosts, that probably will not have such hardware support for a long time to come, only see the hellos they are really interested in.

BR
/Konrad

---

From: "Konrad Feyerabend (ERA)" <[email-masked]>
Date: Wed, 6 Nov 2002 19:52:43 +0100

Hi Kireeti,

Some comments, anyhow.

BR
/Konrad

---

From: "Bakshi, Sanjay" <[email-masked]>
Date: Sun, 10 Nov 2002 20:25:01 -0800

Hi Kireeti,
The protocol is simple and solves an important problem.
The protocol is targeted at two problems 1) state of connectivity to peer 
and 2) peer protocol state.
Why is not just solving bullet 1 enough? What is the value of solving the
bullet 2?  As you have mentioned in the draft, the individual protocols will

continue with their respective versions of Hello or similar mechanisms.
Shouldn't these mechanism augmented by the fast peer connectivity
determination be enough?

Regards,
Sanjay

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]] 
Sent: Thursday, October 31, 2002 9:53 AM
To: Kireeti Kompella
Cc: [email-masked]
Subject: Re: fast protocol hellos 

In message <[email-masked]>, Kireeti
Kompella 
writes:
> 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.
> 

Kireeti,

The protocol is simple, does one thing and does it reasonably well.
It certainly solves a problem for GbE and 10GbE or other interface
that doesn't have a fast link layer fault detection.

This would be very easy to implement on (smart) line cards for a very
fast indication of liveness (or non-liveness) and there is enough
dynamic range in the "Dead Interval" (2^24 microseconds ~ 16 seconds)
to accommodate even relatively slow implementation done in a route
processor.

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.

It might also be worth noting that the PLP packets need to be stuck
into or near the front of any queue to support really short intervals.

Curtis

---

From: "Bakshi, Sanjay" <[email-masked]>
Date: Sun, 10 Nov 2002 20:25:01 -0800

Hi Kireeti,

Regards,
Sanjay

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]] 
Sent: Thursday, October 31, 2002 9:53 AM
To: Kireeti Kompella
Cc: [email-masked]
Subject: Re: fast protocol hellos 

Kireeti,

Curtis

---

From: Naiming Shen <[email-masked]>
Date: Tue, 26 Nov 2002 00:41:46 -0800

Kireeti,

Just read the PLP draft, moving fast keepalives to be protocol
independent makes lot of sense. some thought on the draft:

(1) r bit
    
    Not sure what's the use of this "r" bit. This PLP is supposed to  
    detect the link between the two nodes. This to me should always
    be considered as "local". Even if there is a tunnel between two
    nodes, this PLP should be used to detect the liveness of the
    tunnel(not any path between two nodes), so it's still local to
    the tunnel circuit. 
    
(2) protocol bits
    
    The reasons I have read so far from the mailing list of using
    protocol bits is to tell neighbors if some protocol is de-configured,
    or is down. I don't see how much useful this can be. If a protocol is
    de-configured, and assume the protocol does care, it could have sent
    out a holdtime zero kind of keepalive(or inform dead) message to
    inform all neighbors to tear it down faster; also it's a user  
    configuration issue, it's not a big deal to delay the detection.
    If the protocol is dead/down, then the issue is more complicated,
    since routers are usually running with graceful restart, it's
    not clear what this one bit of protocol down suppose to inform
    the neighbors to do. Should the protocol disregard the current
    graceful restart practice and do something different? probably
    not a good idea. And how does the neighbors know it's a de-config 
    or a "graceful" restart?
    
    In de-config case, take an example of IS-IS, it could have  
    L1/L2 running on the intf, then L1 is de-configured. It would 
    be nice for all the L1 adjacencies(but not the L2 adjacencies)
    to timeout with this router immediately to reduce the packet loss.
    Then should the PLP take up this kind of task?
    
    The purpose of PLP is to enable fast link failure detection, we 
    should keep it this way and to make it as SIMPLE as possible.
    
(3) auto-configuration and protocol bits
    
    Actually this protocol bits can be very useful to simplify the 
    PLP configuration or the interaction between the PLP and protocols.
    The current draft needs to have each protocol to tell the PLP
    which interface, and which neighbor's router id to detect PLP
    status from.
    
    It would be useful to use this PLP protocol bits for auto-configure
    purpose. When a protocol is configured on the interface, (and only
    those protocols configured on the interfaces need to rely on PLP as
    far as I can tell) so the PLP protocol bit for that protocol of
    the interface is automatically set. When a PLP receiver gets a
    PLP packet, it first checks to see if it has this router-id in its
    database(intf related), if not, then checks if this PLP packet's
    protocol bits have any overlap with its own protocol bits, it will
    install this neighbor's PLP record only if there is at least one
    protocol bit in common. Otherwise throw away the PLP packet.
    This way, there is no explicit configuration or PLP and protocol
    interaction is needed to maintain this {interface, neighbor} tuple. 
    
    I would suggest just use one set of "registered protocol" bits for
    the PLP auto-configuration, there is not much need for protocol
    status bits.

(4) non-local PLP
    
    The draft describes a PLP operation between two remote routers.
    If a protocol has a peer multiple hops away, such as ibgp peer,
    or multi-hop ebgp peer, to do this with fast "peer down" detection 
    is probably not a good idea. If this is an ibgp peer session,  
    and if there is no reachability to its peer, igp should respond
    much earlier; If this is multi-hop ebgp peer, you probably
    always have some reachability, even though may go circle around 
    the globe to reach it.
    
    Since there is no interface involved, each pair of PLP needs
    explicit configuration. Also assume the PLP is implemented on  
    the linecards, the PLP neighbor status database itself is on the
    linecard, but the inbound PLP packets can come into any linecards,
    even though there is ways to deal with, but probably not worth
    doing. How do you also guarantee the seq# through the multi-hop
    PLP being kept in order at the receiver?

    If there is a tunnel between two remote nodes, it could be useful
    to have the PLP inside the tunnel itself, which can still be
    considered as "local" interface just like normal interfaces.
    
(5) graceful restart of PLP :-)
    
    During PLP restart, either each PLP on linecards or implemented
    in routing processor, the seq# has to be kept for each interface
    across the restart. Otherwise, according to the draft, lower
    seq# PLP packet is going to be thrown away, then all the PLP    
    sessions will timeout. How fast the PLP module can come back 
    alive after restart also limits how low the PLP dead interval
    should be set.

cheers.

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

- Naiming

---

From: Naiming Shen <[email-masked]>
Date: Tue, 26 Nov 2002 00:41:46 -0800

Kireeti,

(1) r bit

(2) protocol bits

    

    

(4) non-local PLP

    

cheers.

 ] Hi All,
 ] 

- Naiming