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

[<[e-mail]>]

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Mirja Kuehlewind (IETF) [mailto:[e-mail]]
> Envoyé : lundi 24 septembre 2018 11:23
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : The IESG; [e-mail]; [e-mail]; opsawg-
> [e-mail]
> Objet : Re: [OPSAWG] Mirja Kühlewind's Discuss on draft-ietf-opsawg-nat-yang-
> 15: (with DISCUSS)
> 
> Hi Med,
> 
> please see inline.
> 
> > Am 24.09.2018 um 10:55 schrieb <[e-mail]>
> <[e-mail]>:
> >
> > Re-,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Mirja Kuehlewind (IETF) [mailto:[e-mail]]
> >> Envoyé : lundi 24 septembre 2018 10:14
> >> À : BOUCADAIR Mohamed IMT/OLN
> >> Cc : The IESG; [e-mail]; [e-mail];
> opsawg-
> >> [e-mail]
> >> 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.
> 
> Understood. And I also understand that your motivation is to aline with
> existing implementations, which makes sense. I just wonder if there is a way
> to make it even easier to enable new implementations for other protocols in
> future (without defining a new protocol-specific extension).
> 
> >
> >
> >> 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.
> 
> What about maybe renaming the timers and don’t have tcp in the name but
> explain in the text that these timer are used for tcp but could/should also
> be used for other connection-oriented protocols…? Would that be an option
> that could eventually help? E.g. call the "tcp-trans-open-timeout“ just
> "trans-open-timeout“ and explain that RFC 7857 specifies this for TCP but
> other implementation for connection-oriented protocols could use the same
> timer? Just thinking...
> 

[Med] No problem to change the name if this helps, but I'm afraid this effort may be useless if there is no reference document that explains how these timers can be used for other protocols. 


> >
> >>
> >> 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.
> 
> No, that’s exactly the problem. QUIC is a connection-oriented protocol, so it
> would potentially be possible and desirable to have longer time-outs than you
> usually have for other UDP traffic.

[Med] We can already do that with this model: per-port-timeout. An entry for 443, for example may be provided in such case. No?


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