Re: [Yot] YANG notification within CoMI

[Michel Veillette <[e-mail]>]

Hi Peter

About " I recommend to maintain section 5.5, as is, in the CoMI draft and start looking at the other subjects separately."

The current 'observe' method might still be useful for some use cases which requires a temporary subscription. For example, this method can be used to temporarily subscribe to the syslog for debug purposes. This method can also be used to wait for the completion of a transaction initiated using the normal CoAP methods.

To address the more common event stream use cases (i.e. a something equivalent to SNMP traps), it seem we need to introduce a new mechanism.

About how to solution should be packaged (i.e. one of two drafts), we should probably wait for a better understanding of the direction we want to take.

Regards,
Michel

From: Peter van der Stok [mailto:[e-mail]]
Sent: Monday, June 11, 2018 3:20 AM
To: Michel Veillette <[e-mail]>
Cc: Andy Bierman <[e-mail]>; Alexander Pelov <[e-mail]>; Eric Voit (evoit) <[e-mail]>; Henk Birkholz <[e-mail]>; [e-mail]; Core <[e-mail]>
Subject: Re: YANG notification within CoMI

Hi Michel,

Thanks for the message.
I think that load balancers, stable storage for messages, californium implementation restrictions are all separate subjects, and merit a solution independent of CoMI.

I recommend to maintain section 5.5, as is, in the comi draft and start looking at the other subjects separately.

Peter

Michel Veillette schreef op 2018-06-08 20:17:

Support the YANG notifications in the current CoMI draft (i.e https://www.ietf.org/id/draft-ietf-core-comi-03.txt) is based on the observe option as defined by RFC7641.



This solution has the following issues which make it not practical for the targeted use case.



1) This approach in incompatible with load balancers, notifications are directly returned to the specific server within the cluster which have initiated the observe request.

2) Typical CoAP implementation (e.g. Californium) doesn't support the persistence of the observe context. These contexts can't be recovered after a server restart and can't be shared between servers.

3) Registrations to event streams are not resilient, they can terminate unexpectedly upon transmission error or reception of a Reset message.



I recommend to delete draft-ietf-core-comi section 5.5 and start a specific effort on this topic.

Alignment with the [I-D.ietf-netconf-yang-push] also need to be considered.

Those interested to this topic, please send me a email so I can schedule conference calls or a face to face meeting during the next IETF.



The following diagram shows a typical deployment scenario.



  +---------+  +---------+       +---------+

  | CoMI    |  | CoMI    |  ...  | CoMI    |

  | server  |  | server  |       | server  |

  +---------+  +---------+       +---------+

       |            |                 |

       |            |                 |

       +----------+-+-----------------+

                  |

                  |

   +---------------------------------+

   | CoMI         |                  |

   | client       |                  |

   |         +----------+            |

   |         | Load     |            |

   |         | Balancer |            |

   |         +----------+            |

   |              |                  |

   |        +-----+---------+        |

   |        |               |        |

   |   +---------+     +---------+   |

   |   | Server  | ... | Server  |   |

   |   +---------+     +---------+   |

   |        |               |        |

   |        +-------+-------+        |

   |                |                |

   |           +----------+          |

   |           | Database |          |

   |           +----------+          |

        |                                 |

   +---------------------------------+

Regards,
Michel