Re: [mpls] I-D Action: draft-andersson-mpls-open-dt-questions-00.txt
Toerless Eckert <tte@cs.fau.de> Thu, 13 May 2021 12:19 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84BAC3A0E4F for <mpls@ietfa.amsl.com>; Thu, 13 May 2021 05:19:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 xTvBPqoa4o6a for <mpls@ietfa.amsl.com>; Thu, 13 May 2021 05:19:47 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07B5B3A0E27 for <mpls@ietf.org>; Thu, 13 May 2021 05:19:21 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E6BA4548011; Thu, 13 May 2021 14:19:14 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id DEFBB4E7468; Thu, 13 May 2021 14:19:14 +0200 (CEST)
Date: Thu, 13 May 2021 14:19:14 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: loa Andersson <loa@pi.nu>, mpls <mpls@ietf.org>
Message-ID: <20210513121914.GG40483@faui48e.informatik.uni-erlangen.de>
References: <161968317610.20664.11107844270215068679@ietfa.amsl.com> <EDE7FDFB-4063-443D-BB72-C13238D22235@gmail.com> <eb4936d1-f226-4695-ac42-fd4938233645@pi.nu> <509D508D-F5DB-4DE7-B1F4-65318D6D088D@gmail.com> <20210512024715.GY40483@faui48e.informatik.uni-erlangen.de> <5BBD40C1-4CAD-4E1C-A850-392900F696A1@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5BBD40C1-4CAD-4E1C-A850-392900F696A1@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/-cCw4u3wbk-rX9AJ0qneYTBQfZY>
Subject: Re: [mpls] I-D Action: draft-andersson-mpls-open-dt-questions-00.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 May 2021 12:19:53 -0000
On Thu, May 13, 2021 at 11:17:10AM +0100, Stewart Bryant wrote: > We really need to support networks that are deployed with LDP. Sure, but do we think any signaling extensions for the functions we are interested in should be added to LDP or rather IGP ? E.g.: AFAIK (and i may be wrong), all MPLS networks using LDP also use IGP, so we definitely would have the choice. > Maybe one of the SPRING experts on the list can tell me whether the LS approach to label distribution scales to the levels that we need to support LS and a full replacement to LDP? Indeed. The way i understand it, SR can use IGP more efficiently than LS could because you can flood SR (and only deal with SR<->Label mapping on a per-hop basis without doing it per SID/per-label). What LDP does would more naturally map to a DV IGP than our typical MPLS LS IGPs. > I would think that it should be able to, but the SR migration to LS for label distribution led to a few surprises and would like to be sure that all elephants have been accounted for. I think you are quite right, but i was thinking that any additional signaling we would need for the additional forwarding plane functions we come up with would be tied to FEC and not label, and that AFAIK would again allow to easily flood it via LS IGPs. And keep FEC to label mapping in LDP. Cheers Toerless > - Stewart > > > On 12 May 2021, at 03:47, Toerless Eckert <tte@cs.fau.de> wrote: > > > > Any reason why we still need to bother with LDP for future "extended" MPLS > > networks ? Not that we do not want to maintain it where it exists, but > > in the context of the extensions we are discussing, i am not aware of any > > signaling requirement where current IETF mindset would not prefer IGP over > > LDP (and for IMHO good reasons). SR uses AFAIK IGP both for network wide and > > only-to-subnet-neighbor information dissamination. > > > > Cheers > > Toerless > > > > On Thu, Apr 29, 2021 at 02:55:11PM +0100, Stewart Bryant wrote: > >> Hi Loa > >> > >> LDP really layers on an IGP in most practical networks and the IGP can flood this without missing a heartbeat. > >> > >> - Stewart > >> > >> > >>> On 29 Apr 2021, at 14:41, Loa Andersson <loa@pi.nu> wrote: > >>> > >>> Stewart, > >>> > >>> I was that concerned about the amount of data that needs to be flooded, but rather that the mechanisms we have is insufficient. > >>> > >>> In the LDP case an LSR informs its peers about capabilities, they are not flooded across the network > >>> > >>> RFC 5561 > >>> > >>> - Each LDP speaker is assumed to implement a set of enhancements, > >>> each of which has an associated capability. At any time, a speaker > >>> may have none, one, or more of those enhancements "enabled". When > >>> an enhancement is enabled, the speaker advertises the associated > >>> capability to its peers. By advertising the capability to a peer, > >>> the speaker asserts that it shall perform the protocol actions > >>> specified for the associated enhancement. For example, the actions > >>> may require the LDP speaker to receive and process enhancement- > >>> specific messages from its peer. Unless the capability has been > >>> advertised, the speaker will not perform protocol actions specified > >>> for the corresponding enhancement. > >>> > >>> An LSR that initiates an LSP with a maximum scanning depth depth need to know this for every LSR along the LSP. > >>> > >>> /Loa > >>> > >>> On 29/04/2021 12:25, Stewart Bryant wrote: > >>>> It is one additional capability field (no more than a byte) to flood and I find it hard to imagine that it would not scale. > >>> > >>> -- > >>> > >>> Loa Andersson email: loa@pi.nu > >>> Senior MPLS Expert loa.pi.nu@gmail.com > >>> Bronze Dragon Consulting phone: +46 739 81 21 64 > >> > >> _______________________________________________ > >> mpls mailing list > >> mpls@ietf.org > >> https://www.ietf.org/mailman/listinfo/mpls > > > > -- > > --- > > tte@cs.fau.de -- --- tte@cs.fau.de
- Re: [mpls] I-D Action: draft-andersson-mpls-open-… Stewart Bryant
- Re: [mpls] I-D Action: draft-andersson-mpls-open-… Loa Andersson
- Re: [mpls] I-D Action: draft-andersson-mpls-open-… Stewart Bryant
- Re: [mpls] I-D Action: draft-andersson-mpls-open-… Loa Andersson
- Re: [mpls] I-D Action: draft-andersson-mpls-open-… Toerless Eckert
- Re: [mpls] I-D Action: draft-andersson-mpls-open-… Stewart Bryant
- Re: [mpls] I-D Action: draft-andersson-mpls-open-… Toerless Eckert
- Re: [mpls] I-D Action: draft-andersson-mpls-open-… Jeff Tantsura
- Re: [mpls] I-D Action: draft-andersson-mpls-open-… Sergey Fomin