Re: [manet] Benjamin Kaduk's No Objection on draft-ietf-manet-dlep-lid-extension-05: (with COMMENT)

[Stan Ratliff <[e-mail]>]

Benjamin,

Thank you for the review and comments. I wanted to let you know that we
(the authors) are in the process of discussing your comments, but we need a
few more days to complete the process.

Thanks again.

Regards,
Stan


On Fri, Aug 16, 2019 at 4:32 PM Benjamin Kaduk via Datatracker <
[e-mail]> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-manet-dlep-lid-extension-05: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-lid-extension/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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.
>
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>