IETF Logo Mail Archive

Re: [OSPF] [OSPFv3] regarding p bit set and FA for NSSA (Type-7) LSAs

"Balaji Ganesh (balagane)" <balagane@cisco.com> Tue, 09 August 2016 14:10 UTC

Return-Path: <balagane@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92977127078 for <ospf@ietfa.amsl.com>; Tue, 9 Aug 2016 07:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.767
X-Spam-Level:
X-Spam-Status: No, score=-15.767 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-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
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 vknBf1vxKoqf for <ospf@ietfa.amsl.com>; Tue, 9 Aug 2016 07:10:28 -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 50C9E12D810 for <ospf@ietf.org>; Tue, 9 Aug 2016 07:10:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=92379; q=dns/txt; s=iport; t=1470751825; x=1471961425; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=YnvN7JsiUecZBG8qrOBj0mb4Ou6JX32L7WCAUnJEcMA=; b=kDOuIwQg+hEg91pcS91mAzK07zGa7+oZsg13rcPCyYM9/rZaGwu/AZoB +S16E+rl22UojwtreVVtp/1pLJsuV5Ec12ZyPDE4mQQiWXDnQtddIfciS poyR9/ChNZGxonHWNyeaHKFBRVpUDc1monnDpVYs7RYPdmAyqP0dPfPv7 U=;
X-Files: image003.jpg, image005.jpg : 33512, 23769
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BfAgAY46lX/4QNJK1dgndOVnwHtBaBcoEGgg+BfYUNgRACgUk4FAEBAQEBAQFdJ4ReAQEFBQcZCAFbAgEIEQQBAQYBAQEKFQcCBRAPDBQJCAEBBAERAQgGiCPCDQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4OhiqETYR2hSUFly8DggcBhS0BiVSBcoRbDIhxjDSDcAcBHjaCEhyBTG6GTn8BAQE
X-IronPort-AV: E=Sophos;i="5.28,494,1464652800"; d="jpg'145?scan'145,208,217,145";a="308027294"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Aug 2016 14:10:24 +0000
Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u79EAOwn027673 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Aug 2016 14:10:24 GMT
Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 9 Aug 2016 09:10:23 -0500
Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1210.000; Tue, 9 Aug 2016 09:10:23 -0500
From: "Balaji Ganesh (balagane)" <balagane@cisco.com>
To: Veerendranatha Reddy Vallem <veerendranatharv@huawei.com>, OSPF WG List <ospf@ietf.org>
Thread-Topic: [OSPFv3] regarding p bit set and FA for NSSA (Type-7) LSAs
Thread-Index: AdHyOlw5dgxaSWzRReONo0izcxpwhQAC0YxQ
Date: Tue, 09 Aug 2016 14:10:22 +0000
Message-ID: <49270bb6e31e4eecbc264fd06756b2b0@XCH-ALN-017.cisco.com>
References: <73BFDDFFF499304EB26FE5FDEF20F7885081B591@blreml501-mbx>
In-Reply-To: <73BFDDFFF499304EB26FE5FDEF20F7885081B591@blreml501-mbx>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.232.13.69]
Content-Type: multipart/related; boundary="_005_49270bb6e31e4eecbc264fd06756b2b0XCHALN017ciscocom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/LWP2TrvrEAX0SHIvMSBgGYuXNjw>
Subject: Re: [OSPF] [OSPFv3] regarding p bit set and FA for NSSA (Type-7) LSAs
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Aug 2016 14:10:30 -0000

Hi Veera,

Please see inline..


Regards,
Balaji

From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Veerendranatha Reddy Vallem
Sent: 09 August 2016 18:04
To: OSPF WG List <ospf@ietf.org>
Subject: [OSPF] [OSPFv3] regarding p bit set and FA for NSSA (Type-7) LSAs

Hi All,
Can you please provide clarification for following in OSPFv3 NSSA implementation.

As RFC 3101 is considered NSSA RFC for both OSPFv2 and OSPFv3,

Case 1:

As per RFC 3101, 2.4 section, While originating Type-7 LSA, if p -bit is set, then Forwarding address (FA) must be non- zero.


[cid:image003.jpg@01D1F274.61411B80]

For OSPFv3 case, there may be possible FA  is not available (no global address is configured on any of NSSA interface).
If OSPFv3 receives Type-7 LSA with p bit set but no forwarding address, whether this LSA should be consider as valid and can be used for route calculation?


[BALAJI: If the Type-7 LSA has no forwarding address, it does not get translated to Type-5. This is specified in the RFC section 2.3, point 6


      6. Those Type-7 LSAs that are to be translated into Type-5 LSAs

         must have their forwarding address set.

However the LSA is still valid and would be used inside the NSSA area.
]

Case 2:
In section 3.2  , Translating Type-7 LSAs into Type-5 LSAs
[cid:image005.jpg@01D1F274.61411B80]
Same in OSPFv3, if we received Type-7 LSA with no forwarding address but 'p' bit set, whether ABR is allowed to translate this LSA to Type-5 External LSA?

[BALAJI: No. ABR should not be translating such LSAs without forwarding address. This is again as per section 2.3, point 6 in the RFC.]

As per my understanding, if Forwarding address is not available, Type-7 LSA must be originated with no 'p' bit set and no forwarding address. If 'p' bit is set means, it must  always
Carry forwarding address(for OSPFv3, it must be global ipv6 address configured on any of interfaces).


[BALAJI: P-bit not being set would explicitly mean that we don't want the LSA to be translated. Probably to keep the redistributed prefixes only within the NSSA area (for whatever reason it may be).
If P-bit is set, it should also have a forwarding address for it to be translated.]

Please let me know whether my understanding is correct or not for OSPFv3, as per RFC 3101.

Regards,
Veerendranath

v2.23.0 | Report a Bug | By Email