[lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-rfc6830bis-28: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lisp-rfc6830bis-28: Discuss

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-lisp-rfc6830bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for all the updates in the -28; we're making great progress!

My ballot on the -26 included:

% The usage of the Instance ID does not seem to be adequately covered; from
% what I've been able to pick up so far it seems that both source and
% destination participants must agree on the meaning of an Instance ID, and
% the source and destination EIDs must be in the same Instance.  This does
% not seem like it is compatible with Internet scale, especially if there are
% only 24 usable bits of Instance ID.

The -28 now says that the whole LISP deployment has to agree on the
meaning of Instance ID values (thank you!), but I'm still not entirely sure
if the source and destination EIDs need to belong to the same Instance.
If they do need to be in the same Instance, I think we should note that
(but if not, then the current text should be fine as-is).
My apologies if this was already covered and I just forgot.

[Someone (me?) still owe some analysis on the security considerations at the boundaries
of the various components in the ecosystem.  Deborah putting this back on an IESG
telechat as a returning item might be the most expedient way to get this to happen, sadly.]


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the discussion of Map-Version synchronization requirements!
I'm not in a position to assess whether the current 1-minute window is
adequate for the expected usage, and trust that you picked something reasonable.

We had a good exchange off-list about my comments on the -26/-27; I'm going
to keep a couple of the points from that but expand on them when the original was
unclear.

Section 10.1

Some side discussion: in some sense, the echo nonce functionality is the
most reliable method for determining reachability, and yet we say that it
MAY be overridden by other methods.
There's also some potential conflict between the "will set the E-bit and
N-bit for every packet it sends while in the echo-nonce-request state" and
the later text about echoing the peer's nonce when both ETR and ITR go into
the echo-nonce-request state at the same time, since if the E-bit and N-bit
are sent on literally every packet sent, then it's not possible to send packets
that echo the peer's nonce (which would just set the N-bit but not the E-bit,
if I understand correctly).

   erroneously consider the Locator unreachable.  An ITR SHOULD only set
   the E-bit in an encapsulated data packet when it knows the ETR is
   enabled for echo-noncing.  This is conveyed by the E-bit in the RLOC-
   probe Map-Reply message.

Is this only in RLOC-probe Map-Reply messages (and not generic, including
mapping-driven, Map-Reply messages)?   Specifically, my understanding was that
any Map-Reply could set the E-bit to indicate support for echo noncing, and so
there's not much point in us specifically qualifying that the E-bit is set in an
*RLOC-probe* Map-Reply (as opposed to just "a Map-Reply"). If this behavior
is specific to the RLOC-probe replies, I think that 6833bis needs
some clarification in Section 5.4.