[Tsvwg] Re: Dynamic IP add/delete comments

Renee:

I am including the TSVWG list on my reply so they
can have a look at your valuable comments too :) 

"D. Renee Revis" wrote:

> Randy,
> 
>        I've just read through the latest draft of the dynamic add/delete IP
> addrs draft and have a few comments and one question.
> 
> * In section 4.1, B1 describes incrementing error counts and doing dest
> addr failure detection and B2 describes incrementing assoc error counts and
> doing assoc failure detection.  However, both of these steps have the note
> that error counters include both per dest error counts as well as overall
> assoc counts.  As it reads, it makes it sound like assoc error counts
> should be incremented in B1 and then again in B2, but I don't think that's
> what is really intended.  Is the additional note really
> required/necessary?  Doesn't B1 just deal with dest error counts and B2
> just deal with assoc counts?
> 

Ok, in looking at this again... I see the problem.. I had the wrong
version I
was looking at :-0

I will kill the note since it is redundant since B1 has the destination
error counters and B2 has the association...

> * In step B3, you may want to specifically say the T-4 RTO timer.  At first
> read, I was wondering if somehow you were wanting to affect the T-3
> timer.  Don't think so, but it wasn't clear at first.

The RTO is that used by ALL addresses.. I will add a note here saying
something to the effect that the RTO is used for all timers when
sending to a particular destination address. How about...
"
    Note: The RTO value is used in the setting of all timer types
    for SCTP. Each destination address a single RTO estimate.
"

> 
> * Section 4.3.2, the first paragraph talks about the case where an endpoint
> has to use a new IP address as the source in the IP packet, even though the
> address hasn't been officially added to the assoc yet.  But then the second
> paragraph says, "The receiver MUST NOT reply to the source address of the
> packet in this special case, but to the new address that was added by the
> ASCONF."  I thought these would be the same.  The source address of the
> packet is the new address being added and the old address would be in the
> Address Bytes field of the ASCONF.  Am I misunderstanding this?
> 

No this is an error.. I will try to fix it in the next round :-0

How about:

"
    The receiver of such an ASCONF chunk MUST NOT process the
    SCTP packet if any other chunks are contained inside the SCTP
    packet. The receiver MUST always first use the source address
    found in the IP header in looking up the association.  The
    receiver should attempt to use the address found in the Address
    Bytes field only if the lookup fails using the source address from
    the IP header.  The receiver MUST reply to the source address
    of the packet in this case which is the new address that
    was added by the ASCONF (since the old address is no longer a part
    of the association after processing).

"

Thanks for your comments... I see another reply to a reply...

I will look at this one too :)

R
-- 
Randall R. Stewart
Systems & Solutions Engineering
Cisco Systems Inc.
rrs@cisco.com 815-342-5222 or 815-477-2127

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
http://www1.ietf.org/mailman/listinfo/tsvwg