Subject: Re:

From: <[email-masked]>
Date: Thu, 21 Nov 2002 17:52:26 +0800

hi,

I have several questions about implementing add ip.

1) what's the benefit of using Success Indicatyion(0xC005)? 
    It seems its usage is  to explicitly report a success for a requested TLV if some requests success and the others fail.
  Is it possible to treat it as the default value of a response and not using it at all?

2)If the sender requests to delete a address not in its address list by mistake, what shall the receiver do?
  Reply a success or tell error to the sender? If the receiver choose to tell the error to the sender, what's the cause code?

3) In Section 4.2,C3,X1, if the request was refused because of resource shortage in previous process but there is resource available now, shall the receiver still send ERROR the sender?

Thanks!

Dajiang Zhang

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Thu, 21 Nov 2002 08:03:04 -0600

>  Is it possible to treat it as the default value of a response and not using it at all?
The success is not the default case once you deny one.. so if i process a

Add-ip (ipa)
Del-IP (ipz)
add-ip (ipq)>> failed lack of resources
setprimary (ipa)
del-ip (ipq) >> failed due to add-ip rules

Then if you decided to do the setprimary and you want to tell the peer
hyou would
need the success indication to tel them

failed (lack of resources on the ipq)
sucess (setprimary)

Which should tell them the state...

I personelly would report everything from the
failed onward... (even though the last failed is
implied)aka

failed
success
failed.

The earlier successes are implied ...

>  Reply a success or tell error to the sender? If the receiver choose to tell the error to the sender, what's the cause code?

I just send a ok.. since it wanted it out and it is out... Otherwise the
peer may think
it can source packets from that address and you would send an abort if
it did (we are
talking about a buggy sender anyway so this is an extreme corner but I
think attempting
to protect oneself from such a buggy peer is good)...

>3) In Section 4.2,C3,X1, if the request was refused because of resource shortage in previous process but there is resource available now, shall the receiver still send ERROR the sender?

I am not sure of this question...

Once you get a request (add X) then you respond.. You do not hang on to
the request and try
it again later... once you tell the peer.. I failed that is the end of
it as far as you
are concerned

Now if the peer then later sends the request again... (add X) then you
would respond at
THAT time as to your resources... i.e. if you have them you would add it..

Hope that helps...

R

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)