Re: [manet] Mail regarding draft-dlep-lid

[Stan Ratliff <[e-mail]>]

On Mon, Jun 5, 2017 at 11:32 AM, Rick Taylor <[e-mail]
> wrote:

> Stan,
>
> Comments inline...
>
> On Mon, 2017-06-05 at 09:58 -0400, Stan Ratliff wrote:
> >
> >
> > On Mon, Jun 5, 2017 at 8:01 AM, Rick Taylor <rick@tropicalstormsoftwa
> > re.com> wrote:
> > > Stan,
> > >
> > > I think you're over-complicating this.  Given a Data Item is a TLV,
> > > then as long as the lengths are consistent on a per-session basis,
> > > I'd
> > > be happy letting the modem implementer decide on the length.  As
> > > far as
> > > the router is concerned, it really doesn't matter.  Zero-padding
> > > fixed
> > > length fields seems a bit unwieldy...
> > I think some more is required. The consistent length is important,
> > because I can see a router implementation wanting to use the LID as a
> > search key in, for example, an AVL tree. Fixed-length keys are
> > required there.
>
> Okay, I'll agree with you here - consistent LID lengths make sense.
>  And, yes, I can see your argument that knowing the size beforehand
> does help with hardcoded value fields in search data structures.
> Although a malloc equivalent shouldn't hurt too much - hopefully no-one
> is writing routers in ADA.
>
> > And let's consider a failing case - At Destination Up for the first
> > "link", the modem builds a TLV with length 4 and hands the router an
> > integer. At Destination Up for a second link, the modem builds a TLV
> > with length 6, and hands the router a MAC address...
>
> Again, I agree.  If a modem announces the first LID with length 4, then
> all further LIDs (for that session) MUST be length 4.  Note however
> that one can mix and match LIDs with MAC Address Data Items.
>
> >
> > What then? If you "kill" the Destination, then which one? Or, in
> > other words, which LID was "right" - the integer LID, or the MAC-
> > based LID? Or, should the entire Peer Session be brought down (which,
> > as we've already agreed, is an awfully big hammer)?
>
> I think we are agreeing still: mismatched LIDs = Invalid Data status
> code and Terminate.
>
> >
> > My thinking was (and still is) - if you're going to call for
> > "consistent" LIDs (length-wise), then you either have to explicitly
> > state what that LID size is (and possibly be prepared to negotiate
> > the LID size), or allocate sufficient "real-estate" to cover all the
> > possibilities.
>
> I'll try a counter-argument:  In core DLEP, a MAC address can be 6 or 8
> octets - you don't know which until you get one, and I'm not sure if we
> specify if you are allowed to mix and match.  I suggest that LIDs
> should follow the same precedent.
>

It's not exactly the same, though. Here's the relevant text:

13.7.  MAC Address

   The MAC Address Data Item contains the address of the destination on
   the remote node.

   DLEP can support MAC addresses in either EUI-48 or EUI-64 format
   ("EUI" stands for "Extended Unique Identifier"), with the restriction
   that all MAC addresses for a given DLEP session MUST be in the same
   format and MUST be consistent with the MAC address format of the
   connected modem (e.g., if the modem is connected to the router with
   an EUI-48 MAC, all destination addresses via that modem MUST be
   expressed in EUI-48 format).

   Examples of a virtual destination would be (1) a multicast MAC
   address or (2) the broadcast MAC address (FF:FF:FF:FF:FF:FF).


The difference is that the type of MAC is enforced by the connection type
of the modem - so the router implementation *does* have a-priori knowledge
of the MAC length.



> I'm not immediately dismissing the suggestion of a "My LID length is X"
> Data Item for use in Session Init, but it could be seen as 'clunky'.
>
> The only other way I can see is to lift the restriction on LID
consistency, other than "they cannot clash". Then, you have to define how
"clashing" is determined (for interoperability). For example, "LIDs of
different length are to be compared assuming right-justify, fill character
0x00 to achieve equal length). Or something like that.

Regards,
Stan