I am happy to propose some starting text (I am sure it will need further
tuning) as a short definition of a Loopback Interface:
Loopback Interface: A logical or virtual representation of
connectivity for IP communication. It is distinct from any
physical interface on the device. It is typically used to
abstract a point of communication from any physical connectivity.
If we want to elaborate, we could not that this provides an interface to
anchor IPv6 addresses in accordance with the IPv6 addressing architecture.
As for the L2 material, if the WG wants to remove it, I would be fine
with that. It is clearly supplementary. I am just trying to avoid
confusion if we choose to describe it.
Yours,
Joel
On 4/10/2020 5:27 PM, Michael Richardson wrote:
Joel M. Halpern <jmh@xxxxxxxxxxxxxxx> wrote:
> On Loopback, I understand your frustration with the lack of a good
> definition. Given that IPv6 addressing architecture constraints, you need
> some sort of interface. In practice, the way loopbacks are used seems to
> match the need. So I do not object to the usage. just to the definition.
> It would also be acceptable to simply craft a different term and clearly
> define it if the usage is sufficiently different from existing
> practice.
Reading this thread, I was hoping you might be able to help us with a better
definition then :-)
We are doing exactly what OSPF and BGP does operationally on every platform
that I have every worked on. We are just doing it with RPL.
To me, it's *SO* obvious that it goes without saying, so now we are asked to
say it, and we get into trouble because nobody before us bothered to say it.
> On the final minor comment, it was specifically about the section on L2
> devices. Maybe something special is needed for the special case of a shared
> network that is also a border network. But that seems very rare. And getting
> the L2 switch to do the right packet forwarding for the hybrid case seems an
> invitation to trouble.
I'm not happy about any of the L2 text; I would have left it out completely.
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =-
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
