netdev - RE: [PATCH net-next 0/8] Basic MPLS support

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]

Message-ID: <96cd5ea110617310654d828231f19fd4@mail.gmail.com>
Date:	Sun, 1 Mar 2015 16:05:49 -0800
From:	Shrijeet Mukherjee <shm@...ulusnetworks.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, Roopa Prabhu <roopa@...ulusnetworks.com>,
	stephen@...workplumber.org, santiago@...reenet.org
Subject: RE: [PATCH net-next 0/8] Basic MPLS support

>There is also my experience in router contexts that says arp or neighbour
>discovery is usually the last thing to know (short of gratuitious arps)
that a
>neighbour has failed.  So some other protocol is needed to detect
failure.

Definitely a longer discussion is needed here for the router/switch use
case. Our current position on this (not unique) is to let the protocol
manager which handles the neighbor state machine manage the need or lack
thereof of the GARP's.

This also came up in the L3 offload/switchdev side of the discussion,
where the need maybe more pronounced even.

This has led to mechanisms like BFD to exist which in my opinion causes
more problems than it solves. But sounds like some sunlight on mechanisms
that can be used here may have far reaching benefits.
--
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