Subject: [Dots] WGLC signal-18 Draft Hop Limit tidy up

From: "Jon Shallow" <[email-masked]>
Date: Fri, 23 Mar 2018 15:35:11 -0000

Hi there,

I believe that there are a couple of changes required for the hop-limit
definition - see [Jon] inline.

           hop-limit:  This option (see Section 9.4) is used to detect and

              prevent infinite loops.  This option is typically inserted by
a

              DOTS gateway.

              The length of the hop-limit option is 1 byte.

              The value of the hop-limit option is encoded as an unsigned

              integer (see Section 3.2 of [RFC7252]).

              Each intermediate DOTS agent involved in the handling of a
DOTS

              message MUST decrement the hop-limit option value by 1 prior
to

              forwarding upstream if this parameter exists.  DOTS messages
MUST

              NOT be forwarded if the hop-limit option is set to '0' after

              decrement.  Messages that cannot be forwarded because of
exhausted

              hop-limit SHOULD be logged with a 5.06 (Hop Limit Reached)
error

              message sent back to the DOTS peer.  It is RECOMMENDED that
DOTS

              clients and gateways support means to alert administrators
about

              loop errors so that appropriate actions are undertaken.

[Jon] We need to add in something like:-

Each intermediate DOTS agent SHOULD add in the hop-limit option with the
initial default value if it does not exist before forwarding upstream any
information.

[Jon] We need to define the format of the 5.06 CoAP diagnostic message so
that it is potentially parseable by the DOTS client as well as by any other
potential RFC that make use of this 5.06 code.  In addition, it would be
good if each intermediate DOTS agent appended its own IP (prefixed by a
blank) to the end of the diagnostic message as the 5.06 response gets passed
back through the DOST agents to enable troubleshooting at the DOTS client.
The diagnostic message length would need to be restricted to something like
1000 bytes to prevent UDP fragmentation.  Suggestions welcome here.

              The initial hop-limit value SHOULD be configurable.  If no
initial

              value is explicitly provided, the default initial hop-limit
value

              of 16 MUST be used.

              Because forwarding errors may occur if inadequate hop-limit
values

              are used, DOTS agents at the boundaries of an administrative

              domain MAY be instructed to rewrite the value of hop-limit
carried

              in received messages (that is, ignore the value of hop-limit

              received in a message).

              This is an optional option.

[Jon] This should read "This is an optional CoAP Option".

Regards

Jon

---

From: <[email-masked]>
Date: Tue, 27 Mar 2018 08:21:35 +0000

Hi Jon,

Please see inline.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : vendredi 23 mars 2018 16:35
À : [email-masked]
Objet : [Dots] WGLC signal-18 Draft Hop Limit tidy up

Hi there,

I believe that there are a couple of changes required for the hop-limit definition - see [Jon] inline.

           hop-limit:  This option (see Section 9.4) is used to detect and
              prevent infinite loops.  This option is typically inserted by a
              DOTS gateway.

              Each intermediate DOTS agent involved in the handling of a DOTS
              message MUST decrement the hop-limit option value by 1 prior to
              forwarding upstream if this parameter exists.  DOTS messages MUST
              NOT be forwarded if the hop-limit option is set to '0' after
              decrement.  Messages that cannot be forwarded because of exhausted
              hop-limit SHOULD be logged with a 5.06 (Hop Limit Reached) error
              message sent back to the DOTS peer.  It is RECOMMENDED that DOTS
              clients and gateways support means to alert administrators about
              loop errors so that appropriate actions are undertaken.
[Jon] We need to add in something like:-
Each intermediate DOTS agent SHOULD add in the hop-limit option with the initial default value if it does not exist before forwarding upstream any information.

[Med] I'm not sure to understand this one. Please note that the text says "A DOTS gateway may add the following CoAP option". This is typically a GW which is instructed to insert the option will inject the option and follows the setting of the initial value.

[Jon] We need to define the format of the 5.06 CoAP diagnostic message so that it is potentially parseable by the DOTS client as well as by any other potential RFC that make use of this 5.06 code.  In addition, it would be good if each intermediate DOTS agent appended its own IP (prefixed by a blank) to the end of the diagnostic message as the 5.06 response gets passed back through the DOST agents to enable troubleshooting at the DOTS client.  The diagnostic message length would need to be restricted to something like 1000 bytes to prevent UDP fragmentation.  Suggestions welcome here.

