On 6/10/15, 12:13 AM, roopa wrote:
Robert/Thomas, All my changes are in the below repo under the 'mpls'
branch.
https://github.com/CumulusNetworks/net-next
https://github.com/CumulusNetworks/iproute2
The last iproute2 commit has a sample usage.
The commits pushed to this tree do not contain
On 6/8/15, 3:58 PM, Thomas Graf wrote:
I'll immediately ACK any series that supports both models and rebase
my patches on top of it. I think we are on the right track overall.
I am trying to get my code on github to collaborate better. Stay tuned
(hopefully end of day today).
Robert/Thomas,
On 06/08/15 at 08:17am, roopa wrote:
ack, that sounds intuitive.
With RTA_ENCAP and the mpls examples i was using it looks something like the
below for (1)
ip route add 10.1.1.0/30 encap mpls 200 via 10.1.1.1 dev eth0
The tunnel dst is parsed and understood by the light weight tunnel
On 06/05/15 at 07:54pm, roopa wrote:
On 6/5/15, 8:26 AM, Robert Shearman wrote:
It isn't clear to me what the strategy here is for dealing with tunnel
encaps that aren't bound to an interface.
Thomas, I presume you would prefer not to force the user to keep track of
changes to the output
On 6/8/15, 5:33 AM, Thomas Graf wrote:
Yes, the information used to determine the encapsulation and the
route used to select the outgoing interface might be coming from
different components. A simple and typical example is if you are
running quagga to for your underlay which determines which
On 06/03/15 at 07:21am, Roopa Prabhu wrote:
From: Roopa Prabhu ro...@cumulusnetworks.com
This is still WIP and incomplete.
Posting it here because of the other discussions
happening around mpls ler in the context of Roberts
code and I happened to mention this implementation.
This was in
On 6/5/15, 2:14 AM, Thomas Graf wrote:
On 06/03/15 at 07:21am, Roopa Prabhu wrote:
From: Roopa Prabhu ro...@cumulusnetworks.com
This is still WIP and incomplete.
Posting it here because of the other discussions
happening around mpls ler in the context of Roberts
code and I happened to mention
On 05/06/15 10:14, Thomas Graf wrote:
As I mentioned to Robert, the new RTA_ENCAP should be a list of
Netlink attributes from the beginning to make it extendible without
ever breaking user ABI.
Just to be clear in both of our approaches, the contents of the
RTA_ENCAP data is interpreted by
On 05/06/15 15:16, roopa wrote:
On 6/5/15, 2:14 AM, Thomas Graf wrote:
On 06/03/15 at 07:21am, Roopa Prabhu wrote:
From: Roopa Prabhu ro...@cumulusnetworks.com
This is still WIP and incomplete.
Posting it here because of the other discussions
happening around mpls ler in the context of
On 6/5/15, 8:26 AM, Robert Shearman wrote:
It isn't clear to me what the strategy here is for dealing with tunnel
encaps that aren't bound to an interface.
Thomas, I presume you would prefer not to force the user to keep track
of changes to the output interface and nexthop corresponding to
From: Roopa Prabhu ro...@cumulusnetworks.com
This is still WIP and incomplete.
Posting it here because of the other discussions
happening around mpls ler in the context of Roberts
code and I happened to mention this implementation.
This was in response to earlier email thread with Eric on
11 matches
Mail list logo
