Subject: Re: fast protocol hellos

From: Alvaro Retana <[email-masked]>
Date: Fri, 1 Nov 2002 09:08:32 -0500 (EST)

Hi!  While we're on this subject...

We recently submited a draft on what we call MARP -- MultiAccess
Reachability Protocol -- yes, the *name* kindda sucks (no relationship to
ARP)...but we're open to suggestions. ;-)

MARP addresses some of the same things that have been discussed in this
thread, but more specifically fast L2 failure detection/notification.
The traditional approach to detect neighbor failures (or L1/L2 failures -
on multiaccess networks, for example) has been to send/receive "fast
hellos".  MARP takes an "event driven" approach: it facilitates the
notification of *loss of L2 reachability*, which translates into not being
able to reach your L3 peers.  We believe that the application extends not
only to routing protocols...pls take a look:

http://www.ietf.org/internet-drafts/draft-retana-marp-00.txt

Any/all comments are welcome. :-)

TIA,

Alvaro.

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

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 1 Nov 2002 09:08:32 -0500 (EST)

TIA,

Alvaro.

---

From: Barry Friedman <[email-masked]>
Date: Fri, 1 Nov 2002 15:30:19 -0800

Hi Kireeti,

Does this tie all the protocols to a single dead timer (that is less
than or equal to 16.8sec)?  With short dead timers I think you
increase the chance of false dead detection due to congestion, high
CPU utilization, etc. Having an individual dead timer per protocol,
operators can make the choice of faster convergence over stability or
vice versa, for different protocols (such as IGP vs EGP). This
proposal seems to go against that.

I can see the utility of this for event notification ie. "speaker X
on device Y is no longer available", sent only when the event
occurs.

Regards,
Barry

Kireeti Kompella [[email-masked]] wrote:
> 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.
> 

-- 
Barry Friedman
Cisco Systems Inc.  mailto:[email-masked]

---

From: Barry Friedman <[email-masked]>
Date: Fri, 1 Nov 2002 15:30:19 -0800

Hi Kireeti,

Regards,
Barry

---

From: Rohit Dube <[email-masked]>
Date: Sun, 03 Nov 2002 17:08:45 -0500

Some thoughts after a quick look at PLP, MARP and FLIP
(btw the FLIP draft is available at 
http://www.watersprings.org/pub/id/draft-sandiick-flip-00.txt)

The current literature divides the problem into 3 layers,
1. neighbor discovery
2. neighbor adjacency maintenance
3. exchanges with routing and signalling protocols

It seems to me that 1 and 2 would be very useful even with just a lil 
bit of 3 : If a liveness protocol could feed routing protocols when a 
link goes down, the protocols running on the link could react quickly 
to the event. The liveness protocol need not be routing protocol aware
to acheive this. Ofcourse such awareness  can optionally be added for
implementations that can achieve this at a low cost.

Regards,
--rohit.

---

From: Rohit Dube <[email-masked]>
Date: Sun, 03 Nov 2002 17:08:45 -0500

Regards,
--rohit.

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 08 Nov 2002 06:40:47 -0800

Rohit,

> implementations that can achieve this at a low cost.

It would be useful to have a mechanism that provides the control plane
with the information about liveness of the data plane, where the
data plane includes both links as well as forwarding plane of
routers.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 08 Nov 2002 06:40:47 -0800

Rohit,

Yakov.

---

From: phil laverdiere <[email-masked]>
Date: Tue, 26 Nov 2002 09:49:35 -0600

I attended the routing area meeting, but there was so much discussion
of this protocol I did not get a chance to voice my thoughts.

I read this draft and believe it is a simple mechanism that will
allow implementation of much more robust and responsive protocols.

I like the protocol bits and the ability to quickly notify peers of
loss of adjacency due to configuration change.  I know that ospf  can
send out an lsa to tells its neighbors it is gone, but having a generic
mechanism would simplify the protocols.   One might think that
quick propagation of configuration changes is not important.  I
think a network admin trying to regain control of his network would
want quick propagation of configuration changes.

After the rtg area meeting I discussed with Kireeti an idea for
defining a protocol bit up but the port up state down.  We could define
this state to mean forwarding is down, but the protocol is up.   This
could allow a router,s protocols to form adjacencies and learn protocol
state before its starts forwarding.   I think this mechanism would ease
the situation where a large part of the network must be started at the
same time.

Even without adoption my suggestion, I do support this protocol, and
I would like to see it advanced.

Phil Laverdiere
Caspian Networks

---

From: phil laverdiere <[email-masked]>
Date: Tue, 26 Nov 2002 09:49:35 -0600

Phil Laverdiere
Caspian Networks

---

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

] 
 ] I like the protocol bits and the ability to quickly notify peers of
 ] loss of adjacency due to configuration change.  I know that ospf  can
 ] send out an lsa to tells its neighbors it is gone, but having a generic
 ] mechanism would simplify the protocols.   One might think that
 ] quick propagation of configuration changes is not important.  I
 ] think a network admin trying to regain control of his network would
 ] want quick propagation of configuration changes.

