Subject: RE: fast protocol hellos

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:
> 
> >   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. :-)
> 
> "Why"s are good questions.  I'll do my best to answer.
> 
> >  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 ?
> 
> 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, 01 Nov 2002 00:53:21 +0100

kireeti,

you wrote:
> LMP is for Link Management. 

application of the LMP principle(s) to ethernet environments 
or other delivers what you call in this i-d "An ancillary 
application of PLP is for interface liveness." i just refer 
you to the section 3 of LMP and you will see the analogy
with what's defined here "In this case, the Config message 
exchange can be used to dynamically learn the IP address on 
the far end of the control channel. This is done by sending 
the Config message to the Multicast address (224.0.0.1)." 
the main difference being that LMP based this liveness 
mechanism is based on the maintenance of an entity the 
bidirectional "control channel" (setup using the Config 
message exchange) since LMP Hello's maintain the control 
channel while plp does the same but based on the reception 
of the Hello

i can understand that over time LMP has a bit shifted (or 
more precisely has received more attention on some parts of 
its capabilities) thus were i agree is that it does more 
than what you expect however as far as i know nobody has 
taken a closer to the applicability (and profiling) of LMP 
for layer-2 environments. It has to be noticed that the
number of nodes is expected to be limited.

i would be more in favor of fine tuning LMP for ethernet
interface liveness while considering PLP for what it does
"protocol independent mechanisms deadness detection"

thanks,
- dimitri.

> Don Fedyk wrote:
> 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

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361
_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

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

kireeti,

thanks,
- dimitri.