Re: [Lsr] Flooding Path Direction

Peter Psenak <ppsenak@cisco.com> Thu, 04 April 2019 10:19 UTC

Return-Path: <ppsenak@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 1C2EA120478 for <lsr@ietfa.amsl.com>; Thu, 4 Apr 2019 03:19:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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_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
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 uL_FDR-CjkG7 for <lsr@ietfa.amsl.com>; Thu, 4 Apr 2019 03:19:10 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C6B120005 for <lsr@ietf.org>; Thu, 4 Apr 2019 03:19:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2766; q=dns/txt; s=iport; t=1554373150; x=1555582750; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=J0bQ09I/0E+3DblZ+RZx09of2/dlNL3dv6cWDPg41Pw=; b=JTHERuikOjvbqZSPTh7eP+/huT9mxEEwcKM4XnN6jevhjK2Vgudepz2g P7yLr0t2CGXfefuIJXn3DTvJJUiXyeRg11kZ+ZN66UfJLwN4se9aDo18V KNz2oDgBBQ2HOEFkDjzuCmoArjL5jHjN6cA10iIr3aKODLAv+xKT2/zlj 0=;
X-IronPort-AV: E=Sophos;i="5.60,308,1549929600"; d="scan'208";a="11116561"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Apr 2019 10:19:08 +0000
Received: from [10.147.24.34] ([10.147.24.34]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id x34AJ7vL011892; Thu, 4 Apr 2019 10:19:08 GMT
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>, "tony.li@tony.li" <tony.li@tony.li>
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>
Cc: "lsr@ietf.org" <lsr@ietf.org>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <7cc74779-8825-dfc5-b87e-b9f494133add@cisco.com>
Date: Thu, 04 Apr 2019 12:19:07 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <BYAPR11MB3751BE6C14F9879D482EF377C0500@BYAPR11MB3751.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.147.24.34, [10.147.24.34]
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/eLM6-SpJkhComcFnavksb9nwyZI>
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 10:19:13 -0000

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
>>
>
> .
>