Subject: [manet] DLEP Vendor Extensions

From: Rick Taylor <[email-masked]>
Date: Tue, 16 Dec 2014 15:42:56 +0000

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

---

From: Justin Dean <[email-masked]>
Date: Tue, 16 Dec 2014 11:32:53 -0500

This was the biggest point of contention (among the authors) holding DLEP
back with the only other thing to be updated (mentioned in your
presentation in HI) being text and readability.  Are their any other (new)
large issues among the author team at this time?  The proposed schedule of
a new draft in January with an eye towards last call in March looks like
it's on track.  I'll be reviewing the previous document now in anticipation
of minor changes (exception of removal of vendor extensions) and would
encourage all other wg members to do the same.

Justin

On Tue, Dec 16, 2014 at 10:42 AM, Rick Taylor <
[email-masked]> wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Rick Taylor <[email-masked]>
Date: Tue, 16 Dec 2014 16:52:27 +0000

Justin, All,

As a heads up, there is some new functionality that MAY be added to a 
draft-08: Multiple devices at a destination.

The authors understand that this addition must not impact the deadlines 
and we will be making a pragmatic evaluation of how much impact this 
will have on the workload before we commit to including it.

In other words, we have some interesting ideas, but we are aware that 
DLEP needs to get done.

Any feedback on the current draft is gratefully received (as ever) so we 
can get some handle on how much text fiddling we need to do.  As always, 
we are possibly too close to the subject to spot all under-described 
sections.

Cheers,

Rick

On 16/12/14 16:32, Justin Dean wrote:
> This was the biggest point of contention (among the authors) holding
> DLEP back with the only other thing to be updated (mentioned in your
> presentation in HI) being text and readability.  Are their any other
> (new) large issues among the author team at this time?  The proposed
> schedule of a new draft in January with an eye towards last call in
> March looks like it's on track.  I'll be reviewing the previous document
> now in anticipation of minor changes (exception of removal of vendor
> extensions) and would encourage all other wg members to do the same.
>
> Justin
>
> On Tue, Dec 16, 2014 at 10:42 AM, Rick Taylor
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     All,
>
>     [email-masked] <mailto:[email-masked]>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 16 Dec 2014 18:27:50 +0100

> draft-08: Multiple devices at a destination.

You mean (as an example) radios with multiple interfaces?

We have thought about this at our institute too but our best idea is
to address each radio "line" over a pre-configured VLAN tag. Similar
to the usecase where you want to connect multiple physical radios over
a VLAN-capable switch to a single ethernet port of the router.

Henning

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 16 Dec 2014 14:11:08 -0800

Hi All,

I did not know that the manet group agreed on new functions for DLEP. I
hope that WG management follow up with authors that they don't add
functions until we know them and agree on the list. First we had the DT
discussions and now no clear directions. Why don't we discuss in our WG
list about authors' ideas or did we decide not to discuss draft ideas
but just reviewing?

> draft-08: Multiple devices at a destination.

Why not we discuss together before updates. I don't think authors are
authorised to update any new functions. I object any such authority above
WG controls subject to IETF procedures.

> In other words, we have some interesting ideas, but we are aware that

Please specify and discuss those ideas on the list. I am interested more in
discussing them than in updating draft and including things before
agreements.

> we are possibly too close to the subject to spot all under-described

This message is my first feedback. Secondly, I remember we agreed for a
minimal DLEP and any new functions for future update drafts. Thirdly, I
will review the draft shortly.

Regards

AB

> > (new) large issues among the author team at this time?

The authors don't control the draft, but they are editors. The WG must know
before big updates (i.e. New ideas).

The proposed
> > March looks like it's on track.

Do You mean a new update -00 draft or you mean a new draft version -08. I
need updates to be discussed before submitting them. In past DT were
updating without WG agreement and now maybe a smaller group.

  I'll be reviewing the previous document
> > <[email-masked] <javascript:;> <mailto:
> [email-masked] <javascript:;>>>
> > wrote:
> >
> >     All,
> >
> >     [email-masked] <javascript:;> <mailto:[email-masked] <javascript:;>>
> [email-masked] <javascript:;>

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 16 Dec 2014 21:20:22 -0500

Henning,

