Subject: [manet] DLEP proposal

From: Rick Taylor <[email-masked]>
Date: Sat, 26 Jul 2014 14:25:43 +0000

Stan, All,

As DLEP starts to get picked up and looked at, an increasing number of potential implementers keep getting confused about what we within the DLEP DT see as a simple issue: Destination MAC addresses.

As I have stated before, DLEP uses MAC addresses for 2 distinct purposes: 1) As a destination discriminator/identifier, 2) To advertise the attached router's MAC address.

Ignoring the specifics of my unusual use-case of layer-3 modems, in my draft extension I suggest changing destination MAC addresses to unique numeric identifiers generated by the modem.  On consideration I think it makes more sense to do this for core DLEP, and add the MAC address as a data-item TLV, much like layer-3 addresses are currently handled.

Hopefully this will make the DLEP model more obvious to newcomers:  A destination has an ID, and some data-items describing it, one of which MUST be a MAC address TLV.  The semantics of the protocol are unchanged, we don't care about extra octets on the local link (in principle), and the meaning might be clearer to readers.

I would suggest a 32-bit destination identifier, and I assume that most RF equipment has some concept of a 'link id' that might be reusable/mappable in the DLEP agent, so I don't believe it adds extra burden on implementers.

The MAC address TLV should be obvious to formulate: Type = TBD, Length = 6, Value = MAC octets.  Unlike IP address TLVs there is no need for Add/Drop indicators.

It has the advantage that the DLEP draft text can talk about destinations as concept in one section, and then discuss router MACs and addresses in another discrete section, hopefully avoiding some first-pass confusion in the reader.

The only thing this proposal breaks is multicast destinations, but having had a long chat with Toerless Eckert who is heavily involved in the PIM WG, we may not have thought through the multicast/anycast/broadcast part of DLEP thoroughly yet (and that requires a new thread). 

It also might solve a use-case problem we have skirted around: 1 modem with 2 DLEP sessions to 2 routers.  With this proposal, a single set of destination identifiers could be used, and 2 MAC TLV's added to the destination up, i.e. "I have two upstream routers, go chat..."

Lobbying for one of my corner-cases, I would suggest that the Destination Up signal text states something like: "A destination up signal MUST include 1 MAC address TLV or 1 IPv4 address TLV or 1 IPv6 address TLV.  It SHOULD provide a MAC address TLV, and it is RECOMMENDED that at least 1 IPv4 or IPV6 address TLV be included." 

As I think about it, MAC-less destinations with IP multicast addresses/subnets might be the better way to handle multicast destinations...

Anyway, "fire in the hole!"

Cheers,

Rick

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 26 Jul 2014 09:32:57 -0700

a) I have not tried to wrap my head around the L3 use case yet.

b) There are not only 48, but also 64-bit MAC addresses.
   No idea when/if they would ever be applicable to DLEP, just saying.

c) Your email sounds as if this new identifier for a destination is
   solely there to allow writing a more logical draft. I don't think
   that is true though, and i think a nicer reading draft text wouldn't
   be good enough justification for adding a protocol identifier that
   router and modem coder would need to implement.

   1) Having a destination identifier separate from DMAC would of
   course allow to have destinations change their DMAC. If that is
   useful, i don't know. If we do know a use case and we do this
   protocol change, then it would be great to mentoin that use-case.

   2) Having a destination identifier separate from DMAC would allow
   for destinations to NOT have a DMAC, eg: making DMAC optional.
   I do not know if you intend to support this:

   2.1) for a "normal" destination (router/host), i can not see how
   this would work. Without MAC nor IP, a router could IMHO not
   make heads or tail out of such a destination.

   2.2) for a special "default destination" which i think is what Bryan
   would like to see for sat spoke modems, this would work. The
   "default destination" does not need MAC or IP identification. It
   needs to have a pre-defined, unique identifier though so that a
   DLEP router recognizes it and appropriately deals with it.

   2.3) Another special destination could be a destination that
   really only says "network DOES/DOES-NOT support L2 multicast".
   That somehow is missing.
   
   If a (radio) network does NOT support L2 multicast,
   then all modems need to announce "normal" destinations with
   both MAC and IP address, so that routers can use DLEP to replace ARP,
   and routers would need to replicate IP multicast as replicated
   ethernet unicast across the (radio) network.

   If the radio network DOES support L2 multicast, then MAC addresses
   formal destinations are IMHO still mandatory, but IP addresses
   are optional. If supported by the DLEP modems, they can help to
   optimize the RTTs of ARP away and save RF bandwidth.

   2.3) If the concept of destination is meant to be used to indicate
   individual multicast groups, that warrants a longer discussion, let
   me put this into another mail thread.

