Re: [OSPF] RFC 3101 NSSA/External Route preference clarification

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Fri, 21 July 2017 02:02 UTC

Return-Path: <ketant@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 3DE5A126E64 for <ospf@ietfa.amsl.com>; Thu, 20 Jul 2017 19:02:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 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=-0.001, SPF_HELO_PASS=-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
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 OrF3HSx72utm for <ospf@ietfa.amsl.com>; Thu, 20 Jul 2017 19:02:31 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57B52126D73 for <ospf@ietf.org>; Thu, 20 Jul 2017 19:02:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=51516; q=dns/txt; s=iport; t=1500602551; x=1501812151; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hKmtue3an6zfrU/bENl5gs7bH7YsrU3F5AfDRBFQ5SQ=; b=hb5GHpEIwwRYGAfXRhxNKxfep/dopK4nNvOl6Gn23eUQuPJHojqUb4oA adCYN+dOvdRLlKhbBRJLBw8bNgM/dnXSITpKEogFxuXbdY19lHj57KxnC 6Bs+BlFn0T3psCFX5Ra3dxrILmUpUExmpbmCXiuv9lcwOb1QB96MtsINV A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CYAABDYHFZ/5BdJa1cGQEBAQEBAQEBAQEBBwEBAQEBgm9rZIEUB44FkWeIL41Wgg4DIQEMhRkCGoNbPxgBAgEBAQEBAQFrKIUYAQEBAQMBASEKQQsQAgEIEQMBAQEhAQYDAgICHwYLFAkIAgQBDQUIiUNMAxUQsTuCJoc7DYNbAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDKINNgWGCGIEMgTyBG0+BWwkWgl2CYQWKUZQyOwKHSYdfhGeCFYVQiliMDYlQAR84P0t1FUmHFnYBiHiBDgEBAQ
X-IronPort-AV: E=Sophos;i="5.40,387,1496102400"; d="scan'208,217";a="458770869"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jul 2017 02:02:30 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v6L22UIv019693 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Jul 2017 02:02:30 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Jul 2017 21:02:29 -0500
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Thu, 20 Jul 2017 21:02:29 -0500
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, Jeff Tantsura <jefftant.ietf@gmail.com>, David Lamparter <david@opensourcerouting.org>
CC: OSPF WG List <ospf@ietf.org>
Thread-Topic: [OSPF] RFC 3101 NSSA/External Route preference clarification
Thread-Index: AQHS6GH6q/Cb2aEok0aI9cREH6X2MqJE1v4QgAAPUkCAALNQgIAAdBEAgBdEEgCAAAB8AIAAZyWg
Date: Fri, 21 Jul 2017 02:02:29 +0000
Message-ID: <62beecb88c524e6785f464e0feb11240@XCH-ALN-008.cisco.com>
References: <D56C3D71.B5516%acee@cisco.com> <55cc5c59a333478a8af746881e5ac49a@XCH-ALN-017.cisco.com> <VI1PR07MB10716CE25F81A1A41886F26C91D40@VI1PR07MB1071.eurprd07.prod.outlook.com> <D5829AD9.B721C%acee@cisco.com> <07D0BDEA-7DE2-4CA8-B153-B91C420A695B@gmail.com> <D5963A95.B9D72%acee@cisco.com> <D5963B5C.B9D7C%acee@cisco.com>
In-Reply-To: <D5963B5C.B9D7C%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.65.73.29]
Content-Type: multipart/alternative; boundary="_000_62beecb88c524e6785f464e0feb11240XCHALN008ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/1Iwso7sPKFoo_Efj6ZAcHenp5fo>
Subject: Re: [OSPF] RFC 3101 NSSA/External Route preference clarification
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 21 Jul 2017 02:02:34 -0000

Hi Acee,

Implementations would definitely want to use the ECMP for better functionality in this scenario and as we’ve discussed, it should not cause any interop issues or looping. The “optionally” ensures that existing implementations are not made non-compliant. The proposed RFC3101 errata way of addressing this seems to be the best way forward.

Thanks,
Ketan

From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: 20 July 2017 20:21
To: Acee Lindem (acee) <acee@cisco.com>; Jeff Tantsura <jefftant.ietf@gmail.com>; David Lamparter <david@opensourcerouting.org>
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] RFC 3101 NSSA/External Route preference clarification

Been working on BGP too much lately.  Of course, I meant RFC 3101…
Acee

