[j-nsp] MX204 and copper SFP?

[Saku Ytti]

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 <niall.donaghy at geant.org> 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), Multiservices (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,
> respectively ... 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-bounces at puck.nether.net] On Behalf Of
> Chuck Anderson
> Sent: 05 April 2018 20:31
> To: juniper-nsp at 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-bounces at puck.nether.net] On
>> Behalf Of Ola Thoresen
>> Sent: Thursday, April 05, 2018 3:59 AM
>> To: juniper-nsp at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
  ++ytti