[Med] I can see a value in recording the list of GWs involved in a loop for debugging purposes at the DOTS server domain, but I'm not sure there is a value to pass that list to the DOTS client. For example, a server domain may want to hide its internal topology (list of GWs and servers involved in handling a mitigation request). Below a  text proposal for discussion:

      To ease debugging and troubleshooting, the DOTS gateway which
      detects a loop SHOULD include its information (e.g., server name,
      alias, IP address) in the diagnostic payload under the conditions
      detailed in Section 5.5.2 of [RFC7252].  Each intermediate DOTS
      gateway involved in relaying a 5.06 (Hop Limit Reached) error
      message SHOULD prepend its own information in the diagnostic
      payload with a space character used as separator.  The ultimate
      DOTS gateway SHOULD remove the diagnostic payload before
      forwarding the 5.06 (Hop Limit Reached) error message to a DOTS
      client domain.

              The initial hop-limit value SHOULD be configurable.  If no initial
              value is explicitly provided, the default initial hop-limit value
              of 16 MUST be used.

              Because forwarding errors may occur if inadequate hop-limit values
              are used, DOTS agents at the boundaries of an administrative
              domain MAY be instructed to rewrite the value of hop-limit carried
              in received messages (that is, ignore the value of hop-limit
              received in a message).

[Med] I can make the change. Please note that the text starts with "A DOTS gateway may add the following CoAP option" which is clear enough this is about an optional CoAP option.

Regards

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 27 Mar 2018 13:34:57 +0100

Hi Med,

See inline [Jon1]

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of
[email-masked]
Sent: 27 March 2018 09:22
To: Jon Shallow; [email-masked]
Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up

Hi Jon, 

Please see inline. 

Cheers,

Med

Hi there,

I believe that there are a couple of changes required for the hop-limit
definition – see [Jon] inline.

              DOTS gateway.

[Med] I’m not sure to understand this one. Please note that the text says “A
DOTS gateway may add the following CoAP option”. This is typically a GW
which is instructed to insert the option will inject the option and follows
the setting of the initial value.

[Jon1] I guess that I am trying to differentiate between updating an
existing Hop-Limit and not injecting a new one alongside a previous one.
Having multiple Hop-Limit options could get interesting!

[Med] I can see a value in recording the list of GWs involved in a loop for
debugging purposes at the DOTS server domain, but I’m not sure there is a
value to pass that list to the DOTS client. For example, a server domain may
want to hide its internal topology (list of GWs and servers involved in
handling a mitigation request). Below a  text proposal for discussion:

      client domain.

[Jon1] I have no issues if a server domain really wants to strip out its
internal hops – but troubleshooting is more of a challenge and would not
recommend it.

[Jon1] However, when setting up a DOTS client, which is failing to work for
whatever reason, it would be good to have a reasonable level of diagnostics
on the Client – separately invoking someone to look at a DOTS server’s logs
may take time to get responded to – and you as a novice DOTS client user
will have no idea as to what to tell the DOTS server guy to look for in the
server’s busy logs.

[Jon1] I would also like the structure of the diagnostic message to be well
formatted (e.g., no leading text, only one of server name / alias / IP
address, blank separator etc.) so it can easily be documented in user
manuals etc. as well as perhaps parsed by a receiver of the 5.06 message
(interim hop or final destination).  All other responses (albeit in cbor)
are pretty well documented.

              of 16 MUST be used.

              received in a message).

[Jon] This should read “This is an optional CoAP Option”.

[Med] I can make the change. Please note that the text starts with “A DOTS
gateway may add the following CoAP option” which is clear enough this is
about an optional CoAP option.

[Jon1] I guess I am being picky!

~jon1

Regards

Jon

---

From: <[email-masked]>
Date: Tue, 27 Mar 2018 14:13:58 +0000

Re-,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 27 mars 2018 14:35
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up

Hi Med,

See inline [Jon1]

Regards

Jon

From: Dots [mailto: [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 27 March 2018 09:22
To: Jon Shallow; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up

Hi Jon,

Please see inline.

Cheers,
Med

De : Dots [mailto:[email-masked]] De la part de Jon Shallow
Envoyé : vendredi 23 mars 2018 16:35
À : [email-masked]<mailto:[email-masked]>
Objet : [Dots] WGLC signal-18 Draft Hop Limit tidy up

Hi there,

[Jon1] I guess that I am trying to differentiate between updating an existing Hop-Limit and not injecting a new one alongside a previous one.  Having multiple Hop-Limit options could get interesting!
[Med] OK, I get your point. What about adding :
NEW:
 Only one single instance of the option is allowed in a message.

      To ease debugging and troubleshooting, the DOTS gateway which
      detects a loop SHOULD include its information (e.g., server name,
      alias, IP address) in the diagnostic payload under the conditions
      detailed in Section 5.5.2 of [RFC7252].  Each intermediate DOTS
      gateway involved in relaying a 5.06 (Hop Limit Reached) error
      message SHOULD prepend its own information in the diagnostic
      payload with a space character used as separator.  The ultimate
      DOTS gateway SHOULD remove the diagnostic payload before
      forwarding the 5.06 (Hop Limit Reached) error message to a DOTS
      client domain.
[Jon1] I have no issues if a server domain really wants to strip out its internal hops - but troubleshooting is more of a challenge and would not recommend it.
[Jon1] However, when setting up a DOTS client, which is failing to work for whatever reason, it would be good to have a reasonable level of diagnostics on the Client - separately invoking someone to look at a DOTS server's logs may take time
to get responded to - and you as a novice DOTS client user will have no idea as to what to tell the DOTS server guy to look for in the server's busy logs.
[Med] I hear that you are for: s/DOTS gateway SHOULD remove the diagnostic payload before/DOTS gateway MAY remove the diagnostic payload before. Right?

[Jon1] I would also like the structure of the diagnostic message to be well formatted (e.g., no leading text, only one of server name / alias / IP address, blank separator etc.) so it can easily be documented in user manuals etc. as well as perhaps parsed by a receiver of the 5.06 message (interim hop or final destination).  All other responses (albeit in cbor) are pretty well documented.
[Med] Isn't this covered in the above text?

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Tue, 27 Mar 2018 16:14:08 +0100

Hi Med,

See inline [Jon2]

Regards

Jon

Hi there,

              DOTS gateway.

NEW:

[Jon2] Works for me

      client domain.

may take time 

to get responded to – and you as a novice DOTS client user will have no idea
as to what to tell the DOTS server guy to look for in the server’s busy
logs.

[Med] I hear that you are for: s/DOTS gateway SHOULD remove the diagnostic
payload before/DOTS gateway MAY remove the diagnostic payload before. Right?

[Jon2] I feel a lot happier with MAY

[Med] Isn’t this covered in the above text?

[Jon2] Dyslexia rules – I read ‘prepend’ as ‘append’ - sorry.  Prepending
will do what I am looking for in part.

[Jon2] However, adding in more than one of  server name / alias / IP address
per hop might be a bit confusing when you “count” the hops.

~Jon2

              of 16 MUST be used.

              received in a message).

~jon1

Regards

Jon

---

From: <[email-masked]>
Date: Wed, 28 Mar 2018 09:09:43 +0000

Hi Jon,

Please see inline.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mardi 27 mars 2018 17:14
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up

Hi Med,

See inline [Jon2]

Regards

Jon

Hi there,

[Med] OK, thanks.

[Med] OK.

[Jon1] I would also like the structure of the diagnostic message to be well formatted (e.g., no leading text, only one of server name / alias / IP address, blank separator etc.) so it can easily be documented in user manuals etc. as well as perhaps parsed by a receiver of the 5.06 message (interim hop or final destination).  All other responses (albeit in cbor) are pretty well documented.
[Med] Isn't this covered in the above text?
[Jon2] Dyslexia rules - I read 'prepend' as 'append' - sorry.  Prepending will do what I am looking for in part.
[Med] Great!
[Jon2] However, adding in more than one of  server name / alias / IP address per hop might be a bit confusing when you "count" the hops.
[Med] This is exactly why the provided examples are not plural "(e.g., server name, alias, IP address)". I agree that we can use a more strict language. I can add this NEW sentence:
"Only one information per DOTS gateway MUST appear in the diagnostic payload."

~Jon2

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Wed, 28 Mar 2018 10:37:42 +0100

Hi Med,

See inline [Jon3]

Regards

Jon

 

Hi there,

              DOTS gateway.

NEW:

[Jon2] Works for me

[Med] OK, thanks.

      client domain.

[Med] OK.

[Med] Great! 

[Med] This is exactly why the provided examples are not plural “(e.g.,
server name, alias, IP address)”. I agree that we can use a more strict
language. I can add this NEW sentence:  

“Only one information per DOTS gateway MUST appear in the diagnostic
payload.”

[Jon3] Yes please.

~jon3

~Jon2

              of 16 MUST be used.

              received in a message).

