Subject: [manet] Status of DLEP-draft at Cisco?

From: Henning Rogge <[email-masked]>
Date: Tue, 3 Jul 2012 16:31:35 +0200

Hello,

I think it is time to talk about the status of the DLEP draft. We 
stopped the discussion to give the authors time to talk about the ideas 
of the WG about how to change and improve the draft.

That was two months ago.

I would like to hear an update how we should go forward with DLEP in the 
Manet WG, the concept is too important to just let it stay quiet for months.

Has there been a decision what Cisco thinks about all the discussions we 
had in March/April? Do you work on a -03 draft updated to RFC5444 
compatibility?

I think that many members of the Manet WG are very interested to push 
DLEP forward.

Regards
Henning Rogge
-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 3 Jul 2012 15:16:50 +0000

Henning, 

(Based on earlier discussions, *all* of this is from the perspective of a Working Group Participant, and a Draft co-author/editor)...

Yes, the authors are still in discussions with regard to DLEP 5444 "compatibility".  There are still roughly 3 options I see for moving forward. 

1) Remove RFC 5444 compatibility as a requirement. This "solves" the issue of multiple address types vis-a-vis address blocks. Also, since the reactive protocol drafts being considered by the WG don't necessarily require RFC 5444 (e.g., *both* LOADng and DYMO) don't require or have non-5444 packets, the WG mandate that everything use 5444 seems capricious at best. 

2) Re-work DLEP to compress the "sub-TLV's" into 5444 message TLV's, leaving the addressing internal to DLEP. This avoids the issue of carrying multiple address families in 5444 address blocks. I've seen several recommendations on how to "pretend" that a MAC address (or an IPv4 address) is IPv6, so as to carry everything in address blocks of a single length. However, I see that as a hack, plain and simple. I'm adamant that this won't fly - not at IESG review, at least. I'll lodge the complaint against the draft myself if I have to on that one. In order to do that, we'd need to….

3) Create RFC 54444 bis, or some other update to 5444 to handle multiple address families with a single transmission. 

Now, if the WG chooses option 2 or 3, I *still* see an issue with respect to the mandate of "we must use 5444 for all drafts"… especially since our reactive drafts seem to be excluded from that mandate.  Long story short? I'm leaning towards option 1.

Regards,
Stan

On Jul 3, 2012, at 10:31 AM, Henning Rogge wrote:

> Hello,
> 
> I think it is time to talk about the status of the DLEP draft. We stopped the discussion to give the authors time to talk about the ideas of the WG about how to change and improve the draft.
> 
> That was two months ago.
> 
> I would like to hear an update how we should go forward with DLEP in the Manet WG, the concept is too important to just let it stay quiet for months.
> 
> Has there been a decision what Cisco thinks about all the discussions we had in March/April? Do you work on a -03 draft updated to RFC5444 compatibility?
> 
> I think that many members of the Manet WG are very interested to push DLEP forward.
> 
> Regards
> Henning Rogge
> -- 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 3 Jul 2012 15:49:20 +0000

I think your option 2 is missing one point. The idea to use IPv6 addresses was when it appeared that there might be multiple address types that might all be used as a key. But later discussion indicated that all entities should be keyed by their MAC address, with other addresses as additional information. In that case at the 5444 level, the address type would simply be length = 16, and MAC addresses would be used as-is. IPv4 and IPv6 addresses would go in TLVs. It's fairly clean. (How clean it is depends on whether a TLV that carries addresses allows for compression. For DLEP I think not.)

With regard to point 3, I think the last draft of DYMO was 5444 compliant. It was Charlie taking back over from Ian who suggested it didn't need to be 5444 compliant (and should be called AODVv2). That's a discussion the WG hasn't had. LOADng hasn't of course been developed in MANET, though has  now been suggested to MANET, again I think with no conclusions. I thus wouldn't characterise the WG mandate of required use of 5444 as capricious for routing protocols. Specifically I think 5444 must be used (both because 5498 says so and because otherwise things break) if using the allocated manet port/protocol. DLEP on the other hand is not a routing protocol, doesn't need to use the same port, and the argument is not as strong.

Subject to those caveats all three are theoretical possibilities. I'm strongly against number 3 because of its implications for NHDP, OLSRv2 and SMF. (I also think it actually turns out not to help DLEP.) As I've said before, I see good arguments relating to the other two (or three: 5444 as-DLEP-is, better fit to 5444, not 5444), and that always makes things harder. Note that's a DLEP discussion, it's different for DYMO/AODVv2/LOADng (where I do have views, but I'm not going to muddy this discussion with them).

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stan Ratliff (sratliff)
Sent: 03 July 2012 16:17
To: Henning Rogge
Cc: Greg Harrison (greharri); [email-masked]; Shawn Jury; Bo Berry (boberry)
Subject: Re: [manet] Status of DLEP-draft at Cisco?

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Henning, 

2) Re-work DLEP to compress the "sub-TLV's" into 5444 message TLV's, leaving the addressing internal to DLEP. This avoids the issue of carrying multiple address families in 5444 address blocks. I've seen several recommendations on how to "pretend" that a MAC address (or an IPv4 address) is IPv6, so as to carry everything in address blocks of a single length. However, I see that as a hack, plain and simple. I'm adamant that this won't fly - not at IESG review, at least. I'll lodge the complaint against the draft myself if I have to on that one. In order to do that, we'd need to..

Now, if the WG chooses option 2 or 3, I *still* see an issue with respect to the mandate of "we must use 5444 for all drafts". especially since our reactive drafts seem to be excluded from that mandate.  Long story short? I'm leaning towards option 1.

