Jason 

Both use cases are valid but cause problems for interoperability for many years afterwards. 

Not so clear cut. 

I think it might be helpful to illustrate your point with a slightly more complex example. One where the path is not determined via STP. That way the path could be different for Switching and Forwarding, which is where the tremendous value begins to emerge.

My $0.02

-grin-

Question, Why are you calling L2 MAC forwarding switching?  Several decades ago we did one of 3 things to a packet, repeated it (frame was not touched), Bridged it (L2 MAC forwarding), or Routed it (L3 forwarding followed by L2 forwarding).  The term switch is a “marketing” term that really just talks about a multiport Bridge in my opinion, and we have had those for many, many years.

What changes to the Ethernet headers at L2 happen with flow forwarding on a hop by hop basis?  If I put my trusty Sniffer on the wire, what will I see different from an Ethernet standpoint?  The DST MAC address will have to be changed before it gets to it’s final home doesn’t it?

What am I missing here? 
Any examples at that level you can share?

Thanks,
Matt

But how do you establish the information in the FIB?  Does a lower level decision get made first (like destination MAC address switching so the “flow” can even start up promptly and correctly) then additional flow information is pulled and populated in the FIB?  Once you have flows defined and flow information populated in the FIB, then your global flow policies can take effect, such as “if the output queue of this link reaches a certain depth, then begin to shed certain flow(s) out some other interface.”  The new network engineers will be good at creating rules like this that make sense in their own environments.  Of course, there will always be the steadfast “best practices” we can always rely on, right?

regards,

Ali

Definitely have a standard, but in terms of networking equipment I like a functional indicator (cor, bdr, lns, pe etc), and an index (1, 2, 3 etc).

Then use DNS subdomains for each ‘site’ e.g:

bdr1.adl1

The other things that I’ve found work are:

- Don’t use leading zeros (e.g. don’t do bdr01.lax01) – two good reasons:

1) You run out of space, leading to strange things like ‘ce101′ and ‘ce07′, which can increase error rates and make it harder to regex against.

2) People don’t ‘say’ numbers over the phone – they’ll say ‘core one’, not ‘core zero zero one’. More opportunity for confusion – and for what benefit?

- Don’t use hyphens. People don’t say those on the phone either.

- Don’t worry about including things like device model or vendor in the name for devices – you’ll change the device, or the model. Additionally, for the paranoid you’ll be giving free hints to anybody that may be looking into your network.

- Finally (especially about locations e.g. ROOM_SUITE_RACK etc) – I like to go with whatever is likely to be familiar to the majority of people. Our local incumbent Telco goes with ROOM/SUITE/RACK/RU – so we’ve done the same in all of our sites, and it means when contractors come in, they’re in familiar territory.

Too many times, managers feel that only they can make the decisions and don’t like what they hear from their experts and then move in the their own direction. Managers need to “sell down” to their staff just as much as the reverse is true.

Leadership isn’t doing it yourself, it’s just being first among equals.

network degree, certs =  keyboard engineer aka copy/paste monkeys
desk engineers will always get the “consultation” by those experienced field engis – field engis built the stinking network and drive across town at 2am to fix it – with pleasure

so get in the field and get dirty before even thinking about becoming a consultant

learn what optics are all about because your network uses them – dont bend/pinch that glass!
it all starts at the bottom – hardware first, configs second – always (can I get a loopback plz?)

we are all frustrated during outages/critical projects so keep it to yourself and concentrate on the variables being dealt with

and document document document

if you do not document you will regret it
and dont even think about waiting for your manager or disgruntled team members to encourage you to do what needs to be done

good ethics are learned and taken with you to your next job – so are the bad