I think it is important that we either decide that all we care about are
route entries, or that we still have a broader scope.
If all we want are RIB entries then I suspect we can solve the backup
problem in a reasonable fashion.
However, when the WG started it was agreed that our scope was
significantly larger than just the RIB. With that larger scope, the
potential for interactions and similar issues make solving the storage
of backup entries significantly more complex, which is a major part of
why the WG decided against such an approach.
Yours,
Joel
On 11/30/15 1:20 PM, Susan Hares wrote:
Russ:
Andy has mentioned the latency problem of not having back-up routes
repeatedly.
My message at IETF 94 was encourage this type of thing to get the I2RS
protocol and module out of the "just another configuration model".
Sue
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Russ White
Sent: Sunday, November 08, 2015 9:54 AM
To: 'Alia Atlas'; 'Andy Bierman'
Cc: [email protected]; 'Joel M. Halpern'; 'Susan Hares'
Subject: Re: [i2rs] Conversation on Priority and Panes
ideas of store-if-not-best and handling overwrites and so on. There
was a very clear push back against any such complexity. Feel free to
take a read through the archive.
IMHO, then, is severely diminished to the point of being non-useful work. If
there is no way to store a "backup route," then any use of I2RS to install
LFAs, backup tunnels, and even temporary changes in the routing table, are
out of bounds, and I2RS becomes "yet another configuration mechanism."
Russ
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
