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.
As to protection, Let's base our discussion on I2RS RIB IM p. 19 (see
below)
The protection id - identifies of preference, nexthop-id. Preference ID
identifies the tuple. You might have multiple tuples with a nexthop-id.
Protection-id 1: preference=10, nexthop-id=1
Protection-id 2: preference = 2, nexthop-id=1
Protection-id 3: preference=1, nexthop-id = 1
Protection-id 4: preference =1, nexthop-id=2
I do not understand how the protection-id should be linked by nexthop.
Sue
======================
I2RS RIB IM p. 19 for your reference:
----------------------------
<nexthop> ::= <NEXTHOP_PROTECTION> <1> <interface-primary>
<2> <interface-backup>)
Derived as follows:
<nexthop> ::= <nexthop-protection>
<nexthop> ::= <NEXTHOP_PROTECTION> (<NEXTHOP_PREFERENCE> <nexthop>
(<NEXTHOP_PREFERENCE> <nexthop>)...)
<nexthop> ::= <NEXTHOP_PROTECTION> (<NEXTHOP_PREFERENCE> <nexthop>
(<NEXTHOP_PREFERENCE> <nexthop>))
<nexthop> ::= <NEXTHOP_PROTECTION> ((<NEXTHOP_PREFERENCE> <nexthop-base>
(<NEXTHOP_PREFERENCE> <nexthop-base>))
<nexthop> ::= <NEXTHOP_PROTECTION> (<1> <interface-primary>
(<2> <interface-backup>))
Traffic can be load-balanced among multiple primary nexthops and a
single backup. In such a case, the nexthop will look like:
<nexthop> ::= <NEXTHOP_PROTECTION> (<1>
(<NEXTHOP_LOAD_BALANCE>
(<NEXTHOP_LB_WEIGHT> <nexthop-base>
(<NEXTHOP_LB_WEIGHT> <nexthop-base>) ...))
<2> <nexthop-base>)
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Jeffrey (Zhaohui)
Zhang
Sent: Monday, October 05, 2015 9:59 AM
To: [email protected]
Subject: [i2rs] RIB Info/Data model questions: nexthop-id
Hi,
Both the RIB info and data model mentions nexthop-id, but neither specifies
who manages/assigns the ID. Can the specs point that out?
It seems that it could be both ways - the IDs could be allocated by routers
(servers) or could be allocated by clients. Different ID spaces would be
used depending on who allocates the IDs.
Related to the above, a specific question on the data model:
grouping nexthop {
leaf nexthop-id {
mandatory true;
type uint32;
}
choice nexthop-type {
...
case nexthop-protection {
list nexthop-protection-list {
key "nexthop-protection-id";
leaf nexthop-protection-id {
mandatory true;
type uint32;
}
leaf nexthop-preference {
...
}
leaf nexthop {
mandatory true;
type nexthop-ref;
}
}
}
Here a nexthop-protection is a list. Being a list it requires a key and we
defined this uint32 nexthop-protection-id, which I assume the controller
needs to assign and both the controller and the router needs to remember.
The list entry has a member "nexthop" which is a nexthop-ref, which is a
nexthop-id:
typedef nexthop-ref {
type leafref {
path "/i2rs-rib:routing-instance/i2rs-rib:rib-list" +
"/i2rs-rib:route-list/i2rs-rib:nexthop/i2rs-rib:nexthop-id";
}
}
So - why can't we use the nexthop-id itself as the key?
Thanks.
Jeffrey
_______________________________________________
i2rs mailing list
<mailto:[email protected]> [email protected]
<https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
