I don't think that ignoring consistency follows. The combined (long
term plus ephemeral) state still has to be valid and operable.
Pretending that the controller will always send only correct ephemeral
changes seems an invitation to trouble. But the main point is that you
need to make the argument in the draft, not that you need to convince me.
Yours,
Joel
On 3/19/2025 1:53 AM, Zafar Ali (zali) wrote:
Hi Joel
As this is for ephemeral state, the consistency check with the
configuration is not required.
Thanks
Regards … Zafar
*From: *Joel Halpern <jmh.dir...@joelhalpern.com>
*Date: *Wednesday, March 19, 2025 at 11:38 AM
*To: *Zafar Ali (zali) <z...@cisco.com>, rtgwg@ietf.org
<rtgwg@ietf.org>, spr...@ietf.org <spr...@ietf.org>
*Subject: *Re: [rtgwg] RPC for programming ephemeral routing states
My understanding is that part of the reason people are often moving to
restconf is that the protocol exchanges are somewhat simpler. Note
that the significant delay I have heard about is often in the
processing system and consistency checks, and moving to restconf, or
gRPC, or ... does not change that.
Yours,
Joel
On 3/19/2025 12:27 AM, Zafar Ali (zali) wrote:
Hi Joel
Many thanks for your comments; much appreciated.
The goal of the draft is to solicit this type of feedback. MANY
THANKS!
The draft talks about applicability of the Yang over Netconf (I
know you mentioned RESTCONF).
Specifically, the Netconf route is slow and unpredictable for
real-time applications like tactical traffic engineering
I am not an expert in manageability, but I am afraid RESTCONF
would have the same issue?
Looking forward to your/ WGs feedback on how to take this work
forward.
Thanks
Regards … Zafar
*From: *Joel Halpern <j...@joelhalpern.com>
<mailto:j...@joelhalpern.com>
*Date: *Saturday, March 8, 2025 at 2:10 PM
*To: *Zafar Ali (zali) <z...@cisco.com> <mailto:z...@cisco.com>,
rtgwg@ietf.org <rtgwg@ietf.org> <mailto:rtgwg@ietf.org>,
spr...@ietf.org <spr...@ietf.org> <mailto:spr...@ietf.org>
*Subject: *Re: [rtgwg] RPC for programming ephemeral routing states
One thing I missed in reading this draft is why this was better
than existing tools, e.g. YANG over RESTCONF. For which we know
the integration with the rest of the operational environment. (I
can believe there is an advantage, but I couldn't tell what it was.)
Yours,
Joel
On 3/8/2025 1:04 PM, Zafar Ali (zali) wrote:
Hi,
Recently, the industry has witnessed increasing use cases
where a controller needs to install ephemeral routing states
in the network. Protocol use requires the controller to
implement laborious encoding, decoding, serialization of data
streams, etc.
We have written a generic draft of routing RPC API for
programming ephemeral routing states, using SR policy
programming as an example.
https://datatracker.ietf.org/doc/draft-ali-spring-sr-policy-programming-rpc/
<https://datatracker.ietf.org/doc/draft-ali-spring-sr-policy-programming-rpc/>.
It aims to ease the programming of ephemeral routing states in
the network using an SDN controller.
We request a review and discussion on how to forward the work
to the IETF. We will present it at the upcoming RTGWG meeting.
Thanks
Regards ... Zafar (on behalf of co-authors)
_______________________________________________
rtgwg mailing list --rtgwg@ietf.org
To unsubscribe send an email tortgwg-le...@ietf.org
_______________________________________________
spring mailing list --spr...@ietf.org
To unsubscribe send an email tospring-le...@ietf.org
_______________________________________________
rtgwg mailing list -- rtgwg@ietf.org
To unsubscribe send an email to rtgwg-le...@ietf.org
