Subject: RE: another question about implementing add ip

From: <[email-masked]>
Date: Tue, 26 Nov 2002 11:14:58 +0800

do you mean that the receiver just ignores the "set primary path" request and doesn't give a response in ASCONF_ACK?
Then what shall the sender do when it gets such an ASCONF_ACK? Send the  "set primary path" request  again?

-----Original Message-----
From: ext Randall Stewart (cisco) [mailto:[email-masked]]
Sent: 23 November 2002 00:01
To: Manish Rajpal
Cc: Zhang Dajiang (Nokia-RD/Beijing); [email-masked]
Subject: Re: another question about implementing add ip

Manish Rajpal wrote:

>hi
>
>As told in the draft, its an option that receiver SHOULD perform. If the
>request can not be honored for whatsoever reasons, it can be ignored. And no
>response will be taken as success by the peer.
>

Yes.. I agree with the above.. you ignore the set-primary that sets to
an address that does
not exist.

>newayz, any message from the peer with such an address that does not exist
>will be responded back by an abort.
>  
>

Hmm.. what does "newayz" mean? You never would send an abort to a peer
that said
set-primary(x) when (x) is not in the association.

R

>regards
>manish
>----- Original Message -----
>From: <[email-masked]>
>To: <[email-masked]>
>Cc: <[email-masked]>
>Sent: Friday, November 22, 2002 2:30 PM
>Subject: another question about implementing add ip
>
>
>
>hi,
>
>Here is another question about implementing add ip.
>
>If the sender requests to set primary path to an address not in its address
>list by mistake, what shall the receiver do?
>Which error cause should be used?
>
>Thanks!
>
>Dajiang Zhang
>
>
>  
>

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

---

From: "Manish Rajpal" <[email-masked]>
Date: Tue, 26 Nov 2002 16:28:36 +0530

No response means success, so the sender can safely assume that the address
x has been made primary at the receiver. Now how come the sender is trying
to set an address primary that's not a part of association is interesting
part of the story :-)
----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, November 26, 2002 8:44 AM
Subject: RE: another question about implementing add ip

do you mean that the receiver just ignores the "set primary path" request
and doesn't give a response in ASCONF_ACK?
Then what shall the sender do when it gets such an ASCONF_ACK? Send the
"set primary path" request  again?

-----Original Message-----
From: ext Randall Stewart (cisco) [mailto:[email-masked]]
Sent: 23 November 2002 00:01
To: Manish Rajpal
Cc: Zhang Dajiang (Nokia-RD/Beijing); [email-masked]
Subject: Re: another question about implementing add ip

R

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Thu, 28 Nov 2002 19:26:07 -0600

Set primary is always at the receivers option... in the ASCONF ack it does
not mean you honored the request ... you may understand it and ack it
but you
do NOT have to do it...

R

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Thu, 28 Nov 2002 19:28:51 -0600

>to set an address primary that's not a part of association is interesting

It is a BUGGY peer first and formost... Now as far as setting primary
saying ASCONF-ACK does not
mean you accept the peers judgment of what should be primary...

I can acknowledge your opinion.. but it does not mean that I agree with
it.. It is always possible
the receiver of the set-primary has some better knowledge of what should
be primary than
the sender... this is why it is optional for the receiver to do anything
with it.

Realistically the sender probably knows best and so in my implementation
I always do
the change of primary (if it is possible)... it is NOT possible if the
address is not
part of the association...

R

>>request can not be honored for whatsoever reasons, it can be ignored. And
>>    
>>
>no
>  
>