Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension
RFC 8629

Note: This ballot was opened for revision 06 and is now closed.

Alvaro Retana Yes

(Ignas Bagdonas) No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

Roman Danyliw (was Discuss) No Objection

Comment (2019-05-06)
No email
send info
Thank you for addressing my DISCUSSes.

Benjamin Kaduk No Objection

Comment (2019-05-01 for -06)
I support Roman's Discuss.

I think that there's room in the document to add some of the
clarifications made in response to the TSV-art review, especially
regarding the "exception cases" responsible for SHOULD-level
requirements as opposed to MUST-level requirements.

Section 1

   forwarding in intermediate modems.  This document refers to
   forwarding by intermediate modems as 'multi-hop forwarding'.  example
   using . DLEP Destination messages can be used to report such

nit: there seems to be some formatting issue or extraneous pasted text

   It is important to note that the use of the hop control mechanism
   defined in this can result in connectivity changes and even loss of
   the ability to reach one or more destinations.  The defined mechanism

nit: missing word ("this document", perhaps?)

   will report such connectivity changes, but the details of what a
   router does or how it reacts to such are out scope of this document.

nit: maybe s/to such/to such reports/?

Section 2

   The use of the Multi-Hop Forwarding Extension SHOULD be configurable.
   To indicate that the extension is to be used, an implementation MUST
   include the Multi-Hop Forwarding Extension Type Value in the
   Extensions Supported Data Item.  [...]

Is the configurability for exposing that the feature is available (in
the Extensions Supported data item)?  (Independently of that answer?) I
don't think the second MUST is appropriate, as it is just duplicating a
requirement from RFC 8175.

Section 3.1

   The Hop Count Data Item is used by a modem to indicate the number of
   modem that transmits/sends data to reach a particular destination,

nit: "modems" plural and "transmit/send" to match.

   The Hop Count Data Item SHOULD be carried in the Destination Up,
   Destination Update, Destination Announce Response, and Link
   Characteristics Response Messages when the Hop Count to a destination
   is greater than one (1).

I'm not sure that the response to the tsv-art review addressed the key
question, namely: should this data item be carried in messages other
than the four listed here?  The current text makes no statement either
way, but the reviewer seemed to think that the intent was to suggest
that it did not make sense to carry the Hop Count Data Item in messages
not listed here.  Is that incorrect?

   A router receiving a Hop Count Data Item can use this information in
   its forwarding and routing decisions, and specific use is out of
   scope of this document.  The absence of the Hop Count Data Item MUST
   be interpreted by the router as a Hop Count value of one (1).

This "MUST" may not be forward-looking, in the case where some future
extension supersedes this one and so a message lacks a Hop Count Data
Item but has some other indicator of a greater-than-one hop count.  To
phrase it differently, in some sense this text is attempting to place a
constraint on implementations that do not implement this specification.
Perhaps the declarative "is interpreted" is less problematic.

Section 3.2

                                                        The modem MUST
   also notify the router of each destination that is not identified in
   the Link Characteristics Response Message and has a changed Hop Count
   impacted via a Destination Update Message.

nit: "changed" and "impacted" seem redundant.

