Subject: Re: [manet] DLEP/satellite - default destination

From: Toerless Eckert <[email-masked]>
Date: Fri, 25 Jul 2014 04:40:00 -0700

Point 2: I am assuming the Satellite network is supporting ethetnet
multicast/broadcast. If the DLEP modems of spokes do not indicate
all other spokes as destinations with their MAC and IP addresses,
then the spoke routers need to just do normal ARP.

Now hub and spoe routers run some IGP. And the IGP has some hellos.
And hellos from 2000 spokes are a relevant upstream bandwidth cost.
Would actually be nice to have an actual example calculation what
percentage of upstream bandwidth cost we are talking about.

So, DLEP to the rescue. But without DLEP having to indicate all
hub & spokes as destinations with MAC and IP.  So... what is the logic:

Hub and spokes send hellos very infrequently an use DLEP as an
indication for the neighbors to be still alive. For the spokes we
introduce one new magic DLEP destination to indicate "all neighbors are
alive" because it simplifies the life of the RF network operator that
ould otherwise have to do more provisioning such as eg: hub router MAC
address provisioning into spoke modems. Or incurring a longer
startup time to dynamically signal this to spoke modems via RF magic.

And the question is now just how to encode that magic destination in
DLEP. MAC broadcast may not be ideal, but maybe some othrer
magic DMAC. All 0 ?.

Is this correctly summarizing the ask ?

---

From: Henning Rogge <[email-masked]>
Date: Fri, 25 Jul 2014 14:53:22 +0200

> DLEP. MAC broadcast may not be ideal, but maybe some othrer

If the Hub end of the satellite link is connected to a switch (a few
routers), how does this magic ethernet thing work? Or is the
"destination Mac" completely optimized away and "regenerated" at the
Hub?

Henning Rogge

---

From: "Snyder, Brian" <[email-masked]>
Date: Fri, 25 Jul 2014 14:04:08 +0000

I would expect (ideally) the hello timers on the inroute are rather high and the therefore the hello timer from the one upstream router (that is advertising on the outroute) to be fairly low.  So mostly all sessions will get establshied based on seeing the every couple seconds hello from the outroute.  Convergence will then kick off - but that has to happen anyway so there is no 'extra cost' or way to minimize that (and should be fairly infrequent anyway).  So yes I think you summarized my main ask - have some way (special mac or tlv) to signify to a router that this dlep session is a 'default route' and just go ahead and act normally.... arp for a configured unicast router or send -or- receive a multicast hello via an IGP.

brian

-----Original Message-----
From: Toerless Eckert [mailto:[email-masked]] 
Sent: Friday, July 25, 2014 7:40 AM
To: Snyder, Brian
Cc: [email-masked]; Stan Ratliff (sratliff)
Subject: Re: [manet] DLEP/satellite - default destination

Point 2: I am assuming the Satellite network is supporting ethetnet multicast/broadcast. If the DLEP modems of spokes do not indicate all other spokes as destinations with their MAC and IP addresses, then the spoke routers need to just do normal ARP.

Now hub and spoe routers run some IGP. And the IGP has some hellos.
And hellos from 2000 spokes are a relevant upstream bandwidth cost.
Would actually be nice to have an actual example calculation what percentage of upstream bandwidth cost we are talking about.

So, DLEP to the rescue. But without DLEP having to indicate all hub & spokes as destinations with MAC and IP.  So... what is the logic:

Hub and spokes send hellos very infrequently an use DLEP as an indication for the neighbors to be still alive. For the spokes we introduce one new magic DLEP destination to indicate "all neighbors are alive" because it simplifies the life of the RF network operator that ould otherwise have to do more provisioning such as eg: hub router MAC address provisioning into spoke modems. Or incurring a longer startup time to dynamically signal this to spoke modems via RF magic.

And the question is now just how to encode that magic destination in DLEP. MAC broadcast may not be ideal, but maybe some othrer magic DMAC. All 0 ?.

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 25 Jul 2014 16:25:18 +0000

Again, I'm completely and totally confused by this entire thread. 

For purposes of a DLEP discussion, I fail to see why the spoke side of SATCOM is nothing more than a subset of MESH. Essentially, it's a mesh with 1 destination - the hub. In an earlier email on this thread, the claim was made that DLEP wasn't designed for this case - I disagree. I think it will work just fine. 

Regards,
Stan

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Fri, 25 Jul 2014 10:18:22 -0700

> For purposes of a DLEP discussion, I fail to see why the spoke side of SATCOM is nothing more than a subset of MESH. Essentially, it's a mesh with 1 destination - the hub. In an earlier email on th…

I don't think that claim is valid, so lets assume we have moved beyond that. 

Yes, DLEP would work just fine, except that Bryan is claiming the following:

If the spoke modems where to support indicating the correct MAC address of the
hub router in the DLEP destination, then this would have one or two of the following
downsides for the customer:

1) The operator of the SAT solution might need to manually provision the hub router
   MAC into the spoke modems, so that the modem can be lightweight and immediately
   announce that statically configured MAC in the destination as soon as it sees the
   RF being up. Aka: downside Opex overhead.

