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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 30 Dec 2019 14:22:14 -0800

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.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 30 Dec 2019 15:03:35 -0800

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

Thanks Ben. Here are some brief answers.

> % only 24 usable bits of Instance ID.

The source and destination EIDs are scoped within an instance-ID. So all EIDs within a VPN (that is assigned a unique Instance-ID PER mapping system) are unique.

Note it is 2^^32 Instance-IDs PER mapping system. Where 2^^24 can be used by any one ITR.

> My apologies if this was already covered and I just forgot.

Agree. We can add that. They must be part of the same instance-ID. Extra-netting where they can be part of different ones is in the draft-ietf-lisp-vpn draft that is not currently on standards track.

> mapping-driven, Map-Reply messages)?   Specifically, my understanding was that

Yes.

> some clarification in Section 5.4.

Agree. Because even when a map-server proxy-replies, it knows if the ETR registered with Echo-Nonce capable. So the information can be conveyed from multiple sources.

Thanks again,
Dino

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 30 Dec 2019 18:10:27 -0800

> Thanks Ben. Here are some brief answers.

Thanks Dino.

> Agree. We can add that. They must be part of the same instance-ID. Extra-netting where they can be part of different ones is in the draft-ietf-lisp-vpn draft that is not currently on standards trac…

Great; that helps clear things up for me.

> Agree. Because even when a map-server proxy-replies, it knows if the ETR registered with Echo-Nonce capable. So the information can be conveyed from multiple sources.

I'm not sure if you're saying that we should s/RLOC-probe
Map-Reply/Map-Reply/ or make achange to 6833bis.  Sorry for being confused
:(

-Ben

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 30 Dec 2019 19:51:10 -0800

> On Dec 30, 2019, at 6:10 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

Yes we should make this change. 

Dino