Regards,
Stan

********************************************************************
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: Thomas Heide Clausen <[email-masked]>
Date: Tue, 3 Jul 2012 18:38:23 +0200

Just for information, the coming version of LOADng will use 5444 (cleanly). 

-- 
Thomas Heide Clausen
http://www.thomasclausen.org

"Today's scientists have substituted mathematics for 
  experiments, and they wander off through equation 
  after equation, and eventually  build a structure 
  which has no relation to reality."
 - Nikola Tesla, 
    Modern Mechanics and Inventions, July, 1934

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 3 Jul 2012 09:41:26 -0700

Stan,

just one comment on RFC5444 for reactive MANET protocols: I believe that
the reactive MANET protocol should use RFC5444. As a side note, LOADng is
currently being updated to be RFC5444 compliant.

Best
Ulrich

On Tue, Jul 3, 2012 at 8:16 AM, Stan Ratliff (sratliff)
<[email-masked]>wrote:

> Henning,
>
>
> (Based on earlier discussions, *all* of this is from the perspective of a
> Working Group Participant, and a Draft co-author/editor)...
>
> Yes, the authors are still in discussions with regard to DLEP 5444
> "compatibility".  There are still roughly 3 options I see for moving
> forward.
>
> 1) Remove RFC 5444 compatibility as a requirement. This "solves" the issue
> of multiple address types vis-a-vis address blocks. Also, since the
> reactive protocol drafts being considered by the WG don't necessarily
> require RFC 5444 (e.g., *both* LOADng and DYMO) don't require or have
> non-5444 packets, the WG mandate that everything use 5444 seems capricious
> at best.
>
> 2) Re-work DLEP to compress the "sub-TLV's" into 5444 message TLV's,
> leaving the addressing internal to DLEP. This avoids the issue of carrying
> multiple address families in 5444 address blocks. I've seen several
> recommendations on how to "pretend" that a MAC address (or an IPv4 address)
> is IPv6, so as to carry everything in address blocks of a single length.
> However, I see that as a hack, plain and simple. I'm adamant that this
> won't fly - not at IESG review, at least. I'll lodge the complaint against
> the draft myself if I have to on that one. In order to do that, we'd need
> to….
>
> 3) Create RFC 54444 bis, or some other update to 5444 to handle multiple
> address families with a single transmission.
>
> Now, if the WG chooses option 2 or 3, I *still* see an issue with respect
> to the mandate of "we must use 5444 for all drafts"… especially since our
> reactive drafts seem to be excluded from that mandate.  Long story short?
> I'm leaning towards option 1.
>
> Regards,
> Stan
>
>
>
>
> stopped the discussion to give the authors time to talk about the ideas of
> the WG about how to change and improve the draft.
> >
> > That was two months ago.
> >

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 3 Jul 2012 16:59:42 +0000

Chris, 

OK, that's fair enough. As you mention, since DLEP isn't a routing protocol, and can exist quite cleanly on its own port, that's the direction I'm leaning. I think there are also uses outside the MANET WG where use of 5444 would actually cause more code to be employed, and increase packet overhead (think ROLL)… 

Regards,
Stan

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Tue, 3 Jul 2012 17:23:56 +0000

Christopher,

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Dearlove, Christopher (UK)
>Sent: dinsdag 3 juli 2012 17:49
>To: Stan Ratliff (sratliff); Henning Rogge
>I think your option 2 is missing one point. The idea to use IPv6 addresses was
>when it appeared that there might be multiple address types that might all be
>used as a key. But later discussion indicated that all entities should be keyed
>by their MAC address, with other addresses as additional information. In that
>case at the 5444 level, the address type would simply be length = 16, and MAC

Did you mean: length = 6 ? :-)

>addresses would be used as-is. IPv4 and IPv6 addresses would go in TLVs. It's
>fairly clean. (How clean it is depends on whether a TLV that carries addresses
>allows for compression. For DLEP I think not.)

<snip>

Regards,
Ronald in 't Velt
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 3 Jul 2012 17:29:24 +0000

Yes, 6. Finger and/or brain error. Thanks for the catch.

-----Original Message-----
From: Velt, R. (Ronald) in 't [mailto:[email-masked]] 
Sent: 03 July 2012 18:24
To: Dearlove, Christopher (UK); [email-masked]
Subject: RE: [manet] Status of DLEP-draft at Cisco?

Christopher,

<snip>

Regards,
Ronald in 't Velt

---

From: Henning Rogge <[email-masked]>
Date: Tue, 3 Jul 2012 19:34:06 +0200

> OK, that's fair enough. As you mention, since DLEP isn't a routing protocol, and can exist quite cleanly on its own port, that's the direction I'm leaning. I think there are also uses outside the M…

I think the small overhead is pretty meaningless because DLEP is not
sent over the mesh links, just between radio and router.

Also the "use 6 byte addresses for MACs, use TLVs for IPv4/6" will
work quite well for DLEP, because many radios will not even need the
IPv4/6 part at all, especially with the bridged data-path DLEP
describes.

There should be the options to transmit IPv4/6 addresses over DLEP if
they are available, but I wonder if this would be a common usecase.

Most of the workinggroup seems to have the opinion that DLEP should
move to full RFC5444 compliance, because it will fit the purpose of
DLEP fine and spare the IETF "just another proprietary data format".
With RFC5444 we can easily get to a point where we get a protocol that
can be extended for more metrics without the need of a version field,
which will simplify future DLEP revisions.

