Subject: [Ospf-manet] Re: Ospf-manet Digest, Vol 10, Issue 7

From: Aniket Desai <[email-masked]>
Date: Mon, 18 Sep 2006 18:52:48 -0400

At 06:25 PM 9/18/2006, you wrote:
>4. Ack the first reception of an LSA, and ack any LSA received in an LSU
>that contains the router in the Ack list.  Retransmitted LSAs are multicast.

This may actually turn out to be a good idea if a router TLV was 
included in the LSU packet. Currently, router TLVs are used in hello 
and also in the initial DD handshaking. As I recall, OSPF options 
field already reserves an LLS bit, which can be set when 
retransmitting a multicast LSA. A router can include a list of all 
neighbors in a router TLV (Type must be unique and can be assigned, 
length and value are obvious), which must acknowledge this LSA. Also, 
turning on the LLS bit can act as an indication that the LSA is 
retransmitted, and hence each receiving neighbor will try to find its 
own router ID in the attached TLV. Such a change is not that 
extensive from legacy OSPF, and the already existing TLV signaling 
can be used for this purpose.

I still think that such a feature must be used with care, because a 
router may expect different LSAs to be acknowledged by different 
neighbors. If a router starts appending a list of neighbors (each 
neighbor takes 32 bits) for every single retransmitted LSA, that can 
potentially annul the advantage of multicast retransmission. In 
certain situations, this may make some sense. I would like this to be 
an option (if included in the draft at all), that would typically be 
only turned on the MDRs/BMDRs with many adjacencies.

Thanks,

Aniket

_______________________________________________
Ospf-manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf-manet

---

From: Richard Ogier <[email-masked]>
Date: Tue, 19 Sep 2006 00:44:01 -0700

Aniket Desai wrote:

> retransmitting a multicast LSA.

But the LLS draft specifies that only Hello and DD packets can include
an LLS block.
http://www.ietf.org/internet-drafts/draft-ietf-ospf-lls-01.txt

But we shouldn't let this unfortunate limitation of LLS keep us from
including a TLV in LSU packets to indicate which neighbors should Ack,
if this turns out to improve performance significantly.  We should be
allowed to modify the format of LSU packets on a MANET interface,
since this has no effect on non-MANET interfaces.
(Similarly, we should be able to change the format of Hellos on a
MANET interface, so I question the choice of using LLS for Hellos.)
Alternatively, we can use an LSA option bit to indicate that the
LSA should be Acked by all routers in the TLV attached to the
LSU packet. (We don't want to include a separate TLV for each LSA.)

> A router can include a list of all neighbors in a router TLV (Type 
> must be unique and can be assigned, length and value are obvious), 
> which must acknowledge this LSA. Also, turning on the LLS bit can act 
> as an indication that the LSA is retransmitted, and hence each 
> receiving neighbor will try to find its own router ID in the attached 
> TLV. Such a change is not that extensive from legacy OSPF, and the 
> already existing TLV signaling can be used for this purpose.
>
> neighbors.

But in most cases, an LSU that includes several LSAs will not be acked
by a subset of adjacent neighbors, and these LSAs will be retransmitted
to this subset of neighbors in another LSU.  In other words, it is really
the LSU that is usually retransmitted.  But it is possible that new LSAs
are added to the LSU (along with LSAs that must be retransmitted), so the
above idea of using an LSA option bit (to indicate which LSAs are being
retransmitted) might work well.

> If a router starts appending a list of neighbors (each neighbor takes 
> 32 bits) for every single retransmitted LSA, that can potentially 
> annul the advantage of multicast retransmission. In certain 
> situations, this may make some sense. I would like this to be an 
> option (if included in the draft at all), that would typically be only 
> turned on the MDRs/BMDRs with many adjacencies.

Yes, this feature should be optional.  If this option is not used,
retransmitted LSAs will be unicast as before.
But I don't think this option will ever result in more overhead than
unicasting all retransmitted LSAs, since it is more efficient to include
a list of m neighbors in a single multicast LSU, versus unicasting the
LSU to each of m neighbors (even if the LSU sent to each neighbor contains
only a subset of the LSAs that must be retransmitted to the m neighbors).

Note again that only LSUs containing *retransmitted* LSAs will include
a list of neighbors that must ack.  Also, an LSA option bit will indicate
which LSAs are being retransmitted.  As before, each router must Ack
the first reception of each new LSA.

Richard