Subject: [Tsvwg] Re: draft-ietf-tsvwg-addip-sctp-01

From: Randall Stewart <[email-masked]>
Date: Tue, 26 Jun 2001 09:37:23 -0500

Jon Berger wrote:
> 
> I have a few comments on the ASCONF draft.
> 
> 1) Section 3.1.1 and 3.1.2
> Titles should say Address/Stream.
> 
good catch, we missed that one :0

> 2) Section 4
> What happens if a stream number is not mentioned in the SFLR?  I assume it
> is unlimited.
> 

Good point, we need to add this. The implied assumption is
that if you don't mention a stream it stays the same as
it last was... we will get this in the next pass for clearity :) 
We will try to get these in to the 4.5 section next pass ...

> 3) Section 4
> No mention is made of what happens if a streams limit is reduced below the
> current amount of outstanding data on that stream.  I assume this data is
> unaffected.

Good catch... yep you are correct and we will add it in to the
4.5 section next pass as well :)

> 
> 4) Section 4.1
> B1 should say "path error counter".

I think we should say "destination address error count" or what
ever we called it in RFC2960.. can't remember...

AND

we need to also mention incrementing the association error counter
as well. 

We will get this in the next pass too :)

> 
> 5) Section 4.1.1 R6
> What if the ASCONF is smaller than the corresponding ASCONF-ACK and the ACK
> is bigger than PMTU.  I assume you just rely on IP fragmentation in this
> case.

Yes, I think we have to. I would hope this would not. It should
be a rare enough event that IP fragmentation will have to do...

We probably need to add a bit on this as well.

> 
> 6) Section 4.1.1 last para and 4.3 D3
> I don't like saying that either the whole draft is supported or none of it
> is.  It seems perfectly reasonable to support either the flow limiting or
> the ip address manipulation but not both.  A subset of the flow limiting
> would also seem reasonable (not many ULPs are likely to require all types of
> flow limiting).
> 

Hmm, maybe this is not clear enough. 

First: for section 4.1.1. we are discussing the ASCONF chunk. If the
peer sends back a "I don't understand the ASCONF chunk", how would
ANY of the add-ip or flow limit features be supported? 

Second: Maybe 4.3 D3) should be broken in to seperate rules or
sub points for each one. I was attempting to say that

if you send a ADD---->

and the peer says

<------I don't understand ADD

Then you CAN'T send another ADD...

But you COULD send a S-Flow request... for example...

So maybe seperate bullet points would make this clearer...

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg