Subject: Re: [manet] DLEP Vendor Extensions

From: "Viberg, Neil" <[email-masked]>
Date: Wed, 17 Dec 2014 16:42:16 -0700

Stan,

I think the idea for adding multiple MAC addresses is either a case of
creeping requirements or premature optimization or both.

The acronym DLEP represents a "Dynamic Link Exchange Protocol". It's
importance, at least to me, is about the link not about the destinations
that the link leads to. I don't think that adding complexity to turn
DLEP into a neighbour discovery mechanism for everything attached to all
of the LANs connected to all of the modems is a good idea.

It may make someone's system engineering job simpler or keep the total
cost of a system down but it won't make for a simple useful protocol. I
would apply the KISS principle at this point.

My 2 bits.

Neil

-----Original Message-----
>Date: Wed, 17 Dec 2014 09:45:34 -0500
>From: Stan Ratliff <[email-masked]>
>To: Henning Rogge <[email-masked]>
>Cc: manet IETF <[email-masked]>
>Subject: Re: [manet] DLEP Vendor Extensions
>Message-ID:
>
<CALtoyoksEpe6ag5HDarmWTqhBCBJ3QNGioUadpfDQn=[email-masked]>
>Content-Type: text/plain; charset="utf-8"
>
>Henning,
>
>I'll give it a go. Let's assume a MANET deployment where some number
("N") of vehicles are deployed. Each of those vehicles has some >number
of laptops, a VoIP phone (or two), a video camera, and some other
sensors
>- for a total of 12 devices. This setup with the radio and 12 devices
is my "standard kit" - I put that standard kit into almost every vehicle
I >have in my fleet. Additionally, the deployment has a small number
(let's say 3) of "VIP Vehicles" - those vehicles have multiple radios,
>satcom for reach-back, and most importantly, a router.
>
>So now, I take 100 vehicles with the "standard kit", plus my 3 " VIP
Vehicles", and deploy them. I contend that with regard to the vehicles
>having the "standard kit", DLEP doesn't have an effect unless each and
every device is declared as a DLEP "Destination" (via presentation >of a
'Destination Up' order). You see, we've been concentrating on
deployments where every radio has a *router* attached to it, and >then
all devices are attached "behind" the router. So from a DLEP
perspective, there's just 1 DLEP "destination" per radio (that
>'destination' being the router). I believe that works quite well. But
in the case I've described, where a lot of the radios don't have a
router installed, DLEP doesn't scale well - in my little example, the
psuedo-Ethernet segment created by the radios will have 1,200+ MAC
addresses on it (12 devices per vehicle, 100 vehicles - the classic
"M*N" scalability problem). Each of those MAC addresses should be
identified by a DLEP "Destination Up"; and they would also need their
own "Destination Update" orders if/when the RF characteristics change -
that gets unwieldy pretty fast.

So, that's what we mean by the "multiple destinations" verbiage, and
we've been discussing some ideas to reduce the DLEP overhead in those
deployment scenarios. It's not really new functionality; more of things
like:
- Can a "Destination Up" order contain more than 1 MAC address TLV? (I
believe the answer to that is 'yes')
- If a "Destination Up" order contains more than 1 Mac Address TLV, then
how are the associated IPv4 Address and IPv6 address TLVs processed? (I
believe the answer to that is "positionally" e.g., the DLEP buffer looks
something like MAC TLV 1/IPv4 Addr TLV 1/MAC TLV 2/IPv4 Addr TLV 2/IPv6
Addr TLV 2; but the document is not clear on that, and needs to be
explicit in that area.).
- Is there a reasonably straightforward way in DLEP to effectively say
"The data rate *to the remote radio* is <blah>", allowing a single
"Destination Update" order to convey metrics for multiple MAC addresses
across the RF link? (I believe the answer to that question is "Not in
DLEP-07, but I think there is a straightforward "tweak" to the protocol
to let us do
that.")

Now, the "is there a way to reference the remote radio itself, instead
of all of its connected devices" issue also led us to reconsider the
notion that has been described as "Layer 3 DLEP" - that being, radio
devices having sufficient Layer 3 smarts to be able to receive a frame,
and re-write the Layer 2 header for subsequent egress, based on an IP
address lookup. Personally, I believe that once you've created a way to
reference just the remote modem, doing this type of "gateway operation"
*IN LIEU OF"
the "transparent bridge mode" we all know and love (hate?) isn't a large
step at all...

Hopefully, that helps make things clearer. I'm *really* hoping I haven't
muddied the waters... ;-)

Regards,
Stan

---

From: Rick Taylor <[email-masked]>
Date: Thu, 18 Dec 2014 16:46:34 +0000

This is a tentative +1 from me. I need to think it through clearly but it seems like a nice solution.

Rick

Sent from my HTC

----- Reply message -----
From: "John Dowdell" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [manet] DLEP Vendor Extensions
Date: Thu, Dec 18, 2014 16:32

Very interesting compromise. Hopefully we will see vendors taking advantage of the experimental messages in this context.

Any modem vendors care to comment?

John

On 18/12/14 16:03, Stan Ratliff wrote:
I think this is a good compromise - it even closes off the concern I had about allowing Vendor Extensions at the Peer level.

+1 from me. ;-)

Regards,
Stan

On Thu, Dec 18, 2014 at 10:46 AM, Henning Rogge <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

after having some discussion with Stan, I have a compromise that might
replace the Vendor-TLV thing with a simpler concept.

I suggest we replace the complicated "vendor-extension" TLV with a
single "vendor-id" TLV.

The vendor-ID TLV can be (optional) put into the Session negotiation
and gives you the "context" of the experimental range for both
messages and TLVs in all later messages.

This means whenever you plan to use a TLV or message with an ID from
the "experimental range", you put in an ID into the Session
negotiation to tell the other side who you are, so it can check if it
can understand you experimental IDs.

This makes vendor extensions possible, but it is still limited (you
cannot mix the extensions of two vendors in the same session) and will
hopefully push vendors to the IETF to get IDs from the standard range.

What do you think?

Henning Rogge

On Tue, Dec 16, 2014 at 4:42 PM, Rick Taylor
<[email-masked]<mailto:[email-masked]>> wrote:
> All,
>
> In response to the silence concerning Vendor Extensions in DLEP, and
> after much deliberation amongst the authors, we have decided to drop the
> concept from the protocol.
>
> Regards,
>
> Rick Taylor
>
> _______________________________________________
> manet mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet