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

Veerendranatha Reddy Vallem <veerendranatharv@huawei.com> Tue, 09 August 2016 12:38 UTC

Return-Path: <veerendranatharv@huawei.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 4DB8612D0E4 for <ospf@ietfa.amsl.com>; Tue, 9 Aug 2016 05:38:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.467
X-Spam-Level:
X-Spam-Status: No, score=-5.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 RFkkQUtZKFFx for <ospf@ietfa.amsl.com>; Tue, 9 Aug 2016 05:38:46 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47A3812D09A for <ospf@ietf.org>; Tue, 9 Aug 2016 05:38:46 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPD32875; Tue, 09 Aug 2016 12:38:43 +0000 (GMT)
Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 9 Aug 2016 13:38:42 +0100
Received: from BLREML501-MBX.china.huawei.com ([10.20.5.198]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0235.001; Tue, 9 Aug 2016 18:08:33 +0530
From: Veerendranatha Reddy Vallem <veerendranatharv@huawei.com>
To: OSPF WG List <ospf@ietf.org>
Thread-Topic: [OSPFv3] regarding p bit set and FA for NSSA (Type-7) LSAs
Thread-Index: AdHyOlw5dgxaSWzRReONo0izcxpwhQAAFStg
Date: Tue, 09 Aug 2016 12:38:33 +0000
Message-ID: <73BFDDFFF499304EB26FE5FDEF20F7885081B5A7@blreml501-mbx>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.206.180]
Content-Type: multipart/alternative; boundary="_000_73BFDDFFF499304EB26FE5FDEF20F7885081B5A7blreml501mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.57A9CED4.00F3, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: a20d27df79bf7fd41168a565d3c7c8f4
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/33DcDqUK9BTfljwkjsJ5VLejtAQ>
Subject: [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 12:38:48 -0000

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.


2.4<https://tools.ietf.org/html/rfc3101#section-2.4> Originating Type-7 LSAs





   NSSA AS boundary routers may only originate Type-7 LSAs into NSSAs.

   An NSSA internal AS boundary router must set the P-bit in the LSA

   header's option field of any Type-7 LSA whose network it wants

   advertised into the OSPF domain's full transit topology.  The LSAs of

   these networks must have a valid non-zero forwarding address.  If the

   P-bit is clear the LSA is not translated into a Type-5 LSA by NSSA

   border routers.


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?

Case 2:

In section 3.2  , Translating Type-7 LSAs into Type-5 LSAs, (1)


(1) If the Type-7 LSA has the P-bit clear, or its forwarding

          address is set to 0.0.0.0, or the most specific Type-7 address

          range that subsumes the LSA's network has DoNotAdvertise

          status, then do nothing with this Type-7 LSA and consider the

          next one in the list.  Otherwise term the LSA as translatable

          and proceed with step (2).


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?

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).

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

Regards,
Veerendranath