Re: [Lsr] LEEF bit behavior) RE: I-D Action: draft-ietf-lsr-dynamic-flooding-01.txt

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 23 May 2019 00:19 UTC

Return-Path: <ginsberg@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 8BCCB120098 for <lsr@ietfa.amsl.com>; Wed, 22 May 2019 17:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 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, 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 header.b=AL0RUwEV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=E+ZUzi/c
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 44Uplfnf0qht for <lsr@ietfa.amsl.com>; Wed, 22 May 2019 17:18:59 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0D3412006E for <lsr@ietf.org>; Wed, 22 May 2019 17:18:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22798; q=dns/txt; s=iport; t=1558570739; x=1559780339; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=xqpLuP3owUJE5h8hrjJTqsf9ZHZsD9LZVLPoLQvFwnU=; b=AL0RUwEVFfspUEahDqtY8jHkFWLfs5cmbWeNTVb650Ca3rd5XkMLNw25 qprXsxMgmZ+cPNYay4gEu/xfPrsxey/O6YKFQUvkQq/zj9f93wDEfdbbI gRPwxALrM1wEHAvKlRua3mjKYvekXakxd9QW374Zqnn2IxtK5aTT9Qmzb k=;
IronPort-PHdr: =?us-ascii?q?9a23=3Aks7iWRPnZF1VR1m4oFQl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj0LfjxZSEgE+xJVURu+DewNk0GUMs=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BIAACH5uVc/4gNJK1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgQ4vUANpVSAECyiHWgOEUoojSoINlymBLoEkA1QJAQEBDAE?= =?us-ascii?q?BLQIBAYRAAoIxIzQJDgEDAQEEAQECAQRtHAyFSgEBAQEDEhsTAQE4CwQCAQg?= =?us-ascii?q?OAwQBASEHBzIUCQgCBAESCBqDAYEdTQMdAQKcMAKBNYhfgiCCeQEBBYUNGII?= =?us-ascii?q?PCYE0AYtQF4FAP4ERRoJMPoRGNIMGgiaSXZVYCQKCDZMhljKMXZVVAgQCBAU?= =?us-ascii?q?CDgEBBYFPOIFXcBWDJ4IPN4M4ilNygSmKWCqCKAEB?=
X-IronPort-AV: E=Sophos;i="5.60,501,1549929600"; d="scan'208,217";a="476729087"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 May 2019 00:18:54 +0000
Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x4N0IsSY021221 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 May 2019 00:18:54 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 22 May 2019 19:18:53 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 22 May 2019 20:18:52 -0400
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 22 May 2019 19:18:51 -0500
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=NVPNbzU4B/gg35ZOkGVngY2jRhWFXi73JR9Ay5mWc/0=; b=E+ZUzi/c5peTE3qjf6NsUlXPBy2W9r5XhNbtL90zU+yLYQ34zVqnBlea1duAHoNIwBXLDjkYG2Zz44FZk3uNLcwXqbmY3382NMaa4Hoi415VwmAxSOZT4It4sU4sUcQzI/Sv0m0HVgplVYUMnjFmq3P+7TD/kRZNhmTPBfYKuas=
Received: from MN2PR11MB3647.namprd11.prod.outlook.com (20.178.251.26) by MN2PR11MB3741.namprd11.prod.outlook.com (20.178.254.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.15; Thu, 23 May 2019 00:18:50 +0000
Received: from MN2PR11MB3647.namprd11.prod.outlook.com ([fe80::dce4:9aa6:1b16:a94e]) by MN2PR11MB3647.namprd11.prod.outlook.com ([fe80::dce4:9aa6:1b16:a94e%5]) with mapi id 15.20.1922.017; Thu, 23 May 2019 00:18:50 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Huaimo Chen <hchen@futurewei.com>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: LEEF bit behavior) RE: [Lsr] I-D Action: draft-ietf-lsr-dynamic-flooding-01.txt
Thread-Index: AQHVEOACty7NddjteUSYP7U4rpAHm6Z30wJA
Date: Thu, 23 May 2019 00:18:49 +0000
Message-ID: <MN2PR11MB3647DD53F5AC81F4945D76ABC1010@MN2PR11MB3647.namprd11.prod.outlook.com>
References: <MN2PR13MB3470099009F14B8436828F32A3000@MN2PR13MB3470.namprd13.prod.outlook.com>
In-Reply-To: <MN2PR13MB3470099009F14B8436828F32A3000@MN2PR13MB3470.namprd13.prod.outlook.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=ginsberg@cisco.com;
x-originating-ip: [2001:420:c0c8:1008::3ac]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0313cf4a-14af-40c1-8b55-08d6df143af3
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR11MB3741;
x-ms-traffictypediagnostic: MN2PR11MB3741:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <MN2PR11MB37417322A2BFA64D5F228770C1010@MN2PR11MB3741.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00462943DE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(136003)(346002)(396003)(366004)(50084003)(189003)(199004)(13464003)(6246003)(8676002)(2906002)(81166006)(8936002)(2501003)(446003)(52536014)(5660300002)(81156014)(476003)(486006)(7696005)(76176011)(790700001)(6116002)(6506007)(102836004)(53546011)(11346002)(53936002)(14454004)(46003)(33656002)(478600001)(55016002)(561944003)(68736007)(54896002)(6306002)(66476007)(66556008)(73956011)(66446008)(64756008)(9686003)(76116006)(71200400001)(71190400001)(14444005)(66946007)(236005)(256004)(86362001)(25786009)(186003)(74316002)(7736002)(6436002)(229853002)(316002)(110136005)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3741; H:MN2PR11MB3647.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: TKuNH1mal7uLaLBihNS1mUBVqTd7W1DgX6y2TkWlaRwvcrs5V0akoQ6819G2z3xTIB9f/TuKXQuzJvB3Qbc8MUhN6fyO7zrJHYX/e59FYbCBbDVJTeztvBFM211CpNLRDd0sg9Lxb1xSF2mB4k+CE+g66tmEi2rmzMZtfetADnQvUfQfERZVViZJDQQrCKHiRjtNQaiMEb9ob7VB+mUko+mMpNdLZK+MgBgoq4jtnpbEDhFdcjGcRCA0wfHeuIJF6nn8qzqzT8gMk8baviB3VzomsflsWYPBZT81hZLu2PrXiSBKgIWF77GaZWrMa1oonyRWS3vMLwgkNCE/sZ+lapfVyprCAfOKqXJxbro7WmQCg5gc8Z3Sk37lO3mPD6SYGbd6vi359XVbuB5Tn3xg7TNQoZQwtvoaxdFa6zpbGLY=
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3647DD53F5AC81F4945D76ABC1010MN2PR11MB3647namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0313cf4a-14af-40c1-8b55-08d6df143af3
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2019 00:18:50.0013 (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: ginsberg@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3741
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/S_yzJoK1nK1dzc869ChdSPA9PoI>
Subject: Re: [Lsr] LEEF bit behavior) RE: I-D Action: draft-ietf-lsr-dynamic-flooding-01.txt
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: Thu, 23 May 2019 00:19:03 -0000

