Re: [sfc] Mirja Kühlewind's Discuss on draft-farrel-sfc-convent-05: (with DISCUSS and COMMENT)

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Forgot to mention that probably a pointer to RFC8085 might also be helpful. These UDP usage guidelines are probably applicable here as well and the RFC discusses different cases depending on the traffic model. I guess 3.1.3 is most relevant but I actually don’t know what traffic characteristics you are expecting; so maybe addition discussion/consideration would be needed.

Mirja



> Am 02.02.2018 um 21:14 schrieb Mirja Kuehlewind (IETF) <[e-mail]>:
> 
> Hi Adrian,
> 
> 
>> Am 02.02.2018 um 19:25 schrieb Adrian Farrel <[e-mail]>:
>> 
>> Hi Mirja, 
>> 
>> Thanks for the review.
>> 
>> From the Discuss...
>> 
>>> This spec enables an SC node to create new packets and therefore must provide
>>> congestion control consideration to avoid network overload from these packets,
>>> e.g. in the simplest case requiring a maximal sending rate/minimal time
>>> interval between to packets.
>> 
>> You say "consideration" and not "mechanism" and that sounds about right.
>> 
>> I think we should require rate-limiting on transmission and also on
>> receipt/forwarding.
>> 
>> At 30,000 foot we should look at this like ICMP, so rate limits are reasonable.
>> 
>> I am slightly worried that an application here might be OAM (although that is
>> still open for debate in the WG) and so rate limiting might be
>> counter-productive.
>> 
>> Consider, if you will, BFD. There *is* rate limiting in BFD, but the rate may be
>> pretty fast.
>> 
>> Anyway, if we construct some text that advises implementations:
>> - why to rate limit
>> - how to rate limit
>> - what rates may be appropriate
>> would you review it for us?
> 
> Yes to all of this.
> 
>> 
>> For the Comment...
>> 
>>> I think this document should update RFC8300 as it does not only register an
>> new
>>> protocol but also changes some of the process for this specific case.
>> 
>> I am not going to get between the IESG and its  regular discussion of what an
>> "update" is ;-)
>> Once upon a time "B updates A" meant you cannot implement A without also
>> implementing B.
>> It was not my intention that anything in this spec changed the behaviour of an
>> implementation of 8300. If we have inadvertently made that happen, could you
>> point it out so we can fix it.
> 
> Yes, this was more a comment for the AD. However, it is still not true that „updates“ means „must implement“, maybe „must read“ or „must have a look at to figure out if it should be implemented as well“. But I also have to say it's on my todo for a while to write draft for clarification here, so I take all the blame. However, this is also just a comment, so one opinion that does not need to be addressed.
> 
> Mirja
> 
> 
> 
>> 
>> Thanks,
>> Adrian
>> 
>