Cheers
    Toerless

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 27 Jul 2014 07:31:00 +0200

Hi Rick,

Thanks. IMO for simplicity and flexible purposes I think DLEP does not need
any changes, but maybe editorial, because the draft makes
clear assumptions and does not go into modem configuring or router
configuring. However, my comments below,

On Saturday, July 26, 2014, Rick Taylor wrote:

> Stan, All,
>
> As DLEP starts to get picked up and looked at, an increasing number of
> potential implementers keep getting confused about what we within the DLEP
> DT see as a simple issue: Destination MAC addresses.

I think we consider that DLEP destinations/neighbours have MAC addresses.

> As I have stated before, DLEP uses MAC addresses for 2 distinct purposes:
> 1) As a destination discriminator/identifier, 2) To advertise the attached
> router's MAC address.
>
> Ignoring the specifics of my unusual use-case of layer-3 modems, in my
> draft extension I suggest changing destination MAC addresses to unique
> numeric identifiers generated by the modem.  On consideration I think it
> makes more sense to do this for core DLEP, and add the MAC address as a
> data-item TLV, much like layer-3 addresses are currently handled.

We want DLEP to consider wide use cases, so if we do that suggestion then
DLEP core may loose flexibility as the suggestion (which I understand its
purposes) can still be added as extension to core.

> Hopefully this will make the DLEP model more obvious to newcomers:  A
> destination has an ID, and some data-items describing it, one of which MUST
> be a MAC address TLV.  The semantics of the protocol are unchanged, we
> don't care about extra octets on the local link (in principle), and the
> meaning might be clearer to readers.

I agree with you, but I think is was mentioned some where in the draft (not
sure).

> I would suggest a 32-bit destination identifier, and I assume that most RF
> equipment has some concept of a 'link id' that might be reusable/mappable
> in the DLEP agent, so I don't believe it adds extra burden on implementers.

why? does DLEP not cover that issue of link between modems. Each MAC
address has one link so it already identifies it.

>
> The MAC address TLV should be obvious to formulate: Type = TBD, Length =
> 6, Value = MAC octets.  Unlike IP address TLVs there is no need for
> Add/Drop indicators.
>
> It has the advantage that the DLEP draft text can talk about destinations
> as concept in one section, and then discuss router MACs and addresses in
> another discrete section, hopefully avoiding some first-pass confusion in
> the reader.

I think the introduction does clarify that, but maybe not much focus on one
item as the destinations because it considers many items together.

>
> The only thing this proposal breaks is multicast destinations, but having
> had a long chat with Toerless Eckert who is heavily involved in the PIM WG,
> we may not have thought through the multicast/anycast/broadcast part of
> DLEP thoroughly yet (and that requires a new thread).

DLEP does another special multicast it is not similar to the L3 multicast.

> It also might solve a use-case problem we have skirted around: 1 modem
> with 2 DLEP sessions to 2 routers.  With this proposal, a single set of
> destination identifiers could be used, and 2 MAC TLV's added to the
> destination up, i.e. "I have two upstream routers, go chat..."

The DLEP protocol is that: Each modem has only one DLEP-session to one
router.

> Lobbying for one of my corner-cases, I would suggest that the Destination
> Up signal text states something like: "A destination up signal MUST include
> 1 MAC address TLV or 1 IPv4 address TLV or 1 IPv6 address TLV.

You may say L2 address TLV. However, that may make DLEP not flexible
to cover all possible destinations and use cases.

It SHOULD provide a MAC address TLV, and it is RECOMMENDED that at least 1
> IPv4 or IPV6 address TLV be included."

Yes, we can use "should" rather than "must".

>
> As I think about it, MAC-less destinations with IP multicast
> addresses/subnets might be the better way to handle multicast
> destinations...

DLEP is designed to have MAC addresses, but we can make it L2 addresses to
be general.
We have two kind of DLEP destinations; 1) at L2 , 2) at L3. So DLEP handles
multicast addresses of L2 and not L3.

AB

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

---

From: Rick Taylor <[email-masked]>
Date: Sun, 27 Jul 2014 14:26:37 +0000

Comments inline...

-----Original Message-----
From: Toerless Eckert [mailto:[email-masked]] 
Sent: 26 July 2014 17:33
To: Rick Taylor
Cc: Stan Ratliff; [email-masked]
Subject: Re: [manet] DLEP proposal

> a) I have not tried to wrap my head around the L3 use case yet.

Don't worry about the L3 use-case.  I'm trying to concentrate on 'traditional' DLEP here.

Indeed, but given the TLV includes an explicit length field, I think it just works.

Not solely, clarity might be a useful side effect.

I don't have a specific use-case for this, but it would allow routers to change MAC during the lifetime of a session.
How the TCP session stays up during a MAC change is beyond my ken however...

This I can see being useful for 3 cases: 
a) L3 only modems (out of scope here).
b) Broad/Any/Multi-cast.
c) 1 modem talking DLEP to multiple routers (1 destination, N router MACs)

Correct, there must be at least 1 address, L2 or L3.

I'm not keen on a 'magic number' to mean default destination.  I would rather have a TLV that means "This is the default link for layer2 traffic".  DLEP TLV's are the best way to communicate properties of a destination, rather than encoding the properties into the identifier itself.  This is the reason for my change of heart with Brian's proposal.  

Hmmm, the ability to have a 'Multicast accessibility TLV' alongside an Address TLV would fit with this identifier model. But the specifics of multicast are better discussed in another thread I think.

Absolutely, if there is no L2 broadcast capability in the modem, there MUST be an address provided for a destination.  In fact DLEP is harsher, and currently forces that there MUST be an L2 address for a destination whether broadcast is an option or not (again this ties in with Brian's problem).

Yes, that's stock DLEP as it currently stands.  Without address information, there is no way for a router to match the flow of packets to/from a destination to the link over which the packets will travel.

I would like the concept of destination to have a single consistent meaning for uni/broad/any/multi-cast.  Originally Stan was calling them Neighbours, Radio guys often call them Links, but Destinations is a better name:  It's the grouping for a set of 1 or more remote addresses and metrics for the path to them, 1 in the unicast case, N in the multicast case.  (Flows are to be addressed in a later draft, don't go there!) 

Thanks for your constructive feedback,

Rick

---

From: Rick Taylor <[email-masked]>
Date: Sun, 27 Jul 2014 14:41:59 +0000

Comments inline…

From: Abdussalam Baryun [mailto:[email-masked]]
Sent: 27 July 2014 06:31
To: Rick Taylor
Cc: Stan Ratliff; [email-masked]
Subject: Re: [manet] DLEP proposal

Hi Rick,

Thanks. IMO for simplicity and flexible purposes I think DLEP does not need any changes, but maybe editorial, because the draft makes clear assumptions and does not go into modem configuring or router configuring.

In my experience, a lot of people miss the dual use of destination MAC addresses in DLEP and need it explained.  Also, I believe separating the two might enable some of the multicast issues we have to be simplified.

However, my comments below,

Yes, In core DLEP, they do.  I am proposing changing the packet layout, not removing MACs.

We want DLEP to consider wide use cases, so if we do that suggestion then DLEP core may loose flexibility as the suggestion (which I understand its purposes) can still be added as extension to core.