Huaimo -

Thanx for providing the inspiration for advertising LEEF.

The draft is very explicit in saying that LEEF advertisements are for diagnostic purposes only and do NOT alter dynamic flooding state. I think there are good reasons for this. Consider the possibilities when advertised LEEF state is not as expected:

1)LEEF bit is set for an edge which is NOT part of the flooding topology

We have a node which supports dynamic flooding but indicates it is flooding on a link which is NOT part of the flooding topology. This means unnecessary flooding is occurring. If the neighbor enables flooding on that link because it has received LEEF bit, it is only adding to the amount of unnecessary flooding - which is neither useful nor desirable.

2)LEEF bit is NOT set for an edge which is part of the flooding topology

We have a node which supports dynamic flooding but it fails to enable flooding on a link which is part of the flooding topology. This means that the implementation has a bug of some sort:

*         it does not correctly process the flooding path advertisement (centralized mode)

*         it does not correctly calculate the flooding topology (distributed mode)

When interpreting the LEEF bit (presumably) set by the neighbor, the receiving (buggy) node cannot distinguish between case #1 above and case #2 i.e., it cannot tell whether it is correct and the neighbor is wrong or vice versa. If it could it would have set the LEEF bit as it would know this link is part of the flooding topology.

Advertising flooding state is useful for diagnostic purposes - but it is an unreliable tool if used to try to "correct" flooding state.

So we do not want to add the behavior you suggest.

   Les


From: Huaimo Chen <hchen@futurewei.com>
Sent: Wednesday, May 22, 2019 1:52 PM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>om>; lsr@ietf.org
Subject: LEEF bit behavior) RE: [Lsr] I-D Action: draft-ietf-lsr-dynamic-flooding-01.txt


Hi Les,


     Thank you very much for adding the LEEF bit into the draft based on the FT bit for a link. The bit advertised by one end node of the link indicates whether the link is on the flooding topology.

Would you mind adding the behavior below for checking and handling the inconsistency of the flooding topology through using this bit?

For a link L between node A and node B, if the LEEF bit for link L advertised by node A is different from the one advertised by node B, then the flooding topology is inconsistent, the node receiving the LEEF bit set to one for link L from the other node adds link L on the flooding topology temporarily.

If one of the two nodes receives the LEEF bit set to one for link L from the other, but advertises the LEEF bit set to zero for link L for a given time such as 5 seconds, then a warning is issued or logged.



Best Regards,

Huaimo

-----Original Message-----

From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)

Sent: Tuesday, May 21, 2019 1:56 PM

To: lsr@ietf.org<mailto:lsr@ietf.org>

Subject: Re: [Lsr] I-D Action: draft-ietf-lsr-dynamic-flooding-01.txt



Folks -



Major changes in this version include:



1)Added support for LANs as part of the flooding tropology



2)Added support for advertising what links are enabled for flooding at each node. This is based on a proposal in draft-cc-lsr-flooding-reduction (the FT bit) but we have defined it to be advertised associated with a link rather than in hellos. This is to allow management tools to more easily verify correctness of the flooding topology on each node. It does NOT change operational state in any way.



3)Added some text around rate limiting temporary flooding when attempting to repair a partitioned flooding topology.



    Les