The co-authors have been having some discussions with regard to deployments
that have multiple end-stations (for example, laptops, cameras, VoIP
phones, sensors, etc), and not necessarily a router. In this type of
deployment, some (though not all) radios may have a router for access
"upstream" into a network (like, for example, a reach-back to some "home
office", perhaps via satellite), but not necessarily all of the radios.

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Wed, 17 Dec 2014 07:58:46 +0100

Hi Stan,

maybe I missunderstood Rick and you can explain the "multiple
destinations" a little bit better.

I worry that the "bridging" on the radio will become much more
complicated if there is more than a point-2-point connection over the
ethernet to one other device (router).

Henning

On Wed, Dec 17, 2014 at 3:20 AM, Stan Ratliff <[email-masked]> wrote:
> that have multiple end-stations (for example, laptops, cameras, VoIP phones,
> sensors, etc), and not necessarily a router. In this type of deployment,
> some (though not all) radios may have a router for access "upstream" into a
> network (like, for example, a reach-back to some "home office", perhaps via
> satellite), but not necessarily all of the radios.
>
> Regards,
> Stan
>

---

From: Teco Boot <[email-masked]>
Date: Wed, 17 Dec 2014 10:02:15 +0100

> Op 17 dec. 2014, om 07:58 heeft Henning Rogge <[email-masked]> het volgende geschreven:
> 
> Hi Stan,
> 

This is an implementation detail. I have radio gear with multiple ethernet interfaces, sharing same WAN interface.
Using an ethernet hub or switch has same effect.

Teco

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 17 Dec 2014 09:45:34 -0500

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

On Wed, Dec 17, 2014 at 1:58 AM, Henning Rogge <[email-masked]> wrote:
> phones,

---

From: Teco Boot <[email-masked]>
Date: Wed, 17 Dec 2014 18:04:14 +0100

I’m not worried at al on DLEP overhead. It is local traffic and mostly incremental updates.

How the radio’s handle 1200+ MAC addresses: interesting topic, but not related to DLEP.

Teco

> Op 17 dec. 2014, om 15:45 heeft Stan Ratliff <[email-masked]> het volgende geschreven:
> 
> 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: Henning Rogge <[email-masked]>
Date: Wed, 17 Dec 2014 18:27:23 +0100

> I'll give it a go. Let's assume a MANET deployment where some number ("N")
...
> gets unwieldy pretty fast.

So we keep the DLEP assumption that the DLEP "radio" still forward
everything (not DLEP/internal service) between radio interface and
ethernet. Okay...

> believe the answer to that is 'yes')

I think Rick was talking about an "radio neighbor identifier" to have
an abstraction between mac address and radio neighbor identity.

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

I don't like the "positional" thing... at the moment we don't have
TLVs depending on each other (and the order of TLVs), but this could
complicate things.
If its a "one-to-one" mapping, we could introduce a combined "Mac-IP"
TLV which contains both mac and TLV... thats easier to parse (but
still ugly as a concept).

As Teco said overhead is not that important for DLEP... its used on a
fast local ethernet link.

And if you always have 10 devices in your cars behind your radio,
maybe one of them should just work as an IP router.

Henning Rogge

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 17 Dec 2014 12:30:02 -0500

I respectfully disagree with you on both points.

"I’m not worried at al on DLEP overhead. It is local traffic and mostly
incremental updates."
 - As strictly defined, that is true. However, the presentation of (for
example) Destination Update for metrics to some remote destination implies
that *some sort* of OTA signaling has occurred to obtain those metrics in
the first place. Especially in multi-hop mesh networks.

"How the radio’s handle 1200+ MAC addresses: interesting topic, but not
related to DLEP."
- Not if you are a radio vendor, are looking at supporting DLEP, and are
concerned about winging that much state information across your precious RF
network, in order to present the "Destination Up" and "Destination Update"
orders to some small number of routers.

Regards,
Stan

On Wed, Dec 17, 2014 at 12:04 PM, Teco Boot <[email-masked]> wrote:
> > 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
> > 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:
> > - 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

---

From: Henning Rogge <[email-masked]>
Date: Wed, 17 Dec 2014 18:37:45 +0100

On Wed, Dec 17, 2014 at 6:30 PM, Stan Ratliff <[email-masked]> wrote:
> the first place.

Not necessarily... it could be just local measurement or settings,
e.g. link speed to neighbor or signal strength.

Only the optional "IP address" thing will definitely require a
"magical" OTA component. And this OTA component is not part of DLEP.

> orders to some small number of routers.

Sorry, that doesn't make sense Stan.

the question "how does radio X knows where to send mac Y over the air"
is not relevant for DLEP.

DLEP is just for transmitting the local knowledge of the radio to the
attached router (and some control in the opposite direction).

The radios can do all kinds  of tricks between each other to save
airtime... the question is do we need this kind of thing for the local
connection between radio and router.

