DLEP Link Identifier Extension

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

Alvaro Retana Yes

Ignas Bagdonas No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

Comment (2019-08-21 for -05)
I did not review this document myself but I am balloting based on the Gen-ART review.

Roman Danyliw No Objection

Benjamin Kaduk No Objection

Comment (2019-08-16 for -05)
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

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

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

Suresh Krishnan (was Discuss) No Objection

Comment (2019-09-16)
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.

Warren Kumari No Objection

Mirja Kühlewind No Objection

Barry Leiba No Objection

Comment (2019-08-21 for -05)
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

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?

Alexey Melnikov No Objection

Adam Roach No Objection

Éric Vyncke No Objection

Comment (2019-08-19 for -05)
Thank you for the work put into this document.  I have two questions in the COMMENT section that I would appreciate to be answered.



-- 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 ?