From: OSPF <ospf-bounces@ietf.org<mailto:ospf-bounces@ietf.org>> on behalf of Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>
Date: Thursday, July 20, 2017 at 10:49 AM
To: Jeff Tantsura <jefftant.ietf@gmail.com<mailto:jefftant.ietf@gmail.com>>, David Lamparter <david@opensourcerouting.org<mailto:david@opensourcerouting.org>>
Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: Re: [OSPF] RFC 3101 NSSA/External Route preference clarification

 (+David)

I just looked at the Free Range Routing GitHub (https://github.com/FRRouting/frr/blob/master/ospfd/ospf_ase.c) and they do not support NSSA (RFC 3107) and do NOT use the ASBR Router-ID to break ties in the AS External route calculation so this would support making the tie-breaker optional.

Thanks,
Acee

From: Jeff Tantsura <jefftant.ietf@gmail.com<mailto:jefftant.ietf@gmail.com>>
Date: Wednesday, July 5, 2017 at 3:31 PM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>
Cc: Chao Fu <chao.fu@ericsson.com<mailto:chao.fu@ericsson.com>>, "Balaji Ganesh (balagane)" <balagane@cisco.com<mailto:balagane@cisco.com>>, OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: Re: [OSPF] RFC 3101 NSSA/External Route preference clarification

Hi,

I find Acee's proposal reasonable and support it "as is".

Regards,
Jeff

On Jul 5, 2017, at 10:36, Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>> wrote:
Hi Chao,

I think rules (e) 1 and (e) 2 should remain to handle the case of an NSSA that receives both the intra-NSSA LSA and a translated AS External LSA (via a backbone path). I only think that rule (e) 3 needs to be relaxed. If we were doing another NSSA BIS, I’d remove it completely but since we are just talking about an Errata, I think we should just make the Router ID tie-breaker optional.

Thanks,
Acee

From: Chao Fu <chao.fu@ericsson.com<mailto:chao.fu@ericsson.com>>
Date: Wednesday, July 5, 2017 at 3:02 AM
To: "Balaji Ganesh (balagane)" <balagane@cisco.com<mailto:balagane@cisco.com>>, OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>
Subject: RE: [OSPF] RFC 3101 NSSA/External Route preference clarification

Hi all,

In my opinion rule (e) should be removed. ( https://mailarchive.ietf.org/arch/search/?email_list=ospf&q=%5BTechnical+Errata+Reported%5D+RFC3101 ).
If not, it should be clarified more including removing “2. A Type-5 LSA.”

Regards,
Chao Fu

From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Balaji Ganesh (balagane)
Sent: Wednesday, July 05, 2017 14:01
To: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>; Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>>
Subject: Re: [OSPF] RFC 3101 NSSA/External Route preference clarification

Hi all,

Any views/comments on the below?

Regards,
Balaji

From: Acee Lindem (acee)
Sent: 19 June 2017 00:08
To: Balaji Ganesh (balagane) <balagane@cisco.com<mailto:balagane@cisco.com>>; OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: Re: [OSPF] RFC 3101 NSSA/External Route preference clarification

Hi –  I encouraged Balaji to post to the list is that I think many implementations have ignored #3. I know that I changed the IBM implementation to compute ECMP routes to multiple ASBRs and had the Redback implementation do this from the start. Consequently, we’d like to solicit input as to what other implementations do. If we can reach consensus on this, we could issue an Errata to make this optional.

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, June 13, 2017 at 4:13 AM
To: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>
Subject: [OSPF] RFC 3101 NSSA/External Route preference clarification

Hi all,

When the metrics are same, RFC 3101 specifies the preference for NSSA/External routes as follows.
In the section 2.5<https://tools.ietf.org/html/rfc3101#section-2.5> Calculating Type-7 AS External Routes - 2.5.6.(e), it says..

          (e) If the current LSA is functionally the same as an
              installed LSA (i.e., same destination, cost and non-zero
              forwarding address) then apply the following priorities in
              deciding which LSA is preferred:

                 1. A Type-7 LSA with the P-bit set.

                 2. A Type-5 LSA.

                 3. The LSA with the higher router ID.


Points 1 and 2 are clear..

However Point 3 specifies preference of an LSA with a higher router ID. Why is it so?

-         Should we not install ECMP paths in this case?
-         Is point 3 actually intended for NSSA translators to prefer a Type 7 LSA which needs to be used for translation to Type 5?

Considering the above 2 points, I guess point 3 needs to be modified in the RFC to probably say..

                    3. Preference is same, install ECMP paths.
                       Additionally if the router is an NSSA translator, prefer the LSA with higher router ID for Type 7-Type 5 translation.

Please let know any views/comments on the same.

Regards,
Balaji

_______________________________________________
OSPF mailing list
OSPF@ietf.org<mailto:OSPF@ietf.org>
https://www.ietf.org/mailman/listinfo/ospf