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

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net]
> Envoyé : lundi 24 septembre 2018 10:14
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : The IESG; opsawg@ietf.org; draft-ietf-opsawg-nat-yang@ietf.org; opsawg-
> chairs@ietf.org
> Objet : Re: [OPSAWG] Mirja Kühlewind's Discuss on draft-ietf-opsawg-nat-yang-
> 15: (with DISCUSS)
> 
> 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.
> 

[Med] I hear you... but the issue is the other way around: availability of a stateful implementation which adheres to that design approach.

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

[Med] There are ways to overwrite default values, e.g., define a type and derive new one from it. Nevertheless, it is simpler to define explicit timers as we have done in the document given that protocol differentiation is a requirement. One for UDP, one for ICMP, and state-specific timers for TCP. Future documents can re-use state-specific timers for generic configuration matters, if needed. 

> 
> 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).

[Med] For the quic example, one would argue that the UDP-related config parameters are sufficient; there is even no need to inspect whether this is quic or plain UDP packet.

> 
> Mirja
> 
> 
> 
> > Am 24.09.2018 um 07:39 schrieb <mohamed.boucadair@orange.com>
> <mohamed.boucadair@orange.com>:
> >
> > Hi Mirja,
> >
> > Thank you for the review.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : OPSAWG [mailto:opsawg-bounces@ietf.org] De la part de Mirja Kühlewind
> >> Envoyé : vendredi 21 septembre 2018 18:20
> >> À : The IESG
> >> Cc : opsawg@ietf.org; draft-ietf-opsawg-nat-yang@ietf.org; opsawg-
> >> chairs@ietf.org
> >> 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
> >> OPSAWG@ietf.org
> >> https://www.ietf.org/mailman/listinfo/opsawg