Hi,

Manav :
You mentioned that during the database exchange process, we don't have
to explicitly ACK the LSUs.
I feel just removing the LSA from the LSRequest list does not indicate
to the sending neighbour that we have received the update.
I feel the LSAs in the LSUs should be ACKed irrespective of whether they
are received during the database exchange process or when the neighbour
state is FULL. This is because, all LSUs are handled by section 13.
During database exchange process, step 13-(5)(b) is executed. So, when a
LSU is received during the database exchange process, it still goes
through the above step 13 and it might result in an ACK.
Please correct me if I am wrong.

Zhang :
Your point(4) related to BadLSReq event will only happen if a router
receives a LSA that is older or same as what it already has and the LSA
is present its LSRequest list. What it means is that either the router
is requesting for something it already has or the neighbour router has
sent it an older LSA.
In section 13-step(8), when we send a LSU with the newer LSA, the
neighbouring router will go through the section 13-step(5) - which
happens if we receive a LSA that we don't have or we receive a newer
version of a LSA that we already have.
So, BadLSReq is not generated by the neighbouring router.

-
Narendra A

Manav Bhatia wrote:
>
> Hi Zhang,
>
> > 2)In Page 130, in section 12.4.1.1 Option 2, for IP
> > numbered PTP link, If I can't get the peer address,
> > which subnet will be assigned to the PTP link, my own
> > or peer?
> >
>
> AFAIK this kind of situation should not arise. You will have the peer
> address if you are fully adjacent to it.
>
> >
> > 3)why RFC don't discribe the Receiving the LSU packet
> > and Send out the LSU packet, and now I am comfused
> > about the receiving LSU? When I received a LSU, I need
> > to send out a LSA packet?
>
> As i understand, the question is whether we need to send an ACK back once we
> recieve a LSU ?
>
> Depends, upon the neighbor state. In exchange or loading i.e. when DBD
> packets are being exchanged the LSR list contains a list of those LSAs which
> are required from the neighbor. When the neighbor responds to these requests
> with the proper LSUs , the LSR list is truncated and a new LSR list is sent.
> LSAs on the LSR list that have been requested , but not yet recieved , are
> packaged once again into the LSR list. Hence there are *no* explicit ACKs
> sent for all the LSUs/LSAs recvd.
>
> Consider the state when the neighbor state is full. LSU packets provide a
> mechanism for flooding LSAs and *each* LSA must be acknowledged separately.
> Hence there is *explicit* ACK sent now !
>
> For each LSA contained in the LSU packet what all steps are taken is
> explained in section 13. For any specific doubts, hammer them to this group
> !
>
> >
> > 4)In Page 145, at the point (8), when received a LSU,
> > the database copy LSA is more recent, I will send a
> > LSU to neighbor, and that will make neighbor router
> > NBR state machine to generate BadLSReq event,right?
>
> BadLSReq is sent when a LSR is recieved for an LSA which does not exist !
> If the database copy is newer than the one you recvd then simply send the
> database copy back to the sender, encapsulated within a LSU packet.
> What is the problem .. i guess i missed it !
>
> >
> > 5)In the Page 147, when installing the Router-LSAs and
> > network-LSAs to the database, the entire routing table
> > must be recalculated,the reason is that the AS
> > boundary routers may belong to multiple areas.I can't
> > understand this sentence,even the router belongs to
> > multiple area, it can only run the SPF in one area and
> > then generate the type 3 and 4 LSA to other areas, I
> > think it is ok.
>
> If a router belongs to multiple areas then it has to run SPF for *each* area
> that it lies in !
>
> I hope i'm clear.
>
> Regards,
> Manav

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]