Yes, it could exist as an extension only, that was the point of my draft, but I think it might be useful in the core spec.

I agree with you, but I think is was mentioned some where in the draft (not sure).

The draft implies that destinations MUST have a MAC because the destination identifier IS the MAC.

why? does DLEP not cover that issue of link between modems. Each MAC address has one link so it already identifies it.

What if there are multiple routers connected locally to one modem, what is the destination MAC reported at other modems in the radio net?

I think the introduction does clarify that, but maybe not much focus on one item as the destinations because it considers many items together.

DLEP doesn’t do multicast, it talks about multicast, but it still needs some careful review.

The DLEP protocol is that: Each modem has only one DLEP-session to one router.

Not true (anymore).  This was viewed as an unnecessary restriction by the DLEP DT and was planned for removal.  However, if it can’t be handled cleanly, then it might come back.

Lobbying for one of my corner-cases, I would suggest that the Destination Up signal text states something like: "A destination up signal MUST include 1 MAC address TLV or 1 IPv4 address TLV or 1 IPv6 address TLV.

You may say L2 address TLV. However, that may make DLEP not flexible to cover all possible destinations and use cases.

Okay, perhaps I should say: “MUST contain at least one L2 or L3 address TLV”.   I agree with you.

It SHOULD provide a MAC address TLV, and it is RECOMMENDED that at least 1 IPv4 or IPV6 address TLV be included."

DLEP is designed to have MAC addresses, but we can make it L2 addresses to be general.

Yes, that would fit with this proposal.  Currently DLEP uses 48-bit MAC addresses, but it would be nice to use generic L2 addresses, although I’m not sure anyone is intending to use anything apart from Ethernet at layer-2, perhaps Link-16?

We have two kind of DLEP destinations; 1) at L2 , 2) at L3. So DLEP handles multicast addresses of L2 and not L3.

I disagree, DLEP has Destinations.  A destination might be a single endpoint or a multipoint.  The L2 or L3 addresses are just properties of the Destination.

AB

Thanks for reviewing AB!

Rick

Rick

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

---

From: Rick Taylor <[email-masked]>
Date: Sun, 27 Jul 2014 14:56:28 +0000

As I continue my fight with jetlag, I shall summarize my proposal, hoping it is clearer.

All I'm suggesting is not using the remote DLEP router peer's MAC address as the primary key of the destination, but making it a property of the destination, and just using a locally generated number as the primary key.  It's generally viewed as good practice in the database world to do this kind of normalization, and I'm proposing that we do the same with DLEP.

The most obvious complication with this proposal is currently DLEP suggests that routers request metrics for multicast destinations by sending a Neighbour_Up signal to the local modem using the MAC address of the multicast group they are interested in.  Continuing to use this method would require both router and modem to agree a mechanism to generate consistent destination identifiers.  However, I am of the opinion that the MAC method is probably not the best way to handle multicast destinations and should be handled in a different way. 

Also, I happen to know that some people on their first reading of the draft become confused about the use of MAC addresses as identifiers as well as addresses, and think that as a side-effect of my proposal, this confusion might disappear, but I don't consider this alone to be a reason to change the draft.

Regards,
Rick

---

From: Henning Rogge <[email-masked]>
Date: Sun, 27 Jul 2014 17:17:50 +0200

> Also, I happen to know that some people on their first reading of the draft become confused about the use of MAC addresses as identifiers as well as addresses, and think that as a side-effect of my…

So the normal output would have a single MAC address as an attribute?
Or maybe multiple MAC addresses?

And the "L3 DLEP" you suggested would have IP addresses but no MAC
addresses as attributes?

-----------------

I wonder if we should keep this for a DLEP-07 draft... we did a lot of
work for the -06 draft, getting it out would be a real help.

Henning Rogge

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 27 Jul 2014 08:54:51 -0700

> Indeed, but given the TLV includes an explicit length field, I think it just works.

