On 6/2/15, 11:30 AM, Eric W. Biederman wrote:
roopa <ro...@cumulusnetworks.com> writes:
On 6/1/15, 9:46 AM, Robert Shearman wrote:
In order to be able to function as a Label Edge Router in an MPLS
network, it is necessary to be able to take IP packets and impose an
MPLS encap and forward them out. The traditional approach of setting
up an interface for each "tunnel" endpoint doesn't scale for the
common MPLS use-cases where each IP route tends to be assigned a
different label as encap.
The solution suggested here for further discussion is to provide the
facility to define encap data on a per-nexthop basis using a new
netlink attribue, RTA_ENCAP, which would be opaque to the IPv4/IPv6
forwarding code, but interpreted by the virtual interface assigned to
the nexthop.
A new ipmpls interface type is defined to show the use of this
facility to allow IP packets to be imposed with an MPLS
encap. However, the facility is designed to be general enough to be
used by any encapsulation/tunneling mechanism that has similar
requirements of high-scale, high-variation-of-encap.
RFC because:
- IPv6 side not implemented
- struct rtable shouldn't be bloated by pointer+uint
- Hasn't been thoroughly tested yet
Robert Shearman (3):
net: infra for per-nexthop encap data
ipv4: storing and retrieval of per-nexthop encap
mpls: new ipmpls device for encapsulating IP packets as mpls
Glad to see these patches!.
I have a similar series i have been working on...but no netdevice.
A set of ops similar to iptun_encaps and I store encap data in fib_nh
and in ip_route_output_slow i point the dst.output to the output func provided
by one of the encap ops.
I see the advantages of using a netdevice...and i see this align with patches
from thomas.
roopa I think I would prefer your patches. I thinking using a netdevice
the way Robert is proposing is quite possibly a mess, from a scalability
stand point.
Do you mean ip_route_input_slow? There is no ip_route_output_slow.
yes, correct, sorry. I mean ip_route_input_slow. They need work but i
will try to get them out today to add more context to the discussion.
thanks,
Roopa
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
