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

"Acee Lindem (acee)" <acee@cisco.com> Mon, 30 November 2020 17:01 UTC

Return-Path: <acee@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 89E543A0FD2 for <lsr@ietfa.amsl.com>; Mon, 30 Nov 2020 09:01:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.619
X-Spam-Level:
X-Spam-Status: No, score=-9.619 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=ln+BjkuI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=HBT9Yai6
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 R7UZrLcy0cmN for <lsr@ietfa.amsl.com>; Mon, 30 Nov 2020 09:01:02 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0BD3A0FCC for <lsr@ietf.org>; Mon, 30 Nov 2020 09:00:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27019; q=dns/txt; s=iport; t=1606755659; x=1607965259; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=d4sAMeJSRrJFLMDL7KnabZZyzODjm2SzGvCRx+NinhI=; b=ln+BjkuIPsc6esRWRgRB9GXyx9KrR/NLKUP1yg3G4fYLjrpKfJHbOfIX NlKoE+xYV2eMqZn6pdf/8YVns61jAr5nqO5Lf1bMCM4dsIqM2syaWacHt LpGDcpYo5tAAp1w+/c449Z6g/z1r5gxpBOCfHAo526hNG7/iUGEEn8ken I=;
X-IPAS-Result: =?us-ascii?q?A0BWCgCNI8VffZNdJa1iHgEBCxIMgzIvUXxaLy4KhDODS?= =?us-ascii?q?QONMieKFo5wgUKBEQNUCwEBAQ0BARgBCgoCBAEBhEoCF4ISAiU4EwIDAQEBA?= =?us-ascii?q?wIDAQEBAQUBAQECAQYEFAEBhjwMhXIBAQEEAQEQER0BASwLAQ8CAQYCEQMBA?= =?us-ascii?q?igDAgICHwYLFAkIAgQBDQUigwQBgX5XAy4BDpE9kGsCgTyIaXaBMoMEAQEFh?= =?us-ascii?q?QgNC4IQAwaBOIJzg3aGVxuCAIEQAScMEIInLj6CG0IBAYFFBC0JBhCCYTOCL?= =?us-ascii?q?JN8hySLajaQHzhXCoJwkACGFYUXAx+WGot6HZNIjXqSdQIEAgQFAg4BAQWBb?= =?us-ascii?q?SGBWXAVOyoBgj5QFwINjiGDcYUUhUR0NwIGAQkBAQMJfIw0AQYhgQ0BgRABA?= =?us-ascii?q?Q?=
IronPort-PHdr: =?us-ascii?q?9a23=3AaIT8jxVOQWn4fZVcPHzBxUtntmjV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyHuf1BguvS9avnXD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7dp3Sz6XgZHR?= =?us-ascii?q?CsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.78,382,1599523200"; d="scan'208,217";a="619789645"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Nov 2020 17:00:46 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AUH0kAX004776 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 30 Nov 2020 17:00:46 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Nov 2020 11:00:46 -0600
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Nov 2020 11:00:45 -0600
Received: from NAM04-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 30 Nov 2020 11:00:45 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y9C6nVdg0tzm69ALaWvD0jI+PQs2sVRUnlajv0cPTx+KpQLutE567Lmb9TYQI3/JLKW4Asvve98/gQroUFqmZYl7d2dAggTbd9U8mn6U5MCs5sPnOiWFLp4CWR8BfcxFXs47M8Kd9c7MlMFo1N2mMTQZ52G53z2o8UY4SKvmBO/izfIc3V6GTzjVHe1/NKvE3ofA5LpUlrogNq5eutYB8m2bQF8MinEGYRuMvw3wS8EdAvcnN3IhtgtFZ9sTr+RZovsj14ZJnbnc7s6ybcGfKVQQ60dvIRhviI/iUCnYK8GDZU6dQWZJSyt8RzkxKBpj/ULYF6jvm/vtGcPEb6UspA==
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=d4sAMeJSRrJFLMDL7KnabZZyzODjm2SzGvCRx+NinhI=; b=NRrYcbQYqAPkVpn2QkB7p51IM9D5YUPZvjlPnLUr6ApG7gbW5sRCW2afGgHFw0NkK0+hX5QC747e+aT+9GkKCoegzhPcSGnBA7DkNlDHYMiQmjFMb+qetUPFEJ3sJ2Sl5TCu4dYdSMzHbQ/AZlF4Zo3t81kd/45rmJsm4U78ed0JwQUlyv5Kn5ALtEIfv/26k5rDqhIzGxMGBDIP6n4wG4LLnQeuHQDG97bOIapusW7YbnM3YhdHHOIoPFcExk2bLzt81dvHeKgeCy7yfQUk9wlCiLzygaKPAyKB34RBShxpH3Z6iWL8JBjkoJaXyQ2lK0UGQcVlcMhFwMttVtLkaw==
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=d4sAMeJSRrJFLMDL7KnabZZyzODjm2SzGvCRx+NinhI=; b=HBT9Yai6PAel2+ePDl3tSKVtLQprPyBjcZt/q6+GMP0PzIHqefy9PP4oIhfqAnQEatL6X7W3nouQzZI3jCEMDWxHN8QLeAfEbsgkRIAH7NkQM8EU4by+LBTVzaKwExZSO+L5Xq1s/IIjqI3zH/7jbL16/o++ndvBgRbjdafPI/U=
Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BYAPR11MB3512.namprd11.prod.outlook.com (2603:10b6:a03:8f::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.31; Mon, 30 Nov 2020 17:00:44 +0000
Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::65a7:2fad:a960:2557]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::65a7:2fad:a960:2557%3]) with mapi id 15.20.3611.031; Mon, 30 Nov 2020 17:00:44 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Alexander Okonnikov <alexander.okonnikov@gmail.com>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>
CC: "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Link Data value for Multi-area links
Thread-Index: AQHWxBVvmcttObV0lkektoHkq/Bmaqnb3tuAgAAQagCABIaugIAACIGAgAAaOoA=
Date: Mon, 30 Nov 2020 17:00:44 +0000
Message-ID: <F386F007-BA51-44B6-9795-18DE3E564D75@cisco.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>
In-Reply-To: <5D89BE28-934A-4EE3-915A-456AAD7AC59C@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.43.20110804
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [136.56.133.70]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 37899ce8-99ba-4f53-36fd-08d895517a27
x-ms-traffictypediagnostic: BYAPR11MB3512:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR11MB3512E960037AEF887E4F4F52C2F50@BYAPR11MB3512.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: spcxzZK4cwQOTkUXYFyU5CQgAzXKkfbS15ybmOKa65ad6Vl43s9K0NxBhgCqifI3F2dAyRAe6oqUerSL3JASf2g7pODeQHd2YApIsicGhvDorU4yUoFmpNuw2aG2A4Wtg241LdDdd+fg8FtAui0EjFsSVOF+/L11spRVsfRi9uw7m5FAcMWuP8zZf8cdCsmSkRuerH3MhvYe+NQWTdNia8XGHmTus6Hh7C3o65RYBcP/xuZU5+4L+NxV5j+VHs2skF5HN9up+ox2q+FVWrUKXgGV2gQ8Anaj+YVzGA6MdI5CMey3zTMvAJcaqeTv6CduzPIgx0pkL42RY+lzR99zvBTxtt9WrBoMK0c1Yj2mPxDpWO/Kz3sxuyqn1SyNnbfZdkH/uWye26VeHI5YoHthIg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(346002)(376002)(136003)(39860400002)(396003)(36756003)(2616005)(186003)(26005)(316002)(110136005)(66946007)(66446008)(66556008)(66476007)(64756008)(6506007)(5660300002)(53546011)(9326002)(6512007)(76116006)(8936002)(966005)(66574015)(8676002)(86362001)(2906002)(71200400001)(33656002)(83380400001)(6486002)(6636002)(478600001)(4326008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?Und2RDMvZEN3RlFKQ1JoempWZkRPVHdzanNlUE1uR21HVzlBQzNoM3Rhd0pU?= =?utf-8?B?TW5jYkIzSXIzUXkybVhSSTZGZTd1NDlWQ2s0eko2Wk8yQXZjbkJkSy9rQzFO?= =?utf-8?B?bzB5b243UEgvaENVQU9RelRJelBxUGU2YWJmR1c4R25sK05TRE95OFVxZFIr?= =?utf-8?B?ZlVDRmc4S0ZKSGxjN0hrUloyKzlGWVpWTVQvS2luVGVHYitYZzh1VXIxR3dY?= =?utf-8?B?MEFiandaUE9yWjhFUFIrNllsRXZiUHN5NmorVllXQ0gzTU1XdlQxMzNnNTg3?= =?utf-8?B?dUU4VnlrdDNYTDBzUEkvRTYyU3U0U0s3RnJ2QXJlNENrUzd4Qmg3Z2ZNOXdr?= =?utf-8?B?N2N4NHVNMnJBRUxuNUFacTdmanlPQ0pkSE90RVdLcE5JNEYxanBiL1JpOHo2?= =?utf-8?B?MEVXNzRoY3J0TkpvUVl5Sy9ma1NLa1dpSGZqUk9MRzRJb1Fiakd0TUdZelQ5?= =?utf-8?B?QmFKZUtxaE9QVC9vRGtIVkRCejJodGpxWWo4Z2RIMXJaTHJyVHpPWGJPTDNI?= =?utf-8?B?QjJZV3hITUM3V2N1dy81TFF2cG8xaXcxN1dsYnZONTJtUit3aldmSTlmelVw?= =?utf-8?B?ci9ndG5LSDR3OUk2V0JkaUlWM3lBbDNPbE1CUkwzdEdBMHJXcTRabVd4ZXBQ?= =?utf-8?B?ZjZJYmlxeUowYWlPNmw5QWV3V0lvVktlY3JZZVJhbGlTaUdVQXhvaXp2N3hy?= =?utf-8?B?TjdvU095eG5veW9NNkIzZWpSYWtSbFY3NWhmY1h4dkthV2gxQlU1Qm1FZXkr?= =?utf-8?B?Q0NaZ2N3aXMycW1UZ1E0ZUdHK3JoTDdxUDdjQk5CaUpQSmFQUFd4eVorMlJJ?= =?utf-8?B?WmRxbnlLOXprVjk1TkpJOUFuRkh2aE4rVzZScS96ZnJlTXM2V0dEeUlYSytP?= =?utf-8?B?MFFMYWx0N0UwdWUwcGJBRUx0bm1SRU5OY3gwcVdBT29PRzJiUjNzSE1WeUh5?= =?utf-8?B?WEVCVFZKMFN6Q1ZWRlFWRnVQUU9acmlvSmR5NmVybkNsZHo0K2FtNnFHaWFk?= =?utf-8?B?M3RrN2g0Q1A1azlDWk9ibnYwMGlNQnJNbUM0Rm95NUpueCttTndhclNiQ3dW?= =?utf-8?B?Vzc3ckpVR3NHNkgvd2QvRkt6SEYvc1laWW0rT3NZMW0xTysvRzdjWEw3ZWgy?= =?utf-8?B?L3ZON0tvNFhOcEJRVlVjUldlNzlGMlZhVGZ4WnpDWkFWSDd6eCsyWVkzazd0?= =?utf-8?B?cXc0ZW9MeExvQWJMblZaWUs4azNna2tHNW90RnVyUEk0Sks3QTRGb0oySGZl?= =?utf-8?B?ZTRIR2xBZDI3RFhEaWF5ZEE4SXl2RjE1ZjY3WFlYQ1pibUp0bEZVcGtrWVl4?= =?utf-8?Q?Zq9c95WqcEnaQwqA2CJml9RYfQop1tW2OC?=
Content-Type: multipart/alternative; boundary="_000_F386F007BA5144B6979518DE3E564D75ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 37899ce8-99ba-4f53-36fd-08d895517a27
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2020 17:00:44.5456 (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: a6QeubB2/8F+NR5uGvVhlFiBVrqUM/G2pagIo16EmuySbAc5HfOnT0+FKTfjZUQO
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3512
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/hNX5UbjwoPX50uK-uQ6Ypld6juE>
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: Mon, 30 Nov 2020 17:01:05 -0000

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> on behalf of Alexander Okonnikov <alexander.okonnikov@gmail.com>
Date: Monday, November 30, 2020 at 5:27 AM
To: "Peter Psenak (ppsenak)" <ppsenak@cisco.com>
Cc: "lsr@ietf.org" <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