draft says explicitly length=6. Might be worth saying length= what
the length of AC is (currently 6 or 8 are known).

> I don't have a specific use-case for this, but it would allow routers to change MAC during the lifetime of a session.

I don't know a "simple" example of router changing MAC address

But one case i forgot to mention is that a router might have more than one
MAC address. The classical case is HSRP/VRRP where there is an additional
virtual MAC and IP address. Probably worth to discuss in a separate
thread or even draft extension to DLEP if this is of interest, otherwise
this thread becomes too long.

> How the TCP session stays up during a MAC change is beyond my ken however...

TCP should only care about IP addresses, but it might indeed be a
challenge if the network stack on router/modem are "challenged".

> a) L3 only modems (out of scope here).

True. MAC address in multicast destination has no good purpose if
IP is present.

> c) 1 modem talking DLEP to multiple routers (1 destination, N router MACs)

Don't understand that case. DLEP session is TCP, can only go to one router.

> Correct, there must be at least 1 address, L2 or L3.

If we really make DMAC optional for the "normal" case
where there is L2 multicast support on the radio (ARP exists), then
that is indeed true. But i am worried that we very well spec in DLEP
what we expect routers and modems to support:

I don't want that router from Vendor A think they only need to
announce IP address in this "normal" case, and routers from Vendor B
think that they only need to announce DMAC. And they're then surprised
to see destinations that do it differently. And the modems might be
confused either.

The way it stands right now, that the DMAC is mandatory in the "normal"
case and IP optional on top of it is certainly a lot easier guaranteeing
interop.

> I'm not keen on a 'magic number' to mean default destination.  I would rather have a TLV that means "This is the default link for layer2 traffic".  DLEP TLV's are the best way to communicate proper…

Ok, thats fine. So the draft text to explain the identifier would
then say something like the following to explain the identifier:

The identifier solely exists to unique identify a particular destination,
there is no other semantic attached to the identifier.
Using such an identifier permits that no other TLV of a destination is
mandatory because it would need to double-serve as an identifier for the
destination. Every other TLV can therefore also potentially change during
the livetime of the destination. Whether or not specific TLVs are
optional and/or permitted to change is subject to other sections of this
document.

> Hmmm, the ability to have a 'Multicast accessibility TLV' alongside an Address TLV would fit with this identifier model. But the specifics of multicast are better discussed in another thread I thin…

Right. Just trying to find justifications for a separate identifier
that are not just "document nicety". Aka: "default destination",
"multicast capability destination" could be destinations without either
IP nor MAC TLV but with other TLVs indicating their purpose. This
could be IMHO sufficient functional justification for an identifier,
even if for "normal" destinations we figure out that we should always
signal a MAC to make interop easier (see above).

> I would like the concept of destination to have a single consistent meaning for uni/broad/any/multi-cast.  Originally Stan was calling them Neighbours, Radio guys often call them Links, but Destina…

Yes, destinations make sense. So far "special" cases like "default"
and multicast "group/channel" nicely fit under the umbrella of what
people would call a "destination". Lets hope we don't find another
use case where "destination" is not a good word ;-))

> Thanks for your constructive feedback,

Sure.

Cheers
    Toerless

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!

---

From: Rick Taylor <[email-masked]>
Date: Sun, 27 Jul 2014 17:52:59 +0000

Henning,

Yes, the common case would be a single MAC/L2 address TLV per destination as before, but it does open up the possibility of multiple MAC addresses (2 router sessions with 1 modem), or just L3 unicast address or multicast addresses.

As far as accepting or scheduling such a change, the decision is with Stan and the other authors, but I get point about publishing DLEP-06 before cramming in new stuff.

Rick

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 27 July 2014 16:18
To: Rick Taylor
Cc: [email-masked]
Subject: Re: [manet] DLEP proposal

And the "L3 DLEP" you suggested would have IP addresses but no MAC addresses as attributes?

-----------------

I wonder if we should keep this for a DLEP-07 draft... we did a lot of work for the -06 draft, getting it out would be a real help.

Henning Rogge