But...

I think this "bundle X mac addresses together into a neighbor" might
be relevant for queuing. It doesn't make much sense to allocate
multiple queues for priorization and QoS for multiple mac addresses
behind a single OTA link. So the knowledge "these 5 mac addresses are
the same radio link" could still be useful.

Henning

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 17 Dec 2014 12:39:05 -0500

"I don't like the "positional" thing... at the moment we don't have TLVs
depending on each other (and the order of TLVs), but this could complicate
things."

Then we need to come to closure and consensus on this item, and quickly.
IMO, this needs to be better documented than it is in DLEP-07, because, as
I mentioned, an implementation *can* supply multiple MAC address TLVs. In
that case, TLVs like the IPv4/IPv6 address TLVs MUST be correlated to the
correct MAC address TLV. If you're not happy with positional correlation,
do you have an alternative? I have concerns about the "combined MAC-IP" TLV
you mention, as it does not comprehend the notion of running dual-stack
(IPv4 and IPv6) implementations, nor does it comprehend that a device can
have multiple IP addresses.

As for Teco's response - presentation of (for example) "Destination Update"
pretty much implies that some implementation-specific OTA signaling has
indeed occurred. Otherwise, how would my local radio have the metrics in
the first place, *especially* in a multi-hop mesh implentation? Same thing
goes with number of directly-connected MAC addresses - some OTA signalling
is implied.

One way or another, we as a WG need to address these issues - either fix
them (which I think we can), or state they are out of scope (which, I
believe, will hamper radio adoption of the standard).

Regards,
Stan

On Wed, Dec 17, 2014 at 12:27 PM, Henning Rogge <[email-masked]> wrote:
> ("N")
> we've
> how

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 17 Dec 2014 12:47:18 -0500

I think we're going to have to combine the two active threads into one...
that said, I'll address a couple of your comments here.

"Not necessarily... it could be just local measurement or settings, e.g.
link speed to neighbor or signal strength."
Yes, and in your single-RF-hop, 802.11 implementation, that probably works
well. But in a multi-hop mesh networking scenario, some OTA signaling will
be required.

"Sorry, that doesn't make sense Stan.

the question "how does radio X knows where to send mac Y over the air"
is not relevant for DLEP."

Yes, that question is irrelevant. It's also NOT the question I'm
addressing. In my new job, I now have concerns about implementing DLEP,
based on the amount of state data that would need to be flung across the RF
network in those types of deployments. It's not that "radio X knows *where*
to send mac Y...", it's that radio X (DLEP-wise) has to know that MAC Y
*exists*, *and* know metrics to Y. And in a 1,200 MAC deployment, that's a
lot of state.

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Wed, 17 Dec 2014 18:56:48 +0100

**combining threads/answers**

On Wed, Dec 17, 2014 at 6:39 PM, Stan Ratliff <[email-masked]> wrote:
> IMO, this needs to be better documented than it is in DLEP-07, because, as I
> mentioned, an implementation *can* supply multiple MAC address TLVs. In that
> case, TLVs like the IPv4/IPv6 address TLVs MUST be correlated to the correct
> MAC address TLV. If you're not happy with positional correlation, do you
> have an alternative?

We could move the "announce IP address for MAC" into a message of its own.

If you want to attach IPs (one or many) to a MAC, you send a "Announce
IP address" message which contains a single MAC with a list of IPs. A
new message always overwrites the list of IPs for the single MAC it
referrs to, so we can use the same message for adding, changing or
removing IPs.

This works both with an "link id" concept or without it.

> well. But in a multi-hop mesh networking scenario, some OTA signaling will

So you are talking about the "layer-2 mesh" radio with DLEP.

> Yes, that question is irrelevant. It's also NOT the question I'm addressing.
> In my new job, I now have concerns about implementing DLEP, based on the
> amount of state data that would need to be flung across the RF network in
> those types of deployments. It's not that "radio X knows *where* to send mac
> Y...", it's that radio X (DLEP-wise) has to know that MAC Y *exists*, *and*
> know metrics to Y. And in a 1,200 MAC deployment, that's a lot of state.

No, it does not.

Okay, yes it needs to know, but not necessarily in an inefficient way.

The radio could do the "mac address" and the "link id/metric" thing
completely separate to be very efficient... a good example would be a
slow radio that just use a 1-byte "radio id" on the air and use a
small layer-2 protocol to announce the local mac address(es).

But these optimizations for the radio link are completely orthogonal
to the DLEP communication on the local ethernet.