For both the Session Update and Link Characteristic Request cases, we
only talk about Destination Down and Destination Update messages.  Is
there any case where we might need to send a Destination Up message in
response to the changes effected by a Hop Control Data Item (or is that
requirement already imposed by RFC 8175 in a part that I didn't read)?

Section 3.2.4

   A modem which receives the Suppress Forwarding Data Item in a Session
   Update Message MUST suppress multi-hop forwarding on a device wide
   basis.  This means that data traffic originating from the modem's
   peer router SHALL only be sent by the modem to destinations that are
   one modem hop away, and that any data traffic received by the modem
   from another modem that is not destined to the peer router SHALL be
   dropped.  [...]

nit(?): I'm not sure I understand the meaning of "destined to the peer
router", here.  It feels more natural if I instead say "destined to
itself", but perhaps this is because I am using "peer" to refer to
modem-level peering and this is instead intended to reflect a
relationship between the modem and router components of a single DLEP

Section 4

I don't think that "The extension does not inherently introduce any
additional threats above those documented in [RFC8175]." is really
correct -- as Roman notes, we are setting up control messages to change
the configuration of the radio hardware in ways not envisioned by RFC
8175 (i.e., "re-aiming the antenna"), as well as the explicit software
"suppress" controls.

                                        With the Link Characteristics
   Request Message, this risk is implicit.  With the Hop Control
   mechanism defined in this document it is more likely.  From a

nit: I don't think "implicit" conveys quite the intended meaning;
perhaps "implicit and small" is better.

   security perspective, implementations should be aware of this
   increased risk and may choose to implement additional configuration
   control mechanisms to ensure that the Hop Control mechanism is only
   used under conditions intended by the network operator.

(It seems like in practice this will mean the TLS requirement Roman
mentions, for almost all environments, though perhaps I am missing some

Section 5.3

I agree with Barry that some guidance to the expert is probably in

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2019-05-01 for -06)
Thank you for writing this -- I learnt a bunch while reading it.

I have a few minor comments:
1: "This document refers to forwarding by intermediate modems as 'multi-hop forwarding'.  example using . DLEP Destination messages"
There is a random ". exmaple using ." in the above.

2: "The Hop Count Data Item is used by a modem to indicate the number of modem that transmits/sends data to reach a particular destination, ..."
This is really hard to parse - I think you need "number of modem*s*" and s/transmits/transmit/". Or, perhaps something like "The Hop Count Data Item is used by a modem to indicate the number of modems that data will transit to reach ..."? 

3: Question: "The data item also contains an indication of when a destination which currently has a hop count of greater than one (1) could be made directly reachable by a modem, e.g., by re-aiming an antenna." -- how can a modem know this? Unless it knows physically where a destination is, what the antenna information is, what objects might be between the antenna and destination exist, etc I cannot see how this might work -- but, then again, I know very little about this technology, so I'm happy to be educated...

4: IANA is likely to have questions about "Hop Control Actions Registry", like what the registration policy is, etc...

(Mirja Kühlewind) No Objection

Comment (2019-04-29 for -06)
 1) Maybe this is a bit of a blunt question because I might not know enough about DLEP but how does a modem know the number of hops? Is there any need to say something more about how to gather this information in the document?

 2) Should the security consideration section maybe also say something about the frequency of re-configurations? Maybe that should be limited, also in order to not generate a large amount of signalling messages that could congest the link. Maybe you want to at least limit the rate of messages sent such that multiple re-configuration could be covered by one message in case there is a high rate of re-configurations. Or is there already such a limit in DLEP? If yes, it would be good to state that explicitly in this document as well.

 - There seems to be a text fragment (“example using .”) in the intro text:
 “This document refers to
   forwarding by intermediate modems as 'multi-hop forwarding'.  example
   using . DLEP Destination messages can be used to …”
 - Sec 3.1: s/to indicate the number of modem/to indicate the number of modems/ -> plural: modemS

Barry Leiba No Objection

Comment (2019-04-22 for -06)
No email
send info
Section 5.3 creates a registry that includes a Specification Required policy, which has a designated expert reviewing a specification and deciding whether to approve the registration request.  It would be useful to have at least brief guidance to the designated expert about what to consider when making that decision.  Should the only issue be whether the specification is sufficiently clear and complete?  Or are there other considerations that might warrant push-back to a registration request?

(Alexey Melnikov) No Objection

(Adam Roach) No Objection

Comment (2019-04-30 for -06)
Thanks to everyone who worked on this document. I have only two editorial


Please expand "DLEP" in the title and the abstract. See
https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.



> DLEP peers are comprised of a modem and a router.

Nit: This should be either "DLEP peers are composed of a modem and a router."
or "DLEP peers comprise a modem and a router."

Martin Vigoureux No Objection

Comment (2019-04-29 for -06)

thank you for this Document. I have a couple of questions

   The absence of the Hop Count Data Item MUST be interpreted by the router as a Hop Count value of one (1).
I know it is a bit nit-picking but would it be worth explicitly saying that this applies only in the case where the Multi-Hop Forwarding capability has been successfully negotiated?

   Once the change is made, or fails or is rejected, the modem MUST respond with a Session Update Response Message with an appropriate Status Code.
I think you should specify which status code to use depending on the situation.

In sections 3.2.2 and .3 you have a requirement that says: "... MUST NOT be sent in a Session Update Message message" but in 3.2 you have some generic piece of text which says:
   A modem that receives the Hop Control Data Item in a Session Update
   Message SHOULD take whatever actions are needed to make the change
   indicated by the data item for all known destinations.
So if a router does not respect the MUST NOT then a modem might try to take some actions based on something it should have received.
Maybe it would be worth completing the "MUST NOT send" requirement with a "MUST discard/return error/log" type of requirement.

By the way, I'm not sure that the should in "... SHOULD take whatever actions ..." should be in caps. The actions that to be taken are described in detail in 3.2.1 to 3.2.4 and are not all SHOULDs (MUST clear, SHOULD attempt to establish, MUST suppress).


Éric Vyncke No Objection

Comment (2019-04-30 for -06)
Clear and easy to read.
  == NITS ==
 Section 1, there is a dangling ". example using ."
 Section 3.2, the use of a 16-bit value for Hop Control Action suggest that there could be more than 4 values (indeed there is a IANA request for a registry for this field), suggest to mention that there could be more than 4 values in this section

Magnus Westerlund No Objection