Re: [lisp] 6830bis Review

<chair hat on> Let's try to separate things.

1) The fact that the messages are used only between xTRs does not tell 
us whether it is control or data.
2) The manipulation of map-cache may well be control (for example, if we 
were using a push-based control mechanism then map-cache control would 
be largely control.

</chair hat on>

<chair hat off>
Personally, it looks to me like SMR is a control mechanism.  It is 
information to control the operation of the xTR.  It is not data plane 
behavior.  It is driven from and drives control behavior.

One could argue that RLOC-probes are more borderline in tha tthey 
themselves behave more like data packets.  Still, my own thought process 
is to think of them as control operations.

The actual argument that can be made is that the capabilities these 
provide could be provided by another mechanism when another data plane 
is used.  But the capability needs to exist.  Putting these mechanisms 
in the control plane document makes it much easier to have the 
discussion about the fact that the control plane needs these functions 
to be robust.
After all, there is no goal that these are completely separate and 
independent entities.  Even if it may turn out that with sufficient care 
the control plane can be used for other things.
</chair hat off>

<chair hat on>  (Yes, my hats are bouncing.)
I would really like to hear from other WG members about this.  It is the 
WGs document.  The chairs would prefer not to simply use their own 
judgment.  So to repeat Luigi's plea: speak up.
</chair hat on>

Yours,
Joel

On 1/15/18 12:55 PM, Dino Farinacci wrote:
>> SMRs and RLOC-probes are control-plane features used by xTRs to be able to run the data-plane.
> 
> They are data-plane features that use control-plane messages. No other devices sends an RLOC-probe (or SMR) then an xTR. And the elements of operation are based on the map-cache. Any manipulation of the map-cache SHOULD NOT go in 6833bis.
> 
> Dino
> 
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
> 