On 11-Apr-20 09:35, Joel M. Halpern wrote: > 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. That would work for me. > If we want to elaborate, we could not that this provides an interface to > anchor IPv6 addresses in accordance with the IPv6 addressing architecture. Right. That's the only thing that's different from the IPv4 case. Brian > 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
