Re: [manet] DLEP LID lengths

[Rick Taylor <[e-mail]>]

Comments inline...

On Mon, 2017-06-19 at 10:34 -0400, Stan Ratliff wrote:
> 
> 
> On Mon, Jun 19, 2017 at 10:20 AM, Rick Taylor <rick@tropicalstormsoft
> ware.com> wrote:
> > All,
> > 
> > I've been mulling this over.
> > 
> > How about the LID length MUST be the same as the MAC, so it's up to
> > the
> > advertiser of the LID to bit pack?
> Does that mean that if a modem is using EUI-64 MACs, then the LIDs
> are 64 bits as well? I'm OK with that, I just think we need to state
> it. 

Yes, that's the idea.  A draft-01 will be forthcoming...


> Also, I think there should be a sentence about LIDs not being
> duplicated (and, in fact, that a LID MUST NOT duplicate an existing
> MAC, or vice-versa). I'd think that a duplicate LID on Destination Up
> would be rejected, and the Destination would not be seen as Up
> (Destination-level error, NOT a peer session level error).

I'm not sure about this.  I can see why it seems helpful:
an implementation can keep one data structure for all destinations,
physical/logical/LID.  But, I can't see a simple way for a dual-mode
modem implementation to ensure no clashes.

Part of the reasons behind LIDs was to produce a separate namespace.
Forcing and implementation to maintain 2 datastructures (of the same
type) for the two namespaces seems little extra effort (again, ignoring
ADA implementations).

>  
> > 
> > This seems to work with existing use cases, and avoids the need for
> > LID
> > length negotiation.  The only down-side I can see is that 2^48 LIDs
> > is
> > a common maximum, but that seems plenty currently.
> Yeah, I'm thinking that 1 modem supporting 2^48 links will cause
> insanity well before DLEP has a problem... ;-)

As was pointed out to me: 640Kbytes has traditionally been plenty, 2^48
looks like carelessness! :-)

Cheers,

Rick