Flooding using LMP extensions

["Richard Rabbat" <rabbat@fla.fujitsu.com>]

Follow-up email on flooding using LMP extensions

draft-soumiya-lmp-fault-notification-ext-00.txt:
This draft presents an LMP implementation of the above protocol, and ties in
with the P&R Design Team's analysis document, which *proposes the use of LMP
for failure reporting/fault notification* (Sec. 4.1, pp. 4).

i) The main discussion point was whether we should use LMP-WDM for flooding
fault notification messages.

ii) George you'd said that since LMP was a pt-to-pt protocol, using it for
fault notification via flooding would require changes to implementation
models.
I think this assumes that LMP may be implemented only at the line cards, and
its use in flooding would require communication, via the control plane,
between multiple LMP state machines.

To answer your question, however, if the proposal of the P&R team is
implemented, it would still be true that there would need to be
communication between the LMP state machines via the control plane, at least
those running at the downstream link on which a  failure notification is
received and the upstream link on which this notification must be forwarded
onward.
 
But we don't necessarily see that as a problem. 
Could you please share with us why you thought it to be so?

Since a lot of the discussion at the SF meeting focused on the
appropriateness of using LMP for flooding, I'd like to compare this to other
candidate solutions (as requested by Kireeti). 
They are:
- Signaling extended for flooding messages
- Using OSPF Opaque LSA for the flooding
- Using LMP, as we've proposed

A. Signaling extended for flooding messages:
   -----------------------------------------
Advantage:
- Signaling may be used for end-to-end fault notification per the P&R draft

Disadvantage:
- Extending RSVP-TE to flood the network assumes setting up RSVP sessions
between pairs of adjacent nodes (control plane-level adjacency). 
- Handshake process will be broken.
- For failures affecting LSPs between different s-d pairs, aggregating
failure info. in the Notify message wouldn't be possible, so the scheme
would reduce to one doing per-LSP notification, and lead to the possibility
of "notification storms" highlighted in the analysis document (Sec. 4.4, pp.
7).


B. OSPF opaque LSA:
   ----------------
Advantage:
-Flooding using OSPF, in general, is mature

Disadvantage:
- Timers in OSPF for Opaque LSA's will need to be brought to 0; this is an
unconventional implementation. One would need to maintain multiple timers to
account for other LSA's.  
- Opaque LSA processing is quite heavy, since it was not built with time
urgency in mind.
- OSPF will need some tweaking to send out this LSA's ahead of other LSA's
that may be leaving the node
- Need also a solution for IS/IS
- Some networks may not run OSPF or IS/IS while transitioning to a G-MPLS
control plane, but they would run signaling for LSP setup/teardown.

C. LMP:
   ----
Advantage:

- LMP deals with Link Management: fault is naturally part of that management
- Lightweight implementation
- We have working code for the LMP implementation in our labs as a
proof-of-concept, where we achieve 50 ms protection using flooding (we'll be
happy to share details with those interested)

Disadvantage:
- LMP may be implemented at the line card as a pt-to-pt protocol; extending
it to allow flooding will require LMP state machines to exchange messages
through the control plane. (George)
- LMP extensions to allow flooding may lead to network overloading/meltdown
(raised by Alex)

I'd like to get feedback on these issues, and see what people think is best
in order to progress this draft in the WG.