Subject: [manet] DLEP question

From: Lou Berger <[email-masked]>
Date: Tue, 21 Jun 2016 18:46:31 -0400

Hi,

    Please excuse me if we already covered this ground and have
forgotten the answers.  I have two questions on DLEP:

1) How does a router correlate a received Destination Announce Response
Message (sent by a modem) to its Destination Announce Message? 

- A possible answer is it, doesn't; but then why have a Status data item?

2) Shouldn't a Destination Announce Response Message include the same
optional parameters as a Destination Up message? (Notably absent are IP
addresses and subnets).

- If omission is intentional, how does router provide reachable address
and prefix information? (A required subsequent Update? - yuch!)

Thanks,

Lou

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Tue, 21 Jun 2016 23:55:46 +0000

Lou, 

1. The request/response is correlated, since only 1 transaction can be outstanding (the transaction model fixes it for us). 

2.  The Announce message does include IPv4 and IPv6 Address data items (Section 9.13, 5th paragraph). You are correct that the Dest Announce doesn't currently include the IPv4/IPv6 Attached Subnet data items. TBH, I don't remember if that was intentional or not - I know the discussion went on for a long time about whether the attached subnet TLVs effectively made DLEP a routing protocol. IIRC, because of that, there were iterations where the Attached Subnet items were included, and ones where it was removed. I just don't remember where we finally landed. As for allowing other data items on Destination Announce (like the same data items that are on Destination Up/Destination Update), the rationale was that allowing a router to send metrics *to* the modem didn't make a whole lot of sense - no one was sure what the modem would do with those metrics. 

Regards,
Stan

> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]]
> Sent: Tuesday, June 21, 2016 6:47 PM
> To: [email-masked]; MANET IETF <[email-masked]>
> Subject: DLEP question
> 
> 
> Hi,
> 
>     Please excuse me if we already covered this ground and have forgotten
> the answers.  I have two questions on DLEP:
> 
> - If omission is intentional, how does router provide reachable address and
> prefix information? (A required subsequent Update? - yuch!)
> 
> Thanks,
> 
> Lou
> 
> 
> 

_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________

---

From: Lou Berger <[email-masked]>
Date: Tue, 21 Jun 2016 20:26:22 -0400

Hi Stan,

Thanks for the quick response.

> 1. The request/response is correlated, since only 1 transaction can be outstanding (the transaction model fixes it for us). 
umm, the doc says:

   Only one request per
   destination may be in progress at a time per session.

As a Destination Announce Message relates to a single destination, can't
an implementation send multiple of these in parallel?  If not, where
does the document say this?

>
> 2.  The Announce message does include IPv4 and IPv6 Address data items (Section 9.13, 5th paragraph). You are correct that the Dest Announce doesn't currently include the IPv4/IPv6 Attached Subnet data items.
My question what the router sends, i.e., the Destination Announce
Response Message.

>  TBH, I don't remember if that was intentional or not - I know the discussion went on for a long time about whether the attached subnet TLVs effectively made DLEP a routing protocol. IIRC, because of that, there were iterations where the Attached Subnet items were included, and ones where it was removed. I just don't remember where we finally landed. As for allowing other data items on Destination Announce (like the same data items that are on Destination Up/Destination Update), the rationale was that allowing a router to send metrics *to* the modem didn't make a whole lot of sense - no one was sure what the modem would do with those metrics. 

Again, I'm asking about what the modem sends the router and the
difference in the information provided based on which initiates the
"destination".  In modem initiated, the up includes IP address & prefix,
plus metrics; while in the Destination Announce Response Message only
metrics are provided -- yet the same action is expected, i.e.,:

   the router should add knowledge of the available destination to its
   information base.

If the same action is expected for the Up and the response, shouldn't
the same info be available?

Thanks,

Lou

PS If so, this is a minor doc fix IMO...

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Wed, 22 Jun 2016 00:35:07 +0000

> Sent: Tuesday, June 21, 2016 8:26 PM
> To: Ratliff, Stanley <[email-masked]>; [email-masked];
> MANET IETF <[email-masked]>
> Subject: Re: DLEP question
> 
> Hi Stan,
> 
> > 1. The request/response is correlated, since only 1 transaction can be
> outstanding (the transaction model fixes it for us).
> umm, the doc says:
> 
>    Only one request per
> As a Destination Announce Message relates to a single destination, can't an
> implementation send multiple of these in parallel?  If not, where does the
> document say this?

Fair point. The doc isn't clear on that topic. 

