Subject: RE: fast protocol hellos

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: Kireeti Kompella <[email-masked]>
Date: Wed, 30 Oct 2002 16:52:52 -0800 (PST)

Hi Venkata,

Thanks for your comments!

>   No need to answer every "why?" but that will help us to improve

"Why"s are good questions.  I'll do my best to answer.

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

>  2. 1000 ft view, if we go into details and compare the *part of LMP*

No "why" here :-)

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

>     very high (even in a short time scale) when compare to

If you mean that much of the time PLP messages will carry only one
protocol, the answer is it really depends on the SP.  Typically, an
ISP runs an IGP and BGP on every box.  An SP running MPLS will also
have LDP and/or RSVP.

>     protocol-independent-link-management-protocol like LMP.

PLP *is* protocol independent.  Moreover, the "L2" protocol will
accomplish most other things.

>  5. 10 ft view - minor PLP protocol concerns.

This is a first draft, things will have to be fixed/clarified.  As for
neighbor discovery, that is *not* a goal of PLP -- the goal is simply
fast liveness detection.

Kireeti.

---

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

Hi Venkata,

No "why" here :-)

Kireeti.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 31 Oct 2002 12:34:01 +0100

Hey Kireeti,

After digesting this draft a bit I have a few questions/observations ...

First I think the main intention of this draft is great. If I understood
the draft that would be "instead of speeding up hellos on multiple
protocols between given two peers let's have a common way to exchange
liveness of it's components without shortening hello intervals multiple
times between them. 

1. Draft seems to be leaving a lot of freedom reg implementation :). I
think that 100 ms recommended intervals may not be doable when RP CPU is
the responder to those PLP msgs. There could be quite a few directly
connected peers + the whole bunch of remote peers each bombarding you
with PLP msgs ;). Pushing the response to intelligent line cards would
seem like the only hope here. 

2. Reg protocol registry & status ... Hmm draft goes well into the
future assuming nice protocol modularity. Now with this modularity
nothing has been said about interdependencies. For example IGP/LDP
combination. We get event PLP Down for IGP and no change for LDP ...
Should LDP do nothing if it is quite obvious that LDP is based on IGP
routes ? The same goes for IGP/RSVP or IGP/BGP interactions. 

One thing I have noticed is some folks giving recommendation to have IGP
hellos and RSVP hellos both max-ed out. I think this is misconfiguration
as one should make up it's mind if he cares for IGP convergence or FRR
(node protection case). Not both in the same time.

In other words why not just use IGP convergence properties and it's own
detection to relay on in most cases for directly connected peers on
either point to point or multi-access (one way of doing it on the latter
one you will see in Atlanta :):).

Now said this I see a value of detecting BGP liveness alone (provided it
is extended per AF basis !!) or value of adding detection of liveness
for IP tunnels (GRE, L2TPv3 ...). 

3. Another issue is that practically today (well at least in routers I
am bit familiar with) either all protocols go down or non. So PLP would
do no good here as indication that all remote components went down would
easily get us into the local computing resources starvation. In other
words it is good that IGP converges first then BGP after 180 sec clears
his IBGP peer. Even looking into the future when full modularity is
here, each module runs on it's own CPU etc ... there is some likehood
for failure report synchronization caused by PLP.

So PLP draft should I think at suggest some way of prioritization when
multiple protocols are reported down - again that is quite
implementation dependent :).

I think this is enough as an appetizer ...

R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 31 Oct 2002 12:34:01 +0100

Hey Kireeti,

R.

---

From: Brian Haberman <[email-masked]>
Date: Thu, 31 Oct 2002 08:47:19 -0500

> implementation dependent :).

It also looks very similar to the fast link-liveness work that sorta
went into LMP.

www.ietf.org/proceedings/00mar/slides/ POWERPOINT/ipo-flip-00mar.ppt

Brian

---

From: Brian Haberman <[email-masked]>
Date: Thu, 31 Oct 2002 08:47:19 -0500

Brian