Re: [mpls] Comments on draft-andersson-mpls-mna-fwk-01

Tony Li <> Tue, 31 May 2022 14:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A384C15BFE7; Tue, 31 May 2022 07:54:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.506
X-Spam-Status: No, score=-1.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QY9-5dsHjE84; Tue, 31 May 2022 07:54:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::530]) (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 (Postfix) with ESMTPS id 2C8E9C15AE2D; Tue, 31 May 2022 07:54:11 -0700 (PDT)
Received: by with SMTP id j21so13038206pga.13; Tue, 31 May 2022 07:54:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HP5XXxiwS3TdZtghRlyuIprXgadvU+fCsVQLGScNGUU=; b=NUQG9YexLQq7ntpBBDq3Tb5Gii/tAF+/1ZjVpSSEDyT0Z1NngbqgIKCRza9DZOqynZ p2keQc/9vt9/56Zft0CQVvPWMm6S78vEJa+cpKiIMhFQxcaaqFLus+802hludUZ/Mqo6 uIIjlSItb720qrhnys0wCPd2yfmiGwqj932+FofDpviO+MLqszc7VtpEAi185YpYimkc 5HMGFCbNRfJQ+dXzy9CG22IzzVFdu9P0N3KKx0OLjzsEc7KL1nBNtzbvvDIOiLFmv4hg vjIzq7+7HI2Ky2T1mAB3jC7XTQB7ifUZ0IOoqekUOXWNlzewd0doEP1U19CMl8Soh6qU UUrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=HP5XXxiwS3TdZtghRlyuIprXgadvU+fCsVQLGScNGUU=; b=XCf0WsY76hSUB/aN8woxfuw1p94QMs1zBopal4t19PY/8yUi7UlOojDjs+08zVXI2O hWhnGb66+ZRvz43dSRZXCtNJcgUwY23xXz0miJOLPKwHq3RvHoxI/nNYDz6/QhvMG3JE CJw2hFZ4yy14KRliUKDs9Yt5pHZ27s8ythV9ZWbGgyXjXN3XG7PR63ZkeuA7OvtobSuY C4kMlHA5bXS+djSIc1ORqVymUXGeEtm+ImvaA+Pk3XXA/JrXu8yq7FtlsGFjwWHV+pj0 ngMLO1NJmu9ZkzgKBc+QJo30sDKmuVinW65NeoXyXJ9P5QqPeL0Sy5bNYYqWpvOTHihN y8xA==
X-Gm-Message-State: AOAM53315w6d2Ubn563UJ7Znm9nCEzwvrtfGwfwJ036MrPyv7B89Ft8l dcg2FQNjb2XEO5YF2LLQUFihUzFUKIc=
X-Google-Smtp-Source: ABdhPJy1bw6BgXS7fJTBYfeM7jQ9SKiVsRiOYufF277uXKS3Zt3mHtoKmsAMqI6REOY/B+txx6QmDA==
X-Received: by 2002:a05:6a00:2403:b0:4fd:e84a:4563 with SMTP id z3-20020a056a00240300b004fde84a4563mr62388750pfh.60.1654008849870; Tue, 31 May 2022 07:54:09 -0700 (PDT)
Received: from ( []) by with ESMTPSA id k17-20020a170902ba9100b0015ea8b4b8f3sm3849941pls.263.2022. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 May 2022 07:54:09 -0700 (PDT)
Sender: Tony Li <>
From: Tony Li <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4E99047E-9F25-4728-95FB-DADCA40AE0E5"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.\))
Date: Tue, 31 May 2022 07:54:08 -0700
In-Reply-To: <>
Cc: "" <>, "" <>
To: "Dongjie (Jimmy)" <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3693.
Archived-At: <>
Subject: Re: [mpls] Comments on draft-andersson-mpls-mna-fwk-01
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 May 2022 14:54:12 -0000

Hi Jimmy,

> -        Ancillary data. The major question is: are the network actions without further parameters considered as ancillary data? This was recorded as one of the comments to the requirement document, and this document shows that inconsistency understanding of this basic concept could result in different interpretation of other terminologies. Thus I’d suggest the DT and the WG to have further review and discussion about the definition and the scope of ancillary data. 
> A network action is an abstract concept, so it is never considered data.  This is why we have Network Action Indicators.  NAI are not ancillary data.
> [Jie] There are network actions which don’t have any associated data and only need an indicator in the packet.


> According to the ancillary data definition, such indicator also belong to ancillary data (data relating to the MPLS packet that may be used to affect the forwarding or other processing of that packet). Or do you want to modify the definition of ancillary data to exclude the network action indicators?

I disagree with your interpretation of the definition.  I would be open to suggestions on how to clarify the text.

> -        Network Action Sub-stack Indicator (NSI) and MNA label. These terms are used to refer to the indicator of the network action sub-stack. However, there is no clear text about whether they can indicate the existence of PSD or not. In the framework a general term for the indicator of the ancillary data (either ISD or PSD) is needed.
> That’s because they’re orthogonal to PSD.  The indication of PSD is an NAI for a network action that requires PSD.  Similarly, the indication of ISD is an NAI for a network action that requires ISD.
> [Jie] What you said is just one solution to indicate the existence of PSD. The indication of PSD may not rely on the NAI for specific network actions. It is suggested the framework document be generalized to allow different solutions of indicating the PSD.

I disagree.  The solution and the definition of the network action should specify what data is in the PSD.  There is no need for additional redundant signaling and certainly no need for the framework to specify encoding that should be left to the solution.

> 2.      Considerations about ISD and PSD in the framework
> According to the recent DT and mail list discussion, it seems the consensus is that the framework and solution need to include the mechanism for carrying PSD. Whether ISD is needed in the framework and the specific solutions is still under discussion. Thus it is suggested the framework document align with the DT’s discussion on this point: have some text to indicate that PSD is the necessary component of the framework. For the text about ISD, it is suggested to indicate ISD is an optional component, and for some solutions ISD may not be used.
> PSD is not required in every packet.  A solution that may chooses to support network actions that require PSD.  However, we also have solutions (e.g., Bruno’s) that choose NOT to support PSD.
> [Jie] Neither ISD nor PSD is required in every MPLS packet.

Agreed.  Progress!

> From the miad use cases we collected so far, it is clear that some types of network actions need to be carried using PSD. Thus PSD is required in the mna framework to meet the requirement of all the use cases. A solution document may choose to only support a subset of the use cases.

Agreed, and the ability to use PSD is already in the framework.

> The framework currently requires that NAI appear in stack.  I have sent a request to the mailing list (below) to see if the group would be willing to generalize this, but to date, only John Drake has responded.  You have responded in this email, but you have not given a clear answer.
> [Jie] My personal opinion is that the framework can be generalized on the positioning of the NAI.

Thank you.

> 3.      Changes to MPLS forwarding/processing
> The potential changes introduced by MNA to MPLS architecture is not only in the data plane encoding, but also in the forwarding and processing behaviors. This is especially the case for the processing of the ISD data. IMO this is one of the most important things the framework should cover. There is a placeholder section on the development of MPLS forwarding model, the processing of the indicator, the ISD and/or PSD data based on MPLS forwarding model needs to be specified.
> Again, repetition does not improve understanding. 
> The section on the MPLS forwarding model is currently part of the editorial attic.  IMHO, it adds no value and will be discarded.
> We can expect a solution to describe how its particular encoding is to be processed. This is not something that can be dealt with by the framework.  
> As of right now, there are no architectural bounds on a network action. If someone wants to define a network action to compute the Nth digit of pi, that’s 100% acceptable.
> [Jie] The changes to MPLS forwarding model is architectural and not just related to a specific solution or network action. For example, the introduction of NAS to MPLS label stack requires additional processing at the ingress node, and the forwarding (in terms of label stack manipulation) at some transit nodes could be different from traditional label swap or pop.  Such changes to MPLS forwarding needs to be described in the document where NAS is introduced to MPLS.

I disagree. Those details are best left to the solution document.  At the very least, that text will need to be specific about encodings.

> 4.      Incorporation of related existing work
> One of the comments I made is that draft-song-mpls-eh-indicator describes the alternatives of the indicator of the extension header. Please note that most of that text is about general analysis and comparison, and is not specific to any solution (i.e. not PSD only). Thus incorporation of such text would be helpful to this framework document.
> Again, the framework is not an analysis or survey document.
> [Jie] Maybe I was not accurate enough with the above statement, my reading of the content in draft-song-mpls-eh-indicator is mainly the description and summary of the alternatives of the indicator, thus some of which could fit into section 3.1 of the mna framework.

I don’t see anything that is of particular relevance.  If you have a specific suggestion, I’m open to hearing it.