> 
> >
> > 2.  The Announce message does include IPv4 and IPv6 Address data items
> (Section 9.13, 5th paragraph). You are correct that the Dest Announce
> doesn't currently include the IPv4/IPv6 Attached Subnet data items.
> >  TBH, I don't remember if that was intentional or not - I know the discussion
> went on for a long time about whether the attached subnet TLVs effectively
> made DLEP a routing protocol. IIRC, because of that, there were iterations
> where the Attached Subnet items were included, and ones where it was
> removed. I just don't remember where we finally landed. As for allowing
> other data items on Destination Announce (like the same data items that are
> on Destination Up/Destination Update), the rationale was that allowing a
> router to send metrics *to* the modem didn't make a whole lot of sense - no
> one was sure what the modem would do with those metrics.
> 
> "destination".  In modem initiated, the up includes IP address & prefix, plus
> metrics; while in the Destination Announce Response Message only metrics
> are provided -- yet the same action is expected, i.e.,:
> 
> If the same action is expected for the Up and the response, shouldn't the
> same info be available?

Ahh, I understand now. Yes, I agree - metrics should be allowed on the response. I'm still not clear on the Attached Subnet TLVs - if a router says "I found the following destination", does it make sense for the modem to respond "Yeah, and I've got the following subnets attached to it"? What would a router do with a Destination Announce Response that has subnet info attached to it? 

Regards,
Stan

> >> 1) How does a router correlate a received Destination Announce
> >> Response Message (sent by a modem) to its Destination Announce
> Message?
> >>
> >> optional parameters as a Destination Up message? (Notably absent are
> >> IP addresses and subnets).
> >>
> >> - If omission is intentional, how does router provide reachable
> >> address and prefix information? (A required subsequent Update? -
> >> yuch!)
> >>
> >> Thanks,
> >>
> >> Lou
> >>
> >>
> >>
> >
> > information from iDirect, which may be privileged, proprietary and/or
> > confidential. It is intended solely for the use of the individual or
> > entity to whom they are addressed. If you are not the original
> > intended recipient, be advised that you have received this email in
> > error, and that any use, dissemination, forwarding, printing, or
> > copying of this email is strictly prohibited. If you received this
> > email in error, please delete it and immediately notify the sender.

---

From: Lou Berger <[email-masked]>
Date: Tue, 21 Jun 2016 21:43:46 -0400

Stan,

On June 21, 2016 8:35:34 PM "Ratliff, Stanley" <[email-masked]> wrote:

> Ahh, I understand now. Yes, I agree - metrics should be allowed on the 
> response. I'm still not clear on the Attached Subnet TLVs - if a router 
> says "I found the following destination", does it make sense for the modem 
> to respond "Yeah, and I've got the following subnets attached to it"? What 
> would a router do with a Destination Announce Response that has subnet info 
> attached to it?
>

Perhaps a misunderstanding the intent  of the message, but I see the 
destination announce message as basically a query to trigger an up message. 
So I think a router would do the same thing that it does when it receives 
an up with a subnet. Am I missing something?

Lou

---

From: Henning Rogge <[email-masked]>
Date: Wed, 22 Jun 2016 06:21:10 +0200

> 1. The request/response is correlated, since only 1 transaction can be outstanding (the transaction model fixes it for us).

Wouldn't the ORDER or arrivals for the answers be enough to correlate
them, even with multiple in flight? That is why we switched to TCP
(reliable transport), so we can have multiple messages in flight.

Henning Rogge

---

From: Rick Taylor <[email-masked]>
Date: Wed, 22 Jun 2016 09:11:24 +0000

Hi Lou,

Due to time-zones, I'll add some late comments myself, inline..

> Fair point. The doc isn't clear on that topic.

Yes, this possibly needs more clarification.

But, the Announce Request/Response pair can be matched by the MAC
address included in both, and the *intent* of the transaction model is
to prevent parallel requests for the same MAC (i.e. disallowing
parallel Announces for the same destination)

> > My question what the router sends, i.e., the Destination Announce

The Destination announce is sent by the *router* (Sec 9.13), it's a
"Hey, I need info on this destination" message, and therefore MUST
include MAC, and MAY include IP addresses.

The Destination Announce Response is sent by the *modem* (Sec 9.14),
and is a '"Oh yeah, I can forward stuff to that destination, and the
link metrics are X,Y, and Z"

> > one was sure what the modem would do with those metrics.

