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

[Dino Farinacci <[e-mail]>]

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

Thanks Ben. Here are some brief answers.

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

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

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.

> 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

Yes.

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

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