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

From: "Morgan, Keith" <[email-masked]>
Date: Fri, 2 Jun 2017 07:58:18 +0000

Hi,

We have to provide the MAC address in the current protocol so we think it makes sense to use it if Link ID's are accepted.

I think all Link ID's should be the same length in a session, to keep it simple.

Regards
 
Keith

Keith Morgan
Director of Engineering
COMMUNICATION SYSTEMS / HARRIS DEFENCE LIMITED
Office: +44 (0)1256 383132 / Mobile: +44 (0)7917 012248
www.harris.com / [email-masked]
Jays Close, Viables Estate, Basingstoke, Hampshire, RG22 4BA, United Kingdom

Registered in England No. 2803090 Harris Defence Limited a UK Subsidiary of Harris Corporation, USA
CONFIDENTIALITY NOTICE:  This email and any attachments may contain material that is "Harris Proprietary Information" for the sole use of the intended recipient.  Any review, reliance, distribution, disclosure, or forwarding without expressed permission is strictly prohibited.  If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving in any manner.  Thank You.

-----Original Message-----
From: Rick Taylor [mailto:[email-masked]] 
Sent: 31 May 2017 15:57
To: Morgan, Keith (Non U.S.); [email-masked]
Subject: Re: [manet] Mail regarding draft-dlep-lid

Hi Keith,

Comments inline...

On Wed, 2017-05-31 at 13:30 +0000, Morgan, Keith wrote:
> Hello,
>  
> I have been reviewing the proposed Link Identifier Extension to DLEP 
> and have the following comments:

Thanks for the quick review!

>  
> The focus of the proposal appears to be to enable Routers to identify 
> where they cannot reach Destinations via the MAC address provided in 
> the Destination Up message. This would be the case with our Modem.
>  
> Our current implementation does use “sleight-of-hand” and will report 
> both the MAC address and IP address in the Destination Up message, 
> however the Destination is only reachable via its IP address.

This is one of the use-cases I was trying to fix, so I'm glad it helps.

>  
> The concept proposed appears sound; my immediate suggestion would be 
> to recommend a length of 6 bytes for the identifier, this would allow 
> the Modem to use the MAC address of the destination which should 
> ensure uniqueness while allowing the router to determine how to 
> address packets to the Destination based on the use of the Link 
> Identifier Data Item.

4 is only RECOMMENDED.  As a variable length field, Link Id's can be any length, so if you want to use 6, that's fine.  I only picked 4 as I imagined people had integer values and felt I had to recommend something to point people away from using SHA1 hashes or something huge (although they still can).

It's interesting that your Link Ids actually are MACs, but by using Link Ids not MAC Address Data Items you are being explicit that the MACs can't be used in frames.  I hadn't thought of this use-case, but I'm glad it works for you!

One thing that is probably missing is a requirement that all Link Ids should be the same length during a session.  Do people think this is a valid restriction?

Cheers,

Rick

---

From: Stan Ratliff <[email-masked]>
Date: Sun, 4 Jun 2017 12:15:21 -0400

Hi,

So, what about the notion of allocating a 64-bit quantity for the LID? That
way, a MAC address would fit, and by definition, all LIDs would be the same
length. We can specify the characteristics of the data in the LID
(right-justify, fill character 0x00, etc). Or, we could even use the first
octet of that 64-bit quantity as a set of bit flags to indicate what's in
the LID (e.g., is it a MAC address, or an integer, or...)

Regards,
Stan

On Fri, Jun 2, 2017 at 3:58 AM, Morgan, Keith <[email-masked]> wrote:

> Hi,
>
> We have to provide the MAC address in the current protocol so we think it
> makes sense to use it if Link ID's are accepted.
>
> CONFIDENTIALITY NOTICE:  This email and any attachments may contain
> material that is "Harris Proprietary Information" for the sole use of the
> intended recipient.  Any review, reliance, distribution, disclosure, or
> forwarding without expressed permission is strictly prohibited.  If you are
> not the intended recipient, please contact the sender and delete all copies
> without reading, printing, or saving in any manner.  Thank You.
>
>
> 4 is only RECOMMENDED.  As a variable length field, Link Id's can be any
> length, so if you want to use 6, that's fine.  I only picked 4 as I
> imagined people had integer values and felt I had to recommend something to
> point people away from using SHA1 hashes or something huge (although they
> still can).
>
> It's interesting that your Link Ids actually are MACs, but by using Link
> Ids not MAC Address Data Items you are being explicit that the MACs can't
> be used in frames.  I hadn't thought of this use-case, but I'm glad it
> works for you!
>
> One thing that is probably missing is a requirement that all Link Ids
> should be the same length during a session.  Do people think this is a
> valid restriction?
>
> Cheers,
>
> Rick
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Rick Taylor <[email-masked]>
Date: Mon, 5 Jun 2017 12:01:09 +0000

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

Rick

