Re: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for External/NSSA prefixes defined in RFC 8665

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Wed, 19 August 2020 10:11 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 490623A1741 for <lsr@ietfa.amsl.com>; Wed, 19 Aug 2020 03:11:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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_H4=0.001, RCVD_IN_MSPIKE_WL=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=XFH5F9HC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Xdiqtsah
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 RNDnR5oTWAX4 for <lsr@ietfa.amsl.com>; Wed, 19 Aug 2020 03:11:37 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C9743A083E for <lsr@ietf.org>; Wed, 19 Aug 2020 03:11:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11228; q=dns/txt; s=iport; t=1597831897; x=1599041497; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=kPQBKk2+4R0KPAU5f8eicF0ZqGeq2M9+M5qzBjDLhGo=; b=XFH5F9HCBTdODoKqCXrgHio23hIYKa+wbZW89YpfLdo9qkNfl96jX1O+ GzbeVL/mUHCNqflmX1wR7mSeEQujvROrez89mNHH36uaCnfSZgPyNncUV G3nNlw8DGO0a6j3GZtgLtDfQvsOEGCXqLl3GKR+BoMu/DvOdCNhMUYR8V I=;
X-IPAS-Result: A0D2BQCM+jxf/51dJa1fHAEBAQEBAQcBARIBAQQEAQFAgUqBUiMuB3BYLywKhC2DRgONXJhsglMDVQsBAQEMAQEYCwoCBAEBhEwCF4IYAiQ4EwIDAQEBAwIDAQEBAQUBAQECAQYEbYVcDIVxAQEBAwEBARAREQwBASwMCwQCAQgRBAEBAQICHwcCAgIlCxUICAIEARIIGoMFgksDDiABDqY2AoE5iGF2gTKDAQEBBYU9GIIOAwaBDiqCcYNihkwbgUE/gRFDgh8uPoEEgVgBAQKBXxWDADOCLZMFkkCQcgqCYppDgwGJXpEggiiSP59EAgQCBAUCDgEBBYFqI4FXcBU7gmlQFwINjh8MFxSDOoUUhUJ0AgEBMwIGAQkBAQMJfI5VAYEQAQE
IronPort-PHdr: 9a23:jwpIsRaY0EShtt76knFV5E//LSx94ef9IxIV55w7irlHbqWk+dH4MVfC4el21QWVD4ne4uhPzevbr66mXnYPst6Ns3EHJZpLURJNycAbhBcpD8PND0rnZOXrYCo3EIUnNhdl8ni3PFITFJP4YFvf8XG35CQZXBTyKQQzIf76Scbeis2t3LW0/JveKwxDmDu6Z+Z0KxO75QXcv8Ubm81sMKE0nxDIuXBPPe9RwDBl
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.76,331,1592870400"; d="scan'208";a="521657142"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Aug 2020 10:11:34 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 07JABYNT006473 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Aug 2020 10:11:34 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 19 Aug 2020 05:11:34 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 19 Aug 2020 06:11:33 -0400
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 19 Aug 2020 06:11:33 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Lq0r2KE5JkRoXp4Iu19kxT9dre1AVmj8MENBO8nFrsRKiGIHRQnwgaj55fFe7GkrrPRxeiyRfHrq2Xsc56jFH3bpgpxApVlvKmAG4NSlfO1pE7sVAQkDxBW8M6ptVfTPfWAdpIpCirmeRQuUYa3uIb7PPiuOex/FrHPU6Rt+JQKVy5Imk0MnTq5Z4qduo6aRTrHDlFxISI2mHJVO7/K5kAGNcCKLhBfnrvQyxT+9Ldq83kcWjxay2BvONuVDAY9tV2n30+ADUbsaCpAqcwFxDjtmLTnbD06DgmEswrCg7Ic0hNm4nZh+ncSKfsxHDZIaS+jDbpLovrlHNKlwwDaTKg==
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=kPQBKk2+4R0KPAU5f8eicF0ZqGeq2M9+M5qzBjDLhGo=; b=H+C1X6GRnsbpxYKwFUuEX8jUNL9BeepTRDnu6SYJzTlqQqKmfripVUioD1Goojp+Eu7WdBT3GPUxqIM9Sb6xyT/9DbYpLUYqgqOvZ1tiM40j06Fwv30VvIMkdWNBtNzeq0G32rB309/wbgmeSCWmZQ9PgZ1AHtW+tE/XPpskELC92EcGrTzTj2QXLynWXVOROVZDvD2ger1KZnyMi4hmnuIVni1hlbKtZpfLOcujIPDrfOo73+iLHZXyo1abglH27AODZyVvtwT98IcliTBpEclZa9hJNSthKpChRtctqNHrevviQJkED2zKXMtv8doY71eCx31fl4AXmEheBeh02g==
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=kPQBKk2+4R0KPAU5f8eicF0ZqGeq2M9+M5qzBjDLhGo=; b=XdiqtsahUaoxZ+ZkKDfwJTfvoum7f7XoZ79IUyZMaPLDsKYPyea39DtNVa5f22KkskoOGnJ3+YxtlW9haES8J0x4ZhXzeV+7M24FI7rdH7tE9Ede9+lJpSwb1nhajLyCh+9fy585p8w3QfLll9xrxfx4MqrYRA8PVxkV26jsAU4=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR11MB1712.namprd11.prod.outlook.com (2603:10b6:300:29::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24; Wed, 19 Aug 2020 10:11:32 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::3c42:544a:c4b2:6135]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::3c42:544a:c4b2:6135%8]) with mapi id 15.20.3305.024; Wed, 19 Aug 2020 10:11:32 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Veerendranatha Reddy V <veerendranatha.reddy.v=40ericsson.com@dmarc.ietf.org>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for External/NSSA prefixes defined in RFC 8665
Thread-Index: AdZ1bLVZomK+AP1qRgqOeyJr1fTjrwAGU2iAAABLkeAAFmiU4AAA4N5gAAHvoLAACPv6oA==
Date: Wed, 19 Aug 2020 10:11:32 +0000
Message-ID: <MW3PR11MB4570012C5749B15DFDA4A8EBC15D0@MW3PR11MB4570.namprd11.prod.outlook.com>
References: <DB7PR07MB3914AA1BF15E141673DF1E11BB5C0@DB7PR07MB3914.eurprd07.prod.outlook.com> <bb8d3f97-ec52-a91d-c3d6-896f86f498c1@cisco.com> <MW3PR11MB45708EA52FB3AA8E1BB8F199C15C0@MW3PR11MB4570.namprd11.prod.outlook.com> <DB7PR07MB3914AB432758DA51B94DEFE9BB5D0@DB7PR07MB3914.eurprd07.prod.outlook.com> <MW3PR11MB4570D671B21040F78EABC1A7C15D0@MW3PR11MB4570.namprd11.prod.outlook.com> <DB7PR07MB3914029BB21C1FCF41714E51BB5D0@DB7PR07MB3914.eurprd07.prod.outlook.com>
In-Reply-To: <DB7PR07MB3914029BB21C1FCF41714E51BB5D0@DB7PR07MB3914.eurprd07.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [72.163.220.24]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a4378cd9-2a39-48bc-a69d-08d844283f43
x-ms-traffictypediagnostic: MWHPR11MB1712:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MWHPR11MB17124B9720676295A7F0E3EDC15D0@MWHPR11MB1712.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: /10xUsMD8eutQbay6g874YKKJdGNJKHB0uR3QHUmQ9TNcfXBmPSo30sGE47je9RItWwGxS/8XpEdgiergzsD6UDgxUMCEc6fiiHIX+1E3ORB5339t+o7AunKScka2UTAxsLnXpVqOyTk5NbHGU5NoErvJ3KpkDO7SlKtApP2Uxu+l2gP659WA7UNK03N/5a3cX1gVPUA6PeNg50rY4Om5jEo+ZyLr0pGQknbhMKaMBviOyTMLA3DuSWzw4MFFUcrebzsCnsn48qvkCCm+T1y4u493np2Ze7NNo3oEZGG7p84xlGIaLXsCAGP8RFG7QJ9yeQTovynwy1E8Ope+XeiTg6ehgsciKhM2A21LTO/87aSxoJGbZ4h0LPHIwBHeLPhaiC28+cLgIvCc1/GYXGbdg==
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:(4636009)(39860400002)(396003)(346002)(376002)(366004)(136003)(478600001)(316002)(64756008)(110136005)(2906002)(66476007)(66946007)(33656002)(76116006)(66556008)(66446008)(966005)(5660300002)(8676002)(52536014)(26005)(71200400001)(83380400001)(7696005)(86362001)(66574015)(6506007)(9686003)(186003)(55016002)(8936002)(53546011); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: oP13HT6dtwsFd3yBdZGXl9oGAB13yJzNIRTKq91p1oQNOesifZtHjzIEIXSLd1170ATENDgyD8ui6Q0eUc+rteBuF6cxoZbJ7lsc+1b/3IROopHymHxLpjsBuzU+V9cOpX3sMx02I8VBEHpI4DdkVQalicFMqFrnmXWfodYMXIbYad9pJDaLYYJ350eCkx4bBfKk5KVsM4La2XZK6duXg+Sjg0wBHvuI82S+DdjVdp9JTGrmArcF+kd+X9WcSU/0RrM8agE2b9r3abStDLLBIbOvbzeZMQPYckMz2rabPM00w7prvuniVWkLtRYCmN4x/nyfhfRXr0oNOw8+S4igw1yDVCsZXJ8TjdvegXjLhzcQ3H0+GT2oDgBH+rqn1SgxnDm6Q0I/LZ/Z3+G4uCBnj7HvBlpPXQG34nUZKe7yP2RbBaWvOtaKtyopseKLQqh/tagliAM++t183MbI7NawoJJvVwIZ5PFeFWTGrP2XzhGpTg6NrfiLYrxHZZsLT2CvgodE8TAAqQblgi18sKXNL3dXQBK14YG1YA750k28M55AGIlLOW9F7/6fb7kXdGZEgrrjSbvRy1Sw/8odN7SkcOaOwlbhk8vdofQ1EvipdpzjHnOGYE2S5OU5lO2l+TtwjmH8mIv4a+0rPgBJOOSwtw==
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: a4378cd9-2a39-48bc-a69d-08d844283f43
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2020 10:11:32.2230 (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: jXbUXS6l6AbO95EqPdtZnAjMcy8GUjfbC3CNdVSgoBBOfZsRcYWGedp7lIEPkAE4EgV/5BUw+mD5+5ChLvapww==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1712
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/q38EdkCki3Q_VkLxhCXy1grmB5s>
Subject: Re: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for External/NSSA prefixes defined in RFC 8665
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: Wed, 19 Aug 2020 10:11:39 -0000

Hi Veerendranatha,

Please check inline below with [KT2]

-----Original Message-----
From: Veerendranatha Reddy V <veerendranatha.reddy.v=40ericsson.com@dmarc.ietf.org> 
Sent: 19 August 2020 13:07
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Peter Psenak (ppsenak) <ppsenak@cisco.com>; lsr@ietf.org
Subject: RE: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for External/NSSA prefixes defined in RFC 8665

Hi Ketan,
Please find the response in line.

The IA flag in the OSPF Extended Prefix Range TLV does not indicate that the prefix-SID mapping advertised via it is for use for only intra or inter area prefixes. The mappings can be used for assignment of SIDs for ALL types of OSPF prefixes - regardless of the IA bit.
The IA flag is only to prevent looping during flooding of area-scoped LSAs with OSPF Extended Prefix Range TLVs when they are propagated across areas.

[V] As per RFC,
IA-Flag:  Inter-Area Flag.  If set, advertisement is of
               inter-area type.  An Area Border Router (ABR) that is
               advertising the OSPF Extended Prefix Range TLV between
               areas MUST set this bit.
I thought, when prefix Ranges with SID are advertised from Intra to Inter, we need to set this flag. So that it indicates the prefixes are of inter area type. Please let me know if my understanding is not correct.
[KT] What is says is "the prefix range advertisement is of type inter-area or intra-area" (think of it as somewhat equivalent of the D bit in ISIS when leaking across levels). That does not mean that the advertised mappings need to be used for only for intra or inter area prefixes respectively.
[V] When we receive the range TLV received at ABR, while it is originating opaque LSA for that range TLV across the other areas, whether it is required to set IA or not?
[KT2] Yes - please check the RFC8665 Sec 4 - right after where the IA flag is described. 

When OSPF Extended Prefix Range TLVs are advertised using AS-scope, the NSSA notion does not apply for them and does not restrict their flooding into or from NSSA areas (or stub areas for that matter).
[V] If ASBR is part of NSSA, and if we redistributed Prefix SIDs learnt form other protocols or other instance of OSPF, and those prefixes are result of Range TLV  in that protocol, we can apply range in dest  ospf instance 
[KT] I do not follow above statement - can you please try to elaborate/re-phrase?
[V] When redistributing  Prefix SID information to NSSA from other protocols , it may possible to generate Range TLV, if multiple prefixes can be aggregated as range., instead of generating extended Prefix TLV for each prefix. So while originating this range TLV, how we can differentiate whether it is intra Scope or NSSA scope. So that when it is received at ABR, he will consider to translate to inter area Opaque or External Opaque for that range.
[KT2] I believe Peter answered and clarified this part. There is no notion of NSSA area or NSSA-scope flooding for the Extended Prefix Range TLV. 

Thanks,
Ketan 

Thanks & Regards,
Veerendranath



-----Original Message-----
From: Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org>
Sent: Wednesday, August 19, 2020 10:27 AM
To: Veerendranatha Reddy V <veerendranatha.reddy.v@ericsson.com>; Peter Psenak (ppsenak) <ppsenak@cisco.com>; lsr@ietf.org
Subject: RE: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for External/NSSA prefixes defined in RFC 8665

Hi Veerendranatha,

Please check inline below.

-----Original Message-----
From: Veerendranatha Reddy V <veerendranatha.reddy.v=40ericsson.com@dmarc.ietf.org>
Sent: 19 August 2020 10:03
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Peter Psenak (ppsenak) <ppsenak@cisco.com>; lsr@ietf.org
Subject: RE: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for External/NSSA prefixes defined in RFC 8665

Hi Ketan,
Please find the response in line.
The IA flag in the OSPF Extended Prefix Range TLV does not indicate that the prefix-SID mapping advertised via it is for use for only intra or inter area prefixes. The mappings can be used for assignment of SIDs for ALL types of OSPF prefixes - regardless of the IA bit.
The IA flag is only to prevent looping during flooding of area-scoped LSAs with OSPF Extended Prefix Range TLVs when they are propagated across areas.

[V] As per RFC,
IA-Flag:  Inter-Area Flag.  If set, advertisement is of
               inter-area type.  An Area Border Router (ABR) that is
               advertising the OSPF Extended Prefix Range TLV between
               areas MUST set this bit.
I thought, when prefix Ranges with SID are advertised from Intra to Inter, we need to set this flag. So that it indicates the prefixes are of inter area type. Please let me know if my understanding is not correct.
[KT] What is says is "the prefix range advertisement is of type inter-area or intra-area" (think of it as somewhat equivalent of the D bit in ISIS when leaking across levels). That does not mean that the advertised mappings need to be used for only for intra or inter area prefixes respectively.

When OSPF Extended Prefix Range TLVs are advertised using AS-scope, the NSSA notion does not apply for them and does not restrict their flooding into or from NSSA areas (or stub areas for that matter).
[V] If ASBR is part of NSSA, and if we redistributed Prefix SIDs learnt form other protocols or other instance of OSPF, and those prefixes are result of Range TLV  in that protocol, we can apply range in dest  ospf instance [KT] I do not follow above statement - can you please try to elaborate/re-phrase?

Thanks,
Ketan

Thanks & Regards,
Veerendranath


-----Original Message-----
From: Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org>
Sent: Tuesday, August 18, 2020 11:28 PM
To: Peter Psenak <ppsenak@cisco.com>; Veerendranatha Reddy V <veerendranatha.reddy.v@ericsson.com>; lsr@ietf.org
Subject: RE: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for External/NSSA prefixes defined in RFC 8665

The IA flag in the OSPF Extended Prefix Range TLV does not indicate that the prefix-SID mapping advertised via it is for use for only intra or inter area prefixes. The mappings can be used for assignment of SIDs for ALL types of OSPF prefixes - regardless of the IA bit.

The IA flag is only to prevent looping during flooding of area-scoped LSAs with OSPF Extended Prefix Range TLVs when they are propagated across areas.

When OSPF Extended Prefix Range TLVs are advertised using AS-scope, the NSSA notion does not apply for them and does not restrict their flooding into or from NSSA areas (or stub areas for that matter).

I am not sure if that answers your question.

Thanks,
Ketan

-----Original Message-----
From: Lsr <lsr-bounces@ietf.org> On Behalf Of Peter Psenak
Sent: 18 August 2020 23:06
To: Veerendranatha Reddy V <veerendranatha.reddy.v=40ericsson.com@dmarc.ietf.org>; lsr@ietf.org
Subject: Re: [Lsr] Regarding OSPF Extended Prefix Range TLV usage for External/NSSA prefixes defined in RFC 8665

Veerendranath,

On 18/08/2020 16:40, Veerendranatha Reddy V wrote:
> Hi Authors, All,
> 
> OSPF Extended Prefix Range TLV defined in RFC 8665 has IA flag to 
> distinguish between Intra and Inter Area scope prefixes.
> 
> Whether any restrictions to not to use Prefix Range TLV for 
> external/NSSA prefixes ?

I don't see how you can use OSPF Extended Prefix Range TLV for NSSA, the usage of OSPF Extended Prefix Range TLV has only been defined in the context of RFC 8665.

thanks,
Peter


> 
> For External Prefixes, we can able to use  Prefix Range TLV  by using 
> LSA type (based on AS scope Opaque Type , so the TLV is for External
> Prefixes)
> 
> But If we need to use the Prefix Range TLV for NSSA prefixes (Type-7) 
> , which are in area scope, there is no flag/route-type field in this 
> TLV to distinguish between Intra or NSSA prefixes( as IA flag will not 
> be set anyway).
> 
> Thanks & Regards,
> 
> Veerendranath
> 

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr