Subject: [RTG-DIR] RtgDir review: draft-ietf-manet-dlep-14

From: Lou Berger <[email-masked]>
Date: Mon, 08 Jun 2015 15:10:31 -0400

[Note this is a WG LC related review, not IETF LC.]

Hello,

I have been selected as the Routing Directorate reviewer for this
draft. The Routing Directorate seeks to review all routing or
routing-related drafts as they pass through IETF last call and IESG
review, and sometimes on special request -- or WG Last call as was the
case here . The purpose of the review is to provide assistance to the
Routing ADs. For more information about the Routing Directorate, please
see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the (chairs and)
Routing ADs, it would be helpful if you could consider them along with
any other Last Call comments that you receive, and strive to resolve
them through discussion or by updating the draft.

Document: draft-ietf-manet-dlep-14
Reviewer: Lou Berger
Review Date: June 8 (later than requested due to scope of comments -- sorry)
WG LC End Date: unknown
Intended Status: Standards track

Summary:

    While I think the document is pretty decent for the scope of the
    work, I do have concerns about this document and recommend that the
    WG Chairs/Routing ADs discuss these issues further with the authors.
    I'm also available as/if needed to discuss.

Comments:

    I think the document shows significant good work and looks to be a
    useful protocol, although I'm not overly familiar in this space.
    That said, I have a number of serious concerns about the document,
    and its contents from a few of perspectives.  These include basic
    protocol issues, underspecified details  (which could lead to
    interoperability issues), and specification/editorial issues. I
    think the document / protocol can be modified to address the issues
    I raise below.  Of course, it is up to the WG, chairs, and ADs to
    decide which comments to address and which to  ignore. 
    I don't expect that all comments will result in changes.

