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

Veerendranatha Reddy Vallem <veerendranatharv@huawei.com> Wed, 10 August 2016 05:05 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 513A012D69E for <ospf@ietfa.amsl.com>; Tue, 9 Aug 2016 22:05:23 -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 kZglllMY9mxO for <ospf@ietfa.amsl.com>; Tue, 9 Aug 2016 22:05:21 -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 D6A0012B02B for <ospf@ietf.org>; Tue, 9 Aug 2016 22:05:19 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPE23218; Wed, 10 Aug 2016 05:05:16 +0000 (GMT)
Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 10 Aug 2016 06:05:11 +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; Wed, 10 Aug 2016 10:35:04 +0530
From: Veerendranatha Reddy Vallem <veerendranatharv@huawei.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, "Balaji Ganesh (balagane)" <balagane@cisco.com>, OSPF WG List <ospf@ietf.org>
Thread-Topic: [OSPF] [OSPFv3] regarding p bit set and FA for NSSA (Type-7) LSAs
Thread-Index: AdHyOlw5dgxaSWzRReONo0izcxpwhQAC0YxQAAECDwAAHeUAEA==
Date: Wed, 10 Aug 2016 05:05:03 +0000
Message-ID: <73BFDDFFF499304EB26FE5FDEF20F7885081B7E5@blreml501-mbx>
References: <73BFDDFFF499304EB26FE5FDEF20F7885081B591@blreml501-mbx> <49270bb6e31e4eecbc264fd06756b2b0@XCH-ALN-017.cisco.com> <D3CFABC0.77583%acee@cisco.com>
In-Reply-To: <D3CFABC0.77583%acee@cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.206.180]
Content-Type: multipart/related; boundary="_005_73BFDDFFF499304EB26FE5FDEF20F7885081B7E5blreml501mbx_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0203.57AAB60D.0149, 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: 9033f5d16dbffd7cbad65bdf269b699f
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/ILyDkrQhiMRC6cI7frfwyEX-XY4>
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: Wed, 10 Aug 2016 05:05:23 -0000

Thanks to Balaji and Acee for clarification.

Regarding Acee clarification,
I think it is other way. If the “p-bit is not to be set (clear)”, then NSSA LSA may be originated without FA. If the “p bit is to be set”, the NSSA LSA must not be originated when no forwarding address is available. As per section 2.3  in RFC 3101

For an NSSA with no such network the forwarding address
   field may only be filled with an address from one of the its active
   interfaces or 0.0.0.0.  If the P-bit is set, the forwarding address
   must be non-zero; otherwise it may be 0.0.0.0.  If an NSSA requires
   the P-bit be set and a non-zero forwarding address is unavailable,
   then the route's Type-7 LSA is not originated into this NSSA.
Please confirm.

Some OSPFV3 NSSA implementations of different vendors, supported Translation of Type-7 with “no FA” but “p bit is set”, are translating to Type-5 LSAs.
If new implementation strict to do not translate then, it may cause inter-op issues with such implementations.
So whether new implementations are also required to support those LSA translation to make compatible with older ones?

Regards,
Veerendranath

From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: 10 August 2016 01:24
To: Balaji Ganesh (balagane) <balagane@cisco.com>; Veerendranatha Reddy Vallem <veerendranatharv@huawei.com>; OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] [OSPFv3] regarding p bit set and FA for NSSA (Type-7) LSAs

Hi Veera, Balaji,

While I was contributor to this RFC ;^), I can see it could use some more normative language to cover these cases where no IPv6 forwarding address is available. I basically agree with Balaji, if the P-bit is to be set in the NSSA-LSA, the LSA MAY be originated w/o a forwarding address (in OSPFv3 forward address encoding is optional). If the P-bit is to be clear in the NSSA-LSA, the NSSA-LSA MUST NOT be originated when no forwarding address is available.

Thanks,
Acee

From: OSPF <ospf-bounces@ietf.org<mailto:ospf-bounces@ietf.org>> on behalf of "Balaji Ganesh (balagane)" <balagane@cisco.com<mailto:balagane@cisco.com>>
Date: Tuesday, August 9, 2016 at 10:10 AM
To: Veerendranatha Reddy Vallem <veerendranatharv@huawei.com<mailto:veerendranatharv@huawei.com>>, OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: Re: [OSPF] [OSPFv3] regarding p bit set and FA for NSSA (Type-7) LSAs

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<mailto: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:image002.jpg@01D1F2EF.F7B07FE0]

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:image004.jpg@01D1F2EF.F7B07FE0]
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