Folks,
So, I want to address this example from Dave's "home gateway" example:
loopback create
set int l2 bridge loop0 1 bvi
set int ip address loop0 192.168.1.1/24
set int state loop0 up
Here, lines 2, 3, and 4 all have unspoken knowledge of the effects of
line 1. Specifically, it "knows" that "loop0", by name, just got
created. One just knows.
In VPP land, one issues an API call to create a loopback interface.
VPP makes up the name for it ("loop0"), and tells you a new sw_if_index
for it. Likely something like 5 or 6 or so, depending on how many
other IFs have been made already.
In a Popular Router Configuration Language (PRCL), one says
interface loopback 0
and it creates the named interface, "Loopback0".
But there is a subtle difference, in VPP the name is assumed
for subsequent commands, while in PRCL, later commands will
need to know the name of the loopback interface. Not assume,
know. But without specifying it at creation, one can not know its
name for use later.
So, I'm proposing a slight modification to the create_loopback
API message. My proposal can maintain backward compatibility.
Currently:
/** \brief Create loopback interface request
@param client_index - opaque cookie to identify the sender
@param context - sender context, to match reply w/ request
@param mac_address - mac addr to assign to the interface if
none-zero
*/
define create_loopback
{
u32 client_index;
u32 context;
u8 mac_address[6];
};
I'm proposing adding a field that specifies the actual
name of the loopback interface be added.
define create_loopback
{
u32 client_index;
u32 context;
u8 mac_address[6];
u8 name[32];
};
Pick your favorite upper-bound for name length or substitute
a zero-terminated C-string-like name. Don't much care there.
But my point is that to achieve some compatibility with PRCL's
expected behavior, we'll need them to be named "Loopback<n>",
and not "loop<n>". Naturally, if the name isn't supplied by
the API caller, the current default name can be allocated.
At the bare minimum, the instance number should be supplied
in the API call and the VAT command changed to allow the form:
loopback create [<n>]
For example:
> loopback create 2
That way there is an explicit, not assumed, correspondence for
the following commands like:
> set int l2 bridge loop2 1 bvi
Thoughts?
jdl
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