You want a very efficient protocol OTA to separate mac address
gathering and link metrics/state calculation? Fine, do so... but why
do we need to change DLEP for this?

as I said above, the "link vs. multiple mac addresses" concept in DLEP
might be relevant for flow control... but I don't see it necessary as
optimization. DLEP is not transmitted over the air.

Henning Rogge

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 17 Dec 2014 13:20:50 -0500

> This works both with an "link id" concept or without it.

Yes, that might work. But I would contend that adding a statement into the
Destination Up/Destination Update/Destination Down descriptions saying
"Implementations MUST insert one AND ONLY one MAC Address TLV into this
order" accomplishes the same thing. I mentioned that in the email between
co-authors and got a negative response on it. No need to invent additional
protocol unless we need it.

> addressing.

:-)

> to the DLEP communication on the local ethernet.

Not exactly. Consider for a moment that we introduce the concept of a
"Unique Link ID", and mandate that it be carried on all destination
messages (e.g. Destination Up/Destination Update/Destination Down).
Further, we mandate that this "Unique Link ID" be a searchable key on all
DLEP destinations. Effectively, the "Unique Link ID" maps 1-to-1 to a
remote modem.

Then, we can allow implementations to issue Destination Update, with *just*
the "Unique Link ID" and metrics specified. Those metrics would be applied
to *all* destinations (e.g. MAC addresses) with the Unique Link ID. Same
thing with "Destination Down" - if the Destination Down is received with
*just* the Unique Link ID specified, then *all* destinations with that
Unique Link ID are considered down.

Note that this does NOT preclude an implementation from issueing
Destination Up/Destination Update/Destination Down with *both* the Unique
Link ID *and* a MAC Address TLV specified. In that case the receiver would
process it as today - for example, a Destination Update with both the
Unique Link ID and a MAC would apply the metrics ONLY to the specified
MAC.  Same thing with Destinatio Down - ONLY the specified MAC address
would be brought down.

This (relatively easy, IMO) extension removes most of the heartburn I've
got with the deployment scenario I initially documented, since it allows
metrics to be produced on a "REMOTE modem-wide" basis. Different than
metrics in the Peer Update, which apply at a local (all sessions through
*my* radio) level.

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Wed, 17 Dec 2014 19:41:25 +0100

> protocol unless we need it.

Using the position could turn quite funny if you have both MACs with a
single IP, MACs with multiple IPs and MACs without IPs.

Yes, you can solve it, but suddenly you have to sort your MACs based
on the IPs they have.

> "Unique Link ID", and mandate that it be carried on all destination messages
> (e.g. Destination Up/Destination Update/Destination Down). Further, we
> mandate that this "Unique Link ID" be a searchable key on all DLEP
> destinations. Effectively, the "Unique Link ID" maps 1-to-1 to a remote
> modem.
>
> Note that this does NOT preclude an implementation from issueing Destination
> Up/Destination Update/Destination Down with *both* the Unique Link ID *and*
> a MAC Address TLV specified. In that case the receiver would process it as
> today - for example, a Destination Update with both the Unique Link ID and a
> MAC would apply the metrics ONLY to the specified MAC.  Same thing with
> Destinatio Down - ONLY the specified MAC address would be brought down.

Do you really want a third hierarchy level for metrics?

I see the use for "local radio" metrics... and the use for "remote
radio" metrics...

can you give a good example for "single mac behind a remote radio" metric?

> This (relatively easy, IMO) extension removes most of the heartburn I've got
> with the deployment scenario I initially documented, since it allows metrics
> to be produced on a "REMOTE modem-wide" basis. Different than metrics in the
> Peer Update, which apply at a local (all sessions through *my* radio) level.

I see that this would be an additional feature for DLEP... but it will
not save a single byte OTA... because the protocol is not used on the
air interface.

I still think the extension could be useful because it gives you a
better knowledge about the radio topology.

So I would be "+1" for adding a link-id to the Destination messages...
but not because of some OTA efficiency concerns.

Henning

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 17 Dec 2014 14:28:07 -0500

> Yes, you can solve it, but suddenly you have to sort your MACs based

