Re: [OPSAWG] Mirja Kühlewind's Discuss on draft-ietf-opsawg-nat-yang-15: (with DISCUSS)

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

Hi Med,

thanks for you reply. It makes sense that you may want different values for different protocol in the case of UDP and TCP. However, I think the question is not that much which protocol but which properties does the protocol have, e.g. all connection-oriented protocol probably have some kind of handshake that can be used to trigger these timers.

Is it maybe possible to model these times generally for certain protocol feature and the have the ability to overwrite these „default“ values with protocol-specific values? 

Given that these protocol specific differences especially in NAT are a huge problem for the deployment of new protocol it would be really nice if this could be model in a generic as possible way. E.g. would be nice to be able to use the same config for the config for quic (one a NAT is implemented to detect the quic handshake over udp).

Mirja



> Am 24.09.2018 um 07:39 schrieb <[e-mail]> <[e-mail]>:
> 
> Hi Mirja, 
> 
> Thank you for the review. 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : OPSAWG [mailto:[e-mail]] De la part de Mirja Kühlewind
>> Envoyé : vendredi 21 septembre 2018 18:20
>> À : The IESG
>> Cc : [e-mail]; [e-mail]; opsawg-
>> [e-mail]
>> Objet : [OPSAWG] Mirja Kühlewind's Discuss on draft-ietf-opsawg-nat-yang-15:
>> (with DISCUSS)
>> 
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-opsawg-nat-yang-15: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-nat-yang/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> Thanks for a well-written document and also for considering other protocols
>> like SCTP. I've put in a discuss because I would really like have a quick
>> discussion here to double-check that we do the right thing, however, it might
>> well be that we can resolve this discuss without any changes. My question is:
>> given the model is designed to be generic enough to incorporate other
>> transport
>> protocols, I'm wondering if it would be possible to also define the timers
>> you
>> have there in a more generic way such that they can be re-used for other
>> protocols (maybe just changing the name and adding some explanation text).
> 
> [Med] The document includes timers that are valid for any transport protocol (e.g., per-port-timeout, hold-down, etc.). Things are more complicated for the other timers. For example, one could imagine that the same timer can be used to timeout any session (e.g., UDP and ICMP), nevertheless we do have different default/recommended values per transport protocol (e.g., 300s for UDP and 60s for ICMP). Also, existing implementations/deployments are used to allow for differentiating the behavior per transport protocol. For TCP, there are more state compared to UDP, hence the need for more specific timers. Other protocols may reuse some of these specific timers if needed. This should be described in an extension document, not in this one.
> 
>> 
>> As a side node: I myself have been working on a model for a
>> protocol-independent state machine a bit (see draft-trammell-plus-
>> statefulness;
>> now expired); maybe that's a helpful reference to have a quick look at…
>> 
> 
> [Med] Thank you for the reference. 
> 
>> 
>> 
>> 
>> _______________________________________________
>> OPSAWG mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/opsawg