The IM draft was written with the intent as in the draft. In other words, the <nexthop-id> space is private to the I2RS agent. The agent allocates nexthop-id and returns that to the Client. The client can use that as a convenience. The client itself can maintain a global ID space across all agents if it desires. But that is outside the scope of the IM draft.
> Nexthops can be identified by an identifier to create a level of indirection. The identifier is set by the RIB manager and returned to the external entity on request. > Is the above ³identifier² the same as ³nexthop-id²? If yes, then it conflicts with your text below? From: Susan Hares <[email protected]> Date: Wednesday, October 7, 2015 at 5:01 AM To: "'Jeffrey (Zhaohui) Zhang'" <[email protected]>, <[email protected]> Subject: Re: [i2rs] RIB Info/Data model questions: nexthop-id Jeffrey: to start this discussion going, I would like to provide you with the answer that was given when the I2RS RIB Information Model was designed. · All I2RS RIB information is intended config (see ietf-chairs-netmod-opstate-reqs-01 or ietf-openconfig-netmod-opstat for the definition of intended config), · nexthop-id is assigned by the I2RS client, and inserted into the I2RS agent, · the I2RS agent installs the I2RS RIB ephemeral state, and provides back status (installed, not installed). nexthop id allows for all types of next hops (chains, inet-v4, inet-v6, mac-address, interface tunnels) to be indicated with a single id that can be directly accessed. This allows these different types of next-hop to be directly referenced with the nexthop-id.
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
