IETF Logo Mail Archive

Re: [Lsr] Flooding Path Direction

David Allan I <david.i.allan@ericsson.com> Thu, 04 April 2019 20:14 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 BFEFA120132 for <lsr@ietfa.amsl.com>; Thu, 4 Apr 2019 13:14:32 -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 ZqmkxN_ZauFN for <lsr@ietfa.amsl.com>; Thu, 4 Apr 2019 13:14:30 -0700 (PDT)
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680061.outbound.protection.outlook.com [40.107.68.61]) (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 E27B01200B6 for <lsr@ietf.org>; Thu, 4 Apr 2019 13:14:29 -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=UydOLbZ/6EgE8y93ywNrWM0Eeo+Q+2XAYVO4UVTSX3c=; b=FQrakWZ91RcDCNZvbrSeA4KVEfz2QYF2LhzfN4F5esHCAwATt/+kjfjIORyDl/IHrcVJYExddpOiaJukFrSFCINVB0l1sLnJRFuxGr20iX2xXFi8Ca1fc0vsMhkyCv8DhP8TVVpjX8KN0TQkivkQvPLUUcSFKTOK/vwu84IWyeA=
Received: from BYAPR15MB3078.namprd15.prod.outlook.com (20.178.239.16) by BYAPR15MB2950.namprd15.prod.outlook.com (20.178.237.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.20; Thu, 4 Apr 2019 20:14:27 +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 20:14:27 +0000
From: David Allan I <david.i.allan@ericsson.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "tony.li@tony.li" <tony.li@tony.li>
CC: "lsr@ietf.org" <lsr@ietf.org>, "Jakob Heitz (jheitz)" <jheitz@cisco.com>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>
Thread-Topic: [Lsr] Flooding Path Direction
Thread-Index: AdTqkbHsqMouS91uR3+cx5O9DydfsgAEveUAAAFawJAAAQ+AgAAANmRwAAIufgAAAfTScAAEByuAAAzdKqAAAUqnAAABKNWQAAVbToA=
Date: Thu, 04 Apr 2019 20:14:27 +0000
Message-ID: <BYAPR15MB3078135CDC0EBCCBFC119CBCD0500@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> <BYAPR15MB3078AEBB55A61477277BA1AED0500@BYAPR15MB3078.namprd15.prod.outlook.com> <76B663DD-B500-477B-9957-F38A5F8D7B7E@tony.li> <BYAPR11MB3638B96F6A55A85E83CA42D0C1500@BYAPR11MB3638.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB3638B96F6A55A85E83CA42D0C1500@BYAPR11MB3638.namprd11.prod.outlook.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: db1096cd-ed65-4a7f-46f2-08d6b93a236c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(49563074)(7193020); SRVR:BYAPR15MB2950;
x-ms-traffictypediagnostic: BYAPR15MB2950:
x-microsoft-antispam-prvs: <BYAPR15MB295053D8B9CE1FE0C530C61BD0500@BYAPR15MB2950.namprd15.prod.outlook.com>
x-forefront-prvs: 0997523C40
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(366004)(376002)(39860400002)(396003)(13464003)(199004)(189003)(53936002)(6116002)(66066001)(55016002)(26005)(2501003)(14454004)(14444005)(229853002)(9686003)(68736007)(93886005)(316002)(966005)(86362001)(6306002)(74316002)(99286004)(7696005)(256004)(54906003)(3846002)(33656002)(76176011)(81166006)(446003)(53546011)(6506007)(476003)(5660300002)(106356001)(97736004)(110136005)(4326008)(11346002)(6246003)(186003)(305945005)(81156014)(478600001)(71200400001)(7736002)(486006)(6436002)(71190400001)(2906002)(105586002)(102836004)(8676002)(8936002)(52536014)(25786009)(99936001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR15MB2950; 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: 7smxycX3k2o07NWRsR1+B20AMVfdOnAiBBFntr2Lu20BVe69236DpHmGqpIONmeeDtfWGdKpuog7uc6ec5/sY3/EkPybhHqlgOpOPofJothfUYWeJEW3jTRbsK6TXL3eL9nzp91AOLhpYbLMr2KFg6OHaMSO8Bj0ZMbcexzUmDRJz5U/zpsxKEJpgx8LKUL8bnxAGnpmTp9CnxUgzNKAa3XfoC87yR+fyCloqddhbfNFL85hyB0Cwk9reP0OA3QDPkmlyP2nFOcmqZIjSkTukx95ErW8TOWxqjssq/MCHw/d/z/OQ7/X2FxpBpzkljxPIyeWMRq2TjyuBhy8o5LPVrsBX4pLBcgMRy7rdB7zb5cPt/9lvMNVt+GpHxMgGOVKyJq/chOWh3JMcuRgyA/W7pqxR+zRVFKGvCAvRD46tc0=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0233_01D4EB01.74339820"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: db1096cd-ed65-4a7f-46f2-08d6b93a236c
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2019 20:14:27.1503 (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: BYAPR15MB2950
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/YFnf_DQojAyMNW5EQ_5B-deGNQY>
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 20:14:33 -0000

HI Les:

Actually it should not be that bad. Once you are restricting the set of
interfaces you would send an LSP on, you've already crossed the Rubicon.

At least that is the view from here...

Dave

-----Original Message-----
From: Les Ginsberg (ginsberg) <ginsberg@cisco.com> 
Sent: Thursday, April 4, 2019 1:44 PM
To: tony.li@tony.li; David Allan I <david.i.allan@ericsson.com>
Cc: lsr@ietf.org; Jakob Heitz (jheitz) <jheitz@cisco.com>; Peter Psenak
(ppsenak) <ppsenak@cisco.com>
Subject: RE: [Lsr] Flooding Path Direction

But the point that Peter has made needs to be heeded.
Changing IGP flooding to be unidirectional is non-trivial and should not be
done w/o justification.

One of the things the FT draft has been very careful about thus far is to
not change the operation of the Update process on a given link.
We allow links to be excluded from the FT but we do not change flooding
behavior on a link when it is part of the FT.
We have also gone so far as to indicate that even if a link is NOT part of
the FT but we do receive an LSP on that link we acknowledge it in the
standard fashion.

I think all of this simplifies the deployment of the feature and we should
be careful before introducing additional changes in standard protocol
behavior.

   Les


> -----Original Message-----
> From: Lsr <lsr-bounces@ietf.org> On Behalf Of tony.li@tony.li
> Sent: Thursday, April 04, 2019 10:04 AM
> To: David Allan I <david.i.allan@ericsson.com>
> Cc: lsr@ietf.org; Jakob Heitz (jheitz) <jheitz@cisco.com>; Peter 
> Psenak
> (ppsenak) <ppsenak@cisco.com>
> Subject: Re: [Lsr] Flooding Path Direction
> 
> 
> Hi Dave,
> 
> > 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.
> 
> 
> Thanks.
> 
> 
> > 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....(?)
> 
> Or perhaps having a separate TLV for a unidirectional path would suffice.
> 
> That would allow both paths to be encoded most optimally.
> 
> Tony
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

v2.23.0 | Report a Bug | By Email