Major Issues:

    - The length field of the generic data item (i.e., TLV) is only 8
      bits.  While 255 bytes (assuming that this is the unit of measure,
      which BTW isn't specified) is big enough today, allowing for
      larger will greatly simplify things when 255 isn't enough. --
      We've run into this in RSVP and it's a real pain.

    - Version number is currently defined as a data item.  This means a
      signal (i.e., message) needs to be potentially fully parsed to
      discover what version is being used.  This precludes basic format
      changes to the protocol.  Perhaps the Discovery and Init Signals
      should be special cased to include version in their formats.  (And
      shorten version to 8 bits from 32, as mentioned below).

    - The document references, but does not define, 'in-session' and
      'discovery' states.  These either need to be formally defined or
      removed.  BTW we had exactly the same issue with LMP (RFC4204) and
      ended up adding section 11 (FSMs) at a pretty late stage of the
      process.

    - TCP session management is not defined, nor is the relationship
      with TCP and DLEP sessions fully defined.  For example:

      o Closing the TCP session is only mentioned in one place and in a
        way that is inconsistent with the expected protocol behavior
        (close TCP before ACK is received).

      o What happens when a DLEP session is terminated, can the TCP
        session be reused or must it be closed too?

    - There is no transaction model defined.  For example, it's
      completely unclear if only one unacknowledged Signal allowed at a
      time, or perhaps just one per signal type is allowed, or perhaps
      there are no restrictions.  This needs to be explicit.  

    - What is the purpose of retries and timeouts over TCP?  Retries
      aren't needed over TCPs and it's unclear whey they are being used.

    - The higher level implications of ACKs, over TCP, isn't really
      clear.  It seems ACKs are defined for multiple purposes: reliable
      transport, transaction acknowledgment and transaction results. Of
      course the first isn't needed, and implications of the others
      should be clear.  For example, in section 7.10, why would there be
      a retry when receiving a Destination Up ACK signal indicating an
      error?

    - There is no discussion on scaling considerations. Are there really
      none?  For example, how often might be appropriate to issue/limit
      Peer Updates based to changes in link quality, or how to handle
      the case where a large number (all or most) of destinations go
      down.

    - There are 13 places where the protocol allows implementation to
      define their own 'heuristics'.  Some of these seem unnecessary due
      to the TCP point raised above, but any that remain in the protocol
      should be fully specified to ensure predictable/consistent
      behavior from implementations.

    - Data Items are defined for "Extensions" and "Experimental
      Definition" (Sections 8.7 and 8.8).  Both seem to support for
      optional mechanisms, but the former uses assigned numeric values,
      why the latter uses UTF-8 strings.
      o What, if any, is the intended distinction/relationship between
        these?
      o How does an "Experimental Definition" become standardized?

    - Sections 8.19 and 8.20 define "Resources" related Data Items.  The
      definition related to these basically says a resources is "An
      8-bit integer percentage, 0-100, representing the amount of
      resources allocated to receiving|transmitting data.".  If I were
      implementing this protocol, I'd have no idea how to produce,
      update or use this information.  I think there is some missing
      informative and normative (RFC 2119) text related to these
      formats.

    - Sections 8.21 and 8.22 (Relative Link Quality) have a similar
      problem of being under described, in particular it's unclear if
      there's a meaningful, non-proprietary definition for link quality
      that an implementation is to act on or if the passed value is just
      passed for as monitoring information.  Either way, this needs to
      be clarified.

    - Section 9 defines a "credit-windowing scheme analogous to the one
      documented in [RFC5578]". It describes how credits are exchanged,
      but it provides zero definition on the implications or use of
      credits relative to the data plane.   

    - Multiple ways to implement the same function are allowed, e.g.,
      optional presence of Status, Interval and TCP port.  Generally
      allowing such complicates testing and leads to interoperability
      issues.  The document should pick one way and require it.

    - The document doesn't state if there are any ordering requirements
      on data items. It should be explicit on this, e.g., there are no
      ordering requirements on the placement of Data Items within
      Signals.

    - The required and optional data items that are permitted on a
      signal isn't always clear.  For example are 0/1/N copies of a
      particular Data Item required/allowed.  Using something like ABNF
      would really help formalize and clarify this.

    - The document doesn't clearly delineate from informative/narrative
      text, normative / required processing procedures, and message
      formats. This by itself is not necessarily a major issue, it just
      makes it harder to (write,) review and implement the protocol.
      What is a major issue is that this approach allows for duplicate
      (and sometimes contradictory) normative procedures and for
      omissions in procedures (particularly related to exception/error
      processing).  Specific examples are included above and below.  It
      would be best to ensure that each required processing behavior is
      defined just once and in a consistent way.

    - The security consideration section is inadequate.  This section
      should address the security of the DLEP protocol, not user
      traffic.  It should include an analysis of risks/threats/possible
      exploits and how these are mitigated by the protocol.  rfc6952,
      and the protocols it references can serve as examples.

Minor Issues:

    - The data and signal type fields are both 8 bits.  This seems
      pretty small, particularly the data type field.  Given this is a
      control protocol, I think a larger (at least data type) field
      would provide better "future proofing".

    - 2^32 versions are currently allowed (section 8.1).  This seems a
      bit excessive.  I'd opt for max of 8 bits here myself.

    - It's probably too late, but it probably would be cleaner to have a
      generic ack signal rather than a per signal type ack. I mention
      this here as this may come up again when clarifying the
      transaction model (as mentioned above.)

    - Section 2: Assumptions
      This section includes informative and normative text so is more
      than just Assumptions.  Personally, I'd remove all normative text
      from the section.

    - There are no specific rules related to UDP header formation.

    - Sections 8.10->8.17.  Isn't add/drop indicator needed for subnets
      in destination update signals?

    - The IANA Considerations sections must follow​ RFC2360.

    - New registries must include initial values, which are defined in
      the document.  (The document currently has many TBDs that should
      be replaced.)

    - New registries need an allocation policy, e.g.:
    The registry should be established with registration policies of
    "Standards Action" (for Standards Track documents) and
    “Specification Required" (for other documents). The designated
    expert is any current <fill-in> WG chair.

Nits:

    - The document introduces the terms "signals" and "data items" for
      what is commonly called "messages" and "TLVs" (or objects) in
      other protocols.  It's probably too late to change this, but I
      think the introduction of unique terminology is counter
      productive.

    - Use of RFC 2119 conformance language is a bit rough, and there are
      words in all caps that are not defined in RFC2119. Take a look at
      http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuideline for some
      suggestions.

    - Internal socket operation is mentioned a couple of times.  It
      really shouldn't be, the spec should define behavior on the wire.

    - The Length fields are missing unit of measure (presumably octets)

    - The Mnemonics are used basically once and don't really add value,
      suggest dropping them.

    - How/when is the "Unknown Signal" Status Code sent?

    - Section 8.7: Extension List should be shown as a variable length
      field.

    - Section 8.8: Experiment List should be shown as a variable length
      field.

That's it -- for now -- hopefully I didn't miss anything.  Look forward
to hearing response to the above (and how I got things hopelessly wrong ;-)

Lou

---

From: Rick Taylor <[email-masked]>
Date: Tue, 16 Jun 2015 09:00:35 +0000

All,

Stan and I are currently discussing the review.  We will come back to 
the list with a proposed set of actions when we have a plan.

Sorry for the delay,

Rick

On 15/06/15 12:16, Dearlove, Christopher (UK) wrote:
> I haven't seen any discussion of this. It looks to me like requiring another draft for the WG to see. It does (by my rapid count) have 17 major issues.
>
> --
> Christopher Dearlove
> Senior Principal Engineer
> BAE Systems Applied Intelligence
> __________________________________________________________________________
>
> T:  +44 (0)1245 242194  |  E: [email-masked]
>
> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
> www.baesystems.com/ai
> BAE Systems Applied Intelligence Limited
> Registered in England & Wales No: 01337451
> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
>
>
> -----Original Message-----
> From: manet [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: 08 June 2015 20:11
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: [manet] RtgDir review: draft-ietf-manet-dlep-14
>
> ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
> Consider carefully whether you should click on any links, open any attachments or reply.
> Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
> --------------------------------------------------------
>
> I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request -- or WG Last call as was the case here . The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the (chairs and) Routing ADs, it would be helpful if you could consider them along with any other Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.
>
> Review Date: June 8 (later than requested due to scope of comments -- sorry) WG LC End Date: unknown Intended Status: Standards track
>
> Summary:
>
> That's it -- for now -- hopefully I didn't miss anything.  Look forward to hearing response to the above (and how I got things hopelessly wrong ;-)
>
> Lou
>
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: "MATTY, Steven" <[email-masked]>
Date: Thu, 18 Jun 2015 13:02:13 +0000

Hi,

Apologies for hijacking your reply a little Henning, but I thought I could chime
in on a couple of points from a radio vendor point of view!

>My only idea about them would be "battery level"... not sure how
>useful it is to query the radio about this.

Whilst a destination route may be up and currently the preferred choice,
if it's resources are degrading or approaching zero, the router may be
able to make an informed decision to find an alternate route before said
route disappears. This would be preferable to waiting for a heartbeat
timeout.

>It seems the radio vendors really like this field. The reason why we
>made "max/current link speed" mandatory is to make RLQ at least
>reasonable useful.

Yes we do :) Whilst a link may be supporting a given data rate, it
could be running at or near threshold. To prevent unnecessary packet
loss, especially if this is a transient situation it may be preferable for
the router to say "let's choose a more stable link". We might, for instance,
choose reflect Rx Eb/N0 (adjusted to a 0-100 factor). A rapidly degrading
loss of quality can then be picked up the router and again make a decision
about how best to route traffic.

Regards

Steve

This email (including any attachments) may contain confidential
and/or privileged information or information otherwise protected
from disclosure. If you are not the intended recipient, please
notify the sender immediately, do not copy this message or any
attachments and do not use it for any purpose or disclose its
content to any person, but delete this message and any attachments
from your system. Airbus Defence and Space Limited disclaims any and all liability if this email transmission was virus corrupted,
altered or falsified.
-o-
Airbus Defence and Space Limited, Registered in England and Wales No. 2449259
Registered Office:
Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England

---

From: Lou Berger <[email-masked]>
Date: Thu, 18 Jun 2015 17:28:31 -0400

Henning,
    Thanks for the  opinions.  See below for in line response to those
topics that have to do with the review and my intent -- I'm staying away
from "WG/chair/AD" discussion topics.

On 6/18/2015 8:38 AM, Henning Rogge wrote:
> On Mon, Jun 8, 2015 at 9:10 PM, Lou Berger <[email-masked]> wrote:
> Hi...
> I am NOT one of the DLEP authors, but I have been active during the
> design process (some people might say "annoyingly active"), so here
> are my opinions on this review. Hopefully it will be helpful for the
> authors.
>
>> ...

> On the other side the largest data item we have at the moment is 18
> bytes (IPv6 connection point). I am not really seeing lots of
> use-cases for large data items in DLEP.

My experience in the past has been that unknown uses show up later and
make this an issue that needs to be solved by some ugly semantic
fragmentation, so if possible, I think it should be fixed.

> Still, changing the TLV length to 16 bit would be trivial to do... but
> would this mean we also should change the signal length field to 4
> bytes?

I wasn't suggesting this and I don't think so. 2^16 is a pretty big
message.

> Putting it into the UDP based discovery packets as a "header" could
> work... they are a bit special anyways (UDP) and we don't need to
> repeat the version later.

Lots of options here. But recall UDP discovery is optional per current spec.

> I think "discovery phase" is before the TCP connection between radio
> and router is established.

Sure, but the point I was making there's a difference between
unambiguously specifying something that can be independently implemented
by someone not involved in the WG vs a common understanding in the WG
based on discussion while the spec is developed.  The challenge is
ensuring the document (the former) adequately captures the latter.

> Maybe this should be "closing the DLEP session and not using the
> active TCP session anymore" ?
>
> No, I think the DLEP strategy is "start from scratch"... when you
> terminate a DLEP session you go back to the discovery mechanism to
> start a new one.

Whichever reasonable approach is taken it just needs to be explicitly
documented.

> I think we don't need restrictions here because of TCP. The other side
> WILL answer to eachof our signals or the TCP session will be
> terminated.

I don't think TCP helps (or hurts here).  This is a question of what
different implementations will choose to do / support WRT signals of the
same or different types being processed in parallel.

> We want to know when the connection between radio and router is
> lost... this can take a LONG time when the router is mostly listening
> to the Radio (TCP timeout is much to long for our use-case), so we use
> the Heartbeats.

This comment relates to the per signal acks and retries.  I didn't
include the connection failure detection covered by the heartbeat signal
in this comment.

> The DLEP "ACK Signals" are more a response to a "request signal"...
> transaction acknowledgement and result.
>
> Just send as fast as you want and let TCP (buffer) take care of the
> rest... both Destination up/down are small signals, so it shouldn't be
> a problem. 
The assumptions behind this "shouldn't part of this" is what should be
discussed...

> And you are only allowed to send Destination Updates when
> you received the Destination ACK.

Where is this restriction specified?  I don't recall seeing it.

> No comment on this one.
> As far as I understand this "Experimental Definition" is something you
> use in the lab...  you can have a maximum of one experiment for DLEP,
Interesting -- where is this restriction defined?  Section 7.3 says 
that "one or more" are allowed.

> so this is more to make sure your special "work in progress" code does
> not collide too hard with a standard radio/router.
It's pretty unclear from the spec how experimental definitions are to be
used -- or if they belong in standards track document at all.

> On the other side you can support as many "Extensions" as you want...
> and I expect this WG to standardize a few additional of them after
> DLEP becomes a RFC.
okay, look forward to seeing an IANA allocation policy for these.

> useful it is to query the radio about this.

some context would be great.  -- sounds like its akin to a routing metric.

> made "max/current link speed" mandatory is to make RLQ at least
same comment.
> No comment on this one.
> I think "no status TLV" is always "everything is fine"...
>
> I think is exactly as most (all?) of us have implemented it... no
> ordering required.

Cool, then this is just a simple matter of documenting "what everyone
implements".

> Can you give an example where this is undefined? As far as I can see
> the draft explicitly states what and how often you can use TLVs per
> signal.

I think the experimental data item discussion above is a perfect
example.  You though only one is allowed the spec is vague in section
8.8 and explicit in 7.3.  -- Narrative lacks precision and is easily
misread.  Something like ABNF is far more transparent.

> DLEP is only on the local ethernet connection between the radio and
> the router... it is NOT spoken between different router/radio
> components of a network. RFC6952 is talking about securing
> communication over the routed network.

This is a scoping of the problem that should go into a security the
section.   RFC4204 covers a similar scoped protocol, although it's
security considerations section is quite dated.

> So you would like to move BOTH the type and the length fields of the
> TLVs to 16 bit?
I'd probably enlarge data items and leave signal type alone. 
Alternatively you can plan to do something ugly down the road, like type
255 means look in value field for an extended type field - yuck.

> Most likely 8 bits are enough, especially because I would expect the
> version number to become "fixed" after the RFC release.
That would be great.

> could be... but I am not sure about the advantage of moving the "ack
> type" into a TLV.
This would be a really major change at this juncture, as this is a
"minor comment" I didn't really expect for it to be changed at this late
date -- so no need to debate.

> UDP header formation?
format.  I.e., what addresses and ports must be used.

> I think we talked about this and the reason was that subnets are only
> as "fixed settings" supported.
I'm sorry I don't understand your response.  Are you saying subnet
reconfiguration requires a session reset?

>>     - The IANA Considerations sections must follow RFC2360.
> I didn't know about this, I have always seen Drafts with TBDx...

TBD is right for existing registries.  For new registries IANA doesn't
have any policies or guidance.  This comes from the document that
establish the registries, i.e, this one.
 
> Not sure what you mean...
This is a specification of behavior "on the wire" .  It should be
possible to implement in an OS that doesn't implement sockets but
properly conforms to the spec.

> Yes, octets.
> I would guess attached to a "Peer Termination" Signal... the other
> side sent us something we don't understand.
>
> You mean a "..." in the ascii art?
yes.

> Henning Rogge

Thanks!

Lou

---

From: Rick Taylor <[email-masked]>
Date: Mon, 22 Jun 2015 11:00:07 +0000

Hi,

Just adding some replies inline...

>> are my opinions on this review. Hopefully it will be helpful for the

I am one of the authors, and I'll try to help clarify why we have gone
the direction we have.

> I wasn't suggesting this and I don't think so. 2^16 is a pretty big

There is nothing stopping an extension of the data item length to 2^16
octets, but as Henning pointed out, that would suggest an increase of
the signal length field to 2^32 (as signals 'contain' data items).

The reason we haven't gone for 2^16 currently are:

1) We have no data items > ~20 octets.

2) We wanted to keep the data items and signals 'short and sweet' in
form. An implementation could use small stack allocated buffers in
embedded hardware rather than worrying about bigger blocks of memory.

But: Adding big data items later would be more difficult.

Note: There is no 'bits on the wire' performance concerns here, DLEP is
over the local link.

There is a third way:  If the length field in the signal is replaced
with a count field, then both can be kept at 16 bits, but it makes
parsing more complicated.

Can I ask for some +1/-1's from the list on this one please?  It is not
a major change to the document.

> Lots of options here. But recall UDP discovery is optional per current spec.

I see no problem with shortening version to 16 bits (major octet, minor
octet)  I never want to see DLEP version 65538.0!

I see the point of holding the version number at a fixed offset in the
initial messages of the protocol, and it is something we can definitely
do for the UDP discovery messages, as Henning pointed out, they are
special anyway.

I am loathe to do it to the Initialization signals, as it adds special
case code and text.  I think it is okay to allow an implementation *not*
using discovery to expect a process on the reserved address/port
combination to be using some version of DLEP, as long as later DLEP
versions ensure back compatibility.

> ensuring the document (the former) adequately captures the latter.

Fair point.  We will revisit the text about states.

> Whichever reasonable approach is taken it just needs to be explicitly

We favour a start from scratch approach.  But it does need to explicitly
stated somewhere.

