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

[Rick Taylor <[e-mail]>]

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.

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'.

Cheers,

Rick