configuration change, such as de-configure a protocol on a router
or an interface is a rare event, i don't think it's worth the effort.
if the goal is to propagete router configuration change through PLP,
then lets also handle those:

 - since plp uses source ip of the interface address, we should
   definitely have a way to deal with ip address change on the interface,
   have this in one of the plp "extensions" tlv?
 - IS-IS level change from L1/L2 into either L1 or L2 should be handled
   gracefully in order to minimize the packet loss.
 - OSPF hello holdtime change currently can't be unilateral, so if
   one side changes the holdtime over the interface, PLP should fast
   propagate the information and have the other side change to the
   same value hopefully.
 - how about router-id change on a router, that seems to be very
   important, let's figure a way to propagate not only to our neighbors,
   but let PLP flood this over the entire Internet(since PLP is not
   restricted to the domain)
 - etc.

 ] 
 ] After the rtg area meeting I discussed with Kireeti an idea for
 ] defining a protocol bit up but the port up state down.  We could define
 ] this state to mean forwarding is down, but the protocol is up.   This
 ] could allow a router,s protocols to form adjacencies and learn protocol
 ] state before its starts forwarding.   I think this mechanism would ease
 ] the situation where a large part of the network must be started at the
 ] same time.

are you trying to optimize the case when a router first boots up with
no forwarding information? protocol has those stub area or overload bit
concept, which will discourage the packet forwarding. how does the
protocol suppose to handle adjacency is Up but can't use it case?
a router boots up can take minutes, do we need to optimize for
something which only takes a couple of seconds(to establish a protocol
adjacency)?

cheers.
- Naiming

---

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

] 

 ] 

cheers.
- Naiming

---

From: Phil Laverdiere <[email-masked]>
Date: Tue, 26 Nov 2002 13:54:27 -0600

> then lets also handle those:

Ok, point taken.  I realize I made a much more general statement than
I had intended.  I too want plp to remain simple.  I do agree that de-configuring
a protocol from an interface is a rare event.  Its just that I think its
an important one, and might warrant special treatement if it can be 
accomplished simply.  I think what Kireeti has suggested is a simple mechanism
that addresses this rare and important event.

I believe Kireeti believed that de-configuring a protocol was not the most
important use of the protocol bit's.  I will let him explain further.