On Sun, 2017-06-04 at 12:15 -0400, Stan Ratliff wrote:
> Hi, 
> 
> So, what about the notion of allocating a 64-bit quantity for the
> LID? That way, a MAC address would fit, and by definition, all LIDs
> would be the same length. We can specify the characteristics of the
> data in the LID (right-justify, fill character 0x00, etc). Or, we
> could even use the first octet of that 64-bit quantity as a set of
> bit flags to indicate what's in the LID (e.g., is it a MAC address,
> or an integer, or...)
> 
> Regards,
> Stan
> 
> 
> > We have to provide the MAC address in the current protocol so we
> > think it makes sense to use it if Link ID's are accepted.
> > 
> > material that is "Harris Proprietary Information" for the sole use
> > of the intended recipient.  Any review, reliance, distribution,
> > disclosure, or forwarding without expressed permission is strictly
> > prohibited.  If you are not the intended recipient, please contact
> > the sender and delete all copies without reading, printing, or
> > saving in any manner.  Thank You.
> > 
> > 
> > 4 is only RECOMMENDED.  As a variable length field, Link Id's can
> > be any length, so if you want to use 6, that's fine.  I only picked
> > 4 as I imagined people had integer values and felt I had to
> > recommend something to point people away from using SHA1 hashes or
> > something huge (although they still can).
> > 
> > It's interesting that your Link Ids actually are MACs, but by using
> > Link Ids not MAC Address Data Items you are being explicit that the
> > MACs can't be used in frames.  I hadn't thought of this use-case,
> > but I'm glad it works for you!
> > 
> > One thing that is probably missing is a requirement that all Link
> > Ids should be the same length during a session.  Do people think
> > this is a valid restriction?
> > 
> > Cheers,
> > 
> > Rick

---

From: Stan Ratliff <[email-masked]>
Date: Mon, 5 Jun 2017 09:58:31 -0400

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

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)?

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.

Regards,
Stan

---

From: Rick Taylor <[email-masked]>
Date: Mon, 5 Jun 2017 15:32:49 +0000

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

---

From: Stan Ratliff <[email-masked]>
Date: Mon, 5 Jun 2017 12:13:51 -0400

On Mon, Jun 5, 2017 at 11:32 AM, Rick Taylor <[email-masked]

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

> 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

---

From: Rick Taylor <[email-masked]>
Date: Mon, 19 Jun 2017 14:20:42 +0000

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?

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.

Thoughts?

Rick

---

From: Stan Ratliff <[email-masked]>
Date: Mon, 19 Jun 2017 10:34:02 -0400

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

> 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... ;-)

Regards,
Stan

---

From: "Morgan, Keith" <[email-masked]>
Date: Mon, 19 Jun 2017 15:40:28 +0000

Hi,

I would imagine that modems will either report MACs or LIDs consistently depending on whether they are Layer 2 or 3. For us it would just be LIDs, but derived from the routers MAC.

Regards

Keith

Keith Morgan
Director of Engineering
COMMUNICATION SYSTEMS / HARRIS DEFENCE LIMITED
Office: +44 (0)1256 383132 / Mobile: +44 (0)7917 012248
www.harris.com<http://www.harris.com/> / [email-masked]<mailto:[email-masked]>
Jays Close, Viables Estate, Basingstoke, Hampshire, RG22 4BA, United Kingdom

<http://www.harris.com/>
<http://www.harris.com/>
<https://www.facebook.com/HarrisCorp><https://www.linkedin.com/company/harris-corporation><https://twitter.com/HarrisCorp><http://www.youtube.com/user/HarrisCorporation>

From: Stan Ratliff [mailto:[email-masked]]
Sent: 19 June 2017 15:34
To: Rick Taylor
Cc: Morgan, Keith (Non U.S.); [email-masked]
Subject: Re: [manet] DLEP LID lengths

On Mon, Jun 19, 2017 at 10:20 AM, Rick Taylor <[email-masked]<mailto:[email-masked]>> wrote:
All,

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

Yeah, I'm thinking that 1 modem supporting 2^48 links will cause insanity well before DLEP has a problem... ;-)

Regards,
Stan

Thoughts?

Rick

---

From: Rick Taylor <[email-masked]>
Date: Mon, 19 Jun 2017 15:53:14 +0000

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,
> > 
> 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).

> 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

---

From: Rick Taylor <[email-masked]>
Date: Mon, 19 Jun 2017 16:03:22 +0000

On Mon, 2017-06-19 at 15:40 +0000, Morgan, Keith wrote:
> Hi,
>  
> I would imagine that modems will either report MACs or LIDs
> consistently depending on whether they are Layer 2 or 3. For us it
> would just be LIDs, but derived from the routers MAC.

Hi Keith,

I can see that being true in the common case, but there is the lurking
detail of multicast logical destinations, which remain 'normal' MAC
addresses.  So I would expect your implementation to use them in some
way if you have multicast support.

Cheers,

Rick

---

From: Stan Ratliff <[email-masked]>
Date: Mon, 19 Jun 2017 12:06:01 -0400

> type) for the two namespaces seems little extra effort (again, ignoring

Yes, implementations could maintain 2 information bases. But especially
since the LID length will be the same as MAC length, it's an easy extension
to put both in the same tree.
As for how to keep them from clashing - both modems and routers have to
maintain a database (or set of in-memory structures) to be able to report
stats and keep track of what's going on. Since LIDs are "made up", while
MACs are "architected", it would seem pretty easy to:
1. Make a LID up
2. Check to see if that's already in the tree, and if so,
3. Make another one up...

I could even see a pretty straightforward implementation where LIDs are
assigned based on a monotonically increasing counter. I've never see a MAC
address of 00:00:00:00:00:01, 00:00:00:00:00:02, etc... however the
implementation decides to pack the LID into a 48-bit (or 64-bit) quantity.

Regards,
Stan

---

From: Stan Ratliff <[email-masked]>
Date: Mon, 19 Jun 2017 12:06:01 -0400

Regards,
Stan