2) The hub side equipment would need to dynamically signal the hub router MAC
   address via RF protocols, and that would have to happen after the RF to the
   spoke is up and running, and that would increase the time until the spoke modem
   could announce that destination in DLEP and therefore make the bringup of the
   spoke slower. Aka: downside convergence speed.

I am leaving out the argument "doing 2) would be more work for the modem vendor",
because the proposed default-destination would be more work for the router vendor,
and just shifting dev work in either direction doesn't seem to be a relevant customer
benefit or downside, so not a good criteria. I may be wrong on that, so if there
is a difference for the customer, we might consider this aspect too.

Bryan: Is this summarizing it correctly ? Am i forgetting something ?

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 25 Jul 2014 10:25:03 -0700

Henning:

The DMAC used in the default destination DLEP announcement is a special value
by which the router recognizes this to be a special destination. The router would
not use this MAC address in actual data packets as a destination MAC address.
Instead, it would solely use it to detect RF failure: When the default destination
is withdrawn, then the router would have to immediately consider all actual
destinations unreachable.

This behavior would not change in the face of multiple headend device/routers.
The spoke router would only learn about hub routers via their IGP hellos, and
he would consider any hub router only reachable when the hub routers hello
packets hae not timed out AND when he default-destination is announced.

What the default destination does NOT help with - i think - is when there are
two hub routers, and one of them goes offline. The spoke modem could of course
not withdraf the default destination from DLEP. At best, the spoke modems could
withdraw the default destination when the hub modem has no active DLEP session
at all, aka: all hub routers down/unreachable.

Hopefully Brian can chime in an reaffirm or reject that this is how he
thinks this could work.

Cheers
    Toerless

---

From: "Snyder, Brian" <[email-masked]>
Date: Mon, 28 Jul 2014 13:58:36 +0000

Toerless , all,

>The DMAC used in the default destination DLEP announcement is a special value by which the router recognizes this to be a >special destination. The router would not use this MAC address in actual data packets as a destination MAC address.

So this speaks to what Rick was saying about why even tie this id to a MAC address then... If we just consider it some unique discriminator id (like bfd) then it can help simplify the model here, at least in my mind.  Furthermore if this 'ID' isn't actually used by any of the routers - couldn't I just make it up?  Whats to stop me from picking any locally generated # that I want too - so long as I am guaranteed the router doesn't actually try and use it instead of ARP, then my concerns get diluted - because I don't have to start saving and tracking MACs I otherwise wouldn't care about - and I can stay more transparent - with no OAM operator overhead also... no?

At least in my use case, I am not so concerned with tracking multiple routers at all - I am concerned with optimally passing on RF link state information to assist the routers in optimally converging L3 tables with regards to timing and overhead.  If a router dies but the RF is fine - I would expect the routers to figure that out themselves.  If I can assist that convergence I would consider it - but I view that as much less of a likely issue in sat networks then RF troubles.

Brian

-----Original Message-----
From: Toerless Eckert [mailto:[email-masked]] 
Sent: Friday, July 25, 2014 1:25 PM
To: Henning Rogge
Cc: Snyder, Brian; [email-masked]; Stan Ratliff (sratliff)
Subject: Re: [manet] DLEP/satellite - default destination

Henning:

The DMAC used in the default destination DLEP announcement is a special value by which the router recognizes this to be a special destination. The router would not use this MAC address in actual data packets as a destination MAC address.
Instead, it would solely use it to detect RF failure: When the default destination is withdrawn, then the router would have to immediately consider all actual destinations unreachable.

This behavior would not change in the face of multiple headend device/routers.
The spoke router would only learn about hub routers via their IGP hellos, and he would consider any hub router only reachable when the hub routers hello packets hae not timed out AND when he default-destination is announced.

What the default destination does NOT help with - i think - is when there are two hub routers, and one of them goes offline. The spoke modem could of course not withdraf the default destination from DLEP. At best, the spoke modems could withdraw the default destination when the hub modem has no active DLEP session at all, aka: all hub routers down/unreachable.

Hopefully Brian can chime in an reaffirm or reject that this is how he thinks this could work.

Cheers
    Toerless

On Fri, Jul 25, 2014 at 02:53:22PM +0200, Henning Rogge wrote:
> > DLEP. MAC broadcast may not be ideal, but maybe some othrer magic 
> > DMAC. All 0 ?.
>

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 28 Jul 2014 07:27:01 -0700

> So this speaks to what Rick was saying about why even tie this id to a MAC address then... If we just consider it some unique discriminator id (like bfd) then it can help simplify the model here, a…

Given how its Ricks idea, i hope it will validate his goal if we try
to interpret it:

-> That ID would be locally generated by the modem to distinguish the
   different destinations it announces and sends to the router via the
   DLEP session. Or vice versa, router to modem.
-> Ultimatly, we would need for the default destination some other TLV
   to indicate that it is a default-destination. 

> At least in my use case, I am not so concerned with tracking multiple routers at all - I am concerned with optimally passing on RF link state information to assist the routers in optimally convergi…

Well, that problem we need to consider beyond the DLEP encoding of
default destination is how routers would choose to detect that a router
on the remote side has failed. If DLEP implements the default location,
do you think deployments would not need the BFD proxy idea anymore ?

Cheers
    Toerless