netdev - Re: [PATCH net-next RFC v2 3/3] mpls: support for ip tunnels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 20 Jun 2015 07:41:04 -0700
From:	roopa <roopa@...ulusnetworks.com>
To:	Robert Shearman <rshearma@...cade.com>
CC:	ebiederm@...ssion.com, tgraf@...g.ch, davem@...emloft.net,
	netdev@...r.kernel.org,
	Vivek Venkatraman <vivek@...ulusnetworks.com>
Subject: Re: [PATCH net-next RFC v2 3/3] mpls: support for ip tunnels

On 6/19/15, 9:06 AM, Robert Shearman wrote:
>
> Since the entire label stack and the output device is encoded in the 
> route, this means that you won't get prefix-independent convergence 
> with this implementation for an IGP route change. I.e. if you've got 
> 10 million VPN routes via an IGP route for the BGP nexthop, and the 
> IGP route for the BGP nexthop changes (e.g. because a link has gone 
> down somewhere in the network) then you'll have to update all 10 
> million IP routes to change the output device, gateway and IGP label.
>
> That's going to represent a scaling obstacle for one of the primary 
> MPLS use cases.

I cant say I understand PIC very well, but, assuming PIC is not just an 
mpls thing, PIC does require an alternate nexthop infrastructure in the 
kernel (FIB).
And if that were present, It would help the mpls case too. I am not sure 
how you would solve PIC just for the mpls case or if having a netdevice 
makes it any easier.

Thanks,
Roopa


--
To unsubscribe from this list: send the line "unsubscribe netdev" in