It wasn't clear to me at the time of writing that attached subnets made
any sense in the use-case of multicast that Announce was designed to
solve, but I can see no harm in allowing them (as a "MAY contain...")
in the response message.

> >    the router should add knowledge of the available destination to

It's the difference between the modem discovering a unicast neighbour =
Dest_Up; and the router discovering the need (IGMP snooping) for
metrics to a logical (multicast/broadcast) destination =
Dest_Announce. 

Because of the different use-cases the message contents are different,
hence the different messages.  

The 'knowledge' mentioned in the text is the link metrics and
availability status.

> > If the same action is expected for the Up and the response,

No, different use-case.  Each party already has different partial
information, so only the missing information needs to be exchanged.

> Ahh, I understand now. Yes, I agree - metrics should be allowed on
> the response. I'm still not clear on the Attached Subnet TLVs - if a
> router says "I found the following destination", does it make sense
> for the modem to respond "Yeah, and I've got the following subnets
> attached to it"? What would a router do with a Destination Announce
> Response that has subnet info attached to it?

Metrics are already allowed on the response (Sec 9.14).  See above for
my comments on attached subnets.

The Status data item is in the Announce Response so the modem has some
way to say "No, I don't do multicast" or suchlike.

Hope that helps?

Rick

> > > and/or
> > > in
> email
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Lou Berger <[email-masked]>
Date: Wed, 22 Jun 2016 07:36:17 -0400

Hi Rick,

Wrt question 1 - correlation of a router sent announce and the modem
sent response, I missed the mac address in the announce (consistent
formatting wrt data items or bnf would have made it more obvious) --
this answers both the correlation and transaction model questions.  So
no change needed here.

See below for question 2

> Due to time-zones, I'll add some late comments myself, inline..

Hardly late - and certainly helpful.

>> > On 6/21/2016 7:55 PM, Ratliff, Stanley wrote:
.....

>...

While announce may have been targeted at multicast originally, and this
is covered in the 1st paragraph in section 9.13, it also supports the
case where a router previously nacked an Up and is now interested in
hearing about that mac:

   A Destination Announce Message MAY also be sent by a router to
   request information concerning a destination in which it has
   previously declined interest, via the 1 'Not Interested' status code
   in a Destination Up Response Message (Section 9.12), see Table 4, or
   declared as 'down', via the Destination Down Message (Section 9.15).

It's in this case that it would seem that the router would need to hear
the same information as is in the Up message.

> hence the different messages.  

Right, the problem is that both use cases are now supported by announce,
and in the second the information is incomplete.

> way to say "No, I don't do multicast" or suchlike.

I think this is addressed above too.

> Hope that helps?

Yes.  Thank you.
Lou

---

From: Rick Taylor <[email-masked]>
Date: Wed, 22 Jun 2016 13:38:13 +0000

Hi Lou,

Comments inline

> this answers both the correlation and transaction model

Good, I'd hoped not.

> > > > To: Ratliff, Stanley <[email-masked]>; draft-ietf-manet-
> > > > dlep@
> > > > ietf.org;
> > > > > 2.  The Announce message does include IPv4 and IPv6 Address
> > > > > data
> > > > > items
> > > > >  TBH, I don't remember if that was intentional or not - I
> > > > > know
> > > > > the discussion
> > > > where the Attached Subnet items were included, and ones where
> > > > it
> > > > was
> > > > other data items on Destination Announce (like the same data
> > > > items
> > > > that are
> > > > router to send metrics *to* the modem didn't make a whole lot
> > > > of
> > > > sense - no

I disagree, if the router is using Destination Announce to request the
resumption of Destination Updates concerning a Destination it *already*
knows about, we decided it was best to only provide the mutable (link)
information in the response.  

However, comparing Destination Announce Response with the Destination
Update message, it could be argued IP address is mutable; but I suggest
that in the (expected to be unlikely) case that a Destination has
changed IP addresses (and remained up) between a router sending a 'shut
up' Destination Down and a later 'resume' Destination Announce, an
extra Destination Update is all it takes to update the router, and this
applies to Attached Subnets as well.

I think we may be arguing over two different ways of providing the same
functionality, and I believe Stan and I are both in the "many small
messages with few options" camp, rather than the "one big message with
all options" camp.

> > > > "destination".  In modem initiated, the up includes IP address
> > > > &
> > > > prefix, plus
> > > > metrics; while in the Destination Announce Response Message
> > > > only
> > > > metrics
> > > >    the router should add knowledge of the available destination
> > > > to
> > > > its
> > > >    information base.

No, sorry, I disagree, they are different use-cases.

> I think this is addressed above too.

Excellent!

Cheers,

Rick

> > > > > > - A possible answer is it, doesn't; but then why have a
> > > > > > Status
> > > > > > data item?
> > > > > > 
> > > > > > 2) Shouldn't a Destination Announce Response Message
> > > > > > include
> > > > > > the same
> > > > > > address and prefix information? (A required subsequent
> > > > > > Update?
> > > > > > -
> > > > > > yuch!)
> > > > > > 
> > > > > > Thanks,
> > > > > > 
> > > > > > Lou
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > confidential. It is intended solely for the use of the
> > > > > individual
> > > > > or
> > > > > recipient or the person responsible for delivering the email
> > > > > to
> > > > > the

