[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <556DD688.2020308@cumulusnetworks.com>
Date: Tue, 02 Jun 2015 09:15:04 -0700
From: roopa <roopa@...ulusnetworks.com>
To: Robert Shearman <rshearma@...cade.com>
CC: netdev@...r.kernel.org,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Thomas Graf <tgraf@...g.ch>,
Dinesh Dutt <ddutt@...ulusnetworks.com>,
Vivek Venkatraman <vivek@...ulusnetworks.com>
Subject: Re: [RFC net-next 3/3] mpls: new ipmpls device for encapsulating
IP packets as mpls
On 6/1/15, 9:46 AM, Robert Shearman wrote:
> Allow creating an mpls device for the purposes of encapsulating IP
> packets with:
>
> ip link add type ipmpls
>
> This device defines its per-nexthop encapsulation data as a stack of
> labels, in the same format as for RTA_NEWST. It uses the encap data
> which will have been stored in the IP route to encapsulate the packet
> with that stack of labels, with the last label corresponding to a
> local label that defines how the packet will be sent out. The device
> sends packets over loopback to the local MPLS forwarding logic which
> performs all of the work.
>
>
Maybe a silly question, but when you loop the packet back, what does the
local MPLS forwarding logic
lookup with ? It probably assumes there is a mpls route with that label
and nexthop.
Will this need any internal labels (thinking same label stack different
tunnel device etc) ?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists