[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [OSPF] Questions regarding draft-ietf-ospf-manet-or-00.txt
I thought of a better way to fix the problems that I mentioned.
First, the convention that "neighbor" always means "Full neighbor"
should be avoided (since it does not allow the draft to refer to
neighbors that are not Full).
Second, since every router that is not an active OR can be
considered to be to be a non-active OR, I suggest not even
defining "active" and "non-active", but just call an "active OR"
an MPR (which is what it really is!). (Or use "OR" to mean "MPR".)
The behavior of routers that are not MPRs can be specified in the
flooding procedure, as I suggest below.
Since Boeing's implementation allows LSAs received from non-adjacent
neighbors to be processed and flooded, in Section 3.3.8
(Flooding and Relay Decisions), specify that an LSA received from
any bidirectional neighbor can be processed and flooded, e.g.,
"Upon receiving an LSA from a bidirectional neighbor, a node makes
flooding decisions based on the following algorithm."
In step 1, change "active overlapping relay" to MPR.
In step 2, change "If the node is a non-active overlapping
relay for the adjacent speaker" to
"If the node has at least one adjacent neighbor from which
the LSA, or an ack for the LSA, has not been received".
Step 2.1 strikes me as being vague, since it is not clear how to
determine that "flooding the LSA will only result in a redundant
transmission". I suggest modifying this step as follows:
2.1. Upon expiration of PushbackInterval plus jitter, if there exists
at least one adjacent neighbor from which the LSA, or an ack for
the LSA, has not been received, the router MUST transmit the LSA
at this time.
The above is just a suggestion. I am not 100% sure it is correct.
Richard
_______________________________________________
OSPF mailing list
OSPF at ietf.org
https://www.ietf.org/mailman/listinfo/ospf