> same or different types being processed in parallel.

Particularly with the Request signals, there is a weakness in the text
about transactions that needs to be addressed.  This is one of those
areas where those involved early on have a clear idea, but it isn't
clear in the text.

> include the connection failure detection covered by the heartbeat signal

The retries and heartbeats are to detect a failure in the process using
the TCP connection, rather than a failure of the connection itself.
 From experience in the MANET space, complex routers and radios can
crash internally/lose control plane long before the TCP session times out.

>> transaction acknowledgement and result.

ACKs are intended as an processing acknowledgement rather than a receipt
acknowledgement, i.e. "I have done/not done what you asked".

> The assumptions behind this "shouldn't part of this" is what should be

Yes, there is no text about rate limiting updates.  Not from a TCP
datarate perspective, but from a processing perspective.  We don't
really want to predict the performance of processors by stating hard
rules on rate-limiting.

This only applies to Destination_Updates, as everything else is
throttled by waiting for ACKs. (Made clearer when some text on
transactions is put in)

> Where is this restriction specified?  I don't recall seeing it.

It isn't mentioned, but is expected.  The text will have to be improved.
  I think there is a need for a section on transactions.

>>>        behavior from implementations.

As with rate-limiting, this is a can of worms we have intentionally not
opened.  We will have a careful look at every place heuristics are
mentioned and when possible suggest some sensible defaults.

