Hi,
  
>  The definition of IPFIX Transport Sessions allows to distinguish the
>  different sessions. In the case of UDP, the Transport Session is defined
>  by the IP-5-Tuple plus the Observation Domain ID, which is a field in
>  the IPFIX message header.
>  In the case of DTLS/UDP, the Collector needs to maintain the DTLS state
>  for each Exporter.

In the case of UDP, the application can get message through udp directly. 
But for DTLS/UDP, each session maintains the DTLS state for each Exporter, and 
DTLS has no idea about
which session is for which exporter. Which need application maintains, like 
using IP-5-Tuple plus the Observation Domain ID
mapping to each session.

>  
>  A good question is when to remove the DTLS state because there is no
>  connection termination. We remove it after a certain time without
>  receiving any packets from the Exporter. However, we cannot be sure if
>  the Exporter has also deleted its DTLS state :(
>  This is another situation where DTLS Heartbeat extension is useful.

I share this opinion. "timeout" can also work for it.

>  > There may many syslog sender send logs to one receiver, which 
> brings up an issue of dtls-udp.
>  > I wrote it in my proposal, in 5.3 as session demultiplexing. 
>  > 
>  > I think if the ipfix collector need support multiple exporter, 
> ipfix need also support session demultiplexing,
>  > but I didn't see that in your proposal, what's your consideration?
>  
>  You talk about draft-mentz-ipfix-dtls-recommendations-00?
>  Note that this draft does not play the same role as
>  draft-feng-syslog-transport-dtls-01 because IPFIX over DTLS/UDP is
>  already standardized in RFC5101.
>  draft-mentz-ipfix-dtls-recommendations-00 only covers DTLS specific
>  implementation problems and might be considered as an update of RFC 5153
>  (IPFIX Implementation Guidelines).
>  
I mean that is the application need to implement when using DTLS/UDP as 
transport,
which is the issue of DTLS/UDP, I stated in my proposal, but I didn't see you 
add any comments
on it:(. That is why I asked if you have any other consideration. I asked for 
your valuable comments.



Thanks
Linda

>  Gerhard
>  
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog

Reply via email to