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

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