> okay, look forward to seeing an IANA allocation policy for these.

I have covered this in another mail, so I won't repeat. (see Section 11.6)

>> made "max/current link speed" mandatory is to make RLQ at least

The Resources and RLQ metrics are there as DLEP builds upon the work
done in RFC5578.  I have always considered Resources to be some
indication of 'work-load' on the modem rather than explicit battery
level.  Perhaps the descriptive text needs to be expanded.

>>>        credits relative to the data plane.

This is one for Stan.  Credit-windowing is his baby.

>> I think "no status TLV" is always "everything is fine"...

We are currently happy with the way this works.  If an optional data
item is missing, then the default value is used.  This should be
explicitly stated whenever an optional data item can be omitted.

> Cool, then this is just a simple matter of documenting "what everyone

Section 6 states: "There is no restriction on the order of data items
following a signal"

> misread.  Something like ABNF is far more transparent.

Section 6 states: "...the multiplicity of duplicate data items is
defined by the definition of the signal declared by the type in the
signal header."

We have attempted to enumerate the multiplicity of every data item in
each signal.  If we have missed one please point it out.

Section 3.3 states: "Multiple Experimental Definition data items MAY
appear in the Peer Initialization/Peer Initialization ACK sequence."

I have tried to define ABNF, but I struggle with defining the
multiplicity and optional ordering rules, any advice gratefully received.

>>>        defined just once and in a consistent way.

This is a hangover of the major rewrites that have occurred over the
last 14 versions.  Let us have another pass at the text and we can see
what we can do.

> security considerations section is quite dated.

We have done no analysis of a malicious peer in a DLEP session as the
nature of the link-local connectivity made it seem unnecessary.  Are you
suggesting that we need to address this?

> 255 means look in value field for an extended type field - yuck.

See comments above.

>> version number to become "fixed" after the RFC release.

See comments above.

> date -- so no need to debate.

We have debated this before, and the multiple ACKs approach is preferred
by the WG.

> format.  I.e., what addresses and ports must be used.

Does Section 5.1 not cover this?

> reconfiguration requires a session reset?

Subnet reconfiguration requires a session restart.

> establish the registries, i.e, this one.

We shall suggest some values.  Probably from the existing interoperable
implementations.

>>>      "Specification Required" (for other documents). The designated

This is one for Stan.

>>>        productive

TLVs was rejected as a name, as both signals and data items are
Type-Length-Value encoded.  Signals was selected as they are 'events'
rather than RPCs, and it might be a bit late to change the terminology.

>>>        http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuideline for some

We will have another pass.  Can you point out some examples please?

> properly conforms to the spec.

Okay, this can be fixed if we add a section about re-use of the TCP
connection (don't).

>>>      - The Length fields are missing unit of measure (presumably octets)

Yes, octets, will add.

>>>      - The Mnemonics are used basically once and don't really add value,

With the replacement of TBDs with values these should 'boil off'.

>> side sent us something we don't understand.

That was the intention.  I will check the text to make sure this is clear.

>> You mean a "..." in the ascii art?

... will be added.

Hope that helps?

Rick

---

From: Lou Berger <[email-masked]>
Date: Mon, 22 Jun 2015 08:11:43 -0400

I have a really hard time understanding how there could be 2^16 
interoperable versions of anything.  But maybe dlep means something 
different than the norm when refering to versions.

Can you/some explain a use case for more than a few, being really generious 
say 10, version numbers?

Lou

On June 22, 2015 7:25:13 AM Henning Rogge <[email-masked]> wrote:

> On Mon, Jun 22, 2015 at 1:00 PM, Rick Taylor
> <[email-masked]> wrote:
> We could maybe define that both for TCP and UDP the first two bytes
> are a version number... after this we begin decoding signals/tlvs.
>
> This sounds reasonable easy and consistent.
>
> Henning Rogge
>

---

From: Rick Taylor <[email-masked]>
Date: Mon, 22 Jun 2015 12:19:02 +0000

Okay, with a 4bit/4bit split of a single octet, we have 0-15 major 
versions and 0-15 minor versions.

We already have implementations on version 0.14, and with a draft-15 
expected, do you suggest a 3bit/5bit split?  Why not just use 
major.minor 8bits each?  We don't have to worry about bytes over the 
local link.

Cheers,

Rick

---

From: Rick Taylor <[email-masked]>
Date: Mon, 22 Jun 2015 12:25:54 +0000

Oops, misread a bit, comments inline...

>> 255 means look in value field for an extended type field - yuck.

I misread this as length field as 16bit.  I have no problem with a 16bit 
signal/data item id, as it would allow more space for experimental 
assignments.  But, we have yet to use more than 23 ids.

Rick

---

From: Lou Berger <[email-masked]>
Date: Mon, 22 Jun 2015 08:29:05 -0400

On June 22, 2015 8:19:32 AM Rick Taylor <[email-masked]> wrote:

> expected, do you suggest a 3bit/5bit split?

This is in fact a unique (at least in my experience ) usage of version.  
IMO the dlep version for the RFCed version would be 1.

> Why not just use

Yes, but you do need to worry about interoperability.  If the WG really 
wants to go down this path, you'll need some tight text defining how 
versioning and version mismatches are handled.

Lou

---

From: Rick Taylor <[email-masked]>
Date: Mon, 22 Jun 2015 12:36:08 +0000

Comments inline...

>>> This sounds reasonable easy and consistent.

This sounds like a suggestion that the Peer_Init signals should use a 
different header.

Given there are data items that are only used during initialization, 
would people be totally against a different wire format for these 
packets rather than the signal format?

Rick

---

From: Rick Taylor <[email-masked]>
Date: Mon, 22 Jun 2015 12:38:39 +0000

Okay, I see your point - I have spent too long working with FOSS 
software where everything lurks at version 0.97 ;)

