Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension
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
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 here. 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 entity. 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 details.) Section 5.3 I agree with Barry that some guidance to the expert is probably in order.
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. nits: - 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)
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 comments. --------------------------------------------------------------------------- Please expand "DLEP" in the title and the abstract. See https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. --------------------------------------------------------------------------- §1: > 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)
Hi, thank you for this Document. I have a couple of questions regarding: 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? regarding: 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). Thanks
É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