On 19/06/15 16:28, roopa wrote:
On 6/19/15, 8:19 AM, Robert Shearman wrote:
On 19/06/15 05:49, Roopa Prabhu wrote:
From: Roopa Prabhu <ro...@cumulusnetworks.com>
Introduces two netlink attributes RTA_ENCAP_TYPE and
RTA_ENCAP to support attaching encap information to ipv4 routes.
Surely RTA_ENCAP_TYPE should be part of RTA_ENCAP, since the type
doesn't make sense without the data and vice versa?
I went back and forth on this. And started with what you are saying
above. But then I wanted RTA_ENCAP netlink policy to be declared by
individual lwtunnel drivers.
And to determine which RTA_ENCAP netlink policy to pick, you need to
know the RTA_ENCAP policy type (or lwtunnel type)
which is encoded in RTA_ENCAP_TYPE. And I did not want to introduce
another level of nest in RTA_ENCAP (because for nexthops we are already
2 levels deep when parsing RTA_ENCAP).
No need for that - use the example of how RTA_MULTIPATH is used for
ipv4/ipv6:
+----------------------+
| RTA_MULTIPATH |
+----------------------+
| +------------------+ |
| | struct rtnexthop | |
| +------------------+ |
| | RTA_GATEWAY, etc.| |
| +------------------+ |
+----------------------+
You could do similar for RTA_ENCAP where the type is stored in the data
prior to the nested attributes starting. E.g.:
+----------------------+
| RTA_ENCAP |
+----------------------+
| +------------------+ |
| | struct rtencap | |
| +------------------+ |
| | MPLS_IPTUNNEL_DST| |
| +------------------+ |
+----------------------+
struct rtencap {
__u16 rte_type;
};
Hence, fib code first looks for RTA_ENCAP and if RTA_ENCAP is specified,
RTA_ENCAP_TYPE is a required attribute. My iproute2 patches handles this
and makes sure
there is an RTA_ENCAP_TYPE specified with RTA_ENCAP.
No doubt, but surely it's better to present an unambiguous API to
userspace if possible?
Thanks,
Rob
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