I'm a bit lost with this response. Seems to me that there are a couple of
options on the table:
1. Implement an "Announce IP addresses for MAC" order, or
2. Limit Destination Up/Destination Update/Destination Down to AT MOST 1
MAC address TLV (the 0 MAC Address TLV would be the "Unique Link ID" case
discussed below.
Any other options? And which one is preferable (I vote for #2)??

> messages
> Destination

Not really, but you "get it for free"...

> can you give a good example for "single mac behind a remote radio" metric?

A "good" example? That might be subjective... ;-)  That said, I could see
vendors implementing different metrics as a way of influencing
flow-control. In order to get the flow control characteristics I want on
the link, I'll tell you Device "A" has a 30Mbps link, while Device "B" only
has 6Mbps. I don't mean to imply this is a "good" example, just one that
people might employ.

> got

Excuse me whilst I take your "+1" and run for the nearest exit.... ;-) ;-)
;-) ;-)

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Wed, 17 Dec 2014 20:43:05 +0100

On Wed, Dec 17, 2014 at 8:28 PM, Stan Ratliff <[email-masked]> wrote:
> I'm a bit lost with this response.

"Too much mails in the evening" error...

yes, I thought we were still talking about the "multiple mac with each
a single IP TLV" idea.

Sorry.

> Seems to me that there are a couple of
> options on the table:
> 2. Limit Destination Up/Destination Update/Destination Down to AT MOST 1 MAC
> address TLV (the 0 MAC Address TLV would be the "Unique Link ID" case
> discussed below.

I am just curious, if "Destination Up" without MAC TLV is the "unique
Link ID" case, how does the radio the MACs behind the link?

> Not really, but you "get it for free"...

As long as it is okay to ignore it... because the data structures that
can store this "3-level hierarchy" data are not free.

> Excuse me whilst I take your "+1" and run for the nearest exit.... ;-) ;-)

LOL... ;)

Henning Rogge

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 17 Dec 2014 14:51:20 -0500

On Wed, Dec 17, 2014 at 2:43 PM, Henning Rogge <[email-masked]> wrote:
> MAC

Uhh, you got me there. ;-)  I revise the statement:
Option 2:
 - Destination Up MUST contain 1 AND ONLY 1 MAC Address TLV
 - Destination Update/Destination Down MUST contain AT MOST 1 MAC Address
TLV.

That said, we still need to come to consensus on option 1 or the amended 2
above.

> can store this "3-level hierarchy" data are not free.

At least in the implementation I'm familiar with, metrics are already
stored on a "per-MAC basis". So, the "REMOTE modem-wide" case involves
searching through your destinations, updating everyone with the matching
key. No extra data structures, but some extra CPU cycles looping through
your destinations.

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Wed, 17 Dec 2014 21:08:23 +0100

>  - Destination Update/Destination Down MUST contain AT MOST 1 MAC Address

This is still strange.

If "Destination Up" can only contain ONE MAC, the link-id is
useless... which means Destination Update/Down should also ALWAYS
contain a MAC address.

Link-id makes only sense if you allow multiple MAC addresses.
Otherwise we can use the MAC address as the link-id.

> At least in the implementation I'm familiar with, metrics are already stored
> on a "per-MAC basis". So, the "REMOTE modem-wide" case involves searching
> through your destinations, updating everyone with the matching key. No extra
> data structures, but some extra CPU cycles looping through your
> destinations.

I keep my data in a two level AVL-trees to make it easy to lookup data fast.

Hmm... now that you mention it, I changed the data structure some time
ago to a three level AVL tree.

first level: local radios (with metrics and defaults for 2nd level metrics)
second level: remote radios (with metrics)
3rd level: proxied mac addresses behind remote radios (currently no metrics)

Henning

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 17 Dec 2014 15:24:56 -0500

> useless... which means Destination Update/Down should also ALWAYS

What about this use case:

time 0   -  Destination Up, Link ID "foo", MAC Address "1"
time 1   -  Destination Up, Link ID "foo", MAC Address "2"
time 2   -  Destination Up, Link ID "foo", MAC Address "3"
.
.
.
time "n" - Destination Update, Link ID "foo", CDRT=6mbps, CDRR=6mbps
.
.
.
time "n+something"  -  Destination Update, Link ID "foo", CDRT=30mbps,
CDRR=30mbps
.
.
.
time "z"  -  Destination Down, Link ID "foo", MAC Address "2"    (Device
'2' powered off)
.
.
.
time "z+something"  -  Destination Down, Link ID "foo"     (remote modem
died or is dying)

Regards,
Stan

> stored

---

From: Henning Rogge <[email-masked]>
Date: Wed, 17 Dec 2014 21:27:39 +0100

> time "z"  -  Destination Down, Link ID "foo", MAC Address "2"    (Device '2'
> powered off)
> .
> .
> .

Okay, this explanation makes sense.

Henning

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 17 Dec 2014 12:59:32 -0800

illustration, abstract to concrete.

