IETF Logo Mail Archive

Re: [Lsr] Flooding Path Direction

Jeff Tantsura <jefftant.ietf@gmail.com> Thu, 04 April 2019 23:06 UTC

Return-Path: <jefftant.ietf@gmail.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 E8ADA120090 for <lsr@ietfa.amsl.com>; Thu, 4 Apr 2019 16:06:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=gmail.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 d7LkV3fgn0nq for <lsr@ietfa.amsl.com>; Thu, 4 Apr 2019 16:06:01 -0700 (PDT)
Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 578DC12019D for <lsr@ietf.org>; Thu, 4 Apr 2019 16:05:28 -0700 (PDT)
Received: by mail-pf1-x430.google.com with SMTP id c207so2130956pfc.7 for <lsr@ietf.org>; Thu, 04 Apr 2019 16:05:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=lZYzaAdXmmqsGDHLsipE4VM8KcT8sVS7zGz8qlwTRaE=; b=N3yK8ZbnKG9UIn64EwRT2yi18wFlt/rGVX1yXJ2/csxFjx+5quQsYaAnQHzyt0prnd eBk4hF1+dl6/4IoAB20E5UnFufKWHQhuTR54d369R9MDapgCcB3qBE5aj0sktI6JvHWa plLqNDfLkB/wESzyt4NIGyRCdmnrXnzJthtQFNnOkeY+gHgWOU8tPEmT1HhTWgtAGCYO JuysIYAbMR2nOsAywhUpg9teiY98QfMNbj0anPRyNqNmbMnAOVYBMNrgG7ECbt+CjXtW gi938Vs2OKDGeAbL9PfcV0wXB6/XOukX/acnczLYMprEx8+kLOspx/0otDKvt+aUmUvx vzwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=lZYzaAdXmmqsGDHLsipE4VM8KcT8sVS7zGz8qlwTRaE=; b=kKMLWZoc/VNfeYCzNB/1z6FCiKxdRHrHl9D7A7t5Gn3NKBy1lIL9txKeYAbuJdKrxY aYX4rdCBtIXPKXdO6beS6vFa8atyg1CB6AeLkUKVJ5oMA8jcMPhoIBstawz9mkCUUzvb ITXsTvtsAibFWY10TXDBGBq4lZYeCKEY4mrHNp+Oar/EkrJGbFDyAe+a4aJ0zBxdUi+e KI+V7kpRlT3I23rNHAZYEjE+liqAZ4XtsfA+UmHCd+SaD3KY7ZtljITys+Ssc1csEIjD iu/jmjdTDiyzBRJrukXsuW2qnQwnEEadWJdaAxuLA2RNmst0EgsB2U7cMTSf5OLVAsxW w6Mg==
X-Gm-Message-State: APjAAAU57xxCD5i33aclNnqyIy9AMNB2k/JseEsKY1DhCCidFRNNS/AZ YxED1YIpPo3rsii0DJG2ylI=
X-Google-Smtp-Source: APXvYqxZq/qCUf9IWuN7AnE/cxK2EDOhSJGEcihI2/l+rlqRRA1Nr8Vd9I/ukh3N4IefLTwsrWZ8EQ==
X-Received: by 2002:a65:408b:: with SMTP id t11mr8034306pgp.372.1554419127427; Thu, 04 Apr 2019 16:05:27 -0700 (PDT)
Received: from [10.5.5.194] ([50.235.77.202]) by smtp.gmail.com with ESMTPSA id h187sm31271897pfc.52.2019.04.04.16.05.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Apr 2019 16:05:26 -0700 (PDT)
Date: Thu, 04 Apr 2019 16:05:13 -0700
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: "tony.li@tony.li" <tony.li@tony.li>, David Allan I <david.i.allan@ericsson.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: "lsr@ietf.org" <lsr@ietf.org>, "Jakob Heitz (jheitz)" <jheitz@cisco.com>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>
Message-ID: <47387882-e3f0-4af6-8026-98cb16a88d13@Spark>
In-Reply-To: <BYAPR11MB3638B96F6A55A85E83CA42D0C1500@BYAPR11MB3638.namprd11.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>
X-Readdle-Message-ID: 47387882-e3f0-4af6-8026-98cb16a88d13@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5ca68db4_436c6125_622"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/hTVWJXN75CefDNsIulM2iod7utQ>
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 23:06:05 -0000

+1 Les


Cheers,
Jeff
On Apr 4, 2019, 10:44 AM -0700, Les Ginsberg (ginsberg) <ginsberg@cisco.com>, wrote:
> 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
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

v2.23.0 | Report a Bug | By Email