~jon1

Regards

Jon

---

From: <[email-masked]>
Date: Wed, 28 Mar 2018 11:58:04 +0000

Re-,

I confirm that I implemented the changes we agreed in my local copy.

You may double check at: https://github.com/boucadair/draft-ietf-dots-signal-channel

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mercredi 28 mars 2018 11:38
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up

Hi Med,

See inline [Jon3]

Regards

Jon

Hi there,

Jon

---

From: "Jon Shallow" <[email-masked]>
Date: Wed, 28 Mar 2018 14:19:11 +0100

Hi Med,

One thing that I earlier commented on appears to have slipped through the
net (and I missed spotting it in your update)

“The diagnostic message length would need to be restricted to something like
1000 bytes to prevent UDP fragmentation.”

This could be applied to all CoAP diagnostic messages (RFC7252 does not seem
to pick this up) or just to the hop-limit response (which could get large).

Perhaps the text could read something like:-

      “Each intermediate DOTS

      payload with a space character used as separator, subject to there
being sufficient extra space in the diagnostic payload so that the overall
packet does not exceed the IP MTU (RFC7252 4.6. Message Size) .”

Regards

Jon

Sent: 28 March 2018 12:58

Re-,

You may double check at:
https://github.com/boucadair/draft-ietf-dots-signal-channel 

Cheers,

Med

Hi Med,

See inline [Jon3]

Regards

Jon

 

Hi there,

              DOTS gateway.

NEW:

[Jon2] Works for me

[Med] OK, thanks.

      client domain.

[Med] OK.

[Med] Great! 

[Jon3] Yes please.

~jon3

~Jon2

              of 16 MUST be used.

              received in a message).

~jon1

Regards

Jon

---

From: <[email-masked]>
Date: Wed, 28 Mar 2018 14:15:48 +0000

Jon,

RFC7252 does already mention the following :

   If the Path MTU is not known for a destination, an IP MTU of 1280
   bytes SHOULD be assumed; if nothing is known about the size of the
   headers, good upper bounds are 1152 bytes for the message size and
   1024 bytes for the payload size.

We do already refer to that section in the draft. We don't need to call out again for this particular case.

Thank you.

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mercredi 28 mars 2018 15:19
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up

Hi Med,

One thing that I earlier commented on appears to have slipped through the net (and I missed spotting it in your update)

"The diagnostic message length would need to be restricted to something like 1000 bytes to prevent UDP fragmentation."

This could be applied to all CoAP diagnostic messages (RFC7252 does not seem to pick this up) or just to the hop-limit response (which could get large).

Perhaps the text could read something like:-
      "Each intermediate DOTS
      gateway involved in relaying a 5.06 (Hop Limit Reached) error
      message SHOULD prepend its own information in the diagnostic
      payload with a space character used as separator, subject to there being sufficient extra space in the diagnostic payload so that the overall packet does not exceed the IP MTU (RFC7252 4.6. Message Size) ."

Regards

Jon

Re-,

Cheers,
Med

De : Jon Shallow [mailto:[email-masked]]
Envoyé : mercredi 28 mars 2018 11:38
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]<mailto:[email-masked]>
Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up

Hi Med,

See inline [Jon3]

Regards

Jon

Hi there,

Jon