Re: [mpls] Open Design Team online meeting on Thursday (2021-07-01 )
Loa Andersson <loa@pi.nu> Fri, 02 July 2021 21:34 UTC
Return-Path: <loa@pi.nu>
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 B52753A0D6B; Fri, 2 Jul 2021 14:34:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.235
X-Spam-Level:
X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.338, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 1UTF77rLvHVs; Fri, 2 Jul 2021 14:34:33 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD4D33A0D64; Fri, 2 Jul 2021 14:34:32 -0700 (PDT)
Received: from [192.168.1.224] (90-231-104-158-no93.tbcn.telia.com [90.231.104.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id E847F348C2C; Fri, 2 Jul 2021 23:34:24 +0200 (CEST)
To: John E Drake <jdrake@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>
Cc: "pals-chairs@ietf.org" <pals-chairs@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, DetNet Chairs <detnet-chairs@ietf.org>
References: <c3f1c957-db43-a4dd-5ac2-e167398829a4@pi.nu> <BY3PR05MB8081EE2EFB86CB33DAF7A4EBC71F9@BY3PR05MB8081.namprd05.prod.outlook.com>
From: Loa Andersson <loa@pi.nu>
Message-ID: <cffaa5c8-d341-4558-675e-bf85dc6f6c3e@pi.nu>
Date: Fri, 02 Jul 2021 23:34:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <BY3PR05MB8081EE2EFB86CB33DAF7A4EBC71F9@BY3PR05MB8081.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/ZvkTNRARa6ku7V4khINhKXF0heE>
Subject: Re: [mpls] Open Design Team online meeting on Thursday (2021-07-01 )
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: Fri, 02 Jul 2021 21:34:38 -0000
John, Please see inline. On 02/07/2021 14:26, John E Drake wrote: > Loa, > > I think the idea of including multiple indicator/pointer labels in an MPLS label stack is ill-considered. Yes, the thought has struck me. I.e. I have not been pushing "all" these proposals because I think we need to carefully discuss and take decisions in the working group. As I understand it, the reasoning is that some transit LSRs may not be able to reach the BoS, so we will place these indicator/pointer labels in the MPLS label stack at positions where they can be read by all transit routers, except of course, by those transit routers that don't understand them. I think that that is a true description for the GAL, but I have not seem the same proposal for for example FAI. However, for GAL I have seen two different proposals - the first is what you describe above; a copy of the GAL already in the stack is introduced "higher up" in the stack - the second is to add a second unique GAL, pointing to a second different ACH However, the semantics of these indicator/pointer labels are go to the BoS and act upon data subsequent to it. If a transit LSR isn't able to reach BoS, how can it do this? (It should be noted that RFC 8662 doesn't have this problem because it places the actionable data at multiple places in the MPLS label stack.) I agree that this is not straightforward, quite a bit of design is needed, and might not be worth the effort. Another point we should agree on > > I think the conclusion has to be that these indicator/pointer labels have to appear once in an MPLS label stack in the vicinity of the BoS and we live with the fact that some transit LSRs won't be able to read or act upon them. Does that mean that only a GAL or a FAI can be present in a label stack? A similar problem is that the FAI has several flag, with your reasoning it seems to me that for a single FAI we will aloow only one flags might be set. > > Also, why are we adding these new capabilities strictly to MPLS? Aren't there requirements for these new capabilities in non-MPLS environments? If they were added in a non-MPLS specific manner, they would work in an MPLS environment without having to change MPLS. Well, this has not been discussed in detail, but I note that is very likely that the opposite statement also might be true "If they were added in an MPLS specific manner, they would work in a non-MPLS environment without further any further changes to that environment. /Loa > > Yours Irrespectively, > > John > > > Juniper Business Use Only > >> -----Original Message----- >> From: mpls <mpls-bounces@ietf.org> On Behalf Of Loa Andersson >> Sent: Monday, June 28, 2021 1:55 PM >> To: mpls@ietf.org >> Cc: pals-chairs@ietf.org; spring-chairs@ietf.org; mpls-chairs@ietf.org; DetNet >> Chairs <detnet-chairs@ietf.org> >> Subject: [mpls] Open Design Team online meeting on Thursday (2021-07-01 ) >> >> [External Email. Be cautious of content] >> >> >> Open Design Team, >> >> I have uploaded the agenda for the meeting on Thursday. >> >> https://urldefense.com/v3/__https://trac.ietf.org/trac/mpls/wiki/2021-07-01- >> agenda__;!!NEt6yMaO-gk!V6pEM- >> DX6SAK1Iku6Y6c8wN5YqFiHv8FnKKuu7l0qYT_ElLhd2UC6KhD7-8jKvo$ >> >> /Loa >> -- >> >> 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mpls__;!! >> NEt6yMaO-gk!V6pEM- >> DX6SAK1Iku6Y6c8wN5YqFiHv8FnKKuu7l0qYT_ElLhd2UC6KhDsDrBWBo$ -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64
- [mpls] Open Design Team online meeting on Thursda… Loa Andersson
- Re: [mpls] Open Design Team online meeting on Thu… BRUNGARD, DEBORAH A
- Re: [mpls] Open Design Team online meeting on Thu… John E Drake
- Re: [mpls] Open Design Team online meeting on Thu… Haoyu Song
- Re: [mpls] Open Design Team online meeting on Thu… Loa Andersson