If the WG are happy with a single octet of 1 for the final 'first' 
version, then that's good by me.

+1/-1 please people!

Rick

---

From: Rick Taylor <[email-masked]>
Date: Mon, 22 Jun 2015 13:48:26 +0000

On 22/06/15 14:33, Henning Rogge wrote:
> On Mon, Jun 22, 2015 at 2:54 PM, Wiggins, David - 0665 - MITLL
> <[email-masked]> wrote:
>> I read Henning's proposal as being for all signals ("for TCP and UDP...").
>>   Whether that's what he meant or not, I like the consistency and
>> simplicity of just having it in the same place for all signals.
>
> No, not for each signal... once for each incoming "network socket".
>
> So once for the UDP packet (before you give the rest to the signal
> processing code) and once for a TCP stream (before you start
> processing signals).
>
> I would not count them as part of the signals, more like a prefix
> before the signal(s) begin.

I would definitely only want the version numbers once.  In each UDP 
packet, and once on TCP connection start, not on every signal.

The question is, how to I describe that?  Have an extra 1 octet header 
used during initialization?  Once I start writing that, why not expand 
it out to include all those data items only used during initialization?

I'll come back with some ASCII art...

>
>
>
> About the version number thing...
>
> do we really need the "major.minor" version number? We have broken
> compatibility LOTS of times during the "0.x" draft phase, why not use
> a one-byte version number and keep counting up?

I think I'm hearing consensus for a single octet, version 1.

Rick

---

From: Rick Taylor <[email-masked]>
Date: Mon, 22 Jun 2015 14:19:07 +0000

On 22/06/15 14:53, Henning Rogge wrote:
> On Mon, Jun 22, 2015 at 3:48 PM, Rick Taylor
> Agreed... up to 4 times until a DLEP session is completely working...
>
> one in the UDP packets each, and one at the head of the TCP stream (in
> both directions!)
>
> Whats about this?
>>   0                   1                   2                   3
>>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |    Version    | DLEP signal(s) ...                            |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>

That has the advantage of simplicity!

I tried to pack all the Peer_Init data items into a Peer_Init struct and 
it just looked like a standard DLEP signal, but with strict ordering.

Actually, I'm still scratching my head to work out what the problem with 
the current method is:

Byte(0) = Peer_Init/ACK
Bytes(1+2) = Length
Check length for sanity
Scan data items for Version, parse version.

Is the problem that people are worried that the TCP connection they have 
made is not to a DLEP peer that they have a) discovered, or b) 
configured.  Remember this isn't some remote peer that has been met, 
this is locally attached.

If we were discussing a file format, then I can see the advantage of 
having some identifier at a well-known offset, but I'm unconvinced in 
this case.

Rick

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Mon, 22 Jun 2015 12:54:35 +0000

A few comments near the end...

>packets rather than the signal format?

Do you mean having Peer Init and Peer Init Ack would use something other
than data items to express the fields they need?  That seems like a much
larger inconsistency to deal with than having the version number only in
some signals.  I'd rather keep the format of these signals consistent with
the rest.

>Rick

David

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Mon, 22 Jun 2015 12:58:19 +0000

I'm fine with a one byte version with no concept of major/minor.