On Wed, 2014-12-17 at 09:45 -0500, Stan Ratliff wrote:
> ("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.

An excellent use case would be an instrumented ambulance.  
     The primary purpose is to relay casualty status so the EMT in the
ambulance and get a look over her shoulder by the ER doc.  Secondary
purpose is vehicle navigation through traffic -- look over the driver's
shoulder by the 911 dispatcher ... you can think of several variants.
     And coincidentally, '12' is a number in the ballpark.  Several
vital signs sensors attached to a casualty, a VOIP rig for the EMT to
talk to the ER doc, a VOIP rig for the driver to talk with dispatching,
a radionav receiver to grab position (for the dispatcher)... the scale
is about right.  
> Vehicles", and deploy them. 

I'll leave the impact on DLEP to others here far more capable than me:

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

There are lots of very good reasons for multiple WAN interfaces.  High
availability is the trumping one -- get that right and a lot of other
reasons become lesser included offenses.   For example, you might be
able to use 4G cellphone in an urban area, along with opportunistic
WiFi, but might need an 802.16 rig working in VHF for suburban areas and
a satellite shot in a more rural one.  And you might plug router into
wired internet when the ambulance is in the garage.  

> deployment scenarios. It's not really new functionality; more of
> things like:  
> - 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.).
> "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.")  

The use case observation here is that the more you need the instrumented
ambulance, the more expensive and bandwidth-limited the radio-WAN
channel is likely to be.  
> 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...
>

---

From: Henning Rogge <[email-masked]>
Date: Thu, 18 Dec 2014 16:46:09 +0100

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

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 18 Dec 2014 11:03:30 -0500

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

---

From: John Dowdell <[email-masked]>
Date: Thu, 18 Dec 2014 16:26:05 +0000

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,
>
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > All,
>     >

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 18 Dec 2014 17:12:31 +0000

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

Format (of the value)?

I see two (and a half) possibilities:
- Free text, which makes it unlikely that there will be a clash, but is inefficient if you are counting bytes. (I'm not suggesting you are or aren't, just pointing out the interaction.)
- Setting up an IANA-managed registry for vendors. How many bytes to allocate? If a fixed number then at least two.
- (Option 2b) Alternatively a variable length integer (as in RFC something or other) that can be one while still less than 128 vendors. But I'm not sure how that manages an experimental range.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Henning Rogge <[email-masked]>
Date: Thu, 18 Dec 2014 18:18:13 +0100

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

I would suggest 8 bytes (octets).

the first six bytes can be a MAC address (or the beginning of a MAC
block owned by the company followed by 000000) to give you an unique
worldwide ID, the last two bytes can be used without the same
organization to signal different experiments.

If you write an implementation that understands a certain Vendors
experimental extension, you should check the full content of the
"vendor-id" TLV before activating the extension.

Each extension can use all TLV (or message) IDs that have been
assigned as experimental by IANA.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Thu, 18 Dec 2014 19:00:35 +0100

Clarification questions: 
Does this proposal block a session where products from Vendor_A and Vendor_B exchange publicly available and implemented vendor extension?
Is it allowed that a product from Vendor_A uses Vendor_C extensions?

Teco

> Op 18 dec. 2014, om 16:46 heeft Henning Rogge <[email-masked]> het volgende geschreven:
> 
> Hi,
>

---

From: Henning Rogge <[email-masked]>
Date: Thu, 18 Dec 2014 19:05:12 +0100

I think both sides can announce their Vendor-id...

and then both sides can decide to
a) process the incoming extension TLVs
b) ignore the extension TLVs and fall back to standard DLEP
c) drop the session

My suggestion is mostly about testing an extension and maybe pushing
it into the first generation of your products. If you think this
extension will be interesting to the IETF, you should come here and
write a draft about it.

You just announce a "vendor-id" which matches how you use the
experimental id range... if you use them as a different vendor
defined, you should use their vendor-id.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Thu, 18 Dec 2014 19:25:19 +0100

I’m concerned on c)(drop session). Extensions are optional and b) (ignore) is the logical choice.
 
However, when within a session, some form of extension handshake took place, invalid messages could be detected (violations on vendor specified sub-protocol) and yes, a sessions could be dropped. This doesn’t need to be specified in the core spec. I don’t like such handshakes either.

I’m looking forward to an adjusted 10.24 section.

Teco

> Op 18 dec. 2014, om 19:05 heeft Henning Rogge <[email-masked]> het volgende geschreven:
>

---

From: Henning Rogge <[email-masked]>
Date: Thu, 18 Dec 2014 20:37:26 +0100

