I think it depends if and/or how we decouple traffic-bearing interfaces
from the RIB... Do we want the information model to represent
ingress/egress labels, VLANs, etc as fields in the RIB, attributes of
the RIB (or of various tables), or attributes of interfaces? Is the
information model the same for ingress vs egress traffic?
I have opinions, of course. But I'm open-minded.
Cheers,
-Benson
On 3/14/13 1:46 PM, Alia Atlas wrote:
I do see setting an MPLS label as a characteristic of a next-hop. The
concern will be describing capabilities reasonably without a rat-hole.
This is doing L3 routing - so VLAN matching seems out; while there may
be PWE3 or L2VPN type use-cases eventually, I've not seen them yet.
Alia
On Thu, Mar 14, 2013 at 11:17 AM, Robert Raszuk <[email protected]> wrote:
Hi Russ ...
For me the base set is completely not sufficient for any of the
application I would use I2RS for.
As example: it is missing match on VLAN, set MPLS VPN label, set MPLS
transport label.
r.
On Thu, Mar 14, 2013 at 4:14 PM, Russ White <[email protected]> wrote:
I wouldn't frame the question in terms of the packet header but the routing
table... I don't know that the answer comes out different, but... :-)
That said, I think a good base set would be:
- Dest IP Address
- Next hop IP address
- Outbound interface
- Admin distance
- Some form of tags
- Table ID
We've talked about the ad,in distance being more like a community string than
an integer (having multiple parts so you can have several types of metrics
here), but I don't know how useful that would be. I'm all for thinking past the
immediate need and leaving doors open for unthought of things, though.
There's also the back channel out of the rib to consider -- specifically, things like, "your route was just
overwritten by another process," "a route was just redistributed to you," "the next hop for this
route just went away," "this connected route just failed," and other related stuff.
But I think we might need to get the use cases to give us what information they need, and
work build a good list from that. Then we can ask the question, "is there a model
that fits already?"
:-)
Russ
<><
[email protected]
On Mar 14, 2013, at 11:02 AM, Robert Raszuk <[email protected]> wrote:
My main question is what L2-L4 fields for the packet lookup I can
program to the 'RIB" by I2RS. Very precise and simple.
The use case for multiple RIBs is just being shown in the room. L3VPN
PE auto-provisioning ;)
Best,
R,.
On Thu, Mar 14, 2013 at 3:58 PM, Scott Whyte <[email protected]> wrote:
On 03/14/2013 07:46 AM, Robert Raszuk wrote:
I think we agree that RIB elements for read and write must be clearly
defined. And should be extensible.
But is RIB abstraction sufficient for I2RS ?
For example as we know each VRF contains it's own RIB (different table
id). So protocol must be able to also encode which RIB we are talking
to.
Further who will instantiate the VRF in this case ? Will I2RS be able
to create a RIB instance on the fly ? How will we attach such RIB
instance to interfaces ? There is dozens of details here without which
I am afraid we can't go productively forward.
I guess I'm confused now on what you consider propietary implementation
detail of a RIB, but I'll assume you are still talking strictly about a RIB
abstraction and increasing its scope to multiple RIBs communicating with a
single I2RS agent.
Not sure about dozens of details, but your four good questions above all
seem to revolve around a single issue, handling of multiple RIBs, which I
think is important to have as a use case.
-Scott
Best,
R.
On Thu, Mar 14, 2013 at 3:41 PM, Scott Whyte <[email protected]> wrote:
On 03/14/2013 07:34 AM, Robert Raszuk wrote:
Hi Scott,
Why do we need to go beyond defining an interface to the RIB to make
your
use case work?
I am talking precise about that definition of RIB interface. Not how
the RIB works in given vendor of network element. That is
implementation detail.
Basically a list of values one can write or read to/from RIB. Have you
seen any document with such list yet ?
So we agree that what a RIB looks like is out of scope, and we need to
insure extensibility beyond proposed use cases for the actual RIB
interface?
If so I think the group is well on track to get there, as we grind
through
use cases and existing data models.
-Scott
Cheers,
R.
--
People who are essentially without the power to implement their ideas in
the
real world must leverage the power of their reputations.
--
People who are essentially without the power to implement their ideas in the
real world must leverage the power of their reputations.
_______________________________________________
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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
