Re: [Lsr] Flooding Path Direction
David Allan I <david.i.allan@ericsson.com> Thu, 04 April 2019 16:39 UTC
Return-Path: <david.i.allan@ericsson.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 A2E5112002E for <lsr@ietfa.amsl.com>; Thu, 4 Apr 2019 09:39:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Y3or-jZvX_tx for <lsr@ietfa.amsl.com>; Thu, 4 Apr 2019 09:39:22 -0700 (PDT)
Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710080.outbound.protection.outlook.com [40.107.71.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2EA11200C7 for <lsr@ietf.org>; Thu, 4 Apr 2019 09:39:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xbvI/yPiVvzNcT7enoLFKD1kfhR30D99hM9+hzr2IsA=; b=bRGxp2cGCuGxeN2BdBin2YDPGCQVR8hcufyTMRcVj0GpTuezHdcSwWkOE6wdvmNGhxcOX3fv/Cxmo6OyRA6Z/0n4ptpuGtVjBPAo/fZlkVuURHG7rgSfU0/KYdylf15rWPlzKxg1YC57VnL5MMfEw7sV3ONtONzPKhbFy7Z6D68=
Received: from BYAPR15MB3078.namprd15.prod.outlook.com (20.178.239.16) by BYAPR15MB3095.namprd15.prod.outlook.com (20.178.239.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.15; Thu, 4 Apr 2019 16:39:20 +0000
Received: from BYAPR15MB3078.namprd15.prod.outlook.com ([fe80::f149:ac42:91ed:98d]) by BYAPR15MB3078.namprd15.prod.outlook.com ([fe80::f149:ac42:91ed:98d%5]) with mapi id 15.20.1750.017; Thu, 4 Apr 2019 16:39:20 +0000
From: David Allan I <david.i.allan@ericsson.com>
To: Peter Psenak <ppsenak@cisco.com>, "Jakob Heitz (jheitz)" <jheitz@cisco.com>, "tony.li@tony.li" <tony.li@tony.li>
CC: "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Flooding Path Direction
Thread-Index: AdTqkbHsqMouS91uR3+cx5O9DydfsgAEveUAAAFawJAAAQ+AgAAANmRwAAIufgAAAfTScAAEByuAAAzdKqA=
Date: Thu, 04 Apr 2019 16:39:20 +0000
Message-ID: <BYAPR15MB3078AEBB55A61477277BA1AED0500@BYAPR15MB3078.namprd15.prod.outlook.com>
References: <BYAPR11MB375152970011BD7563A8E271C0500@BYAPR11MB3751.namprd11.prod.outlook.com> <DE048608-1403-431D-BD88-27D95E49E089@tony.li> <BYAPR11MB375129E24A8D1C0BB5E4D598C0500@BYAPR11MB3751.namprd11.prod.outlook.com> <89E37338-8E33-43F9-B8AB-76DD1884914C@tony.li> <BYAPR11MB3751127FEA49D06038EBE623C0500@BYAPR11MB3751.namprd11.prod.outlook.com> <0c505c69-955f-4eb5-c0b0-820ec8e0019f@cisco.com> <BYAPR11MB3751BE6C14F9879D482EF377C0500@BYAPR11MB3751.namprd11.prod.outlook.com> <7cc74779-8825-dfc5-b87e-b9f494133add@cisco.com>
In-Reply-To: <7cc74779-8825-dfc5-b87e-b9f494133add@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.i.allan@ericsson.com;
x-originating-ip: [206.47.221.212]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fe27bdf5-24e8-432b-06d5-08d6b91c1698
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(49563074)(7193020); SRVR:BYAPR15MB3095;
x-ms-traffictypediagnostic: BYAPR15MB3095:
x-microsoft-antispam-prvs: <BYAPR15MB30958F176D1925AFF59A5266D0500@BYAPR15MB3095.namprd15.prod.outlook.com>
x-forefront-prvs: 0997523C40
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(39860400002)(376002)(366004)(136003)(199004)(189003)(13464003)(966005)(256004)(2501003)(99286004)(76176011)(6306002)(229853002)(52536014)(81166006)(5660300002)(6506007)(53936002)(102836004)(7696005)(105586002)(8676002)(106356001)(55016002)(8936002)(66066001)(86362001)(9686003)(81156014)(97736004)(68736007)(74316002)(316002)(3846002)(25786009)(6116002)(486006)(186003)(2906002)(478600001)(71200400001)(446003)(71190400001)(6436002)(4326008)(305945005)(11346002)(6246003)(53546011)(110136005)(99936001)(93886005)(33656002)(7736002)(14454004)(476003)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR15MB3095; H:BYAPR15MB3078.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: lyIUS3nvEpwvck6BbGIuewvc7atgbz1543KfRfIFvXjxTqPZ2da3BifK91D3lt29gquhdd2rSI68aNd4cafC+v1YuDvVTSU3SKEDYegrb4cASGGwcirxJFTMbPIo4f7jkvI5lAiedItFdL7Ir19iK3yKIwBbdUhe0KuF8ujaSuY5aXthFAmKFd8r3ND31LC1KmPAdblyyyIaWcuQjuS79lnNPrnP9sMNyeX4W3UR6b5wGrCCd1bcGnMGSAMWokK7/T4liIqT1KyuoPyztFiOl7u0oPMIxChLGm7XyPejRIyxeTYo9r7B2TKelSPDhdD7QR7aaKbk0kv0PPrfwTKvbmSzHEEsi1a25pKtbXm8vTlhdIyBWWx8TlzGtZbTd0vxpGK/vCSzwrdSi87pbBlt09MUFMiYIZpelH/pVbstTmw=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0146_01D4EAE3.67C97A00"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fe27bdf5-24e8-432b-06d5-08d6b91c1698
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2019 16:39:20.6937 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB3095
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/t0qj1KgVLJMEzR6Yayx384ZcJuo>
Subject: Re: [Lsr] Flooding Path Direction
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, 04 Apr 2019 16:39:26 -0000
Hi Gents: The algorithm in draft-allan actually has the notion of upstream, downstream and both upstream and downstream FT adjacencies. However as a generalized form is still a WIP and has yet to demonstrate merit against any of the other approaches on the table, I'd not be looking to suggest a specific encoding. If at some point it is decided that different classes of FT adjacency are required, simply using additional types that share the format of the flooding path TLV would appear to be sufficient....(?) Cheers Dave -----Original Message----- From: Lsr <lsr-bounces@ietf.org> On Behalf Of Peter Psenak Sent: Thursday, April 4, 2019 6:19 AM To: Jakob Heitz (jheitz) <jheitz@cisco.com>; tony.li@tony.li Cc: lsr@ietf.org Subject: Re: [Lsr] Flooding Path Direction Jakob, On 04/04/2019 10:55 , Jakob Heitz (jheitz) wrote: > How is it impossible that A may flood to B, but B does not flood to A ? every node in the area must be able to flood the data and they must reach all other nodes. Adjacency bringup involves database exchange which is bidirectional, so is the flooding. Flooding in one direction often serves as an ACK from the other direction. > How does it follow that if A floods to B, then B must also flood to A ? does not have to be, but the LS protocols have been designed for bidirectional flooding. Making this unidirectional would require significant changes to the flooding procedures. Not something we want to go into. > > Uni-directional flooding allows a more efficient flooding topology to be built. > Suppose you had to build a flooding topology with the rule: 2 incoming and 2 outgoing floods. why 2 incoming and 2 outgoing? We want each node to do minimal flooding, which is 2 connections to flooding topology, not 4. regards, Peter > With bidirectional flooding, the incoming are the same as the > outgoing, so any incoming flood can only be propagated on one interface. > With uni-directional, any incoming can go out two interfaces. > To achieve 2 out with bidirectional, you need 3 in, 3 out, because the ins and outs are the same. > > Regards, > Jakob. > > -----Original Message----- > From: Peter Psenak <ppsenak@cisco.com> > Sent: Thursday, April 4, 2019 12:28 AM > To: Jakob Heitz (jheitz) <jheitz@cisco.com>; tony.li@tony.li > Cc: lsr@ietf.org > Subject: Re: [Lsr] Flooding Path Direction > > Jakob, > > given that there is a single flooding topology calculated for an area, > I don't see how this can be unidirectional, considering that flooding > topology is used to flood in any direction. > > thanks, > Peter > > > On 04/04/2019 08:26 , Jakob Heitz (jheitz) wrote: >> I mean flooding in one direction only, not unidirectional forwarding. >> >> >> >> Regards, >> >> Jakob. >> >> >> >> *From:* Tony Li <tony1athome@gmail.com> *On Behalf Of >> *tony.li@tony.li >> *Sent:* Wednesday, April 3, 2019 11:19 PM >> *To:* Jakob Heitz (jheitz) <jheitz@cisco.com> >> *Cc:* lsr@ietf.org >> *Subject:* Re: [Lsr] Flooding Path Direction >> >> >> >> >> >> I think this is too restrictive. >> >> We should not exclude algorithms that can build a flooding topology >> with unidirectional links. >> >> >> >> >> >> Well, right now, the protocol doesn't really support unidirectional >> links. At all. >> >> >> >> Tony >> >> >> >> >> >> >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr >> > > . > _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
- [Lsr] Flooding Path Direction Jakob Heitz (jheitz)
- Re: [Lsr] Flooding Path Direction tony.li
- Re: [Lsr] Flooding Path Direction Jakob Heitz (jheitz)
- Re: [Lsr] Flooding Path Direction tony.li
- Re: [Lsr] Flooding Path Direction Jakob Heitz (jheitz)
- Re: [Lsr] Flooding Path Direction Peter Psenak
- Re: [Lsr] Flooding Path Direction Jakob Heitz (jheitz)
- Re: [Lsr] Flooding Path Direction Peter Psenak
- Re: [Lsr] Flooding Path Direction David Allan I
- Re: [Lsr] Flooding Path Direction tony.li
- Re: [Lsr] Flooding Path Direction Les Ginsberg (ginsberg)
- Re: [Lsr] Flooding Path Direction David Allan I
- Re: [Lsr] Flooding Path Direction Les Ginsberg (ginsberg)
- Re: [Lsr] Flooding Path Direction David Allan I
- Re: [Lsr] Flooding Path Direction Les Ginsberg (ginsberg)
- Re: [Lsr] Flooding Path Direction Jeff Tantsura
- Re: [Lsr] Flooding Path Direction Jakob Heitz (jheitz)
- Re: [Lsr] Flooding Path Direction Peter Psenak
- Re: [Lsr] Flooding Path Direction Peter Psenak
- Re: [Lsr] Flooding Path Direction David Allan I
- Re: [Lsr] Flooding Path Direction Acee Lindem (acee)