<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
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
