Re: [netmod] rfc6991bis: loopback addresses

tom petch <ietfc@btconnect.com> Mon, 03 August 2020 11:57 UTC

Return-Path: <ietfc@btconnect.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129693A0ED7 for <netmod@ietfa.amsl.com>; Mon, 3 Aug 2020 04:57:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8VTAlK-Btr6 for <netmod@ietfa.amsl.com>; Mon, 3 Aug 2020 04:57:31 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10119.outbound.protection.outlook.com [40.107.1.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB02F3A0ED3 for <netmod@ietf.org>; Mon, 3 Aug 2020 04:57:29 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YJarbaN9+itwPVhtcJ3qFjoTb7eSpRVFjLy1zH36fXmR6Lx+2ckp54/rU9dFWSPonkiTWq2Ef18OIq+07bffiYGWR2Q9KAcX2HN8+H3bosZ/84xRC7OcP/6s80Gur0gvK1KBl6aWw8z2t/Ut3BcNckOcs3t6G1F3xQl4IwYmHuHmsX0yS0pDjreg14Pz8tVE4W7sJO1+xBXCKjKmlnK230qe+7GqN5uALoS/WJZTMqIU05WEmzQcCJOqjkIce+voYv9kegSAYN9v8iHBHd6lGGr/hPS4qH0gN1cLxmWv0n5SsC3IVOk+QLH6TZet7uXbHm+gFDyRipesWbIF+rG5KA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tISSJdi0O0mnADp48lDrAviBsihhzJo78pblmn5b4v4=; b=es/8RyOLDj8MXZR9inWpG18MPKQ5jdXVt2YsxTzArnApQ6qzuEzGwDCrqFwWac/Yh5LnLYX9zj2fYHzYrJQEGaP3xl8/DPcv3OPaA2GJT4BRDi4ywGLnPRDQBLNp77WU8bxx1+G4ztKPg0UfP71NJ0kVeUz8ixr0xhPdrOxCJE5p0u5m5I61beW5hi1vDevNk6s6jKpEV2CIL+/bSFN53nyqEf9k2Qp8Oe7LmFbpVRlP8S7KOdWnbTwDQKViYQHuupEuZd2PJmG/8nM9GCh8mEo0QRcJAh/7MIGliWIBwmHerqwv/u0vLsQNAUoGC1eCr/cK8zQut2lhmdsomPE21g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tISSJdi0O0mnADp48lDrAviBsihhzJo78pblmn5b4v4=; b=bGLR4viL/VIOtqBYh+CtzMs5U3JIWD3J7OpaF9mpN/8Yn8r7scLVpo3Pb+SDyYdr4fmh7uOc65yES6D7hach32IOWpSdNSqG61KGp+9VgQEAPoYY/ACrC9KRubK2LPeQyKrYdlhqR+IcxXim5YtS0JeBn9EaaiSwnJXcDprV0v8=
Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM7PR07MB6930.eurprd07.prod.outlook.com (2603:10a6:20b:1c3::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.14; Mon, 3 Aug 2020 11:57:27 +0000
Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::893c:ca97:acbf:1c76]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::893c:ca97:acbf:1c76%5]) with mapi id 15.20.3239.021; Mon, 3 Aug 2020 11:57:27 +0000
From: tom petch <ietfc@btconnect.com>
To: "Nagendra Kumar Nainar (naikumar)" <naikumar@cisco.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
CC: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Thread-Topic: [netmod] rfc6991bis: loopback addresses
Thread-Index: AQHWZnQDpfprWxs6WkidzS2pA1jayakgIvWAgAYoJfY=
Date: Mon, 03 Aug 2020 11:57:27 +0000
Message-ID: <AM7PR07MB624840434B36519C0A48F79BA04D0@AM7PR07MB6248.eurprd07.prod.outlook.com>
References: <20200717192556.63e7gfbbrn2qyqzo@anna.jacobs.jacobs-university.de> <AM6PR07MB52220AD16FAC337D4F89A674A07B0@AM6PR07MB5222.eurprd07.prod.outlook.com> <64A58592-5FD0-4752-8069-E59E62C3F699@cisco.com> <AM6PR07MB5222C7EC1927B652D7C7389DA07B0@AM6PR07MB5222.eurprd07.prod.outlook.com> <A27BF4C9-FD50-46C0-8D95-36BD778EBAC6@cisco.com> <7D333828-EF9E-4786-B820-5B4A29B37440@cisco.com>, <20200730134715.otyb4e6uqjylszdg@anna.jacobs.jacobs-university.de>
In-Reply-To: <20200730134715.otyb4e6uqjylszdg@anna.jacobs.jacobs-university.de>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [81.131.229.35]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9d64c6fb-92c6-4671-3e34-08d837a464a9
x-ms-traffictypediagnostic: AM7PR07MB6930:
x-microsoft-antispam-prvs: <AM7PR07MB69306341560BB1DAA09322F5A04D0@AM7PR07MB6930.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: CyqJMIUYynRP2xWi2+sRtMdgK7895A2D+Fg+15FrSOHLA+9OOeyyMQ03BBy2Obf5a2KB0x3JCDSj9K/dcHdGOH1f5M1mbIzidiBmp6tYDRq3E82p9PHcaQh1iGMh/Cl/CND3eYYpJvmAhqhMkzGESiTM9Z4D7Urwp39Wonuwbo3n4lnbmUS/anHAXueqlFyRC3f67OT4ZUO8xmAqxXS1tr7nupkjgGkicEJ6+UrcXa4WLmMqE2BADLWYPN+tTVrbBAQDXf/4Gu5rtzHJXYVJsSBQch8T/Pu5UhorthL+cWK412DdZiYzropOGsA5MPeCYnACQmmRrAwZwcQJoc7pZypo8Jk4O1jtHAt5rwVWLIRLXZOdJ/vqTb4APtk4g4f21Cq0+I6YoFZBYHC77PCA9w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(39860400002)(376002)(396003)(346002)(366004)(136003)(53546011)(76116006)(83380400001)(66946007)(2906002)(33656002)(4326008)(26005)(186003)(66556008)(66476007)(64756008)(66446008)(91956017)(8936002)(6506007)(7696005)(8676002)(966005)(86362001)(71200400001)(52536014)(5660300002)(110136005)(316002)(54906003)(478600001)(83080400001)(66574015)(9686003)(55016002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: KFe640lO8WPHHgziZJLvP3ZgKpxIoG8gnjyXNHQ0ZtFXRQT05eGW7aEeeJtvQT4NiwLbE8jeNlTomoGJwNI09qIuuSckK5YXY9O3k3IPAf4GmTcF4LOrHSN7ZWY4+RrD396BWs8SjndPdeyTCAenEJfHCkHV9cD51V/lX/aoVz2s2hbU7e6Tw6lxu+tErLvCorLO6WSPz0kTEz/jUfccsSpKQJIhi2HdgfuKDOK7LolHi0WeGwpX6nZpigUOXvWAOLxr5PwirGUQbtVicKOlx0+UxNxAEjwUwQjiLFsb0QI29m1zKoj1yJhMvh/BNXqzmIwz5IZ2P5JKSe31qMvrsLttPwHpyCjjmFl6C60kPQ5kivhvT9h++s9KpYVGpFAp97ODttjyjXfrhjpacl/IMV8rS6kSdu1eRVKHXP3h7gEmFqxVFnDzDqn3STtgDqqvM9xgK9b0mL3WDrBr8eAdqMEhKpGwu9f51JuNLD6OODRCGUkxCKQvAv0E5sBG+0IHes5k5aqnOwSblFEDSaGAgyYIkmG4Q+bDa6Cy4vzDtbrMqZ3/v+smsRV3hzeA4BbvhBBMJZnIq/I8Z0aFfa51XV7V8/4DUp1IPkZNgEiFnDJHG0kYS9pRqQawnFba3WQ0x8v8+0KD6XR2koks3oxWIQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9d64c6fb-92c6-4671-3e34-08d837a464a9
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2020 11:57:27.4817 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: FdczDvJic+de1rXGUAyi0ivMHlxwS0p3J7w/swX+NZ2GN9+3Zwcl76b6KxuWImJMXEidQWqYswYydM5udwUcsw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6930
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/xeXI8Tz4mQ3rGq8oHGpwNMf-OV0>
Subject: Re: [netmod] rfc6991bis: loopback addresses
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2020 11:57:33 -0000

FRom: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Sent: 30 July 2020 14:47
To: Nagendra Kumar Nainar (naikumar)
Cc: Reshad Rahman (rrahman); tom petch; netmod@ietf.org; Carlos Pignataro (cpignata)
Subject: Re: [netmod] rfc6991bis: loopback addresses

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?

<tp>
Clear may be but wrong!

LSP Ping DOES NOT use loopback.  For IPv4 it uses 127/8 and for IPv6 it uses the IPv6 format that encodes that IPv4 address.  IPv6 loopback is something completely different.

What LSP Ping needs is the addresses used in LSP PING which are NOT loopback.  This is needed for MPLS but I cannot imagine it having any other use so I cannot see any reason to include it in 6991bis.  And it would be grossly misleading for MPLS to refer to these addresses as loopback.

I have not seen any use of the genuine loopback addresses in IETF YANG modules so cannot see any reason to include them in RFC6991bis.

Tom Petch

/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)" <rrahman@cisco.com> 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" <ietfc@btconnect.com> wrote:
>
>         From: Reshad Rahman (rrahman) <rrahman@cisco.com>
>         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" <netmod-bounces@ietf.org on behalf of ietfc@btconnect.com> 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 <netmod-bounces@ietf.org> on behalf of Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
>             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
>             netmod@ietf.org
>             https://www.ietf.org/mailman/listinfo/netmod
>
>             _______________________________________________
>             netmod mailing list
>             netmod@ietf.org
>             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/>