Return-Path: X-Original-To: mpls@mail2.ietf.org Delivered-To: mpls@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 9F3AA2416F2E; Fri, 2 May 2025 07:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HU0UmcR3tLut; Fri, 2 May 2025 07:34:31 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 922DD2416F23; Fri, 2 May 2025 07:34:31 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4ZptjJ0Bbhz1R8WN; Fri, 2 May 2025 16:34:28 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4ZptjH6SlKzl0Q9; Fri, 2 May 2025 16:34:27 +0200 (CEST) Date: Fri, 2 May 2025 16:34:27 +0200 From: Toerless Eckert To: Loa Andersson Message-ID: References: <9D3BA859-A778-4DE6-9839-401ACA913861@tony.li> <027901db83e1$104f6300$30ee2900$@olddog.co.uk> <61225e10-78ca-4673-b096-e37b83b57726@pi.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <61225e10-78ca-4673-b096-e37b83b57726@pi.nu> Message-ID-Hash: 6TZULXKLUQZUCRYDEK7OEEG6BWZ5NCOJ X-Message-ID-Hash: 6TZULXKLUQZUCRYDEK7OEEG6BWZ5NCOJ X-MailFrom: eckert@i4.informatik.uni-erlangen.de X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-mpls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pals-chairs@ietf.org, bier-chairs@ietf.org, "Dongjie (Jimmy)" , mpls X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bmpls=5D_Re=3A_Potential_MNA_technical_issue?= List-Id: Multi-Protocol Label Switching WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: I've tried to answer the question here: https://mailarchive.ietf.org/arch/msg/mpls/PmUGhC7rLBNRyL-30jbGBSWbZ0w/ Aka: Likely "No" if we ONLY want to strictly follow the rules of rfc8296, but likely "easy to build an extension in the MNA architecture", so it looks like clean rfc8296 - even though we've stuffed PSD in. Cheers Toerless On Fri, Feb 21, 2025 at 09:21:44PM +0100, Loa Andersson wrote: > Greg, > > The question if MNA can occupy the slot immediately after the LSE with the > BoS has been discussed before. I have heard different answers. > > Let us ask the PALS and BIER chairs. > > BIER and PALS chairs, > > Can we occupy that slot? Do you have specifications that MUST be in that > slot? > > /Loa > > Den 21/02/2025 kl. 20:50, skrev Greg Mirsky: > > Hi Haoyu, > > if you refer to PW and BIER technologies, then their respective headers > > must immediately follow the BoS LSE. Now the proponents of PSD MNA, in > > my opinion, have a choice - make PSD applicable to PW and BIER signaling > > relative location of PSD, or explicitly exclude use of PSD from PW and > > BIER. But even then, RLD concern remains for PSD. > > > > Regards, > > Greg > > > > On Fri, Feb 21, 2025 at 11:43 AM Haoyu Song > > wrote: > > > > Let’s consider these facts:____ > > > > 1. There have been several use cases that defines certain header > > structure after the MPLS label stack. ____ > > 2. There have been more than one use cases which claim to use the > > location for their header after the MPLS label stack. ____ > > > > __ __ > > > > Do they use any offset to indicate their location? No. the use case > > and potential conflicts can be resolved through control plane > > provisions. ____ > > > > __ __ > > > > If we truly want to support PSD, at least we should follow the same > > track. Anyway, PSD also has the potential to consolidate other use > > cases which need any data out side of the MPLS label stack. I think > > it’s very reasonable to keep the mechanism simple and practical. ____ > > > > __ __ > > > > Best regards,____ > > > > Haoyu____ > > > > __ __ > > > > *From:*Haoyu Song > > > > *Sent:* Friday, February 21, 2025 11:35 AM > > *To:* Greg Mirsky > > > *Cc:* Dongjie (Jimmy) > >; mpls > > > > *Subject:* [mpls] Re: Potential MNA technical issue____ > > > > __ __ > > > > It’s unprecedented to have any header structure to define the > > location of another header. Such complexity could only kill the use > > case. ____ > > > > The RLD limitation can easily be taken into consideration through > > control plane means. ____ > > > > (If you insist this, the ISD has the same concern)____ > > > > But the complex data plane mechanism is a true killer to the PSD.____ > > > > __ __ > > > > Best regards,____ > > > > Haoyu____ > > > > __ __ > > > > *From:*Greg Mirsky > > > > *Sent:* Friday, February 21, 2025 11:26 AM > > *To:* Haoyu Song > > > > *Cc:* Dongjie (Jimmy) > >; mpls > > > > *Subject:* Re: [mpls] Re: Potential MNA technical issue____ > > > > __ __ > > > > Hi Haoyu,____ > > > > I cannot agree that "PSD and ISD are entangled here because the PSD > > indicator needs to be specified in ISD header. " As was > > demonstrated, to signal the presence and location of a PSD block > > safely, a flag in MNA HDR is not sufficient. MPLS networks include > > nodes that might have different RLD capability, and the mechanism > > that used to signal PSD must take that into consideration. AFAICS, > > that can be solved using ISD opcode, not MNA Header. Defining a new > > ISD opcode that signals presence and location of the PSD block would > > be logical in PSD-related draft.____ > > > > __ __ > > > > Regards,____ > > > > Greg____ > > > > __ __ > > > > On Fri, Feb 21, 2025 at 11:14 AM Haoyu Song > > > wrote:____ > > > > PSD and ISD are entangled here because the PSD indicator needs > > to be specified in ISD header. I think it’s crucial to have a > > well-specified PSD indicator in the MNA header draft. If it’s > > left unattended, we won’t know the implications which might make > > the whole MNA fail. To me, PSD is more extensible, flexible, and > > useful so I’d like to ensure it will work fine with an enabling > > mechanism well defined ahead rather than leaving it as an > > afterthought which might render PSD unusable. ____ > > > > ____ > > > > I also insist that a P-flag is sufficient, simple and > > straightforward. Trying to use offset is a very bad idea which > > will introduce unnecessary complexity to the parser and render > > many chips unusable because they can’t support parsing this kind > > of header at all. We can simply require that no other data can > > be inserted between BoS label and PSD. If we really want to > > support PSD, we shouldn’t try to add any artificial mechanism to > > the design.____ > > > > ____ > > > > Best regards,____ > > > > Haoyu____ > > > > ____ > > > > ____ > > > > *From:*Greg Mirsky > > > > *Sent:* Friday, February 21, 2025 9:04 AM > > *To:* Dongjie (Jimmy) > > > > *Cc:* mpls > > > *Subject:* [mpls] Re: Potential MNA technical issue____ > > > > ____ > > > > Hi Jie,____ > > > > AFAICS, PSD is an optional mechanism to realize MNA functions. > > Furthermore, it was sufficiently demonstrated that the proposed > > P-flag in MNA Header is not sufficient to signal the presence of > > PSD in the packet. Considering that, I believe that a note to > > optional use of PSD in draft-ietf-mpls-mna-hdr and that detailed > > discussion of the mechanism to signal its presence and format of > > a PSD are outside of the scope of draft-ietf-mpls-mna-hdr would > > suffice.____ > > > > ____ > > > > Regards,____ > > > > Greg____ > > > > ____ > > > > On Thu, Feb 20, 2025 at 10:49 PM Dongjie (Jimmy) > > > > wrote:____ > > > > Hi Adrian and Tony, > > > > Since PSD has been acknowledged as needed for some types of > > MNA data and use cases, I'd agree with Adrian on making this > > explicit in section 5.2 of the MNA header draft. > > > > Another open issue is where should the PSD indication > > mechanism be specified. To my understanding PSD indication > > is part of the general MNA solution and is orthogonal to the > > encoding of Post-stack data, thus it is more suitable to be > > covered in the MNA header draft. > > > > During the interim this week we didn't get chance to discuss > > the possible PSD indication mechanisms. This may be > > considered as a remaining open technical issue for further > > discussion. > > > > Best regards, > > Jie > > > > > -----Original Message----- > > > From: Adrian Farrel > > > > > Sent: Friday, February 21, 2025 5:48 AM > > > To: 'Tony Li' > > > > Cc: 'mpls' > > > > Subject: [mpls] Re: Potential MNA technical issue > > > > > > No, I personally don't have a problem with that solution. > > > Others may have, I don't know. > > > > > > The text could, perhaps, be a little clearer in 5.2 to > > direct applications to use > > > PSD. Yeah, I know one could possibly work out that having > > a lot of LSEs is not > > > very wise (especially as we have a limit to the number of > > LSEs we can support > > > because of the size of the NASL). Just a few words of > > advice: nothing heavy. > > > > > > And the fixes for points 1 and 2. > > > > > > A > > > > > > -----Original Message----- > > > From: Tony Li > > On Behalf Of Tony Li > > > Sent: 20 February 2025 21:27 > > > To: Adrian Farrel > > > > > Cc: mpls > > > > Subject: Re: [mpls] Potential MNA technical issue > > > > > > [WG chair hat: off] > > > > > > Hi Adrian, > > > > > > I recall that we discussed this before and we reached the > > conclusion that > > > actions that needed more variable data should go the > > post-stack route. Do you > > > have a problem with that? > > > > > > Regards, > > > Tony > > > > > > > > > > On Feb 20, 2025, at 12:58 PM, Adrian Farrel - adrian at > > olddog.co.uk > > > > > wrote: > > > > > > > > Hi all, > > > > > > > > I thought the virtual interim was useful in airing some > > opinions. > > > > > > > > I exchanged a few emails with Jie to try to better > > understand his > > > > concerns, and then Stewart and I sat down for a couple > > of hours to > > > > work through all of the possibilities. > > > > > > > > This is mainly thinking aloud. > > > > > > > > A big question surrounds how the NAS might be parsed by > > a non-MNA node. > > > > > > > > The first part of the question is "What happens if a > > non-MNA node > > > > encounters the MNA label?" Well, it shouldn't! The MNA > > label should > > > > only rise to the top of stack at nodes known to be MNA > > capable. But, > > > > if it does, the MNA label is an SPL, and processing > > unknown SPLs at > > > > the top of stack is well defined. > > > > > > > > The next part of this question is "What if part of the > > NSA looks like > > > > an SPL?" The most concerning case we have at the moment > > is if it looks > > > > like an ELI to a non-MNA node that searches ahead for > > an entropy label. > > > > This question is covered in the draft in two places: > > > > 6.1 tells us that Opcode 0 is not to be used. That > > means that LSE > > > > formats B and C can never be mistaken for bSPLs because > > they don't > > > > start with eight 0 bits. > > > > 4.4 tells us that format D LSEs must always start with > > a 1 so they can > > > > never be mistaken for bSPLs. > > > > So all good here. > > > > > > > > The last part of the question is "Suppose a (legacy) > > node does ECMP > > > > hashing by reading the first n labels on the stack?" > > > > Since it doesn't know about MNA, it will find Opcodes > > and ISD and > > > > treat them as labels. > > > > This is not a problem in itself, but if the ISD can > > vary from packet > > > > to packet in a flow, it can lead to packets taking > > different paths. > > > > This question is covered in section 5.2 which tells us > > to be careful > > > > which ISD bits are allowed to vary. > > > > > > > > But it was in re-reading 5.2 that Stewart and I had > > some worries. > > > > > > > > 1. The text says: > > > >       if a network action encodes data > > > >       that will change during packet forwarding > > > >    While this may be interesting for OAM, what is more > > interesting is > > > > when the > > > >    data is different on different packets in the same > > flow. So > > > > probably change > > > >    this to: > > > >       if a network action encodes data > > > >       that may be different on different packets in the > > same flow > > > > > > > > 2. s/Indicators those need/Indicators that need/ > > > > > > > > 3. There are not many bits that are allowed to contain > > variable data. > > > >     This is a bit grim. We reckon that: > > > >     - No bits in a type B LSE can be variable > > > >     - Only 7 bits in a type C LSE can be variable > > > >     - Just 11 bits in a type D LSE can be variable > > > >     If you wanted to carry something like a time stamp > > (RFC 8877) you > > > > need > > > > 32 bits > > > >     or even 64 bits. That would need 4 or 7 LSEs (BDDD or > > > BDDDDDD/BCDDDDD) > > > >     instead of 2 or 3 (BD or BDD/BCD). > > > >     There are some possible mitigations: > > > >     - Use an entropy label. This allows any > > implementation that > > > > supports entropy > > > >        labels to not hash. But: > > > >         * it costs two additional LSEs > > > >         * it doesn't help with implementations that > > don't support > > > > entropy labels > > > >     - Stop hashing when you reach an SPL. > > > >       This advice would work for new implementations, > > but it doesn't > > > > help with > > > >       existing implementations which will hash their > > way through into > > > > the NAS. > > > >     - Follow the draft and restrict where variable data > > is placed. > > > >         * Use lots of LSEs. Not a very good answer. > > > >         * Don't send much variable data. A bit of an > > unfortunate > > > > limitation. > > > >         * Put variable data post-stack. > > > >     - Decide that we don't care about legacy nodes. > > This is not ideal, > > > > but an > > > >       operator might know about the nodes in their > > network. If this is the > > > >       choice, then the document would need to be clear. > > > >     - Choose a behaviour based on knowledge of the > > nodes in the network > > > >       and the (potential) path of the LSP. This > > approach would require > > > >       capabilities to be advertised (perhaps alongside > > the RLD ). > > > > > > > > Cheers, > > > > Adrian > > > > > > > > _______________________________________________ > > > > mpls mailing list -- mpls@ietf.org > > > > To unsubscribe send an email to mpls-leave@ietf.org > > > > > > > > _______________________________________________ > > > mpls mailing list -- mpls@ietf.org > > > To unsubscribe send an email to mpls-leave@ietf.org > > > > _______________________________________________ > > mpls mailing list -- mpls@ietf.org > > To unsubscribe send an email to mpls-leave@ietf.org > > ____ > > > > > > _______________________________________________ > > mpls mailing list -- mpls@ietf.org > > To unsubscribe send an email to mpls-leave@ietf.org > > -- > Loa Andersson > Senior MPLS Expert > Bronze Dragon Consulting > loa@pi.nu > loa.pi.nu.@gmail.com > > _______________________________________________ > mpls mailing list -- mpls@ietf.org > To unsubscribe send an email to mpls-leave@ietf.org -- --- tte@cs.fau.de