Venkata, Group,
My two cents..
LSA reqs are bundled together into a
single pkt. If our pkt is MTU sized
then we bundle X requests into a single
pkt.
However, if our pkt was 10MTU or we
had sent 10 MTU sized pkts and our
rexmit timer expired, we would need
to resend that data all over again.
Thus, to allow us to minimize the latency
of the reply, to be able to somewhat equally
spread our exchange workload between multiple
connections, and to minimize the amount
of wasted header space we shoot for a
MTU size type pkt at any one point in time.
If you are looking to improve the speed of
the exchange / loading, their are other
methods to generate parallism during this
exchange / loading process.
Mitchell Erblich
--------------------
"Naidu, Venkata" wrote:
>
> I have a question in the Database Exchange/Loading process.
>
> RFC2328 section 10.9 page 105 says:
> "There should be at most one Link State Request packet outstanding
> at any one time."
>
> I understand the reason behind having only one DD packet outstanding
> at any one time. But I don't understand why we need this requirement
> for LSA requests? There is no such requirement for LSA transmissions.
> LSA retransmissions have such requirement.
>
> RFC2328 13.6 page 155 says:
> "Another packet of retransmissions can be sent whenever some of the
> LSAs are acknowledged, or on the next firing of the retransmission
> timer."
>
> I think the convergence will be faster if we send as many LSA requests
> as we can in the loading process. Similar to what we do for LSA
> transmissions in the flooding process. So the LSA request requirement
> should change to:
>
> "Another packet of LSA request retransmissions can be sent whenever
> some of the LSAs that are requested are received, or on the next
> firing of the LSA request retransmission timer."
>
> Am I missing something?
>
> Thank you,
> Venkata.
>
> _______________________________________________
> OSPF mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
