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

Veerendranatha Reddy V <veerendranatha.reddy.v@ericsson.com> Wed, 19 August 2020 07:37 UTC

Return-Path: <veerendranatha.reddy.v@ericsson.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 EE3E93A10E9 for <lsr@ietfa.amsl.com>; Wed, 19 Aug 2020 00:37:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 UP40-FopM92y for <lsr@ietfa.amsl.com>; Wed, 19 Aug 2020 00:37:09 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2073.outbound.protection.outlook.com [40.107.20.73]) (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 8BC893A10EC for <lsr@ietf.org>; Wed, 19 Aug 2020 00:37:08 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NvkNABqhG/vn0n8iicknfBfGd9Y0gaV1AHzQz7pwHMNIodZAMhFrV9lzu+S+NkmD4yjqdLJ7t1te97AS0jozjdjP1JP3yWVNpqcyoUrLJU2IVS3bDpvf6pthvxYeGP1sSmeWOqinRG2ZODAjNh/xkoO21yKHDhjCVJ/CIB0upu+tDmlwQPCgAI6JJ4EJaNp+83DzZMNx99Zb4RoEwumWcoM4hOwW4oBUWgaYrMGA7xRjVV/2op6Hk+iyb/KCJQGeuJtsgC1t/q3UbZsPSiBj9QR4uAqSWPNGqYSq/nMSelfwWwpcOY6TffkY2TaynYb0jyPnF2P439w00ctdLwOJJg==
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=6WsWbXSymE7kdBq2DUdk6DdwaOA+9wPA938Pk8OxaDI=; b=kW0yMHFX9UK2xj205bgb2zbq4GT67H0k1s39EsXT7WNRwDxzaljQmyTnNcZ8qJtcrFJK9EaHJtAC0ixwr177ReDpgNtid5KLoPubjEnhBnzJ37gDCYOzSR66WOam1Y+ct/nayJf6UpbAmEsQGUzcH0+qr5Vbj3ySSP/dk2rMK/+st4ZdO4SyBUh850B4RoFoFNAz9ceF1BUIL14OFS+br58KPwpwyYRXkEJ0BcPCVyCITeF5tTMupSd/dA1ufxK3qBByr40SPuubQAjyV/TNQ2eiQcVZ3/s3hbZOE0eQJdgKnqrRDhE+nG0Mr+HvBgVkONVx9qNnCtJIR9XZrWAsTQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6WsWbXSymE7kdBq2DUdk6DdwaOA+9wPA938Pk8OxaDI=; b=unnA0GzNb/BRZ+zfBYoSCeVZhOubbcAqJnDLwg5YqfXceaLJSzkXqZ04MZKm4/2RpBhvoaWyrdHYooYhgTrev2C9FyVCi1lfF7zIj5xfcgRuFmI2Fbrq9UEMtRc9LywISvC9UPEvoi/Z9F+XTkX5x6TnFW5HINPkY+uPUpmDPrQ=
Received: from DB7PR07MB3914.eurprd07.prod.outlook.com (2603:10a6:5:c::25) by DB7PR07MB4810.eurprd07.prod.outlook.com (2603:10a6:10:60::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.18; Wed, 19 Aug 2020 07:37:01 +0000
Received: from DB7PR07MB3914.eurprd07.prod.outlook.com ([fe80::50fa:d892:934f:190c]) by DB7PR07MB3914.eurprd07.prod.outlook.com ([fe80::50fa:d892:934f:190c%3]) with mapi id 15.20.3305.021; Wed, 19 Aug 2020 07:37:01 +0000
From: Veerendranatha Reddy V <veerendranatha.reddy.v@ericsson.com>
To: "Ketan Talaulikar (ketant)" <ketant=40cisco.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+AP1qRgqOeyJr1fTjrwAGU2iAAABLkeAAFmiU4AAA4N5gAAHvoLA=
Date: Wed, 19 Aug 2020 07:37:01 +0000
Message-ID: <DB7PR07MB3914029BB21C1FCF41714E51BB5D0@DB7PR07MB3914.eurprd07.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>
In-Reply-To: <MW3PR11MB4570D671B21040F78EABC1A7C15D0@MW3PR11MB4570.namprd11.prod.outlook.com>
Accept-Language: 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=ericsson.com;
x-originating-ip: [103.210.133.150]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 96332938-fe96-4764-b837-08d84412a963
x-ms-traffictypediagnostic: DB7PR07MB4810:
x-microsoft-antispam-prvs: <DB7PR07MB48105F1BAF3D30BA49B1BF19BB5D0@DB7PR07MB4810.eurprd07.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: XxzIlUzyrsO64pNENqeDbcAIsiRJmpd0SElnq56JWzQrHQvqFfXCnmL9WWLOR5HaJlibTDdtk8gsI35+JQaK1M7xG1xnxq749HdqybC2PpaJGTQfHV0sMtHv9M3IyjI+q3vZTmYClzJwEy/JFSp9fAFb4YXxzzdFG96J/fkPU0JpDovadaVVWXjK1L87ffNmXbtRSpAhu7DzNmbuDT0CGbKL1M7tLBTfxlyFAmATGca+u2DZRnR/j3vP31K9OcLzvtDQWPnm03qUHTDGHqfcfCDS5uCTXuVIffdReWyXbPMKomZW+DuHlxZzOPkX7nO053KfdV/TJs9FJBBDaw3goOkhcMdBjpEbBiIfiDaT3xCSUxPvak8eh8YRbTh8uacvTG8cUD83eV07ONZivUGKuA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR07MB3914.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(396003)(136003)(346002)(366004)(376002)(71200400001)(64756008)(186003)(66946007)(26005)(9686003)(66556008)(52536014)(66446008)(66476007)(76116006)(2906002)(53546011)(478600001)(83380400001)(8936002)(8676002)(5660300002)(316002)(966005)(86362001)(33656002)(110136005)(6506007)(55016002)(7696005)(66574015); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: qUeiexbhBHDqhwNiJvSxH+ue37feG4/+cAJA/ShQqHOBSRq+Yv+T7wyASN4MEZ90/kIBaY9A2y82qrXcOGt9EG27P0NlSi0WpdzUa1pWNs4ci00bOB1ZSyqB2Ut7QPHjyLtYhux+Pr2MfVer7mRnASk2tjDfEoQxmc/nqdMTmMYrsCBsZNqE7xWueZEje2IJAbHBgZrJGgCm9Rlp6ZDdk7TBD2qJd+G/PL8dnWJ8u7CruCokRi/Qbt2chkuaI3DNMDJQM5+NnNEBRKWaLLIjPTlDb01dUVq9Jbom1VUFVOoL5p4mIB8J9vVHeox49kvMG5i23xOnBfxlZNSZfL6+dYv+gdOHCPM72hbkCU9FSgDe+4NQw74BEjAakQGkB9jRSxYBLKaVQsvaiJefKLJcUQ/yssLhNP2XBLD7QlDzjyfY4otoMSqBDiwixhKHTyA9jG/sXw2PkbiREs4GNxXaT/Nc66mVgg4JQhl84SmYv59GHmzjWGzF/JhNff/e+PhNoHUf5SINIpGd3hzxAXfgay+moAkay2h9zLgFH38UXZa/HXoqSkXJz5NAUz/VTe0EaCkeQF8BNaNPC6qAn+QPdn6BhKSWdEr7TqmzB3EBeqPAT5zQNaBq6NDWKYgNUH3DDjvuhmTlqJptfXykyuVh/Q==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB7PR07MB3914.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 96332938-fe96-4764-b837-08d84412a963
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2020 07:37:01.4040 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: LV9xjKNvjnRGPYoOOjQ+T7YgtwoGdHp4FjOiwhX/gWBSq2Kwioms8BIVT3/NOgdYS5iymrVIEzgkjciEbmA+FfN/VHgmGVkuz7xKKd+5sN6MZpeww6F+u/aSVvmEIVTt
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4810
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/q5NoRuqcqkvZFCHQbCq4oJ0VVOs>
X-Mailman-Approved-At: Wed, 19 Aug 2020 03:52:02 -0700
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 07:37:11 -0000

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?

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.

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