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

["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?

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.

Thanks,
Adrian