Re: [manet] DLEP address semantics and in-the-wild examples

I have done so with my current implementation... no real code change
necessary, just the options to put the DLEP UDP/TCP socket on a
different interface.

DLEP MUST deliver data-plane MACs in Destination-Up messages... the
DLEP-control-plane MACs are irrelevant for most things. I don't see a
reason to specify it, DLEP only cares about a layer-3 control
connection...

Henning

On Fri, Nov 19, 2021 at 10:09 AM Rick Taylor
<rick@tropicalstormsoftware.com> wrote:
>
> Hi Henning,
>
> I think we're agreeing here.
>
> By "out of band" I meant that while developing modem simulators, I have come across routers that have an internal L2-switch, and wish to establish DLEP on their "control interface" but the data-plane uses a "data interface" (with a different MAC).  In this scenario, the modem uses the TCP MAC (learned via ARP) as the Destination ID, and then the data-plane traffic arrives from the router with a source MAC that doesn't match.  In my simulator I just drop this traffic (because it's not to or from a 'destination') which causes confusion amongst users.  In the real world, should the modem be sniffing the packets and learning new local destinations rather than them being signalled via DLEP?  It's a very corner-case example, but RFC8175 is quite silent on the correct behaviour.
>
> I suppose this behaviour should be captured by the mythical "DLEP implementation Experience" draft all of us agree needs writing when we have the cycles...
>
> Cheers,
>
> Rick
>
> > -----Original Message-----
> > From: Henning Rogge [mailto:hrogge@gmail.com]
> > Sent: 19 November 2021 08:55
> > To: Rick Taylor
> > Cc: Sipos, Brian J.; manet@ietf.org; Taylor, Rick
> > Subject: Re: [manet] DLEP address semantics and in-the-wild examples
> >
> > As long as the Radio/Router answers the ARP for the unicast IPs used
> > for both DLEP UDP and TCP, the MAC for them should not matter.
> >
> > MAC addresses in DLEP in the default "bridging" mode are the router
> > end-to-end MACs... DLEP has to refer to these, otherwise the router
> > will not be able to make sense of the DLEP messages.
> >
> > I am not sure what you mean by "out of band"... are you talking about
> > Layer-3 routing DLEP radios?
> >
> > Henning
> >
> > On Fri, Nov 12, 2021 at 6:10 PM Rick Taylor
> > <rick@tropicalstormsoftware.com> wrote:
> > >
> > > Hi Brian,
> > >
> > >
> > >
> > > Your first assumption is correct.  The MAC address of the interface the
> > router uses to maintain the DLEP session is the MAC address used as a
> > Destination identifier by its peers.  DLEP does not (currently) define an ‘out-
> > of-band mode’ where the DLEP session is maintained on a different MAC
> > address from the data-plane.
> > >
> > >
> > >
> > > One could define an out-of-band mode by a router using a Destination Up
> > message with an alternate data-plane MAC address, but that is currently not
> > defined anywhere.
> > >
> > >
> > >
> > > Cheers,
> > >
> > >
> > > Rick
> > >
> > >
> > >
> > > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Sipos, Brian J.
> > > Sent: 25 October 2021 16:05
> > > To: manet@ietf.org
> > > Cc: Taylor, Rick
> > > Subject: [manet] DLEP address semantics and in-the-wild examples
> > >
> > >
> > >
> > > All,
> > >
> > > I am in the process of investigating and implementing a DLEP router
> > component and trying to figure out which sets of data items are available for
> > which contexts (peer session vs. destinations) and how they must/may be
> > interpreted.
> > >
> > > Specifically, it’s not fully clear to me what the IPvX and MAC Address data
> > items [1] are allowed or required to represent for a peer (modem) or a
> > destination (other router). My assumption is that the IPvX are addresses on
> > which the router sends/receives traffic for forwarding on past the DLEP-
> > informed link and the IPvX Attached Subnets are those to-be-forwarded nets,
> > but the MAC Address is really an opaque identifier for the far-side
> > destination and may or may not be an address actually associated with or
> > seen by any of the routers.
> > >
> > >
> > >
> > > In the Link Identifier extension [2] it’s more explicitly stated that the MAC
> > Address is supposed to be an address on the far-side router, but I don’t see
> > that same kind of language in the original DLEP document [1]. And since
> > there is no signaling of the router MAC Address within the Session
> > Initialization, I assume that it is implied that the MAC Address of the peer
> > (router) used to establish the TCP connection is used for this purpose. For
> > multi-interface routers there may be no relation between the MAC Address
> > and it’s routed-traffic IPvX addresses (if the router is talking DLEP on a
> > different interface than the routed traffic), but if the MAC Address is
> > supposed to be just an opaque identifier then this doesn’t really matter.
> > >
> > >
> > >
> > > I’ve been able to dig into the OONF [3] implementation of DLEP to see how
> > it works, but this is just one implementation and not an authority of the
> > correct or possible semantics.
> > >
> > >
> > >
> > > Thanks for any clarification,
> > >
> > > Brian S.
> > >
> > >
> > >
> > > [1] https://www.rfc-editor.org/rfc/rfc8175.html
> > >
> > > [2] https://www.rfc-editor.org/rfc/rfc8703.html
> > >
> > > [3] https://github.com/OLSR/OONF
> > >
> > >
> > >
> > > _______________________________________________
> > > manet mailing list
> > > manet@ietf.org
> > > https://www.ietf.org/mailman/listinfo/manet