Note: This ballot was opened for revision 05 and is now closed.
I did not review this document myself but I am balloting based on the Gen-ART review.
I'm not entirely sure I understand the expected mode of operation here. Clearly the overall goal is to advertise IP reachability, but it seems the way we do this is to construct an opaque "link identifier" to indicate to the DLEP peer that there is "some other link broader than layer-2" attached, and then rely on the existing IP address/attached-subnet data items to associate that opaque link identifier with the corresponding IP resources. But this document doesn't make it fully clear to me the details of associating IP resources with the link identifier: how are the two data items known to be bound together; what is the scope of attachment; is there potential for confusion if multiple bindings are transmitted in parallel; etc. As best as I can tell this is intended to be wrapped into the single line that "[t]he Link Identifier Data Item MAY be used wherever a MAC Address Data Item is defined as usable in core DLEP.", but spending another sentence or two for a brief overview and/or section reference might be worth the reader's time. (In some sense, we also don't really say how the semantics from the MAC Address Data Item transfer over to the Link Identifier Data Item usage, which could be helpful, too.) In a similar vein, I'm not sure that I understand the distinction between this mechanism and the existing IP address/attached-subnet data items from RFC 8175. My current understanding is that the semantics of the structures in RFC 8175 is to indicate IP resources that are "directly attached" to the indicated Destination, but that this new mechanism is needed for cases when the IP resources are not directly attached to, but are reachable via, the indicated Destination. Is that correct? It might be good to have some further discussion in the document about why the existing mechanisms are inadequate/insufficient for the described use cases (I mostly assume that having the additional Destination/link identifier allows for more granular updates, instead of having to reannounce the entire IP reachability via the layer-2 Destination's entry, but that's just an assumption). Section 1.1 I'm probably just confusing myself, but: Local Layer 2 domain: The Layer 2 domain that links the router and modem participants of the current DLEP session. uses "DLEP session", which suggests to me that it is indeed quite local, with the current DLEP session just involving the directly-connected router and modem. On the other hand: Layer 3 DLEP Destination: A DLEP Destination that is not directly addressable within the local Layer 2 domain, but is reachable via a node addressable within the local Layer 2 domain. (in combination with the introduction) is suggesting to me that the layer-3 destination is something with IP reachability via a device on the other end of a radio link from one of the local modems, and also implying that the router/modem at the other end of the radio link is itself supposed to be part of the "local Layer 2 domain". So I'm not sure how broad the local Layer 2 domain is supposed to be. Gateway Node: The last device with a MAC address reachable in the local Layer 2 domain on the path from the DLEP router participant, towards the Layer 3 DLEP Destination. This device is commonly the DLEP peer modem but could be another DLEP Destination in the Layer 2 domain. Just to check my understanding: the DLEP peer modem is the "directly attached" one, and another "DLEP Destination" would be a different router? Section 2 As only modems are initially aware of Layer 3 DLEP Destinations, Link Identifier Data Items referring to a new link MUST first appear in a DLEP Destination Up Message from the modem to the router. Once a nit/style: this statement of fact ("only modems are initially aware") comes a bit out of the blue and doesn't have any surrounding justification/explanation. It's fairly clear that it's just an inherent property of how the information flows around, but could perhaps be written in a more reader-friendly way. Section 2.2 If a modem requires support for this extension in order to describe destinations, and the router does not advertise support, then the "In order to describe destinations" is perhaps ambiguous about some vs. all attached destinations. Section 3.1 Am I supposed to only send this data item in the Session Initialization Response Message if I'm also negotiating the Link Identifiers extension? Section 4 It would be good to see a response to the secdir reviewer's question about potential privacy considerations of expanding the scope of IP connectivity described. Additionally, we require that the router "must not make any assumptions about the meaning of Link Identifiers, or how Link Identifiers are generated". To me, this suggests that various modem implementations are likely to reuse identifiers of some other nature as DLEP link identifiers, and we are imploring the routers to not rely on any specific such internal structure. In the general case, when this sort of "identifier reuse" occurs, we have to be careful to consider any security or privacy considerations should a router ignore the advice and attempt to look at the internal structure of the identifier. In this specific case of DLEP, there does not seem to be much of a concern, since we expect the router and modem to be fairly tightly integrated and at an equivalent trust level, but I did want to mention it as a possible consideration. It might also be appropriate to talk about collision probability when randomly assigned Link Identifiers are used and how that relates to the frequency of DLEP session creation and the churn rate of link identifiers.
Thanks for addressing my DISCUSS point. I think the new MAY (I had suggested a conditional "if advertised ... MUST") might be a bit too relaxed but it is totally your call.
I'm sure it's just because I don't fully understand DLEP, but I don't get this bit in Section 2.2: However, the modem SHOULD NOT immediately terminate the DLEP session, rather it SHOULD use a combination of DLEP Session Messages and DLEP Attached Subnet Data Items to provide general information. Will implementers know, based on how DLEP works in general, what "general information" to provide? What good will that general information do? The implication here is that the modem will terminate the DLEP session after providing the general information (as it requires this feature and the feature isn't available). So what's the point of the general information the modem will provide before terminating? Is it worth saying a few more words here?
Thank you for the work put into this document. I have two questions in the COMMENT section that I would appreciate to be answered. Regards, -éric == COMMENTS == -- Section 3.1 -- Is there any use of the "link identifier length data item" as in section 3.2 the link identifier has a field for its length? -- Section 3.2 -- What is the expected behavior when the "link identifier data item" does not match the length ?