Re: [Lsr] 答复: some doubts about RFC3101

"Acee Lindem (acee)" <acee@cisco.com> Mon, 09 December 2019 15:20 UTC

Return-Path: <acee@cisco.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 6ECD3120043 for <lsr@ietfa.amsl.com>; Mon, 9 Dec 2019 07:20:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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, 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 header.b=c2xJKGGS; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=qeMnOoDR
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 zCZUtu5hKyic for <lsr@ietfa.amsl.com>; Mon, 9 Dec 2019 07:20:23 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 784CB12000F for <lsr@ietf.org>; Mon, 9 Dec 2019 07:20:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33569; q=dns/txt; s=iport; t=1575904823; x=1577114423; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Bsaa4adnvh+/kZ/Mq3njOuq8s6XBB5dAdcU0PHCO/L0=; b=c2xJKGGSMZcNK9CnLYccUKK3K7rmOGpFp+/LR9nJ71MVaxbAdCeppFE4 yu8SV9HgiOHoCKVJMZmNCHfGqyYTghVfm787DAMKZZX4s6sre6dpj55pR fgRz1wOd2rHqQZWAHqDSIKVXtLcsQaTg/dlns/GnS4T3XtiQBKT13PPxP 8=;
IronPort-PHdr: 9a23:W3Ru3hLcMrqmIujlpdmcpTVXNCE6p7X5OBIU4ZM7irVIN76u5InmIFeCuKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFKa5lQT1kAgMQSkRYnBZuMAkD2BPXrdCc9Ws9FUQwt8g==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C6AADNZe5d/4kNJK1kHAEBAQEBBwEBEQEEBAEBgWoHAQELAYEbL1AFbFggBAsqhAKDRgOEWoYpToFsJZgFgS6BJANUCQEBAQwBAS0CAQGEQAIXggIkNAkOAgMNAQEEAQEBAgEFBG2FNwyFUgEBAQEDEhEdAQE4DwIBBgIRAwECIQcDAgICMBQGAwgCBAESIoMAAYF5TQMuAQKQQJBkAoE4iGF1gTKCfgEBBYJKgk4YghcJgTYBjBcaggCBEScMFIJMPoEEgx4+CRaCWjKCLJAnhVCJUI8WCoIulWYbgkKHc499g0aLBIFFmGYCBAIEBQIOAQEFgVI5gVhwFTsqAYJBUBEUjGYYO4MgilN0EYEXiyiCQQEB
X-IronPort-AV: E=Sophos;i="5.69,296,1571702400"; d="scan'208,217";a="677050324"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Dec 2019 15:20:21 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id xB9FKL1f019844 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Dec 2019 15:20:21 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 9 Dec 2019 09:20:21 -0600
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 9 Dec 2019 09:20:20 -0600
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 9 Dec 2019 10:20:20 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U6w1jO2Fk6UYMQzwWzBouN4uWqbEZ5VvEuf1a25ps+3rRLe3/lEof48J/GdK/nARGcGEwy1CARw7XdiSCrbYvkkx1QeyPOsrDxLKxrfEJCFUnj2ZrAbIJq2LJ+WX7OdPnAjm8wuqZZirgJtZ3nZvmqnhLfyKf69nBlENmaN/2pQdjP9Cst8xaTpxfxidkveOw4Bzr/G37FFu091yfbsQsTCyLrIQTgNIsmxyGiLjmwrzrzzaz8bA/L0PT37eXkyhqkkJm4mwH+oNIDhfOTkskXWZwWg/38d98pIFA7vPLLpE2Ci9QwmJp02CFrVcI2G8EOHfuPl23AfcU7n4rSf7Vw==
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=Bsaa4adnvh+/kZ/Mq3njOuq8s6XBB5dAdcU0PHCO/L0=; b=hmV6k31e2I1hwSpPx5NHs/NBzM88yY3AbfKeyAeOUsqC/bh9LV1ZxhWSMl+Ng9CD+pjrxAgc13TzTv0t9Xm7oKWoJPWitsDZRnBwIe+QWWbUjWdbvQ/qyqqSXMv1ZAMJyKRKk9C+VOw3+OgGVTr0+hYG8krAsQzRt1Ce1iEsA1DvOYYl1uAMaYinAr4gp5WBouTFgM8q0MDFY9msnwIRwe/bKYqXKmSTARL8NjC67i4UYexuHFitZNhcOAb6udIH1S6zhXDPvbOeJ30xFc+6XNhWp77FBIfhEhCJL8h8QeAgq5haCiXJje793eX5MQnYYMOmCtzlltgpgVf5XOuUSQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Bsaa4adnvh+/kZ/Mq3njOuq8s6XBB5dAdcU0PHCO/L0=; b=qeMnOoDRAvkZ55JrAtgccjWERhJVQuL9d5GMaumLuHP0pnaqVD1WbGGXd8z1tUlBQKqdk9E4MDzKrE95oelfEM9KwCyBI3A1HOyVsqxBbX7xdGo3TmJ0arQ1n65NWf3kU3Ki0SHLlR9M7vmJ28y4ZbTE1Z3dALCDcZlnUOs0wio=
Received: from MN2PR11MB4221.namprd11.prod.outlook.com (52.135.38.14) by MN2PR11MB3616.namprd11.prod.outlook.com (20.178.251.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.14; Mon, 9 Dec 2019 15:20:18 +0000
Received: from MN2PR11MB4221.namprd11.prod.outlook.com ([fe80::218b:2d04:e653:105]) by MN2PR11MB4221.namprd11.prod.outlook.com ([fe80::218b:2d04:e653:105%7]) with mapi id 15.20.2516.018; Mon, 9 Dec 2019 15:20:18 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: meicong <meicong@huawei.com>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] 答复: some doubts about RFC3101
Thread-Index: AQHVrpqm4vYAU87dz0687uR9lbnV9qexl0uA
Date: Mon, 09 Dec 2019 15:20:18 +0000
Message-ID: <3F27B162-A75A-46B0-9987-DD4F8F2E6E9A@cisco.com>
References: <C45D89487DC65947BCBD4149DD0967C3341AA157@DGGEML503-MBX.china.huawei.com> <87B4F90C-720B-473F-91D2-BE1A80209085@cisco.com> <C45D89487DC65947BCBD4149DD0967C3341B70AF@DGGEML503-MBX.china.huawei.com>
In-Reply-To: <C45D89487DC65947BCBD4149DD0967C3341B70AF@DGGEML503-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com;
x-originating-ip: [2001:420:c0c8:1001::3df]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0f134eca-2820-4e44-d54a-08d77cbb4d0a
x-ms-traffictypediagnostic: MN2PR11MB3616:
x-microsoft-antispam-prvs: <MN2PR11MB36167FF1A17E246171F10F74C2580@MN2PR11MB3616.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 02462830BE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(376002)(346002)(366004)(136003)(199004)(189003)(129404003)(53754006)(186003)(6486002)(6512007)(224303003)(8936002)(53546011)(81156014)(6506007)(81166006)(2906002)(76116006)(91956017)(33656002)(36756003)(86362001)(5660300002)(110136005)(66446008)(2616005)(478600001)(316002)(66476007)(71200400001)(66946007)(66556008)(9326002)(229853002)(66574012)(64756008)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3616; H:MN2PR11MB4221.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: D6XcFmO6kbTyezrAndEUP7k52GWoZybQoTr0+1DI4RpujWqQvVod+U30+GHGok0jlAnDCTRCjyeBC46sfu1o9We1zzuinjQb5Sm0i1lW+Zx1HHex5KMf1D0UH/hv8SazGBsutrIj4EfmGNQY/2m1SEE0qLzNuUMPMIZ+6lkP6oFRkPXJv6GmKG5XTmSHJ+ebRa0Sqz+3zHgchJSv1n1KIvSeVjEVWQBTRZboGCVOEKXPwyVpXYsrFnbQdrpYzQXlAeNju7svNuMX8dpfbG82jJ8S2DbMGLy+SFdKzGNY23zaePtRdLSy3oWr1roWGat8qpGO7dVdKDZdXIncfDmHXF8wSpR0d/saT6NOp+9N3n0N20v1STlgT3zjfIdUvJX2Xwt4sl5eT7CjySSPsya33n+TeO8TJ+QtSX6HANR5/XuqlV9PdvhmjSvLCuQcMwSg2fIzeHp6lMI8rCQBJLRrZk3H4wI8Ibb2puBCK5shQYEYkxlcBXz89RI+Tk6gAQVVbqeF4ViFXMJ52qlKUTNn2Q==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_3F27B162A75A46B09987DD4F8F2E6E9Aciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0f134eca-2820-4e44-d54a-08d77cbb4d0a
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2019 15:20:18.8099 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: AGBE2BX7BhlcRsz2XJBrQjC9kOfpmw9WGfA/1Gq3sP1Foq4f4Mq5Cp2AxZQGX8Sw
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3616
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/LzEXgLeOQPsEEEPVvpWJV-F0wlw>
Subject: Re: [Lsr] 答复: some doubts about RFC3101
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: Mon, 09 Dec 2019 15:20:25 -0000