> something which only takes a couple of seconds(to establish a protocol

Yes, I am trying to optimize the case when a router boots without forwarding
information.  Some protocols have stub area or overload concept, not all.
I also thought it would be especially useful if a isp has to restart a
large part of the network topology.  I was thinking of the failure scenarios
like those cited in draft-ash-ospf-isis-congestion-control-02.txt, where
large portions of the network come up at the same time.  While many vendors
have implemented an ospf version of overload, this solution would require
re-flooding of the lsa's when leaving overload mode.  

I was considering whether this plp mechanism might be a way to allow the flooding
of link state to occur before we start forwarding.

I am well aware that current implementations may not have as great a problem
with this scenario, and graceful restart also helps, but I do belive there
may still be failure scenarios where this sort of aproach might be useful.

Phil

---

From: Phil Laverdiere <[email-masked]>
Date: Tue, 26 Nov 2002 13:54:27 -0600

Phil

---

From: Naiming Shen <[email-masked]>
Date: Tue, 26 Nov 2002 13:08:10 -0800

] >  ]
 ] >  ] After the rtg area meeting I discussed with Kireeti an idea for
 ] >  ] defining a protocol bit up but the port up state down.  We could define
 ] >  ] this state to mean forwarding is down, but the protocol is up.   This
 ] >  ] could allow a router,s protocols to form adjacencies and learn protocol
 ] >  ] state before its starts forwarding.   I think this mechanism would ease
 ] >  ] the situation where a large part of the network must be started at the
 ] >  ] same time.
 ] > 
 ] > are you trying to optimize the case when a router first boots up with
 ] > no forwarding information? protocol has those stub area or overload bit
 ] > concept, which will discourage the packet forwarding. how does the
 ] > protocol suppose to handle adjacency is Up but can't use it case?
 ] > a router boots up can take minutes, do we need to optimize for
 ] > something which only takes a couple of seconds(to establish a protocol
 ] > adjacency)?
 ] 
 ] Yes, I am trying to optimize the case when a router boots without forwarding
 ] information.  Some protocols have stub area or overload concept, not all.
 ] I also thought it would be especially useful if a isp has to restart a
 ] large part of the network topology.  I was thinking of the failure scenarios
 ] like those cited in draft-ash-ospf-isis-congestion-control-02.txt, where
 ] large portions of the network come up at the same time.  While many vendors
 ] have implemented an ospf version of overload, this solution would require
 ] re-flooding of the lsa's when leaving overload mode.  

even though the overload-bit mechanism is only for IGPs, but without
IGP routes in the network, other protocols can hardly work. e.g., LDP
does not have overload-bit thing, but if it does not learn routes from
IGPs, it can bind labels, so the forwarding will not work, which is
just fine.

during network hours long chaos, i don't think the goal is to
bring up a particular adjacency 5 seconds faster, or optimize the
forwarding so packet loss is less. in particular, the chaos could
well be caused by "plp" like optimization mechanim.

the forwarding state of a router is not only interested to their
immediate neighbors, but it should be a domain wide knowledge. If
only the immediate neighbors respond to your "forwarding" hint, it
can easily cause forwarding loops, since routers multiple hops
away don't know that. unless you want to make plp as routing protocol
and plp packets being flooded over the domain.

some line cards in lower number of slots, or total circuit number on
the card is small, thus they might be brought up faster than the other
linecards, should PLP also reserve some bits for those cases?
the point is: make it simple, as simple as it can be.

cheers.

 ] 
 ] I was considering whether this plp mechanism might be a way to allow
 ] the flooding of link state to occur before we start forwarding.
 ] 
 ] I am well aware that current implementations may not have as great a problem
 ] with this scenario, and graceful restart also helps, but I do belive there
 ] may still be failure scenarios where this sort of aproach might be useful.
 ] 
 ] 
 ] Phil

- Naiming

---

From: Naiming Shen <[email-masked]>
Date: Tue, 26 Nov 2002 13:08:10 -0800

] >  ]

cheers.

 ] 

- Naiming

---

From: Phil Laverdiere <[email-masked]>
Date: Tue, 26 Nov 2002 18:29:27 -0600

Naiming,

I do agree that plp needs to be as simple as possible.  

I simply find the protocol bits useful and fairly simple to implement.  
I would use plp even if it did not have the protocol bits.

I certainly do not propose any of the extensions you have (not really)
suggested.

I just like plp the way it is.

So long,

phil

---

From: Phil Laverdiere <[email-masked]>
Date: Tue, 26 Nov 2002 18:29:27 -0600

Naiming,

So long,

phil

---

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

Phil,

I too think protocol bits is useful(the protocol registration bits,
not the status bits). A router can use them to build a plp neighbor
relationship automaticaly without configuration: if we have LDP
configured on this interface, and i receive a PLP packet has LDP
bit on from that interface, we are probably neighbors. This can
make plp very simple to implement, and not much interaction among
the plp and other protocols. And that's about it I think.

