Subject: [manet] comments and questions on draft-ietf-manet-dlep-02

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 28 Mar 2012 14:16:39 -0700

Stan, below please find some comments and questions on the latest DLEP draft.

   There are two classes
   of sessions - the first is identified as a 'peer session'. The
   peer session exists between a DLEP server and a DLEP client.

I found (also in the R2RI draft) the use of 'peer' to be at odds with what is basically an asymmetric, client/server relationship.  I might suggest to replace 'peer' with 'local'.

   The other type of DLEP session is referred to as a 'neighbor session'.
   Neighbor sessions can be instantiated by either the DLEP server or
   client, and represent an identifiable destination (i.e. an address)
   within the network. Examples of a destination would be a unicast
   address (for either a next-hop router, or for an end-station), or
   a multicast address. A DLEP neighbor session MUST exist for every
   destination that exists in the network.

This description is somewhat unclear.  What are the session endpoints (the remote DLEP router or the local DLEP radio)?  What happens if the MUST is not satisfied?  What is the definition of 'exists in the network' (I think this means the IP link bounded by the DLEP routers, but am not sure).

   The
   unsigned 16-bit Sequence Number rolls over at 65535 to 1.  A
   Sequence Number of 0 is not valid.

Why doesn't the sequence number wrap in the usual way?  Can you please state the reason in the draft, or else align it with RFC 5544?  I saw that Ulrich had the same question (didn't notice a response to it).

   If used, credits are managed on a neighbor session basis; that is,
   separate credit counts are maintained for each neighbor session
   requiring the service. Credits do not apply to DLEP peer sessions.

Why are credits also not applicable to peer sessions (as are the metrics)?  I'm imagining that a broadcast-based radio may want to advertise a credit grant to all reachable radios, not on a neighbor-session basis.

Regarding the credits (new in this draft version), is section 10.7 on the Credit Window Status Sub-TLV also applicable to post-initialization updates?  Some consideration ought to be given to advertising a window rather than (or in addition to) the incremental granting specified, to take away credit previously granted (e.g. to pause the peer).

I agree strongly with Ulrich's suggestion to move the elements of procedure (message processing rules) out of the appendix and into normative text such as done in RFC 6130.  Some of the specification on message processing seems to be also embedded in the TLV and message descriptions at the moment.  I would also recommend consulting RFC 4101 for guidance on how to write the high-level overview of DLEP to start the draft.

- Tom