---

From: Lou Berger <[email-masked]>
Date: Wed, 22 Jun 2016 15:24:35 -0400

Rick,

see below.

> information in the response.  
this works for IP addresses, but not subnets -- as I read the spec.

> applies to Attached Subnets as well.
this means that you assume a router maintains state for a destination it
is *not* tracking????  This isn't stated in the spec, nor do I think it
is particularly obvious.

> functionality,
I agree, but read the spec as saying that an announce response needs to
be followed by the modem sending a destination update to provide the
latest IP information.  This should be clarified IMO, or the requirement
for a router to store state even for destinations which it rejects --
but honestly think this makes little sense.

>  and I believe Stan and I are both in the "many small

Sure, but in this case I personally would have just had a destination
announce trigger a destination up...

> No, sorry, I disagree, they are different use-cases.

I'm sorry, I just don't see how IP addresses and subnets are covered in
the 'now interested' case based on the current document.  I think there
is at a minimum some (minor) clarifications / changes to the doc to
clear this up, which should be doable before the next step, i.e., IETF
last call.

Thanks,
Lou

---

From: Rick Taylor <[email-masked]>
Date: Thu, 23 Jun 2016 09:10:41 +0000

Lou,

Comments inline...

On Wed, 2016-06-22 at 15:24 -0400, Lou Berger wrote:
> > > > > > (Section 9.13, 5th paragraph). You are correct that the
> > > > > > Dest
> > > > > > Announce
> > > > > > doesn't currently include the IPv4/IPv6 Attached Subnet
> > > > > > data
> > > > > > items.
> > > > > > went on for a long time about whether the attached subnet
> > > > > > TLVs
> > > > > > effectively
> > > > > > made DLEP a routing protocol. IIRC, because of that, there
> > > > > > were
> > > > > > iterations
> > > > > > removed. I just don't remember where we finally landed. As
> > > > > > for
> > > > > > allowing
> > > > > > on Destination Up/Destination Update), the rationale was
> > > > > > that
> > > > > > allowing a
> > > > It wasn't clear to me at the time of writing that attached
> > > > subnets
> > > > made
> > > > any sense in the use-case of multicast that Announce was
> > > > designed
> > > > to
> > > While announce may have been targeted at multicast originally,
> > > and
> > > this
> > >    previously declined interest, via the 1 'Not Interested'
> > > status
> > > code
> > >    in a Destination Up Response Message (Section 9.12), see Table
> > > 4,
> > > or
> > > It's in this case that it would seem that the router would need
> > > to
> > > hear

No, only in the case when a router refuses a Destination Up *and* wants
to resume information about it later, it probably should, but this is
an implementation detail.

> announce trigger a destination up...

But a Destination Up has no Status Code (as it's a request not a
response) and you end up with lots of if's and excepts about re-using a
request message for a response under some circumstances.  It is our
considered opinion that a separate message is cleaner.

> > > > > > difference in the information provided based on which
> > > > > > initiates
> > > > > > the

The 'not-interested' use-case is when a router wants to avoid being
blasted with updates about links to destinations that it is not
currently using.  The router knows the link was there at some point,
and can resume updates (or test its presence) by just issuing a Dest
Announce when it does care.

However, adding optional IP address/subnet information to the announce
response is a minor change, and may cover a use-case we have not
considered, and aligns the content with Destination Update. 

We will most likely be issuing an update to take onboard the AD
comments we have received, so we have a good opportunity to address
this.

Thanks for really having a good look at the doc!

Rick

---

From: Lou Berger <[email-masked]>
Date: Thu, 23 Jun 2016 07:04:04 -0400

Rick,
the proposed change will resolve my comment/concern.

Thank you,
Lou

On June 23, 2016 5:11:59 AM Rick Taylor <[email-masked]> wrote:
...