Henning Rogge
-- 
Steven Hawkings about cosmic inflation: "An increase of billions of
billions of percent in a tiny fraction of a second. Of course, that
was before the present government."

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 3 Jul 2012 17:55:46 +0000

> sent over the mesh links, just between radio and router.

I guess the amount of overhead (and introduction of 5444 parsers in environments where they currently don't exist) is in the eye of the beholder… 

> IPv4/6 part at all, especially with the bridged data-path DLEP

Again the "work quite well" is subjective. Yes, we can make it work.

> they are available, but I wonder if this would be a common use case.

I most definitely hope it will become a common use case. As we've talked about before, this addition helps to overcome issues like population of IPv4 ARP caches…. something that either needs a-priori knowledge, which is not likely in my deployments, or some mechanism such as this. 

> which will simplify future DLEP revisions.

And again, we disagree on that point. 

Regards,
Stan

---

From: Teco Boot <[email-masked]>
Date: Wed, 4 Jul 2012 07:01:41 +0200

> I most definitely hope it will become a common use case. As we've talked about before, this addition helps to overcome issues like population of IPv4 ARP caches…. something that either needs a-prio…

IMHO Cisco should update their ARP implementation, so it supports RFC 5889. ND should not be a problem.
Most .!!!! problems I have seen were caused by lost packets on last hop router, not on transit links.

Teco

---

From: Teco Boot <[email-masked]>
Date: Wed, 4 Jul 2012 07:42:06 +0200

> And again, we disagree on that point. 

Stan, you could set up a poll to find out the working group opinion.

In the discussion on full RFC 5444 compliance, or just use it as a 
transport container, my non-important opinion:
 - dlep-02 implements reliable transport, with tiny chunks of to_be_acked 
   data and the ack messages 
 - this reliable transport requires (complex) state machines, but provides 
   reduced data volume over the wire
 - when transferred data is highly variable, this reliable transport 
   doesn't make sense. A timer based refresh, with triggered fast updates, 
   would better fit the required functionality
 - RFC 5444 provides a mechanism to compress larger arrays of data. This 
   could be used for MAC address TLV's, for transfer of ever changing link 
   metrics
 - for reliable transfer, one option would be using another protocol, 
   already standardized. It is called TCP, if I remember well. For
   discovery, TCP doesn't work well... 
 - because dlep acts on local, often high speed links, reduction of volume
   of transferred data has low priority.
I guess we have to choose how to implement the link metrics exchange.
If we opt for reliable transfer, I prefer TCP. For a straightforward
stateless transfer, RFC 5444 MAC address TLV's looks an obvious choice.
Opinions on address TLVs would be influenced on having the parser already, 
or facing something on the todo list. Dito the validity timer stuff.

Teco

---

From: "John Dowdell" <[email-masked]>
Date: Wed, 4 Jul 2012 10:03:12 +0100

Based on our experience with using DLEP, I would request that it becomes
mandatory to supply either an IPv4 or IPv6 address of the far end router
during a Neighbour Up/Down message as that would speed up the routing
process. Total contact time between routers in a MANET could be very
short, and anything that helps speed the establishment of the connection
is welcome.

As to the 5444 debate, I do not see the need for 5444 compliance in
DLEP. I agree with the 'it's not a routing protocol' stance, and in my
view it just adds unnecessary complexity, but I'm open to discussion on
the extensibility issue.
 
John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Teco Boot
Sent: 04 July 2012 06:02
To: Stan Ratliff (sratliff)
Cc: Dearlove, Christopher (UK); [email-masked]; Shawn Jury; Bo Berry
(boberry); Greg Harrison (greharri)
Subject: Re: [manet] Status of DLEP-draft at Cisco?

Op 3 jul. 2012, om 19:55 heeft Stan Ratliff (sratliff) het volgende
geschreven:

> I most definitely hope it will become a common use case. As we've
talked about before, this addition helps to overcome issues like
population of IPv4 ARP caches.... something that either needs a-priori
knowledge, which is not likely in my deployments, or some mechanism such
as this. 

IMHO Cisco should update their ARP implementation, so it supports RFC
5889. ND should not be a problem.
Most .!!!! problems I have seen were caused by lost packets on last hop
router, not on transit links.

Teco

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 4 Jul 2012 09:46:15 +0000

With regard to 5444, there is a (good in my opinion) argument that the current version is technically worse than either of the options of a better fit to 5444 (which I think the shape of is clear, although there would need to be work on the details) or a new non-5444 format. (A key question about the latter is flexibility for the future; that is offered by 5444.) Of course the current version has the advantage that it is the current version.

-----Original Message-----
From: John Dowdell [mailto:[email-masked]] 
Sent: 04 July 2012 10:03
To: Teco Boot; Stan Ratliff (sratliff)
Cc: Dearlove, Christopher (UK); [email-masked]; Shawn Jury; Bo Berry (boberry); Greg Harrison (greharri)
Subject: RE: [manet] Status of DLEP-draft at Cisco?

 
John

-----Original Message-----

Teco

---

From: Henning Rogge <[email-masked]>
Date: Wed, 4 Jul 2012 12:57:31 +0200

> short, and anything that helps speed the establishment of the connection

I would say it should be mandatory if the knowledge is present on the 
DLEP-capable device. If you do not know the IP addresses of each 
partner, you can still use DLEP and leave this job to the router.

> DLEP.

If we can find a good fit for all the DLEP use cases with RFC5444, I see 
no need to specify another packet format for it. DLEP transports 
information (many of them optional) about the local radio/modem and 
information (also many of them optional) about connection between 
radios/modems. This seems to be a very good description of the concept 
of RFC5444.

It also needs multiple kinds of messages, which makes message 
aggregation into a single block of information an useful feature.

At last, it needs to interact with routing protocols (especially MANET 
protocols), which makes reusing rfc5444 a good thing.

 > I agree with the 'it's not a routing protocol' stance, and in my
 > view it just adds unnecessary complexity, but I'm open to discussion 
 > on the extensibility issue.

What do you think is the difference in implementing a custom DLEP 
protocol language and a RFC5444 compliant one? In the second case, you 
might be able to reuse code written for routing protocols, in the first 
one you have to do it from scratch.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Wed, 4 Jul 2012 13:19:29 +0200

Op 4 jul. 2012, om 11:03 heeft John Dowdell het volgende geschreven:

> process.
I like fast convergence. The question is how to do it.

Neighbor up/down would fire triggers in the L3 hello mechanism. Up would 
start send out new hello's. Down would update the link state, and optionally
send out new hello's.

The IP addresses, related to neighbor up, could be used for unicast hello's
or updates in neighbor tables directly. So it may help. But do we set adjacency 
to what DLEP provides? Or mandate verification with L3 hello's?

Often, all info for neighbor cache is already available in the hello packet. 
There is running code that actually use it. Another approach is trigger L2 
address resolving for all next-hop IP addresses. IMHO good quality routers 
do that / should do that, also in a non-MANET environment.

> Total contact time between routers in a MANET could be very
Yes, with limits on "anything". Is header snooping acceptable?

My main concern is, there are already enough methods that can do the job.

Teco

---

From: "John Dowdell" <[email-masked]>
Date: Thu, 5 Jul 2012 10:10:50 +0100

OK can I modify my request below then to read as follows?

If a DLEP client (radio) receives one or more IP addresses from its immediately attached DLEP server (router) during the Peer Offer or Peer Update message, it MUST pass that information across to the remote client (by means of radio magic) and that information MUST be passed from the remote client to the remote DLEP server during the Neighbour Up and Neighbour Address Update messages.

I cannot immediately think of a scenario where an IP address would not be supplied from the server to the client, but I'm happy to allow for that possibility.

John 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 04 July 2012 11:58
To: [email-masked]
Subject: Re: [manet] Status of DLEP-draft at Cisco?

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Thu, 5 Jul 2012 11:14:35 +0200

On 07/05/2012 11:10 AM, John Dowdell wrote:
> If a DLEP client (radio) receives one or more IP addresses from its
> immediately attached DLEP server (router) during the Peer Offer or
> Peer Update message, it MUST pass that information across to the
> remote client (by means of radio magic) and that information MUST be
> passed from the remote client to the remote DLEP server during the
> Neighbour Up and Neighbour Address Update messages.

What is with radios that do NOT exchange IP addresses as part of their 
"neighbor detection" (the radio magic is not present?) ? I don't think 
it is a good idea to mandate DLEP to send data over the radio on its own.

If the radio supports this, I agree this is a MUST.

But think about DLEP implementations for simpler devices (maybe as 
simple as IEEE 802.11 embedded radios, connected to a central router 
with ethernet).

Henning Rogge

> I cannot immediately think of a scenario where an IP address would
> not be supplied from the server to the client, but I'm happy to allow
> for that possibility.
>
> John
>
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Henning Rogge Sent: 04
> July 2012 11:58 To: [email-masked] Subject: Re: [manet] Status of
> DLEP-draft at Cisco?
>
>> Based on our experience with using DLEP, I would request that it
>> becomes mandatory to supply either an IPv4 or IPv6 address of the
>> far end router during a Neighbour Up/Down message as that would
>> speed up the routing process. Total contact time between routers in
>> a MANET could be very short, and anything that helps speed the
>> establishment of the connection is welcome.
>
> I would say it should be mandatory if the knowledge is present on
> the DLEP-capable device. If you do not know the IP addresses of each
>> As to the 5444 debate, I do not see the need for 5444 compliance
>> in DLEP.
>
> If we can find a good fit for all the DLEP use cases with RFC5444, I
> see no need to specify another packet format for it. DLEP transports
> radios/modems. This seems to be a very good description of the
> concept of RFC5444.
>
> At last, it needs to interact with routing protocols (especially
> MANET protocols), which makes reusing rfc5444 a good thing.
>
>> view it just adds unnecessary complexity, but I'm open to
>> discussion on the extensibility issue.
>
> protocol language and a RFC5444 compliant one? In the second case,
> you might be able to reuse code written for routing protocols, in the
> first one you have to do it from scratch.
>
> Henning Rogge
>

---

From: Teco Boot <[email-masked]>
Date: Thu, 5 Jul 2012 14:00:14 +0200

Op 5 jul. 2012, om 11:10 heeft John Dowdell het volgende geschreven:

> If a DLEP client (radio) receives one or more IP addresses from its immediately attached DLEP server (router) during the Peer Offer or Peer Update message, it MUST pass that information across to the remote client (by means of radio magic)
Having a standard would be great for interoperability. That is what we try to achieve, isn't it?

> and that information MUST be passed from the remote client to the remote DLEP server during the Neighbour Up and Neighbour Address Update messages.
What if remote node doesn't use DLEP at all? And this information exchange is optional, isn't it?

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 5 Jul 2012 14:07:03 +0000

On Jul 4, 2012, at 6:57 AM, Henning Rogge wrote:

> I would say it should be mandatory if the knowledge is present on the DLEP-capable device. If you do not know the IP addresses of each partner, you can still use DLEP and leave this job to the router.
> 
> If we can find a good fit for all the DLEP use cases with RFC5444, I see no need to specify another packet format for it. DLEP transports information (many of them optional) about the local radio/modem and information (also many of them optional) about connection between radios/modems. This seems to be a very good description of the concept of RFC5444.
> 
> It also needs multiple kinds of messages, which makes message aggregation into a single block of information an useful feature.
> 
> At last, it needs to interact with routing protocols (especially MANET protocols), which makes reusing rfc5444 a good thing.

That's a red herring, IMO. The fact that DLEP should interact with routing protocols does *not* mean that 5444 use is, in and of itself, "a good thing". For example, the current DLEP offering I work on interacts with OSPFv3. RFC 5444 compliance is actually a burden in that environment. Or, at a bare minimum, it becomes "DLEP-specific". I believe DLEP has applicability outside the MANET space, and as has been said before, it isn't a routing protocol. So, I don't see a requirement to "make it fit" with 5444. 

Regards,
Stan

> > view it just adds unnecessary complexity, but I'm open to discussion > on the extensibility issue.
> 
> What do you think is the difference in implementing a custom DLEP protocol language and a RFC5444 compliant one? In the second case, you might be able to reuse code written for routing protocols, in the first one you have to do it from scratch.
> 
> Henning Rogge
> 
> --

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 5 Jul 2012 14:11:29 +0000

> My main concern is, there are already enough methods that can do the job.

The problem with header snooping is that it has to be done *in the radio*. With the DLEP mechanism, passing Layer 3 devices is as straightforward as: 

1. A router and it's *locally attached* radio establish DLEP session. The router hands the radio it's addresses via "Peer Offer". 
2. The radio does NOT need to know what these addresses are. Radio can treat the information as opaque TLV's. Radio stores that information. 
3. When the radio detects a new potential neighbor (e.g., another radio), it can exchange the opaque TLV's as part of the radio handshake. 
4. Each radio now builds a "Neighbor Up" back to the routers involved, appending the opaque TLV's received from the other radio. 

And presto, you have exchanged Layer 3 addresses, irrespective of subnet masks, ARP quirkiness, etc…

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Thu, 5 Jul 2012 16:48:18 +0200

If a radio has this mechanism, its a good idea to use it.

The nice thing is that even if the radio does NOT have this feature,
the network will still work.

The Router will send the Radio IP-Addresses, which the radio will
throw away because it cannot transport them over the air. This means
the routers will not get IP-addresses as part of the information about
the neighbors through DLEP... which means that they will not pre-fill
the ARP-Table.

and will just trigger the normal ARP mechanism. Of course it will be
as slow as the normal ARP, which means that companies might integrate
it in more radios.

Which means the "IP over radio-layer2 handshake" has a good fallback
for the case that the router DOES support "IP addresses over DLEP" but
the radio does not.

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 5 Jul 2012 14:53:39 +0000

>   would better fit the required functionality

Relying on "yet another independent timer" isn't the way to go, IMO. That will only extend time to converge the network. It also doesn't cover the case where some of this data might get dropped. Yes, DLEP flows are typically on a high-speed wired link, and the theoretical drop rate would be small. However, Murphy's Law says traffic *will* get dropped, and the traffic that gets dropped will be that which is most important to you. There is also the use case where the wireless link itself is used for DLEP traffic - what we've currently called the "Detached Discovery" mode. 

Regards,
Stan

---

From: Teco Boot <[email-masked]>
Date: Thu, 5 Jul 2012 16:53:25 +0200

Op 5 jul. 2012, om 16:11 heeft Stan Ratliff (sratliff) het volgende geschreven:

> The problem with header snooping is that it has to be done *in the radio*.
No, it is a mechanism in the router. Routing packets have L2 and L3 headers, good info to populate adjacency tables.

> With the DLEP mechanism, passing Layer 3 devices is as straightforward as: 
> 
First hello packet has all needed info. Using it needs no additional bit over the air.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 5 Jul 2012 14:54:36 +0000

> for the case that the router DOES support "IP addresses over DLEP" but

Yep, we're in agreement there. :-) 

Regards,
Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 5 Jul 2012 15:06:51 +0000

> No, it is a mechanism in the router. Routing packets have L2 and L3 headers, good info to populate adjacency tables.

No, it's in the radio… especially where multicast is concerned. 

> First hello packet has all needed info. Using it needs no additional bit over the air.

Not true. I don't know of a single HELLO packet, from any protocol, that contains both IPv4 and IPv6 addresses. 

Stan

---

From: Teco Boot <[email-masked]>
Date: Thu, 5 Jul 2012 17:11:25 +0200

Op 5 jul. 2012, om 16:53 heeft Stan Ratliff (sratliff) het volgende geschreven:

> Relying on "yet another independent timer" isn't the way to go, IMO. That will only extend time to converge the network.
No, it isn't. Updates are send as fast as the reliable mechanism. Timers are for auto-cleanup. It is in OSPF too. 

> It also doesn't cover the case where some of this data might get dropped.
Wait for retransmit. When link is unstable, updates might be send quite frequent. Probably faster than delayed ACKs.

> Yes, DLEP flows are typically on a high-speed wired link, and the theoretical drop rate would be small. However, Murphy's Law says traffic *will* get dropped,
OK.

> and the traffic that gets dropped will be that which is most important to you.
Why?

> There is also the use case where the wireless link itself is used for DLEP traffic - what we've currently called the "Detached Discovery" mode. 
I am less interested in this mode. I would use a proxy, and reliable protocol over the satcom link (scenario in I-D for this mode). 
On satcom links, extremely efficient protocols is highly preferred. IMHO few (one?) metric type is used, and address TLVs.
For this satcom link scenario, is info provided the 2 links, for a 2-hop system, for spoke-spoke traffic? 

Teco.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 5 Jul 2012 17:17:19 +0200

Can we maybe agree that we want a protocol that supports multiple
kinds of optimizations for quick IP resolution, if possible with the
same protocol mechanism?

If the router does want to handle the ARP-Cache prefilling itself by
listening to incoming broadcast (or calculate them from the MAC
address in case of linklocal unicasts), this should be easy...

If the radio handles the ARP magic by doing packet snooping, this
should be also possible with DLEP. Either the radio would implement
some Arp-Cache on its own (in which case the router will never see
whats happening), or it will supply the received IPs from the
interface via DLEP to the router.

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 5 Jul 2012 15:20:23 +0000

> No, it isn't. Updates are send as fast as the reliable mechanism. Timers are for auto-cleanup. It is in OSPF too. 

Can't be. You have to wait on the timers to expire. Thus, you extend the time. 

Stan

---

From: Teco Boot <[email-masked]>
Date: Thu, 5 Jul 2012 17:20:23 +0200

> No, it's in the radio… especially where multicast is concerned. 
Why should a radio snoop headers? 

> Not true. I don't know of a single HELLO packet, from any protocol, that contains both IPv4 and IPv6 addresses. 
There is no need for such.
There are protocols that provide IPv4 and IPv6 topology with a single protocol instance, so single hello packet.
Before packets flow, a next-hop calculation is needed, on some to_be_exchanged data.

Teco

---

From: Teco Boot <[email-masked]>
Date: Thu, 5 Jul 2012 17:22:59 +0200

> Can't be. You have to wait on the timers to expire. Thus, you extend the time.
This is the wrong approach. Triggered updates make sense, especially if bandwidth is no concern.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 5 Jul 2012 15:49:51 +0000

> This is the wrong approach. Triggered updates make sense, especially if bandwidth is no concern.

Wow. So in your earlier email, you say "A timer based refresh, with triggered updates…". Now it's just "triggered updates"? I'm confused - it looks like you're trying to take all positions at once. And I'll also argue that a "triggered update" pretty much *has* to be based on a timer the way you've described it. So it also looks like a difference without a distinction…

Stan

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 5 Jul 2012 16:15:42 +0000

I'm of the view
- There is no compulsion for DLEP to use 5444. The only compulsion is 5498's that anything using the manet protocol/port uses 5444.
- 5444 is a flexible format. I believe (but no one has yet done and published the work to support that) that 5444 could be used to represent DLEP at least quite well, maybe very well.
- The currently proposed way to use 5444 to represent DLEP is not a very good use of 5444 to do that.
- The pros and cons of a non-5444 representation of DLEP versus a good 5444 representation of DLEP are hard to judge when neither is well-defined yet.
- A key question is future extensibility, adding new attributes. This is a strength of 5444. How much is it needed by DLEP?
- As an author of 5444 it's always gratifying when someone uses what you helped create. But that's not a factor in the choice.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stan Ratliff (sratliff)
Sent: 05 July 2012 15:07
To: Henning Rogge
Cc: <[email-masked]>
Subject: Re: [manet] Status of DLEP-draft at Cisco?

Regards,
Stan

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 5 Jul 2012 09:29:42 -0700

I support that view (all of the arguments, besides the "as an author of
RFC5444" in the last one ;-).

Best
Ulrich

On Thu, Jul 5, 2012 at 9:15 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> I'm of the view
> - There is no compulsion for DLEP to use 5444. The only compulsion is
> 5498's that anything using the manet protocol/port uses 5444.
> - 5444 is a flexible format. I believe (but no one has yet done and
> published the work to support that) that 5444 could be used to represent
> DLEP at least quite well, maybe very well.
> - The pros and cons of a non-5444 representation of DLEP versus a good
> 5444 representation of DLEP are hard to judge when neither is well-defined
> yet.
> - A key question is future extensibility, adding new attributes. This is a
> strength of 5444. How much is it needed by DLEP?
> - As an author of 5444 it's always gratifying when someone uses what you
> helped create. But that's not a factor in the choice.
>
> --
> Christopher Dearlove
> DLEP-capable device. If you do not know the IP addresses of each partner,
> you can still use DLEP and leave this job to the router.
> >
> radios/modems. This seems to be a very good description of the concept of
> RFC5444.
> >
> That's a red herring, IMO. The fact that DLEP should interact with routing
> protocols does *not* mean that 5444 use is, in and of itself, "a good
> thing". For example, the current DLEP offering I work on interacts with
> OSPFv3. RFC 5444 compliance is actually a burden in that environment. Or,
> at a bare minimum, it becomes "DLEP-specific". I believe DLEP has
> applicability outside the MANET space, and as has been said before, it
> isn't a routing protocol. So, I don't see a requirement to "make it fit"
> with 5444.
>
> Regards,
> Stan
>
>
>
> >
> might be able to reuse code written for routing protocols, in the first one
> you have to do it from scratch.
> >
> > Henning Rogge
> >
> > --

---

From: Henning Rogge <[email-masked]>
Date: Thu, 5 Jul 2012 18:29:48 +0200

> - There is no compulsion for DLEP to use 5444. The only compulsion is 5498's that anything using the manet protocol/port uses 5444.

Interesting question... do we need a different port for the DLEP
protocol or can we just use what RFC5498 provides? If DLEP use its own
message type (and most likely work on a different interface), it
should not make any trouble with existing users. Otherwise we would
need an UDP port and an IP multicast group for DLEP.

> - 5444 is a flexible format. I believe (but no one has yet done and published the work to support that) that 5444 could be used to represent DLEP at least quite well, maybe very well.

I had an early draft for this, but I will work on an update.

> - The currently proposed way to use 5444 to represent DLEP is not a very good use of 5444 to do that.

I think most of us agree to this.

> - A key question is future extensibility, adding new attributes. This is a strength of 5444. How much is it needed by DLEP?
First  of course would be adding of more routing metrics and
statistical data from layer 2.
My second argument for RFC5444 is that DLEP is primarily about
delivering layer-2 data for networks/interfaces and layer-2 data for
neighbors of interfaces. This maps very well on the concept of RFC5444
messages with message- and address-TLVs.

There is also the discussion about optional features like the
ARP-table entry generation through layer-2 transmitted IP-Addresses.
Another point is the existence of multi-line radios, which need to be
considered.

A last argument for using something as flexible as RFC5444 is that the
development Software Defined Radios is still fluid, especially with
all the ideas about how to use them as Cognitive Radios later. Most
likely we will have a much better view what we need to add in a few
years, so having enough flexibility available without breaking the
protocol by moving to "version 2/3" is a good thing.

It would be of course possible to build a packet format that can do
all of this without being RFC5444. But I don't think building another
new packet format is a good way to reduce the complexity of a
protocol. We should work to reduce complexity of DLEP (without killing
features), not adding to it.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 5 Jul 2012 17:13:08 +0000

We can't use the port (I'll ignore protocol for this email) that 5498 defines for non 5444 formatted traffic without violating 5444, and breaking the whole multiplexing method that it mandates (although we were forced to put into 5444 rather than it being in its proper place in 5498 directly). The 5444/5498 model is that a multiplexing entity sits on that port. It gets a packet, parses it as a 5444 packet, and then passes the messages to whatever has registered as that message owner. (I'm simplifying here, for example I'm not discussing the packet TLV block, or protocols A modifying protocol B's messages.) If a non-5444 packet arrives on that port than the multiplexer should reject it. Yes, you could then send that somewhere else, create a new packet format guaranteed to fail to parse as 5444 and so on. But that approach and good design live on different continents.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 05 July 2012 17:30
To: Dearlove, Christopher (UK)
Cc: Stan Ratliff (sratliff); Henning Rogge; <[email-masked]>
Subject: Re: [manet] Status of DLEP-draft at Cisco?

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Thu, 5 Jul 2012 19:17:57 +0200

> We can't use the port (I'll ignore protocol for this email) that 5498 defines for non 5444 formatted traffic without violating 5444, and breaking the whole multiplexing method that it mandates (alt…

I was thinking about full compliant RFC5444 messages. There can be
multiple receivers on the same UDP multicast port.

So in either case (both with and without RFC5444 in DLEP) DLEP needs
it own port and Multicast group.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 5 Jul 2012 17:25:04 +0000

I can see DLEP needing its own multicast group, that's quite different from usual MANET case. I'm not quite so clear on why a different port is necessary if using 5444 and its own message type. (A different port is acceptable, and may even be preferable, I just haven't understood why necessary.)

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 05 July 2012 18:18
To: Dearlove, Christopher (UK)
Cc: Stan Ratliff (sratliff); Henning Rogge; <[email-masked]>
Subject: Re: [manet] Status of DLEP-draft at Cisco?

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Thu, 5 Jul 2012 19:26:59 +0200

hm...

I thought you just said we couldn't reuse the MANET port, even if DLEP
becomes completely RFC5444 compliant? Maybe I misunderstood you...

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 5 Jul 2012 17:36:08 +0000

That's not what I intended to say. (I may not have been clear, I'm not going to check.) I'm not saying definitely you can use the manet port, just that I can't see why not.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 05 July 2012 18:27
To: Dearlove, Christopher (UK)
Cc: Stan Ratliff (sratliff); Henning Rogge; <[email-masked]>
Subject: Re: [manet] Status of DLEP-draft at Cisco?

hm...

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 5 Jul 2012 17:46:53 +0000

Chris, 

First off, I think this is a pretty good summarization. Thanks for putting it on the list.  One comment inline:

> - A key question is future extensibility, adding new attributes. This is a strength of 5444. How much is it needed by DLEP?

Any protocol that is TLV based should be extensible. In removing the requirement for 5444, we (the co-authors) don't mean to imply that DLEP would stop being TLV based. So I would contend that the extensibility (such as adding new metric types) would be consistent. 

Regards,
Stan

---

From: Teco Boot <[email-masked]>
Date: Thu, 5 Jul 2012 21:08:10 +0200

> Wow. So in your earlier email, you say "A timer based refresh, with triggered updates…". Now it's just "triggered updates"? I'm confused - it looks like you're trying to take all positions at once.…

Could you take a look at olsrv2? It provides a good example. TC generation is "scheduled or triggered by a  change of contents". When congestion may occur, having a shaper is a good thing.

Teco

---

From: Teco Boot <[email-masked]>
Date: Thu, 5 Jul 2012 21:16:06 +0200

Op 5 jul. 2012, om 19:25 heeft Dearlove, Christopher (UK) het volgende geschreven:

> I can see DLEP needing its own multicast group, that's quite different from usual MANET case.
Maybe two multicast groups. One for attached mode and one for detached mode. Both can be IP link-local, but have different L2 scope.

Teco

> I'm not quite so clear on why a different port is necessary if using 5444 and its own message type. (A different port is acceptable, and may even be preferable, I just haven't understood why necessary.)
> 
> -- 
> Christopher Dearlove

---

From: Henning Rogge <[email-masked]>
Date: Thu, 5 Jul 2012 21:19:44 +0200

What do you mean with "attached" and "detached"?

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 5 Jul 2012 19:21:54 +0000

[snip]
> Could you take a look at olsrv2? It provides a good example. TC generation is "scheduled or triggered by a  change of contents". When congestion may occur, having a shaper is a good thing.

OK, that is a model…. but from a router's perspective, how do you tell the difference between a radio that just hasn't hit any triggers (so it doesn't need to tell you anything), and one that's failed? I guess the answer would be that Layer 3 timers would eventually clear that up…. but wait - that's what we were trying to avoid in the first place.

The same question applies to a radio - how does it tell the difference between a router that just doesn't have anything to say, and one that's crashed?

We've gone around and around on this issue, and at this point, I don't see either of us changing the other's mind...

Stan

---

From: Teco Boot <[email-masked]>
Date: Thu, 5 Jul 2012 21:41:59 +0200

Op 5 jul. 2012, om 21:21 heeft Stan Ratliff (sratliff) het volgende geschreven:

> OK, that is a model…. but from a router's perspective, how do you tell the difference between a radio that just hasn't hit any triggers (so it doesn't need to tell you anything), and one that's failed? I guess the answer would be that Layer 3 timers
Just timers, not _layer 3_ timers.

> would eventually clear that up…. but wait - that's what we were trying to avoid in the first place.
I wonder how lost packets (no acks) are retransmitted, without timers.

A simple implementation just has fixed timers. A more advanced mode is sending updates more often when there is something to tell. In ROLL, they have such a mechanism standardized. 

> The same question applies to a radio - how does it tell the difference between a router that just doesn't have anything to say, and one that's crashed?
I am not a fan of state in the radio.

> We've gone around and around on this issue, and at this point, I don't see either of us changing the other's mind...
We agree on that :-)
But IMHO it is important we know how our protocols actually work.

Thanks, Teco

---

From: Henning Rogge <[email-masked]>
Date: Thu, 5 Jul 2012 21:45:55 +0200

> The same question applies to a radio - how does it tell the difference between a router that just doesn't have anything to say, and one that's crashed?

Typical answer is that the side that needs to be discovered sends
regular packets with a validity time. If you do not hear anything for
more than a validity time you assume that the other side is gone.

That works very well for autodetection between services and does not
need any state machine.

Henning Rogge

---

From: "John Dowdell" <[email-masked]>
Date: Fri, 6 Jul 2012 12:59:03 +0100

We had some problems in testing a few months back where the DLEP client
on the radio crashed and failed to restart. The immediately attached
router didn't catch this condition either. Unless there is something in
the protocol that maybe has not been implemented yet, I would like to
see something that does this kind of housekeeping.

John

-----Original Message-----
Of Henning Rogge
Sent: 05 July 2012 20:46

On Thu, Jul 5, 2012 at 9:21 PM, Stan Ratliff (sratliff)
<[email-masked]> wrote:
> OK, that is a model.... but from a router's perspective, how do you
tell the difference between a radio that just hasn't hit any triggers
(so it doesn't need to tell you anything), and one that's failed? I
guess the answer would be that Layer 3 timers would eventually clear
that up.... but wait - that's what we were trying to avoid in the first
place.
>
> The same question applies to a radio - how does it tell the difference
between a router that just doesn't have anything to say, and one that's
crashed?

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Fri, 6 Jul 2012 14:57:49 +0200

That is why I (and Teco Boot) suggest moving to a timer based connection 
between DLEP radio and router instead of the session system included in 
Draft 02.

The radio just keeps repeating its Discovery message, which all contain 
a Validity time. If the radio crashes the Discovery messages cease to be 
received by the router, which allows the router to detect the connection 
loss.

The same can be done for information sent by the router in the other 
direction.

Because the radio and the router do not change their state, it should be 
much easier to (re)establish a connection between radio and router.

With the specified validity-time there is a guaranteed time interval 
after which the stored information on the other side of the connection 
will be cleaned up.

Henning Rogge

---

From: "John Dowdell" <[email-masked]>
Date: Fri, 6 Jul 2012 16:14:36 +0100

I'd just like to say that this is not a problem with DLEP per se. After a number of missed heartbeats from an AWOL radio, DLEP will correctly mark the link as down. It's then a question of what the routing protocol does. MANET radio links can be quite unstable by their very nature, so the routing protocol could then decide to wait, to decide if the radio link is really gone or has just had a short temporary outage. In our case the wait was too long, and this has since been fixed.

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 06 July 2012 13:58
To: [email-masked]
Subject: Re: [manet] Status of DLEP-draft at Cisco?

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Fri, 6 Jul 2012 18:09:20 +0200

> I'd just like to say that this is not a problem with DLEP per se. After a number of missed heartbeats from an AWOL radio, DLEP will correctly mark the link as down. It's then a question of what the…

The reported problem could be an implementation bug. Probably it is. Maybe a missing piece in recovery of unexpected conditions in state machines, in the DLEP protocol. This is a reason we should keep protocols as simple as possible. Maybe at cost of less efficiency.

Reminder: I do not have a strong opinion on using a reliable protocol, or the expiration timer based approach. I dislike strong options, with lack of understanding other approaches. But yes, I do suggest using timer based approach for fluent data. At least, we can take a look at it.

Teco