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

Greg Mirsky <gregimirsky@gmail.com> Sat, 28 May 2022 18:51 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 62F6AC15AE22; Sat, 28 May 2022 11:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.097
X-Spam-Level:
X-Spam-Status: No, score=-6.097 tagged_above=-999 required=5 tests=[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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 43yGpqyERPpw; Sat, 28 May 2022 11:51:42 -0700 (PDT)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 5CF4CC159827; Sat, 28 May 2022 11:51:42 -0700 (PDT)
Received: by mail-lf1-x129.google.com with SMTP id br17so11331861lfb.2; Sat, 28 May 2022 11:51:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YQsSAlB+g97EZa0+chPQx4xdVTEbD83CYrSDcS42f9Y=; b=e8m4dSeb/EqcFkowO39dNvCsWkj2xz1kltcMGFcLPIcwJQLQCzYpjUOfkPCKxA4Fba /LcbIL9vH/+QQXCw4spw9L8j5ouSPdEBUEJMPNupiXBkidv2hzBVMGKYU3/ov0dAYgvV hfpwGKkiYSFYbr0mVksaVCgJbdxJ3NOJEBJcXR/2A5+/5aElJWWWRrgUK0ABZ9qjuzZV 1wZfo+T7KiVWC733Ywuf6gH15YxPAfI5uZo3wWonf6NEQNXdXiHb5mSbVkbXu8q9+gdk ygN5vVcas+xu6gRfxfONewqUo8wmpEHhmMwhJijsVetJw9ByDFRS4jVobgTZpRQFRxxn XlkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YQsSAlB+g97EZa0+chPQx4xdVTEbD83CYrSDcS42f9Y=; b=e27oi5M7rrfAldKl5mYGVvqUYGE6jLoEGlfTGManPaKn/eebqhVvZNu3Ym1byBRc6l 0tJpJd2YKTfz1BcsTrRTT8ErU3Kpj2i4CGOa8zen+08zGFw3BEJJtPgzz2sv9RwCdZKC mXMKs1JNqf5NwWwROXhxo8e7xOpE6BJnFfCX+Qw9kEVGTDvvcn4aUJpMLhRy8ipPLf1U OLr8yEN17EZdzaUS1OiM6lF77Ib2ARG25pAYykWjWvPiYVbRybyCE95nq/To2m90MFKk BgyysE81sxuhp1wwOI2SLUcvST/FIES2x0IjhNvuonaKM6DiAB+w3bFXOYg5W+ITjosK FIVA==
X-Gm-Message-State: AOAM533FAfpvWajol50LiQBfyNo6uYLD1LHEOpjcglMy8qsROnJLwjp9 8zF2s8+ovcPgXEnaO4iqdXf2ifKXsCPS2BZvesGRKLZfgDk=
X-Google-Smtp-Source: ABdhPJwdM3E7oOzvbtofdJugiPdrXu2J5fr4t51B7Sczau1bQRNJhfykj82PChtxT9NUWyJseOEECY87ExIiQmOxsPo=
X-Received: by 2002:a05:6512:3f8e:b0:474:bb8:4434 with SMTP id x14-20020a0565123f8e00b004740bb84434mr34207179lfa.310.1653763900071; Sat, 28 May 2022 11:51:40 -0700 (PDT)
MIME-Version: 1.0
References: <2a6db1c68e594c3082349733b32df351@huawei.com> <4204F6A9-5D62-4A3C-846E-4FB323B8A05E@tony.li> <3a37f2ab48924f059451f7f55317c74b@huawei.com>
In-Reply-To: <3a37f2ab48924f059451f7f55317c74b@huawei.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sat, 28 May 2022 11:51:28 -0700
Message-ID: <CA+RyBmV5a4vk=Li-qsz=CRDozm1rL_vWVkwkd7Kr0qC8b6WfDw@mail.gmail.com>
To: "Dongjie (Jimmy)" <jie.dong=40huawei.com@dmarc.ietf.org>
Cc: Tony Li <tony.li@tony.li>, "draft-andersson-mpls-mna-fwk@ietf.org" <draft-andersson-mpls-mna-fwk@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ce623405e016e95c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/ScVOhc6GiK56krmYJ2ondL2M8r8>
Subject: Re: [mpls] Comments on draft-andersson-mpls-mna-fwk-01
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.34
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: Sat, 28 May 2022 18:51:44 -0000

Hi Jimmy,
I want to share my views on the question of ISD and what we can interpret
as "consensus".
As I've commented before, ISD is a viable and useful option and I don't see
a good technical reason to not include it in the MNA architecture. Whether
this view is where the WG consensus falls, I don't know. I believe that is
the prerogative of the WG Chairs to determine that. As for the authors of
this individual draft, I believe they are not obligated to change their
document unless they want that.

Regards,
Greg

On Sat, May 28, 2022 at 1:22 AM Dongjie (Jimmy) <jie.dong=
40huawei.com@dmarc.ietf.org> wrote:

> Hi Tony,
>
>
>
> Thanks for your prompt reply, and the effort of making some changes in the
> updated version.
>
>
>
> The remaining comments I see are mainly about the following aspects:
>
>
>
> 1.      Concepts and terminologies
>
>
>
> -        Network Action vs forwarding action. Since this document
> introduces the concept “network actions”, and it says network action is
> more general than forwarding action, I’m not sure the concept “forwarding
> action” needs to be defined here, actually it is only mentioned in the
> introduction. I’d suggest to just introduce one new concept (network
> action) instead of two.
>
>
>
> -        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.
>
>
>
> -        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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> Another existing work which may be incorporated is
> draft-andersson-mpls-eh-architecture, which describes the architecture of
> MPLS extension header. Some of the text in that document may be reused for
> the description of the PSD part, and some text may even be generic for both
> ISD and PSD.
>
>
>
> Hope this helps.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Tony Li [mailto:tony1athome@gmail.com] *On Behalf Of *Tony Li
> *Sent:* Friday, May 27, 2022 1:50 AM
> *To:* Dongjie (Jimmy) <jie.dong@huawei.com>
> *Cc:* draft-andersson-mpls-mna-fwk@ietf.org; mpls@ietf.org
> *Subject:* Re: Comments on draft-andersson-mpls-mna-fwk-01
>
>
>
>
> Hi Jimmy,
>
> Thank you for your comments.  I’ve replied to each and every one of
> them.  As you commented inside of a Word document, I’ve replied in kind.
> Please see the attached document.
>
> I have made a number of the changes that you’ve suggested.  I will send a
> separate post to the list with the updated document and a diff.
>
> Many of the changes that you suggested hinge on a single question which
> you did not raise directly.  That question should have the input of the
> broader group, so I’ll raise it explicitly now:
>
>         Currently the framework document implicitly precludes some of the
> mechanisms found in draft-song-mpls-eh-indicator.
>         Should the framework draft be broadened to encompass this draft?
>
> Speaking personally (co-author hat off), I don’t see an architectural
> reason to disagree. Please don’t take this as support of the draft.  I
> still believe that this is a sub-optimal approach, but could it work
> architecturally?  I have to say that yes, it could, and thus the framework
> draft could and should be broadened to encompass this.
>
> If the group agrees with this, the changes to implement this are minimal
> and straightforward.
>
> Could I please get input from the group?
>
> Regards,
> Tony
>
>
>
> > On May 25, 2022, at 7:34 AM, Dongjie (Jimmy) <jie.dong@huawei.com>
> wrote:
> >
> > Dear authors,
> >
> > Thanks for the effort in organizing and updating this document. I've
> reviewed the current version and have a number of comments and suggestions.
> >
> > In my view, the most important thing for this framework document is to
> describe the possible changes introduced to the MPLS architecture, the MPLS
> data plane encoding, and the processing behaviors of the LSRs.
> >
> > Please find the attached file for the details of my review notes.
> >
> > Hope it helps and looking forward to your feedback.
> >
> > Best regards,
> > Jie
> > <draft-andersson-mpls-mna-fwk-01_Jie Dong_0525.docx>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>