Hi Meicong,

From: Lsr <lsr-bounces@ietf.org> on behalf of meicong <meicong@huawei.com>
Date: Monday, December 9, 2019 at 9:12 AM
To: Acee Lindem <acee@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
Subject: [Lsr] 答复: some doubts about RFC3101

Hi Acee,

The subnet 128.185.1.0/255.255.255.0 is an intra-area of the NSSA area,
and subnet 128.185.0.0/255.255.0.0 is a directly attached subnet on the ASBR that originate the type-5 LSA.
The fowarding address of the type-5 LSA is 128.185.1.1.

This is broken. Nobody within the NSSA will be able to reach hosts within the 128.155.1/24 subnet that are on the ASBR’s directly attached network.


There are two subnet seemly same but different netmask in the network
128.185.1.0/255.255.255.0 intra-area route of nssa area,
128.185.0.0/255.255.0.0 intra-area route of normal area.

Maybe we could say it is a config error,

There is no “Maybe” about it.

but what should be the result?
It is working as designed.
Hope this helps,
Acee

Regards

发件人: Acee Lindem (acee) [mailto:acee@cisco.com]
发送时间: 2019年12月6日 20:23
收件人: meicong <meicong@huawei.com>; lsr@ietf.org
主题: Re: [Lsr] some doubts about RFC3101