> I’m concerned on c)(drop session). Extensions are optional and b) (ignore) is the logical choice.

Drop session might be a configuration thing. If I tell my router "XYZ
is mandatory" as a configuration, I expect it to drop the session if
something bad happens.

Normally you should just ignore the extension TLVs (in my opinion).

> However, when within a session, some form of extension handshake took place, invalid messages could be detected (violations on vendor specified sub-protocol) and yes, a sessions could be dropped. T…

Could be similar to the announcement of used TLVs/Messages... if you
see something you don't like, you can either ignore it or you can drop
the session.

If you don't drop it during session initialization, you have given
your "approval" that you will accept the incoming data and not drop
the session later because of it.

Henning

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 19 Dec 2014 10:58:38 +0000

> Normally you should just ignore the extension TLVs (in my opinion).

That's the approach we've taken in our protocols using 5444 (with its own TLV structure) but have taken it further by requiring a positive TLV in order to use an address (what in the 5444 case a TLV is associated with, but that's specific to that).

An alternative (which didn't happen for 5444 as there never was a coherent proposal - those concentrated more on forwarding, which turned out to be a nasty can or worms, rather than use) is to flag TLVs. One case I saw in a protocol I looked at recently (I don't recall which one right now) used bits to control what to do if you didn't recognise it. Not exactly what it did, but close, would be to do triage: if you don't recognise this TLV then (a) ignore the whole message it is in, (b) ignore everything in this message associated with this TLV, (c) just ignore this TLV. You could split (a) by report error/do not report error.

I'm not proposing exactly that (in part because I'm not up to date on all the details) but it may be worth considering something like this. (Could of course just be two options - carry on/don't carry on.)

---

From: "Taylor, Rick" <[email-masked]>
Date: Fri, 19 Dec 2014 11:02:59 +0000

> -----Original Message-----
> From: manet [mailto:[email-masked]] On Behalf Of Dearlove,
> Christopher (UK)
> Sent: 19 December 2014 10:59
> To: Henning Rogge; Teco Boot
> Cc: manet IETF
> Subject: Re: [manet] DLEP Vendor Extensions
>
> Henning:

We have ignore rules for this in DLEP already, which I'm loathe to change.

>
> That's the approach we've taken in our protocols using 5444 (with its own TLV
> structure) but have taken it further by requiring a positive TLV in order to use
> an address (what in the 5444 case a TLV is associated with, but that's specific
> to that).
>
> An alternative (which didn't happen for 5444 as there never was a coherent
> proposal - those concentrated more on forwarding, which turned out to be a
> nasty can or worms, rather than use) is to flag TLVs. One case I saw in a
> protocol I looked at recently (I don't recall which one right now) used bits to
> control what to do if you didn't recognise it. Not exactly what it did, but close,
> would be to do triage: if you don't recognise this TLV then (a) ignore the
> whole message it is in, (b) ignore everything in this message associated with
> this TLV, (c) just ignore this TLV. You could split (a) by report error/do not
> report error.

This sounds a lot like SCTP to me.  It works, but it can be viewed as fiddly.  Personally I like it, I know Stan doesn't.

>
> I'm not proposing exactly that (in part because I'm not up to date on all the
> details) but it may be worth considering something like this. (Could of course
> just be two options - carry on/don't carry on.)

Thanks for the useful input Chris,

Rick
The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure.

If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system.

Emails to Airbus DS Limited may be processed, recorded and monitored anywhere in the European Community.

Airbus DS Limited

Registered Office: Quadrant House, Celtic Springs, Coedkernew, Newport , NP10 8FZ.
Registered in England and Wales under company number 04191036

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 19 Dec 2014 11:12:35 +0000

> This sounds a lot like SCTP to me.  It works, but it can be viewed as fiddly.  Personally I like it, I know Stan doesn't.

No, not SCTP. But as I said I don't recall which protocol. What is clear is that this is a frequently reinvented wheel. (That's a bit unfair, requirements differ.)

Not DLEP, but may be of interest, digging into my memory the issue that was the killer for trying to put something like this into 5444 was the expectation that messages would be forwarded. Then we run into cases such as when we have A - B - C where A and C support whatever it is that the TLV indicates, but B does not. In some cases that's fine, in others it's a killer. Which would mean trying to manage whether B forwards the message. But what is forwarding? It could be blind forwarding. It could be something like MPR forwarding. It could be regenerating a new message from that message. We eventually threw up our hands and gave up, things were taking too long already.

---

From: Henning Rogge <[email-masked]>
Date: Fri, 19 Dec 2014 12:24:07 +0100

> Not DLEP, but may be of interest, digging into my memory the issue that was the killer for trying to put something like this into 5444 was the expectation that messages would be forwarded. Then we…

The good thing with DLEP is that its a direct point to point
connection between two different partners.

If you are the radio you are always talking to a single router... you
just announce the radio vendor-extension you transmit (if any at all).
You also have to check if you understand the Vendor-extension of the
router.

If there is a "Radio Vendor extension X" that requires a "Router
Vendor extension Y" then you can check the presence of this extension
during session buildup.

Of course if a Vendor starts to build multiple extensions (and some
extensions that are just multiple extensions combined), things get
complicated... but I see no problem here, this problems go away when
you come to the IETF to standardize new TLVs.

Henning Rogge

---

From: Justin Dean <[email-masked]>
Date: Fri, 19 Dec 2014 07:55:19 -0500

It doesn't forward but there are limitations when only having one approach
for dealing with unknown extensions. (Drop connection vs ignore
extensions). But as you point out limitations with vendor extentions isn't
really a bad thing as it encourages standardization. I like the approach.

Justin

On Dec 19, 2014 6:24 AM, "Henning Rogge" <[email-masked]> wrote:
> > No, not SCTP. But as I said I don't recall which protocol. What is
clear is that this is a frequently reinvented wheel. (That's a bit unfair,
requirements differ.)
> >
> > Not DLEP, but may be of interest, digging into my memory the issue that
was the killer for trying to put something like this into 5444 was the
expectation that messages would be forwarded. Then we run into cases such
as when we have A - B - C where A and C support whatever it is that the TLV
indicates, but B does not. In some cases that's fine, in others it's a
killer. Which would mean trying to manage whether B forwards the message.
But what is forwarding? It could be blind forwarding. It could be something
like MPR forwarding. It could be regenerating a new message from that
message. We eventually threw up our hands and gave up, things were taking
too long already.

---

From: "Taylor, Rick" <[email-masked]>
Date: Fri, 19 Dec 2014 14:31:15 +0000

Just to clarify the ‘Drop Connections’ statement.  DLEP as it currently stands has a capability negotiation phase with graceful refusal as part of the session initialization.  The drop connection behaviour happens only if an implementation reneges on what has previously been negotiated.

Rick

From: manet [mailto:[email-masked]] On Behalf Of Justin Dean
Sent: 19 December 2014 12:55
To: Henning Rogge
Cc: Christopher Dearlove; [email-masked]
Subject: Re: [manet] DLEP Vendor Extensions

It doesn't forward but there are limitations when only having one approach for dealing with unknown extensions. (Drop connection vs ignore extensions). But as you point out limitations with vendor extentions isn't really a bad thing as it encourages standardization. I like the approach.

Justin

On Dec 19, 2014 6:24 AM, "Henning Rogge" <[email-masked]<mailto:[email-masked]>> wrote:
> <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>

Airbus DS Limited

---

From: Henning Rogge <[email-masked]>
Date: Fri, 19 Dec 2014 15:41:36 +0100

On Fri, Dec 19, 2014 at 3:31 PM, Taylor, Rick <[email-masked]> wrote:
> Just to clarify the ‘Drop Connections’ statement.  DLEP as it currently
> stands has a capability negotiation phase with graceful refusal as part of
> the session initialization.  The drop connection behaviour happens only if
> an implementation reneges on what has previously been negotiated.

Yes, "drop connection" was maybe a bit too hard...

I meant "decide to refuse the session" after receiving the session
information of the other side.

Henning Rogge

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Fri, 19 Dec 2014 18:05:42 +0000

Christopher,

>Sent: vrijdag 19 december 2014 12:13
>To: Taylor, Rick; Henning Rogge; Teco Boot
>Cc: manet IETF
>> This sounds a lot like SCTP to me.  It works, but it can be viewed as fiddly.
>Personally I like it, I know Stan doesn't.
>
>No, not SCTP. But as I said I don't recall which protocol. What is clear is that this
>is a frequently reinvented wheel. (That's a bit unfair, requirements differ.)
>

Perhaps http://tools.ietf.org/html/rfc5050#section-4.3, in conjunction with http://tools.ietf.org/html/rfc5050#section-4.6  ?

Regards,
Ronald
 
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 19 Dec 2014 18:25:17 +0000

No, not that either. Clearly a common issue.

-- 
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 19 Dec 2014, at 18:05, Velt, R. (Ronald) in 't <[email-masked]> wrote:
> 
> Christopher,
>