[j-nsp] BOOTP helper on MX vrf

[Saku Ytti]

On (2013-06-13 13:25 +0200), Sebastian Wiesinger wrote:

> Okay, but for dhcp-relay you need a license which is really not
> something we want to do just for bootp helper. :)

Phil already covered fix to your issue, and I recommend using it.
Stateless, dumb, working.

Another problem with DHCP-relay is that, AFAIK, it causes _all_ dhcp
packets in every interface to be punted. So some transit DHCP packet
jetting through your router in unrelated interface gets punted.
I find this most unsatisfactory, but of course we're 'only one who has
complained about this'. 

I wonder if we need some community site to aggregate and vote-up feature
requests and fixes, maybe something simple like userecho. Since there are
tons of features I know many people want, but no one (not even JNPR) has
clue what these are.

It's baffling vendors (I'm not pointing at JNPR, every one does this) fail
to capitalize on the valuable information customers give them about things
they need to change in their gear to sell more.
How I'd handle this is, if TAC issue looks like feature request, ticket is
moved to another BU handling features. Then they verify that both custoemr
and Juniper understand what is requested, then punch in the data in a
formal way, this way everything would be logged and in some time, you'd
have database where you can check what features are most requested.

Now vendors are just telling customers to file PERS/ER which is not even
formal process, but somehow in the air, you email your account team, which
may or may not do something about it, but there is formal metadata or
format for the request so the data is obviously of very low value and very
low quality. And most customers don't even bother doing it at that point,
just give up, so the data is simply lost.
How can anyone afford to lose this data is beyond me.


-- 
  ++ytti