Re: [Lsr] Link Data value for Multi-area links

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Thu, 03 December 2020 10:27 UTC

Return-Path: <ketant@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356453A0E3B for <lsr@ietfa.amsl.com>; Thu, 3 Dec 2020 02:27:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=MgLWqcI/; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Po4lqiwO
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 mgtGD0wFlG8J for <lsr@ietfa.amsl.com>; Thu, 3 Dec 2020 02:26:59 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152093A0E3A for <lsr@ietf.org>; Thu, 3 Dec 2020 02:26:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17752; q=dns/txt; s=iport; t=1606991219; x=1608200819; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2lmPPQSJPIh/0hicq1OhWGZWXyBElbOUrRazTpqDpks=; b=MgLWqcI/NECBwC/1sM2P7XJCRlfQpwXfv22VFny7X26U219HBZwtkjhq rp4C/0y1SY9Jh5YiJNi9I5NSnTvs1y5L5jeIS4U3knjT3hyRHnPvK6eHZ C5xk+wJjO1bzb8oCeHJMOywOoH68MaGi/wuM5SJq/tb5PcIBYUw+cH48w 4=;
X-IPAS-Result: =?us-ascii?q?A0AGCQDdvMhffYUNJK1YCh4BAQsSDECDIVF8Wy8uCoQyg?= =?us-ascii?q?0gDjVyKF4RyiX+BQoERA1QLAQEBDQEBGAsKAgQBAYRKAheBfQIlOBMCAwEBA?= =?us-ascii?q?QMCAwEBAQEFAQEBAgEGBBQBAYY8DIVyAQEBAQIBAQEQEREMAQEsCwELBAIBB?= =?us-ascii?q?gIRAQIBAQEBAgIjAwICAh8GCxQBAgYIAgQBDQUIEweDBYJVAw4gAQ6QAZBrA?= =?us-ascii?q?oE8iGl2gTKDBAEBBYUvDQuCEAMGgQ4qgnOCZk5CgQaBPoQTG4FBP4EQAUOBV?= =?us-ascii?q?1AuPoIbQgEBAoEwEwQYFQ+CcTOCLJA1g06TFjaPMHE4VwqCcpAGhhaFOoMhi?= =?us-ascii?q?iGIZYlHgjYdk1WNfY4iJoRQAgQCBAUCDgEBBYFtIYFZcBU7gmlQFwINjiEMF?= =?us-ascii?q?4NOhRSFRHQCNQIGAQkBAQMJfIxiAQYhgQ0BgRABAQ?=
IronPort-PHdr: =?us-ascii?q?9a23=3A4fy+RBCkgJxxc3Z55fySUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw00A3CXJ7Q7LRPjO+F+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGE8flbFqUqXq3vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.78,389,1599523200"; d="scan'208";a="629723687"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Dec 2020 10:26:57 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B3AQvaS031135 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Dec 2020 10:26:57 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 3 Dec 2020 04:26:57 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 3 Dec 2020 04:26:57 -0600
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 3 Dec 2020 05:26:56 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c+P7eiSjTWEYUfvbEpWAK/kWKN+0HG0Gg0DRmg2vIFsXx+9eeXGHt2tfb+aWSl45T+oo5N/TYSQuvqDug/QgQjX5E6DGyxJjXQLrOob6U+CaFrjwURF2t1Bt0PY0LfaOwpqlxCEPOhHjPK3AtblqkIr9KpryfKP5+B09fie/ycTO8TByNe1DUvQDmJR+wd+kBrU08dlgS1vbDAavMXOXzQSe+9NKnWxlRHTIrad09l7GMArDMm+XEm7zuEv/5yg4wLJdaZLWvKg40i82kxBbhVjzrRWhkZjkDorER8Zx05cRQIyBPH7O9E7VCX53oBCp4K/H7lGqgqcVt4TSUj5dhg==
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=2lmPPQSJPIh/0hicq1OhWGZWXyBElbOUrRazTpqDpks=; b=BFiKibtOlDBxr8pDT5agji5yRIpUJMu1hicCeUqTxQznno1pheV7w4SeKTN+tzBUmK4stFcQNfyiZhVpAQNyIXBsAI7AMZdeM1gJcPnIssadXWAuRX3lBJ376NKzaTzhQsXWo+SbHoPo2YsWtJB1IEyjhGsNyk0Gxw1Qme7Dg2zmnlAd4xNZ0LDEeRIdRbl35aESfi4KyS5HcNsbcDDNYKzybb+haaIiLedBxkQEbnbHblgaOGgmUnULnpGI4jb9tCu3BcKP8+S3njM2vuNJsFehi5xRXeYZd4AEEsgx35tUAVNtwn1XC9wYmEQkMgQfJzhNyEM8mQ2Fu5PzKah63g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2lmPPQSJPIh/0hicq1OhWGZWXyBElbOUrRazTpqDpks=; b=Po4lqiwOmGxS49vHJHVmm3+rQo/HJxAj8ylJ+Xwuzx+0sANrLJ1qSnwd42KvdLOYR6XlRhPpjcR4fIkD8qw68QGrTGtk8L7S2ZHyeKNeuMNqX/hrgtiygcOiRggSfZ4tQq3U74bc0WyUF+kvaa9gvuMZzayROX1Pylckl7FGyK0=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by CO1PR11MB4851.namprd11.prod.outlook.com (2603:10b6:303:9b::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17; Thu, 3 Dec 2020 10:26:55 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::bcfe:ddee:3f3e:577]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::bcfe:ddee:3f3e:577%5]) with mapi id 15.20.3611.034; Thu, 3 Dec 2020 10:26:55 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>, Alexander Okonnikov <alexander.okonnikov@gmail.com>, "Acee Lindem (acee)" <acee@cisco.com>
CC: "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Link Data value for Multi-area links
Thread-Index: AQHWxBVvac0UdmyaYk+uNcVNf4WqG6nb3tuAgAAQagCABIaugIAACIGAgABuDwCAAAWfgIAAB4aAgAQpgUCAAA/CAIAAAgmw
Date: Thu, 3 Dec 2020 10:26:55 +0000
Message-ID: <MW3PR11MB457061E350112785A7716DD4C1F20@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <61201EB5-3F36-401A-9D39-FB0C577C7966@gmail.com> <3d3d863b-3e1f-ea87-0c45-09e119aa7c8f@cisco.com> <3FE4F6F8-6819-425E-852F-6B5B968ECAF5@gmail.com> <57b88873-b0e9-c2d3-2732-7f2629eebf27@cisco.com> <5D89BE28-934A-4EE3-915A-456AAD7AC59C@gmail.com> <F386F007-BA51-44B6-9795-18DE3E564D75@cisco.com> <AM0PR07MB6386BE057F092AD0837FE299E0F50@AM0PR07MB6386.eurprd07.prod.outlook.com> <ED93174A-F221-4EE4-9FCF-04442218628D@cisco.com> <MW3PR11MB4570EA1008B66087C060EBBDC1F20@MW3PR11MB4570.namprd11.prod.outlook.com> <a3595464-df30-a503-fe24-90b1ff81224e@cisco.com>
In-Reply-To: <a3595464-df30-a503-fe24-90b1ff81224e@cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
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=cisco.com;
x-originating-ip: [72.163.220.30]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1357776a-2c21-4f22-8deb-08d89775f570
x-ms-traffictypediagnostic: CO1PR11MB4851:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <CO1PR11MB485178D3AE0C949808847C4BC1F20@CO1PR11MB4851.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: iULmNA257h5x4nKBdtGriLGQjssqSgeWsdsw9AjpaspiYNdq0OZI+aJ8JdKcew4BnVdJe3zdzcTEL35i46LouTqYe+/TfMTnhb27M9iWjHV5lN0HqyTLjzfOGQUUUavSi67LgdyEIJGfS8mLvci46zoiam+e+iEDO396KhTGu5Hg6Uy3KKnMHItIuy5m7eey2IH08wNwIfSw/rPQUR3tXQoRSru3rw9q/UCIpDRyrUQeiVxPjaDmB9p3mHxLmC1g+wqC1QepBEJ2Ps3hnVERqec1+74OYODxa/uZMxsMlcPb4C0NcgYX4iterMW/ZXjxwQWI96qDZJfhDAd5nSbZtWzL416hiF0mu8E6qiW1bUYDf465nG1xs6eSg6bo59uaOgHmzrGGjqpobrnjHpuCJA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(346002)(376002)(396003)(366004)(39860400002)(33656002)(6506007)(9686003)(186003)(53546011)(8936002)(83380400001)(66574015)(478600001)(966005)(316002)(86362001)(110136005)(7696005)(26005)(76116006)(55016002)(8676002)(66946007)(30864003)(64756008)(5660300002)(66556008)(4326008)(66476007)(71200400001)(2906002)(6636002)(52536014)(66446008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: a7N6dpAsDpIII3SQjFTzwOFvDbWXSYk7ujca3SvEsXV/lYXzHlA0607u7vEdIU/TKJOL7DXeplSNKwOkjV97sG7pG3JSWoqDG8ffKJWNgA0WZBWqacpnok44dk952JDwjIVb/+eVLzaA3v2Ae4PC3PtngnCEJav5TJLVl6ThUltqVYMHBihCwN12LUxlX+wG3lDYVX4xxQQlQVDnZsK3VTl0Kyg+4J7M4QZ2EXREER7TxScQkriKYrkm7LMKtimncr0UlaqhJo5+lW/TrUdXzCl0hZ4+d9jH2D+AAkAuUgPckyWBSd/IydbHe4AiXnkHKFA79IZAjVuE3JqhpOg8eZTJRi5HOWiNwZVC5ApC9ldsX/MwhVF2ednjGZXYfZgSyeYr/dAXoVHhsJc4CQrR37Ti+xFd3L7kChEbiRdnMMfL1ytapj/EH7KnzyjMPRFg90Erp54fJYsI75Ijhn2W90yiZuxyvLNioz3asFhXQ6ra/mVJn2OLSTfkqp4XOu9RlxtZuoXIPd+LGYrT0CbsoAT+x6ginAdM9zppW0QKqDGVa82Hgx44rUT7qbgtp5y7h1FzeXTj/ffVIa7Gmhl9tWsApK7c7krcj+5+/h5UvfjbkT+6GssSE5xPOpgsE3eVeGxU2wPbVtv8gQXkNU21dLVjCRyHHQQN7r4h623KS/NUJZnRG+ewTmgmOttHajW0V3t62QvRhmIHXyaqi9TnV3H0HUgPJ9LtdzMFyh9rK3w=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1357776a-2c21-4f22-8deb-08d89775f570
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2020 10:26:55.6602 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 5Z6QxKm7AGNb3mxGNJgTg6VuPZ6PKdr11p8zfbTBEaPARiI5inXs8z0EoxY7Mq4XLDOWzXH9geuxf/iOr/Fv7w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4851
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/RoXtWQ-WBFBYaBnW90pDvnPMfRU>
Subject: Re: [Lsr] Link Data value for Multi-area links
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2020 10:27:01 -0000

Hi Peter,

Please check inline below.

-----Original Message-----
From: Peter Psenak <ppsenak@cisco.com> 
Sent: 03 December 2020 15:48
To: Ketan Talaulikar (ketant) <ketant@cisco.com>om>; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>rg>; Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com>om>; Alexander Okonnikov <alexander.okonnikov@gmail.com>om>; Acee Lindem (acee) <acee@cisco.com>
Cc: lsr@ietf.org
Subject: Re: [Lsr] Link Data value for Multi-area links

Hi Ketan,

On 03/12/2020 10:31, Ketan Talaulikar (ketant) wrote:
> Hello All,
> 
> The text in RFC5185 for picking the neighbor’s IP Address or IfIndex 
> for the link-data is indeed very odd and flies against how things are 
> done for normal p2p links per RFC2328.
> 
> The implementations that I am aware of do not really following this 
> “decision” of RFC5185 and instead stick to RFC2328 architecture by 
> picking the local IP address or IfIndex even for MADJ links. This way, 
> a remote router cannot really distinguish between a normal P2P link or 
> a MADJ – they look the same in the LSDB.
> 
> While the neighbor IP address can be learnt via the source address 
> used for the hello messages, there is really no simple way to learn 
> the neighbor’s IfIndex for unnumbered links [1].

rfc8510?
[KT] Yes

> 
> So IMHO the RFC5185 is in error and we should fix this if we have 
> consensus in the WG via a BIS as suggested by Acee.


I'm not convinced about the error. Nor about the need of the bis.
[KT] The question is why is RFC5185 not aligned with base OSPF RFC2328 on this aspect? What was the need for MADJ to have a reverse link-data information as compared to normal P2P links?

Thanks,
Ketan

my 2c,
Peter


> 
> Gunter, I am not getting into your other questions because of what 
> I’ve mentioned above 😊
> 
> Thanks,
> 
> Ketan
> 
> [1] Note that over time we have introduced such mechanisms (RFC8510), 
> but they have all been optional and not “base/required” behavior.
> 
> *From:*Lsr <lsr-bounces@ietf.org> *On Behalf Of *Acee Lindem (acee)
> *Sent:* 30 November 2020 23:18
> *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) 
> <gunter.van_de_velde@nokia.com>om>; Alexander Okonnikov 
> <alexander.okonnikov@gmail.com>om>; Peter Psenak (ppsenak) 
> <ppsenak@cisco.com>om>; Acee Lindem (acee) <acee@cisco.com>
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] Link Data value for Multi-area links
> 
> You are welcome to propose an alternate solution which could possibly 
> be accepted as a BIS document. However, this is not something that can 
> be simply changed in an Errata to reduce the complexity.
> 
> Thanks,
> Acee
> 
> *From: *Lsr <lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>> on 
> behalf of Gunter Van de Velde <gunter.van_de_velde@nokia.com 
> <mailto:gunter.van_de_velde@nokia.com>>
> *Date: *Monday, November 30, 2020 at 12:21 PM
> *To: *"Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org 
> <mailto:acee=40cisco.com@dmarc.ietf.org>>, Alexander Okonnikov 
> <alexander.okonnikov@gmail.com 
> <mailto:alexander.okonnikov@gmail.com>>,
> "Peter Psenak (ppsenak)" <ppsenak@cisco.com 
> <mailto:ppsenak@cisco.com>>
> *Cc: *"lsr@ietf.org <mailto:lsr@ietf.org>" <lsr@ietf.org 
> <mailto:lsr@ietf.org>>
> *Subject: *Re: [Lsr] Link Data value for Multi-area links
> 
> The oddnes is that the architecture decision in RFC5185 to select 
> remote-ip-address instead of local-ip-address for the ‘Link Data’ is 
> making things much more complicated.
> 
> I am surprised to see that using the remote-ip-address is seen as the 
> ‘better’ choice as selecting local-ip-address. To me it seems as a 
> worse choice.
> 
> A question that was asked: How router will be able to match Link TLV 
> (RFC 3630) to corresponding Link in Router LSA?
> 
> Answer:
> 
> For unnumbered links we can match Link TLV with Router TLV using the 
> IfIndex when there is no stub type 3 link (=easy)
> 
> For numbered:
> 
> 1.we must first look if the there is a stub type 3 link
> 
> 2.If stub type 3 exists, then the RFC3630 local ip address must be 
> used to identify the correspond link within the router TLV to the 
> neighbor
> 
> 3.If the stub type 3 link did not exist in Router TLV link, then the 
> maybe the link is unnumbered, and we try to match upon IfIndex… This 
> may give a match or no match
> 
> 4.If there is no match, then maybe the link is MADJ and we must use 
> the
> RFC3630 remote IP address to match upon the Link Data
> 
> 5.= over-complex. (If we used  for RFC5185 ‘Link Data = local ip 
> address’ then (2) would given answer directly)
> 
> In addition, for a router it is much simpler to learn and advertise 
> local-ip-address in Router LSAs then using a remote-ip-address.
> 
> I also believe that if we want to search something in TEDB after 
> receiving a TE Link TLV. How can we identify from the TE Link TLV if 
> multi-area or not multi-area? If we can not, then how can we create 
> the correct key?
> 
> Looking at the above, the choice of using remote-ip-address for 
> RFC5185 Link Data seems not the best design that we can do, and is 
> adding OSPF complexity without benefits.
> 
> Should this not be corrected in RFC5185 and simply use 
> local-ip-address instead of the remote-ip-address for Multi-area Link 
> Data and avoid the additional unnecessary complexity the current RFC for numbered links?
> 
> Brgds,
> 
> G/
> 
> *From:*Lsr <lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>> *On 
> Behalf Of *Acee Lindem (acee)
> *Sent:* Monday, November 30, 2020 18:01
> *To:* Alexander Okonnikov <alexander.okonnikov@gmail.com 
> <mailto:alexander.okonnikov@gmail.com>>; Peter Psenak (ppsenak) 
> <ppsenak@cisco.com <mailto:ppsenak@cisco.com>>
> *Cc:* lsr@ietf.org <mailto:lsr@ietf.org>
> *Subject:* Re: [Lsr] Link Data value for Multi-area links
> 
> Hi Alex,
> 
> Multi-Area interface disambiguation is required to support the OSPF 
> MIB as specified in RFC 4750. The table indexing doesn’t include the area.
> For example:
> 
> --  OSPF Interface Table
> 
>    ospfIfTable OBJECT-TYPE
> 
>         SYNTAX       SEQUENCE OF OspfIfEntry
> 
>         MAX-ACCESS   not-accessible
> 
>         STATUS       current
> 
>         DESCRIPTION
> 
>            "The OSPF Interface Table describes the interfaces
> 
>            from the viewpoint of OSPF.
> 
>            It augments the ipAddrTable with OSPF specific information."
> 
>         REFERENCE
> 
>            "OSPF Version 2, Appendix C.3  Router interface
> 
>            parameters"
> 
>         ::= { ospf 7 }
> 
>    ospfIfEntry OBJECT-TYPE
> 
>         SYNTAX       OspfIfEntry
> 
>         MAX-ACCESS   not-accessible
> 
>         STATUS       current
> 
>         DESCRIPTION
> 
>            "The OSPF interface entry describes one interface
> 
>            from the viewpoint of OSPF.
> 
>            Information in this table is persistent and when this 
> object
> 
>            is written the entity SHOULD save the change to 
> non-volatile
> 
>            storage."
> 
> INDEX { ospfIfIpAddress, ospfAddressLessIf }
> 
>         ::= { ospfIfTable 1 }
> 
> Note that if you really want to support this optimally, you could use 
> a separate subnet pre-area and have adjacencies on secondary 
> addresses. My Redback/Ericsson implementation allowed for this.
> 
> Thanks,
> 
> Acee
> 
> *From: *Lsr <lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org>> on 
> behalf of Alexander Okonnikov <alexander.okonnikov@gmail.com 
> <mailto:alexander.okonnikov@gmail.com>>
> *Date: *Monday, November 30, 2020 at 5:27 AM
> *To: *"Peter Psenak (ppsenak)" <ppsenak@cisco.com 
> <mailto:ppsenak@cisco.com>>
> *Cc: *"lsr@ietf.org <mailto:lsr@ietf.org>" <lsr@ietf.org 
> <mailto:lsr@ietf.org>>
> *Subject: *Re: [Lsr] Link Data value for Multi-area links
> 
> Hi Peter,
> 
>     30 нояб. 2020 г., в 12:56, Peter Psenak <ppsenak@cisco.com
>     <mailto:ppsenak@cisco.com>> написал(а):
> 
>     Hi Alex,
> 
>     On 27/11/2020 13:49, Alexander Okonnikov wrote:
> 
>         Hi Peter,
>         Which kind of ambiguity is meant? In case of numbered
>         point-to-point each link has its own unique IP address, so there
>         is no ambiguity.
>         Per my understanding this problem has appeared due to follow
>         reasons:
>         1) In old versions of the draft (up to -05) it was proposed that
>         multi-area links are treated as unnumbered. ifIndex to be
>         encoded in Link Data field, irrespectively whether interface has
>         its own IP address (numbered) or borrow it (unnumbered);
>         2) From -06 to -08 multi-area links are still treated as
>         unnumbered, but if interface is numbered, then IP address of the
>         neighbor (rather than local one) to be encoded into Link Data,
>         in order to make the link look like unnumbered;
>         3) In version -09 of the draft and in RFC 5185 itself there is
>         no more mentions that multi-area link to be treated as
>         unnumbered. Rather, another approach is used - if router's
>         interface is numbered, then link is also numbered; if router's
>         interface is unnumbered, then link is unnumbered. The rule that
>         specifies omitting corresponding type 3 link is added. Mention
>         of 'unnumbered' link is also removed from section 3 in RFC 5185. >
>         Hence, in version -09 with removing unnumbered nature of
>         multi-area links Link Data for numbered links had to be changed
>         from Neighbor's IP address to own IP address, as it is specified
>         in RFC 2328. From perspective of other routers this link can be
>         treated as numbered or unnumbered, depending on configuration of
>         neighbor's corresponding interface.
> 
> 
>     you are free to advertise the link as unnumbered. RFC5185 is not
>     mandating to send IP address really.
> 
> The same valid for numbered ones. I.e. I'm free to advertise the link 
> as numbered. This is straightforward when the link is numbered indeed. 
> And if we would prefer to have deal with unnumbered interfaces, we 
> would not need RFC 5185 (section 1.2).
> 
>         One question - how neighboring router will perform next-hop
>         calculation (in case it needs to do so)? If neighbor is
>         configured with numbered interface, it will treat Link Data as
>         IP next hop, which will be its own IP interface address.
>         Another question - how router will be able to match Link TLV
>         (RFC 3630) to corresponding Link in Router LSA? For example, we
>         want to calculate RSVP-TE LSP based on IGP metric (RFC 3785) and
>         thus router needs to match IGP link to TE link.
> 
> 
>     I don't believe you are going to do any traffic engineering over a
>     multi-area adjacency. MADJ is there to address the OSPF route
>     preference rules that may lead to sub-optimal routing. MADJ link is
>     not advertised for TE purposes.
> 
> Why not? We need multi-area configuration and at the same time we need 
> ability to build intra-area RSVP-TE LSPs within each of areas. And 
> what about calculating IP next hop? Which compatibility is meant in section 3?
> 
>     thanks,
>     Peter
> 
> Thank you.
> 
>         Thank you.
> 
>             27 нояб. 2020 г., в 14:50, Peter Psenak <ppsenak@cisco.com
>             <mailto:ppsenak@cisco.com>> написал(а):
> 
>             Alexander,
> 
>             On 26/11/2020 17:58, Alexander Okonnikov wrote:
> 
>                 Hi WG,
>                 RFC 5185 says that Neighbor's IP address to be encoded
>                 into Link Data field. Per RFC 2328 router's own IP
>                 address to be encoded into Link Data. What is the reason
>                 to advertise neighbor's IP address for multi-area links
>                 and not local IP address? It seems like bug. Could
>                 someone comment on this?
> 
> 
>             Advertising a neighbor address/ifindex helps to eliminate
>             ambiguity in case of parallel point-to-point adjacencies.
>             It's not perfect, but that's how it was specified. So it's
>             not a bug.
> 
>             thanks,
>             Peter
> 
>                 Thanks in advance.
>                 _______________________________________________
>                 Lsr mailing list
>                 Lsr@ietf.org <mailto:Lsr@ietf.org>
>                 https://www.ietf.org/mailman/listinfo/lsr
>