Hi Meicong,
The problem is that the subnet 128.185.1.0/255.255.255.0 is seemly in two places in the network. It is both an intra-area subnet withins the NSSA and a directly attached subnet on one of the ASBR’s OSPF interfaces. The ASBR should not advertise it as a forwarding address if it is not a directly attached subnet on an OSPF interface. Refer to section 2.3 in RFC 2328.
Thanks,
Acee

From: meicong <meicong@huawei.com<mailto:meicong@huawei.com>>
Date: Thursday, December 5, 2019 at 8:40 PM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>, "lsr@ietf.org<mailto:lsr@ietf.org>" <lsr@ietf.org<mailto:lsr@ietf.org>>
Subject: Re: [Lsr] some doubts about RFC3101

Hi Acee,
Thanks for your answer.
In the example,
If the type-5 lsa is originated by the ASBR that in the normal area,
the other router in the normal area will use the type-5 lsa,
for the ASBR is reachable in the normal area,
and there is (128.185.1.0, 0xffffff00) inter-area route that be orignated by the abr in routing table of  other router,
and the calculated result for the type-5 lsa is path to the abr,
but there is no path on the abr, because the route (128.185.1.0, 0xffffff00) is intra-route of Nssa area on the abr.
In the scenario, the fowarding address is advertised by differnet router in different capable area with different netmask.
It maybe fall under a configed error, but the result of the calculate result seems wrong.
What is your opinion for it?
Regards

发件人: Acee Lindem (acee) [mailto:acee@cisco.com]
发送时间: 2019年12月5日 20:40
收件人: meicong <meicong@huawei.com<mailto:meicong@huawei.com>>; lsr@ietf.org<mailto:lsr@ietf.org>
主题: Re: [Lsr] some doubts about RFC3101

Hi Meicong,

From: Lsr <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> on behalf of meicong <meicong@huawei.com<mailto:meicong@huawei.com>>
Date: Thursday, December 5, 2019 at 4:48 AM
To: "lsr@ietf.org<mailto:lsr@ietf.org>" <lsr@ietf.org<mailto:lsr@ietf.org>>
Cc: "draft-ietf-ospf-nssa-update@ietf.org<mailto:draft-ietf-ospf-nssa-update@ietf.org>" <draft-ietf-ospf-nssa-update@ietf.org<mailto:draft-ietf-ospf-nssa-update@ietf.org>>
Subject: [Lsr] some doubts about RFC3101


Hi All,
Could you please provide clarification for following section 2.5.(3) in rfc3101.

          If the forwarding address is non-zero look up the forwarding
          address in the routing table.  For a Type-5 LSA the matching
          routing table entry must specify an intra-area or inter-area
          path through a Type-5 capable area.  For a Type-7 LSA the
          matching routing table entry must specify an intra-area path
          through the LSA's originating NSSA.  If no such path exists
          then do nothing with this LSA and consider the next in the
          list.
          [NSSA]

In the section, the matching routing table entry of the forwarding address is limited("an intra-area or inter-area path through a Type-5 capable area" or "an intra-area path through the LSA's originating NSSA").
If the best matching routing table entry for the forwarding address does not match the limited, the secondory best matching routing table entry should be find or not?

e.g., the forwarding address of a Type-5 LSA is 128.185.1.1,
and there are two routing table entry int the routing table on the abr,
(128.185.1.0, 0xffffff00) intra-area route of the NSSA area,
(128.185.0.0, 0xffff0000) intra-area route of the normal area(Type-5 capable area),
The path of the forwarding address should be consider as exist or not?

The short answer is no. The OSPF AS-External LSA should not be used since the forwarding address is not reachable through a normal area. As one would expect, the route lookup is always a longest prefix lookup. Note that having NSSA routes implies that the computing OSPF router is an ABR with both normal and NSSA area(s). One would expect that prefix being computed would also have a corresponding OSPF NSSA LSA that would satisfy the reachability check. If not, something in the OSPF routing design is broken.

Hope this helps,
Acee



Regards