David

On 6/22/15, 8:38 AM, "Rick Taylor" <[email-masked]> wrote:

>>>>>>> Lots of options here. But recall UDP discovery is optional per
>>>>>>>current
>>> spec.
>>>>>>

---

From: "Wiggins, David - 0665 - MITLL" <[email-masked]>
Date: Mon, 22 Jun 2015 14:53:36 +0000

>That has the advantage of simplicity!

So let me see if I understand this proposal.  In the Peer Discovery and
Peer Offer signals, we'd add the version to the signal header.  When the
TCP connection is made, but before any signals are sent, each side sends
their one-byte version number.  After that, signals do not contain a
version.

If that's right, I count three different ways of handling the version.
The last one is a no-op, but still, different from the others.  I agree
that this would work, but it sure seems simpler to me to just put version
as a fixed part of the signal header of all signals.

David

---

From: Lou Berger <[email-masked]>
Date: Mon, 22 Jun 2015 14:08:20 -0400

Rick,

Thanks for the response.  See below.

> the signal length field to 2^32 (as signals 'contain' data items).

I think both being 2^16 is fine. It just means data items have a length
constraint that is less than the field size.  Nothing unique in that.

> a major change to the document.

My experience is that usage of successful protocols go beyond what's
originally envisioned. So unless the constraint is important I'd "be
liberal" here and go for the larger size.

> We favour a start from scratch approach.  But it does need to explicitly

WFM, just needs to be documented.

> areas where those involved early on have a clear idea, but it isn't

thanks

> crash internally/lose control plane long before the TCP session times out.

Again, this is *not* the point I raised.

> acknowledgement, i.e. "I have done/not done what you asked".
Okay, I think calling them something like responses rather than acks
would clarify this.

And the purpose of retries is???

> throttled by waiting for ACKs. (Made clearer when some text on

Seems like some discussion on this is warranted.

> mentioned and when possible suggest some sensible defaults.

I think this will be an interoperability and conformance testing
nightmare. Also, keep in mind a standard helps users know what they
should expect from an implementation / vendor and this leaves major
behaviors wide open .

> I have covered this in another mail, so I won't repeat. (see Section 11.6)

okay, will go looking for it.

> level.  Perhaps the descriptive text needs to be expanded.

yes, please.

> explicitly stated whenever an optional data item can be omitted.

options make conformance and interoperability testing much harder.  In
general, if they don't serve a specific purpose options *should* be
eliminated.  Too many options have dead-ended protocols in the past.

> Section 6 states: "There is no restriction on the order of data items
Okay missed that.  Certainly for version number this is probably not the
best answer. For everything else, don't really have an opinion.

> multiplicity and optional ordering rules, any advice gratefully received.

I have done far too much ABNF so to me this isn't too hard.  Unicast me
what you have and I'll provide feedback.

> suggesting that we need to address this?

I'm suggesting that the IESG/Security review will block this document
until there is a substantive Security Consideration section.  I've just
pointed to some examples that may help construct one.

...> >
> Does Section 5.1 not cover this?

No. Not every implementation may use sockets.  Also much of the text
relates to TCP socket init.  I think a sentence that says something like:
For the Peer Discovery signals the IP destination address MUST be set to
the DLEP link-local multicast address and port (TBA), there is no
restriction on the UDP source port. For Peer Offer signals the IP
destination address and port MUST be set to the source IP address and
Port contained in the received Peer Discovery signal, the source IP
address and port MUST be set to the DLEP port.  For both signals, the
source IP address MUST be set to the IP address that will be used in
subsequent DLEP TCP connections.

> Subnet reconfiguration requires a session restart.

fine.  this needs to be explicit.

> We shall suggest some values.
Again, whatever for new registries the document defining the registry
*must* define initial values.

>  Probably from the existing interoperable
> implementations.

Makes sense.

> rather than RPCs, and 

I don't follow -- but doesn't really matter as topic seems to be OBE.

>it might be a bit late to change the terminology.

> We will have another pass.  Can you point out some examples please?

Just a few picked at random-- *not* the full list:

Section 3. the first two MUSTs are duplicative, the same requirement is
listed for a third time in the third paragraph with a lower case
"required".  The "OPTION" and "MAY" clauses are duplicative.

Section 4: "DLEP Does NOT specify..."

Section 7.3: "there is NO support"

> Hope that helps?
Yes.  Thanks.

Lou