Cheers.

 ] Naiming,
 ] 
 ] I do agree that plp needs to be as simple as possible.  
 ] 
 ] I simply find the protocol bits useful and fairly simple to implement.  
 ] I would use plp even if it did not have the protocol bits.
 ] 
 ] I certainly do not propose any of the extensions you have (not really)
 ] suggested.
 ] 
 ] I just like plp the way it is.
 ] 
 ] So long,
 ] 
 ] phil
 ] 
 ] Naiming Shen wrote:
 ] > 
 ] >  ] >  ]
 ] >  ] >  ] After the rtg area meeting I discussed with Kireeti an idea for
 ] >  ] >  ] defining a protocol bit up but the port up state down.  We could d
efine
 ] >  ] >  ] this state to mean forwarding is down, but the protocol is up.   T
his
 ] >  ] >  ] could allow a router,s protocols to form adjacencies and learn pro
tocol
 ] >  ] >  ] state before its starts forwarding.   I think this mechanism would
 ease
 ] >  ] >  ] the situation where a large part of the network must be started at
 the
 ] >  ] >  ] same time.
 ] >  ] >
 ] >  ] > are you trying to optimize the case when a router first boots up with
 ] >  ] > no forwarding information? protocol has those stub area or overload b
it
 ] >  ] > concept, which will discourage the packet forwarding. how does the
 ] >  ] > protocol suppose to handle adjacency is Up but can't use it case?
 ] >  ] > a router boots up can take minutes, do we need to optimize for
 ] >  ] > something which only takes a couple of seconds(to establish a protoco
l
 ] >  ] > adjacency)?
 ] >  ]
 ] >  ] Yes, I am trying to optimize the case when a router boots without forwa
rding
 ] >  ] information.  Some protocols have stub area or overload concept, not al
l.
 ] >  ] I also thought it would be especially useful if a isp has to restart a
 ] >  ] large part of the network topology.  I was thinking of the failure scen
arios
 ] >  ] like those cited in draft-ash-ospf-isis-congestion-control-02.txt, wher
e
 ] >  ] large portions of the network come up at the same time.  While many ven
dors
 ] >  ] have implemented an ospf version of overload, this solution would requi
re
 ] >  ] re-flooding of the lsa's when leaving overload mode.
 ] > 
 ] > even though the overload-bit mechanism is only for IGPs, but without
 ] > IGP routes in the network, other protocols can hardly work. e.g., LDP
 ] > does not have overload-bit thing, but if it does not learn routes from
 ] > IGPs, it can bind labels, so the forwarding will not work, which is
 ] > just fine.
 ] > 
 ] > during network hours long chaos, i don't think the goal is to
 ] > bring up a particular adjacency 5 seconds faster, or optimize the
 ] > forwarding so packet loss is less. in particular, the chaos could
 ] > well be caused by "plp" like optimization mechanim.
 ] > 
 ] > the forwarding state of a router is not only interested to their
 ] > immediate neighbors, but it should be a domain wide knowledge. If
 ] > only the immediate neighbors respond to your "forwarding" hint, it
 ] > can easily cause forwarding loops, since routers multiple hops
 ] > away don't know that. unless you want to make plp as routing protocol
 ] > and plp packets being flooded over the domain.
 ] > 
 ] > some line cards in lower number of slots, or total circuit number on
 ] > the card is small, thus they might be brought up faster than the other
 ] > linecards, should PLP also reserve some bits for those cases?
 ] > the point is: make it simple, as simple as it can be.
 ] > 
 ] > cheers.
 ] > 
 ] >  ]
 ] >  ] I was considering whether this plp mechanism might be a way to allow
 ] >  ] the flooding of link state to occur before we start forwarding.
 ] >  ]
 ] >  ] I am well aware that current implementations may not have as great a pr
oblem
 ] >  ] with this scenario, and graceful restart also helps, but I do belive th
ere
 ] >  ] may still be failure scenarios where this sort of aproach might be usef
ul.
 ] >  ]
 ] >  ]
 ] >  ] Phil
 ] > 
 ] > - Naiming
 ] > _______________________________________________
 ] > routing-discussion mailing list
 ] > [email-masked]
 ] > https://www1.ietf.org/mailman/listinfo/routing-discussion

- Naiming

---

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

Phil,

Cheers.

 ] Naiming,
 ] 

- Naiming