Subject: [netmod] rfc6991bis: loopback addresses

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Jul 2020 21:25:56 +0200

- 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/>

---

From: tom petch <[email-masked]>
Date: Mon, 20 Jul 2020 08:46:37 +0000

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-masked]> on behalf of Juergen Schoenwaelder <[email-masked]>
Sent: 17 July 2020 20:25

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 20 Jul 2020 10:56:02 +0200

Adding documentation addresses as a _type_??

/js

---

From: tom petch <[email-masked]>
Date: Mon, 20 Jul 2020 09:03:14 +0000

From: Juergen Schoenwaelder <[email-masked]>
Sent: 20 July 2020 09:56

<tp>
I know, silly idea really but people do understand types in a way that they seem not to understand other YANG constructs.  And  I have seen real damage done by people not realising that an address is an example and not to be taken literally - I see documentation addresses as an example of excellent engineering.

Tom Petch

/js

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 20 Jul 2020 13:39:02 +0000

I don't understand the comment "...implementation choice of one manufacturer."

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-masked] on behalf of [email-masked]> wrote:

    Tom Petch

---

From: Erik Auerswald <[email-masked]>
Date: Mon, 20 Jul 2020 16:30:15 +0200

Hello Reshad,

while the I-D draft-nainar-mpls-lsp-ping-yang-00 only specifies ::1/128
as IPv6 loopback address, RFC 8029 sections 2.1., 3.4.1.1.1., and 4.3.
specify to use the IPv4 loopback range as IP4-mapped IPv6 addresses for
IPv6 MPLS echo request UDP packets, not the IPv6 loopback address ::1/128.

This seems to be inconsistent to me.

Best regards,
Erik

---

From: tom petch <[email-masked]>
Date: Mon, 20 Jul 2020 15:30:46 +0000

From: Reshad Rahman (rrahman) <[email-masked]>
Sent: 20 July 2020 14:39

<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.

Regards,
Reshad.

    Tom Petch

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 20 Jul 2020 18:49:06 +0000

Hi Erik,

You are correct, for IPV6 RFC8029 mentions 0:0:0:0:0:FFFF:7F00:0/104.

Regards,
Reshad.

On 2020-07-20, 10:30 AM, "Erik Auerswald" <[email-masked]> wrote:

    Hello Reshad,

    Best regards,
    Erik

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 20 Jul 2020 18:54:58 +0000

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-masked]> wrote:

    <tp>

    Tom Petch.

    Regards,
    Reshad.

        Tom Petch

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Thu, 30 Jul 2020 13:11:23 +0000

Hi Erik,

Thank you for catching this inconsistency. The choice of v4-mapped-v6 address was discussed while co-authoring RFC8029 and I think I mixed up and used the IPv6 loopback address in the YANG module. I will fix the same in the next revision of draft-nainar-mpls-lsp-ping-yang.

Thanks,
Nagendra

On 7/20/20, 2:49 PM, "Reshad Rahman (rrahman)" <[email-masked]> wrote:

    Hi Erik,

    Regards,
    Reshad.

        Hello Reshad,

        Best regards,
        Erik

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Thu, 30 Jul 2020 13:19:11 +0000

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-masked]> wrote:

    Hi,

    Regards,
    Reshad.

        <tp>

        Tom Petch.

        Regards,
        Reshad.

            Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Jul 2020 15:47:15 +0200

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

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Thu, 30 Jul 2020 15:00:58 +0000

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-masked]> wrote:

    /js

---

From: Kent Watsen <[email-masked]>
Date: Thu, 30 Jul 2020 20:55:01 +0000

> With that, your request is relatively clear now

Looking at draft-nainar-mpls-lsp-ping-yang, the proposal is a “typedef” that constrains inet:ipv[46]-address so that it can only contain loopback address values.

> and the question the WG

I don’t think so, but I’m not a routing person.

> /js

K.  // contributor

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 30 Jul 2020 21:05:49 +0000

Hi Kent,

I wouldn't think that an internal loopback address would be widely used. In fact, I checked our Cisco native models for IOS-XE and there is no such definition. 

Thanks,
Acee

    K.  // contributor