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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Fri, 16 Aug 2019 13:32:06 -0700

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.

---

From: Stan Ratliff <[email-masked]>
Date: Sun, 18 Aug 2019 20:38:16 -0400

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 <
[email-masked]> wrote:

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>