Re: [mpls] Fwd: Notes on draft-jags-mpls-mna-hdr-04
Greg Mirsky <gregimirsky@gmail.com> Thu, 05 January 2023 19:32 UTC
Return-Path: <gregimirsky@gmail.com>
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 6542FC1522D9 for <mpls@ietfa.amsl.com>; Thu, 5 Jan 2023 11:32:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2nRM7JERUob for <mpls@ietfa.amsl.com>; Thu, 5 Jan 2023 11:31:59 -0800 (PST)
Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5081DC1524B1 for <mpls@ietf.org>; Thu, 5 Jan 2023 11:31:57 -0800 (PST)
Received: by mail-qv1-xf31.google.com with SMTP id j9so19833118qvt.0 for <mpls@ietf.org>; Thu, 05 Jan 2023 11:31:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=iFILrXqOD8fy+9KYjxaBbBnCbXFUxRZWRaZdQpfwoeU=; b=Bp3dK6Y1BdmPwrmi9S75or/1ZPOeZV6kAY8NQVve6A0k+hTxRSwMjzdg4eYUkHNwuR BxgILG/NUZFQSX+/ao5ZJ2ysKh3ugI4PWCBZhkhnx4NAmpZrdK1Vpqygo5PpPTRDyU5s KWJOak7dZ3rDTCcBiLjMyb3yWktwOJtnDAcz3LdhxHgCoMFnUufhiDjtMuZATMaIL+I4 O7Dy8AsyoOiX4JUj/ivW3XWboBRur1GB5OcNTy43egAktjg8YDjYLyI+kU5FuL0OOb5/ PG49jRm4Y4qkkcbWDwFNQY0FAEsSkCl6FD0/a5RJg5+n47KojP/FBN+k7YES8qKEYvAN xm7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=iFILrXqOD8fy+9KYjxaBbBnCbXFUxRZWRaZdQpfwoeU=; b=Nc1Ih8OkLWKAlqQP5KwmKtSiXsO4b458wrpTFoW1oXoKO0NI1IDaJ9f0FAxJ0NcAT5 HemCmitaKvBhVfsdynIh2t9ZPFiIgpjcytDLt5mqS8a1lr3F8hvIeX5HFbEL5KyIFYsd Q8yCOZJUfGgqTy/BTP2KTMoa3cC3TZ5dIpuTZ+GhOTq96W8A3SMTcZlG+f1WleP+MqpV c2TUZpgbgKKy0oFjdnB+PnrMNwdANKHtvwd+XWetk99ErYkhy9ZxyUsGTVI1DTycEWXX wlLvLvsPHCAinQ319fwElEmJ9k2xKIg73LM3ga0DvVMQP/fc2igwjW+wK1wENLqhSqQN Hz/A==
X-Gm-Message-State: AFqh2kpwS3TM+kxZS1f0XM+S64RaYzMFrVpoL2QNnCMrMn5qeP+eyijJ 7n9QI3XeINlox9cyzO8YvVb5ZncQOD17GZAqQKQTGoZanTQ=
X-Google-Smtp-Source: AMrXdXtsoP6MqN2c3dzxiOhGrt2YdgsGXA/EZ4o5SwPgg6qrqbtIj3VZv7NKPtlVHGK754uCi0fdpc1PBg6gg9O0A/M=
X-Received: by 2002:ad4:4e8a:0:b0:4c6:e904:3582 with SMTP id dy10-20020ad44e8a000000b004c6e9043582mr2651290qvb.112.1672947115969; Thu, 05 Jan 2023 11:31:55 -0800 (PST)
MIME-Version: 1.0
References: <CA+RyBmX14e=5P6jxpxCm1LYVJZet2bn-OjzXkTSAJ9VGDAZoBw@mail.gmail.com> <CA+RyBmUMp6Zxit=_qnrOCjMAG0uQ5XNwE7A2vCBoZUnviqfZ_w@mail.gmail.com> <BY3PR05MB8081FC71A7FD563B4300200CC7FA9@BY3PR05MB8081.namprd05.prod.outlook.com>
In-Reply-To: <BY3PR05MB8081FC71A7FD563B4300200CC7FA9@BY3PR05MB8081.namprd05.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 05 Jan 2023 11:31:44 -0800
Message-ID: <CA+RyBmWcq+F-efXrBQgX8eRrfW=ywFRuVDSqYqjyAK9teHfx+g@mail.gmail.com>
To: John E Drake <jdrake@juniper.net>
Cc: mpls <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000093523e05f1895a95"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/duHxHxFcYb7ekgEbj-jT606SmH0>
Subject: Re: [mpls] Fwd: Notes on draft-jags-mpls-mna-hdr-04
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
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, 05 Jan 2023 19:32:03 -0000
Hi John, thank you for the clarification. I've put a figure to illustrate my understanding. 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opcode | Data |P|IHS|S|Res|U|O| NASL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opcode = 3 | NAI |S| Data | NAL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~1| Ancillary Data |S|Ancillary Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Ancillary Data |S|Ancillary Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - None, one or more Format C LSEs with Opcode 3 MAY be present in the same NAS. - Each Format C LSE with the Opcode 3 MUST be followed by one or more Format D LSEs carrying associated Ancillary Data. If my understaning is correct, I have some questions about the Ancillary Data encoding: - Can an AD associated with the particular NAI span more than a single Format D LSE? - Can a single Format D LSE carry ADs of more than one NAI? And I still need a help to answer How a node skips an AD associated with the unsupported NAI? Best regards, Greg On Thu, Jan 5, 2023 at 8:51 AM John E Drake <jdrake@juniper.net> wrote: > Greg, > > > > You had previously asked a question about opcode 3 (section 6.4) which you > asked again in today’s DT meeting, viz, for the LSEs which follow the > opcode 3 LSE, how does a node distinguish between an LSE that contains > additional network action flags and an LSE that contains AD? As I > indicated in today’s DT meeting, in response to your initial asking of the > question, we had decided to restrict the network action flags to only the > opcode 3 LSE. This means that any subsequent LSEs by definition contain > only AD. Unfortunately the text in section 6.4 is not completely clear on > this. > > > > Our thinking was that if we run out of room in the opcode 3, we can just > define another opcode with the same semantics to contain the additional > network action flags, and repeat this process as more network action are > defined. This has two advantages, 1) it partitions the network action > flags by opcode so that the ingress node only needs to specify the opcodes > for the network actions in which it is interested and 2) it would allow us > to define custom sets for the most commonly used network actions regardless > of the time order in which they were defined. > > > > Yours Irrespectively, > > > > John > > > > > > Juniper Business Use Only > > *From:* mpls <mpls-bounces@ietf.org> *On Behalf Of * Greg Mirsky > *Sent:* Thursday, January 5, 2023 10:21 AM > *To:* mpls <mpls@ietf.org> > *Subject:* [mpls] Fwd: Notes on draft-jags-mpls-mna-hdr-04 > > > > *[External Email. Be cautious of content]* > > > > Happy New Year to All, and apologies for missing sending my notes to the > MPLS WG. > > > > Regards, > > Greg > > ---------- Forwarded message --------- > From: *Greg Mirsky* <gregimirsky@gmail.com> > Date: Sun, Jan 1, 2023 at 4:06 PM > Subject: Notes on draft-jags-mpls-mna-hdr-04 > To: <draft-jags-mpls-mna-hdr@ietf.org>, MPLS Working Group < > mpls-chairs@ietf.org>, <pals@ietf.org>, DetNet WG <detnet@ietf.org> > > > > Dear All, > > firstly, many thanks to the draft authors for their dedication and hard > work on this document. I've read the latest version, and below you can find > my notes (and nits): > > - the scope of the draft is characterized in the Abstract as the > "solution for carrying Network Actions and Ancillary Data in the label > stack" and as "This document defines the syntax and semantics of network > actions encoded within an MPLS Label Stack" in the Introduction. That may > be viewed as excluding handling of a post-stack placing of MNA and AD. In > particular, how is a PSD-based MNA disposed of (more use cases below)? > - s/OAM logging/OAM action/? > - User-defined actions are mentioned twice in the document. > Considering the extent of the document, a new document documenting > user-defined actions, their scope, etc., would be a reasonable format. What > do you think? > - Would NASes be a better plural form of NAS? > - What is the purpose of the Overview section? Could it be merged with > the Introduction? > - What could be the practical outcome of this case: > > If the node performing this copy is not > > aware of MNA, this could overwrite the values in the first LSE of the > > MNA sub-stack. > > > - As indicated in Section 6.3, Format D may be used to list MAIs > without ancillary data. If that is the case, then the title of Section > 4.4 LSE Format D: Additional Ancillary Data seems to not reflect that use > case. Perhaps removing "ancillary" be acceptable? > - What could be the reason for the modification of the AD by a > transient node, as suggested in the second paragraph of Section 5.2? Which > use cases listed in draft-ietf-mpls-mna-usecases > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-mpls-mna-usecases/__;!!NEt6yMaO-gk!A9Ca9huYFlCTpBVlsrcnvXtGzlbM81LKurzfP85mh-2ylWweGf6aUG9Vdjy_PhycJriZX6ZKZ71tVIoJxtb9$> (minus > APN, as the group agreed) requires AD modification by a transient node? > - Perhaps s/multiple NASs may be/multiple NASs MAY be/? > - It is not clear what is the scope of the "last copy" in the > following requirement: > > penultimate node MUST NOT remove the last copy of a HBH NAS > > Could it be that the "penultimate node MUST NOT remove NAS that includes > MNA of HBH scope"? > > > - Could it be that the following requirement restricts how MNAs are > processed at the egress node: > > An I2E scope NAS MUST be encoded after any HBH or Select scope NASs. > > I imagine that some I2E NAS has to be processed by the egress before the > particular HBH NAS. It looks like the requirement prohibits that. > > > - The following text defines the interpretation of O-bit being set: > > If the 'O' bit is set in a Format B LSE (Section 4.2) then it > > indicates that the network actions encoded in the NAS MUST be > > processed in the order that they appear in the NAS, from the top of > > the NAS to the bottom. > > Is there a particular interpretation of the case when the O bit is > cleared? If there is no particular order of processing NASes, perhaps there > is no practical need for the O bit, and the processing rule can be defined > as the general requirement? > > > - It seems like Opcode == 1 is intended, at least partially, to handle > PSD MNA for non-IP payload, i.e., PW. I am not sure that encoding PSD as > part of the PW payload is the best option. > - A couple of questions on Flag based NAIs with AD (Opcode == 3): > > > - Can the same Format C's LSE combine NAI and associated AD? > - Can the same Format D's LSE be used to list additional NAIs as > well as associated AD? > - Consider that Format D's LSEs are used to encode ancillary data > for a number of NAIs. Can a node that supports only some of these NAIs find > ancillary data for NAIs it does support if there's no uniform format for > the ISD-based AD? > > > - Could MNA be used in an LDP-based IP/MPLS network, as it is excluded > from mentioning in the text? > - What constitutes the "entire NAS" that is mentioned in Section 7? AS > I understand it, NAS is defined as a sequence of LSE following a new bSPL: > > In stack actions and ancillary data are contained in a > > Network Action Sub-Stack (NAS), which is recognized by a new base > > Special Purpose Label (bSPL) (value TBA). > > Furthermore, multiple NASes may be used to signal specific ordering of > NAIs. If that is the case, then what is the "entire NAS"? > > > - Some questions about the Select scope of NAS. > > > - What are the restrictions of using the Select scope in NAS? For > example. is the Select scope associated with only ISD or PSD or both types > may be used in the same NAS? > - Furthermore, if HBH and Select scopes are used in subsequent > NASes, then is there a recommended order similar to the requirement in > Section 5.3 for I2E? > > > - In Section 9.1 seems like s/each LSP/each LSE/ is needed. > - Is the following requirement equally apply to the ISD- and > PSD-located ancillary data: > > A transit node MAY change the Ancillary Data found in the least > > significant 8 bits of an LSE. > > > - In Section 10, it seems like "must" and "should" need to be > capitalized. > - It seems like captions for Table 4 and Table 5 need to be swapped. > Also, if the initial allocation in the "Network Action Flags Without > Ancillary Data" registry is 0-469, it seems logical to do the same for the > "Network Action Flags With Ancillary Data" regstry. > > And here are some questions about use cases. Pleased let me know if any of > them is real or I'm way off: > > - As I understand it, MNA can be used in SR-MPLS. In that case, > multiple NASes may be present in the label stack. Since I couldn't find any > restrictions for use of multiple NASes, these might be different, i.e., > include different NAI and/or different ADs. Is that right? > - Also, for the SR-MPLS case that uses PSD. Would there be a single > PSD or a copy for every ISD NAS? > - If there's a single PSD for all NASes in the stack, which node must > remove the PSD? > - If there the PSD is per NAS then the node that disposes of NAS must > remove corresponding PSD. Right? But that might affect the offset from BoS > for remaining PSD. > > Thank you for your kind consideration of my notes and questions. Looking > forward for our discussion. > > > > Happy New Year and Best Wishes to All! > > > > Regards, > > Greg >
- [mpls] Fwd: Notes on draft-jags-mpls-mna-hdr-04 Greg Mirsky
- Re: [mpls] Fwd: Notes on draft-jags-mpls-mna-hdr-… John E Drake
- Re: [mpls] Fwd: Notes on draft-jags-mpls-mna-hdr-… Greg Mirsky
- Re: [mpls] Notes on draft-jags-mpls-mna-hdr-04 Tony Li
- Re: [mpls] Notes on draft-jags-mpls-mna-hdr-04 Tony Li
- Re: [mpls] Notes on draft-jags-mpls-mna-hdr-04 Greg Mirsky
- Re: [mpls] Notes on draft-jags-mpls-mna-hdr-04 Greg Mirsky
- Re: [mpls] Notes on draft-jags-mpls-mna-hdr-04 Tony Li
- Re: [mpls] Notes on draft-jags-mpls-mna-hdr-04 Greg Mirsky
- Re: [mpls] Notes on draft-jags-mpls-mna-hdr-04 Tony Li
- Re: [mpls] Notes on draft-jags-mpls-mna-hdr-04 Greg Mirsky