Thanks for pointing to the definitions in draft-nainar-mpls-lsp-ping-yang. With that, your request is relatively clear now and the question the WG needs to answer is whether these types are common enough to warrant being part of inet-types, i.e., are there any other places where these types may be useful?
/js On Thu, Jul 30, 2020 at 01:19:11PM +0000, Nagendra Kumar Nainar (naikumar) wrote: > Hi, > > As Reshad mentioned, RFC8029 uses internal host loopback address > (127..0.0.0/8 range as defined in section 4.2.2.11 of RFC1812). The YANG > module for LSP Ping (RFC8029) defined in draft-nainar-mpls-lsp-ping-yang is > using this address and so we felt it will be good to have the same included > in the right document. > > Thanks, > Nagendra > > On 7/20/20, 2:54 PM, "Reshad Rahman (rrahman)" <[email protected]> wrote: > > Hi, > > I think what you're referring to is the use of "loopback interfaces". The > loopback addresses Juergen was referring to do not belong to loopback > interfaces. > > Regards, > Reshad. > > > On 2020-07-20, 11:30 AM, "tom petch" <[email protected]> wrote: > > From: Reshad Rahman (rrahman) <[email protected]> > Sent: 20 July 2020 14:39 > > I don't understand the comment "...implementation choice of one > manufacturer." > > <tp> > Go back to the early specifications of IPv4 routers and routing > protocols, which are still the ones we use today, and loopback was a state > into which an interface could be put, with a loop back in hardware or > software, often used for testing. A router had a router id, a 32 bit number > with no syntax. One major manufacturer conflated parts of this and created a > virtual address or addresses which could be used to send and receive packets > for the router, as opposed to an interface on the router, which had no > physical manifestation; fine until they called it the loopback address(es) > which, sadly, caught on and many people, included those writing IETF I-D > think that the router id can only be such a routable address. Some even > think that there can only be one such address on a box, as opposed to one for > network management, one for the control plane and so on. Not so. > > Tom Petch. > > As for the details, see > https://tools.ietf.org/html/draft-nainar-mpls-lsp-ping-yang-00 > > Regards, > Reshad. > > > On 2020-07-20, 4:47 AM, "netmod on behalf of tom petch" > <[email protected] on behalf of [email protected]> wrote: > > I am not a fan of loopback seeing it as the implementation choice > of one manufacturer. On the other hand, the IETF has defined documentation > addresses which many if not most writers of examples for YANG modules seem > unaware of so if we add anything, I would add those. > > Tom Petch > > From: netmod <[email protected]> on behalf of Juergen > Schoenwaelder <[email protected]> > Sent: 17 July 2020 20:25 > > - There was a request to add types for loopback addresses > (127.0.0.0/8 and ::1/128). > > - This is related to an effort to define a YANG module for MPLS > LSP > Ping (RFC 8029) but the details are unclear, i.e., what is > exactly > needed and how such a type will be used and whether there is a > common need for types for loopback addresses. > > - Proposal: do not add such types at this point in time > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > Fax: +49 421 200 3103 > <https://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
