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
>