[HECnet] Multinet peerings...?

[Johnny Billquist]

On 2016-01-15 03:55, Brian Hechinger wrote:
> Well, the routers really only need to support ethernet and whatever we
> make their WAN links. No one else should care. The only thing this
> changes for others is which bridge hub they connect to.

Right. As long as they have something they can connect with.

> It’s only a small number of people who need to decide on what this WAN
> link is going to be. And it doesn’t have to be the same between any two
> hubs. If you want to use Multinet to me (for example) and I want to do
> GRE to Paul that really shouldn’t matter.
>
> Does that makes sense?

Yes. Totally. But a couple of years ago, your options were really 
limited no matter who you were. Multinet VMS, Cisco GRE, and that was 
about it. If people were running something else, you had no options at 
all. And that is still true for some people. However, with the pything 
decnet router and so on, they now also have an option.

My point is essentially that for many, ethernet was the only reasonable 
option for a long time, so the bridge made sense. And it still does for 
some. However, where we can run something else, we should. Having a 
larger ethernet segment that covers the whole world is not really a 
great solution. :-)

	Johnny

>
> -brian
>
>> On Jan 14, 2016, at 9:42 PM, Johnny Billquist <bqt at softjar.se
>> <mailto:bqt at softjar.se>> wrote:
>>
>> On 2016-01-15 03:25, Brian Hechinger wrote:
>>>
>>>> On Jan 14, 2016, at 8:03 PM, <Paul_Koning at Dell.com
>>>> <mailto:Paul_Koning at dell.com>> <Paul_Koning at Dell.com
>>>> <mailto:Paul_Koning at dell.com>> wrote:
>>>>
>>>>
>>>>> On Jan 14, 2016, at 4:40 PM, hvlems at zonnet.nl
>>>>> <mailto:hvlems at zonnet.nl> wrote:
>>>>>
>>>>> ...
>>>>>> Can the bridge program detect whether there are area routers for
>>>>>> the dame area at both ends and favor the local one, possibly block
>>>>>> advertising of the remote area router?
>>>>>
>>>>> I tried blocking traffic from a node in one area from getting to
>>>>> another
>>>>> area, with the exception of packets from area routers.
>>>>> Unfortunately, it does not work. DECnet can be clever about local
>>>>> ethernet connectivity. If you are on the same ethernet segment, nodes
>>>>> can communicate directly with other nodes on the same ethernet segment,
>>>>> even if they are endnodes, and this exen extends to nodes on different
>>>>> areas. So such filtering in the bridge cause communication to fail for
>>>>> endnodes on the ethernet segment, when the destination is on the same
>>>>> ethernet, even if in a different area.
>>>>
>>>> DECnet expects a "transitive Ethernet" -- if A can talk to B and B
>>>> can talk to C, A must be able to talk to C.  That's actually a
>>>> common assumption, other network protocols do the same.  DECnet is a
>>>> bit unusual in that it explicitly verifies this property, at least
>>>> for routers -- that's why router hellos have the router list in
>>>> them.  We put that in because we had run into some defective
>>>> Ethernets that were non-transitive, causing very strange misbehavior
>>>> until this protocol mechanism was added.
>>>>
>>>> End nodes have an on-Ethernet cache: if X talks to Y and both are on
>>>> the same Ethernet, they will do it directly.  From the first packet
>>>> if there are no routers; after the initial round-trip if there are.
>>>>  If you create a non-transitive Ethernet -- which is what filtering
>>>> does -- this will fail.  There is no workaround.  If you don't want
>>>> all the nodes on an Ethernet to have direct communication, the only
>>>> solution is to split it into two separate Ethernets, interconnected
>>>> by a router (not a bridge).
>>>
>>> And this is what I was (and always have been) thinking. Make
>>> “shorter” ethernet segments that are less geographically diverse. Put
>>> routers between them. That should solve most problems, no?
>>
>> Yes. This is actually just the traditional way networks are designed.
>> Ethernet is a LAN - as in local. It's not designed for long haul
>> connections. It only works because the internet today have pretty
>> amazing capacity compared to the 80s.
>>
>> But to get a more traditional topology, we need the routers in between
>> somehow - and the WAN links.
>> The problem with that have been that much DECnet gear only supports
>> various links that best would be described as arcane by todays
>> standards, in addition to the ethernet. How many use X.25 nowadays? Or
>> synchronous serial lines?
>>
>> Well, if you were running a Cisco box, you could tunnel DECnet over
>> GRE. Not everyone have one of those. The other option more "generally"
>> available was VMS machines running Multinet, as that supported DECnet
>> links carried over IP.
>>
>> One option that is slowly becoming more and more plausible are
>> specific routers, such as Pauls python router, and Rob Jarrats
>> implementation.
>>
>> I can now happily add another. I think I found the annoying bug in my
>> Multinet-compatible DECnet driver for RSX, so now RSX can also haul
>> long links over point-to-point instead of having to rely on the bridge.
>>
>> First link, between MIM and LEGATO is up, and looking stable.
>> More coming, I hope. Steve, how about SG1? ;-)
>>
>> Peter, would you like a link or two between somewhere at your end and
>> MIM as well? Maybe less useful, since we already have DIMMA that does
>> the same.
>>
>> Johnny
>>
>> --
>> Johnny Billquist                  || "I'm on a bus
>>                                  ||  on a psychedelic trip
>> email:bqt at softjar.se <mailto:bqt at softjar.se>            ||  Reading
>> murder books
>> pdp is alive!                     ||  tryin' to stay hip" - B. Idol
>


-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol