Hi Juergen,

Thank you for the response.

I am not aware of any other use cases that leverage (Internal host) loopback 
address. I will wait for the WG to decide if it can be included as part of 
inet-types. If not, we will stick with the typedef defined in 
draft-nainar-mpls-lsp-ping-yang.

Thanks,
Nagendra

On 7/30/20, 9:47 AM, "Juergen Schoenwaelder" 
<[email protected]> wrote:

    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

Reply via email to