Subject: [manet] DLEP-17 comments

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Mon, 23 Nov 2015 15:40:27 +0000

Here are a few minor comments on DLEP-17.  It is much improved over the
drafts I saw at the beginning of this year.

-- The IPv4/6 Attached Subnet data item can appear in Destination Up, but
not in Destination Update.  At first I thought this was an omission, but
then I found this in section 10.11:

   As in the case of the IPv4 attached Subnet
   data item above, once an IPv6 attached subnet has been declared, it
   SHALL NOT be withdrawn without withdrawing the destination (via the
   Destination Down message (Section 9.11) and re-issuing the
   Destination Up message.

Why have this restriction?  It seems odd for this data item to have
different behavior than all of the other similar ones.

If the restriction is kept, then the definition of the data item may need
adjusting.  The flags field indicates "whether this is a new or existing
subnet address (1), or a withdrawal of a subnet address (0)," but the
above paragraph rules out the possibility of withdrawal.  So this is an
option that can never be exercised, which is confusing.  Perhaps you can
keep the flags field for future extensibility, but just not define any
flags for now.

-- When the session initialization handshake completes, it seems like a
good idea for the protocol to require each peer to send all of its
currently-up destinations to the other peer.  If they don't, the protocol
can get into an endless cycle of terminating and re-establishing the
session (we have seen this):

Peer A and B start a session
Peer A sends Destination Up X to B
something happens to terminate the session (some other error, for example)
Peer A and B restart the session
Peer A sends Destination UpDATE X to B
Peer B terminates the session because it's never heard of destination X

Peer A and B restart the session...

Peer A made a mistake by sending an Update before an Up.  Requiring a
database dump of all existing destinations to your new peer avoids this
mistake.  You could instead track which destinations you've send to each
peer, and make sure that any Update is preceded by Up, but that
complicates the implementation.  Anyway, your peer probably needs to know
the state of your world up front.  If you're not telling a peer about a
known destination, it seems likely that routing is not going to work as
you expect.

--Remove the normative reference to the credit windowing extension if this
really gates progress on DLEP.

Hope this helps.

David

---

From: Rick Taylor <[email-masked]>
Date: Mon, 23 Nov 2015 16:05:46 +0000

Thank you very much for the review David,

Some comments inline...

> keep the flags field for future extensibility, but just not define any

I believe you have found some legacy text.  The restriction is not 
supposed to be there any more, hence the Add/Drop indicator.  I will 
correct the text.

> known destination, it seems likely that routing is not going to work as

This is a very good point.  I have always assumed that an implementation 
dumps its destination state after session initialization, as the rules 
specify that one cannot have an Update without a prior Up on a session. 
  I will double check the text to see if there is a good place to 
clarify this.

> really gates progress on DLEP.

We would like both drafts to progress in lock-step unless the WG really 
doesn't want to.

> Hope this helps.

Yes it does!

Rick