The I2RS WG is passing its requirements for I2RS protocol's to NETCONF. These requirements include ephemeral state, pub/sub, traceability, authentication of I2rs client/agent, security and transport requirements. As part of that work, we would like to confirm that the following things are useful for the I2RS protocol to support.
. IGP-REQ01: Track system-id used in ISIS instances and IS neighbors on ISIS adjacencies . IGP-REQ02: Allow ephemeral (temporary) configuration changes to ISIS . IGP-REQ03: Allow ephemeral configuration to fast-reroute in ISIS . IGP-REQ04: Allow ephemeral load balancing configuration changes to ISIS flows . IGP-REQ05/REQ07: I2RS subscription (pub/sub) to ISIS notification via I2RS for interface, neighbor, database, and prefix . IGP-REQ06: Subscription (pub/sub) or query of ISIS configuration and dynamic statistics via I2RS (interface, neighbor, database) . IGP-REQ08: Subscription (pub/sub) or query of ISIS protocol statistics The number IGP-REQxx refers to the numbering used in draft-ietf-i2rs-usecase-reqs-summary-01 <http://datatracker.ietf.org/doc/draft-ietf-i2rs-usecase-reqs-summary/> . Please let me know if these I2RS features ISIS changes that can help manage short-term changes to ISIS topology for DDoS, changes to exits, or on-demand bandwidth paths. How much yang model additions will these I2RS additions cost? All I2RS requirements can be implemented an ephemeral copy of the ISIS yang module augmented by: a) 5+ notifications and b) I2RS L3 Topology model which reads in the IGP data from ISIS. Thank you for your help. Sue Hares
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
