You're exactly right Saku, those are the questions to ask, the design decisions to be made. I posit that as Juniper break this up into type-fpc/pic/port, and there is some indication of speed in the type name, they would do well to standardise, or abandon the idea. Currently even the documentation states the type indicates speed, for some types, then lists exceptions to this. My only complaint is if you have to remember exceptions, best not to use it as an indicator at all.
I am certainly immersed in Ethernet interfaces more than any other, so accustomed to ge, xe, et denoting one speed, as per the deployment I work on every day. A little biased indeed. :) I categorically wouldn't want a single 'type' prefix. Agree on the dynamic update on linerate OID being an ideal feature to have. Get Outlook for Android<https://aka.ms/ghei36> From: Saku Ytti Sent: Friday, 6 April, 19:55 Subject: Re: [j-nsp] MX204 and copper SFP? To: Niall Donaghy Cc: Chuck Anderson, juniper-nsp@puck.nether.net Maybe you're right. Maybe you're suffering status quo bias. If interface name should give some indication, but provably unreliable indication of interface rate. Is that the idea amount of information encoded to interface name? Or should we code more information in the name? Or less? Should interface name include encapsulation type, why not? Why is rate special? We have field for bandwidth in SNMP MIB and interface CLI configuration, this could be automatically set to linerate of interface, so we would offer dynamic and accurate data about linerate, as opposed to interface name. Unless we want interface name to change once we change the speed?. On 6 April 2018 at 21:07, Niall Donaghy wrote: > Indeed, encapsulating a port speed in its name offers some convenience in > show commands, configuration groups, and interface-ranges; I would say the > value there is non-zero. > > Going beyond that, how about logical tunnels (lt-), GRE interfaces(gr- and > gre), loopback interfaces (lo), Multis ervices (ms-), SONET/SDH (so-) and the > various assortment? > Ref: > https://www.juniper.net/documentation/en_US/junos/topics/concept/interfaces- > interface-naming-overview.html > This page seems to say that aside from PTX routers, where et- can be > 10/40/100GE, et- == 100GE. > We know that's not the case as on MX204 and MX10k3, et- can be 40/100GE. I > guess they might update this page sometime.. > > Consider operators whose interface descriptions don't encapsulate the > relevant information, or worse still - whose operational interfaces may not > have interface descriptions at all. > In those cases it is *incredibly* useful to identify interface type by > interface name. > I would say identifying speed by name is an extension of that. > > I don't see that moving to a generic prefix such as inf- is for the greater > good. > > So now we have ge-, xe-, and et- meaning physical Ethernet interfaces - and > depending on your hardware, optics, and config - *likely* 1GE/10GE/100GE, > r espectively ... but, maybe not. > Now with the speed variances, at least we can still say they're physical > interfaces. > > > Br, > Niall > > > -----Original Message----- > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of > Chuck Anderson > Sent: 05 April 2018 20:31 > To: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] MX204 and copper SFP? > > Back-in-the-day we had fe-x/x/x for 10/100 Mbps ports. Now we have ge-x/x/x > that can take a 100 Mbps SFP, but the name doesn't change to fe-x/x/x AFAIK. > So there is precedent for the names not changing when the speed changes. > > But I do like having the ability to match ports based on speed, e.g. find > all "uplink" ports by assuming ge-* are access ports and xe-* are uplinks. > Patterns can be used within configuration groups and interface-ranges. > > On Thu, Apr 05, 2018 at 01:38:46PM +0000, Nelson, Brian wrote: >> Port-foo is so archaic. >> It's an interface, inf-x/x/x would be more germane. >> >> Brian >> >> -----Original Message----- >> From: juniper-nsp >> >> [mailto:juniper-nsp-boun...@puck.nether.net] On >> Behalf Of Ola >> >> Thoresen >> Sent: Thursday, April 05, 2018 3:59 AM >> To: >> >> juniper-nsp@puck.nether.net >> Subject: Re: [j-nsp] MX204 and copper >> >> SFP? >> >> On 05. april 2018 10:44, Saku Ytti wrote: >> >> > Since of >> >> the fathers. >> > >> > 'Cisco did it'. >> > >> > I also see no value in >> >> it. >> >> Don't we all love that "linux" changed from eth0, eth1, >> >> eth2... to > beautiful stuff like wwp0s20u4 and enp0s25... >> >> Just >> >> call them port-x/x/x and be done with it. >> >> >> /Ola (T) > >> >> _______________________________________________ > juniper-nsp mailing >> >> list juniper-nsp@puck.nether.net > >> >> https://puck.nether.net/mailman/listinfo/juniper-nsp > > >> >> _______________________________________________ > juniper-nsp mailing >> >> list juniper-nsp@puck.nether.net > >> >> https://puck.nether.net/mailman/listinfo/juniper-nsp > -- ++ytti _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
