Re: [mpls] on MIAD ADI requirement draft RE: Agenda for the MPLS Open DT 2021-10-14

Kireeti Kompella <kireeti.ietf@gmail.com> Thu, 21 October 2021 14:42 UTC

Return-Path: <kireeti.ietf@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 7F5213A1746; Thu, 21 Oct 2021 07:42:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.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, HTML_MESSAGE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysVlBpCZNEsL; Thu, 21 Oct 2021 07:42:48 -0700 (PDT)
Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DD23A1740; Thu, 21 Oct 2021 07:42:48 -0700 (PDT)
Received: by mail-pf1-x433.google.com with SMTP id f11so812647pfc.12; Thu, 21 Oct 2021 07:42:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zPFzWC9xQt18oYCcAKZbS7t6dUNunx7IZ/AXy6e6R+U=; b=E+pjNUm+PrVR49wVhSwvwiJnybfgVCVqpmLHV+azjNsmAZ1/h7B8W0EmSbSEHM740Z RG71gBoikIIrKk/hlY/eJio4TmzNG5RotvQHFBGVlVpcknuItsyOC0n2RSTdR0gWs0bQ l7mBRk9rKOXDFGym1IkExyzgI/wtR0pQ2qrQAQ7ex4xmDzpmxxbBnvweAAa9K7/uMibk qYxyt3uBgxL6+EQRTk5pWi6DFT2oo3pMhu/vDd0SqwEhybBJNpqRLuWOOGdr23CwALtv t1zPY+5smN5xI9/Ad4wi8VpdWZI93wqwcPRKDOBNI75jBdz+d/OA6wujoYkV0ZfvpT/l nRAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zPFzWC9xQt18oYCcAKZbS7t6dUNunx7IZ/AXy6e6R+U=; b=TBgVdHvQfX6d4VaPGjXU3k0BqL3zZiHesVsE3wtRMJey90/ei+pcGZUDLVOan5G/Uu DyJ6aPRMFcBPv6G4uQaeiWftFUYXeLxqTyUTXo+iWTqeMwOHgznEAITxMMGjXqqb7o0y togmQnbUHhpqkPkuuXGp49k2c3UixoTDBuVspca6JyuYIk4Mj9sCOhkMYCuLU0smcbyD ZyfFhn7Fq8up/n6KytI4Und0s+mo1Rbuqe+oBGzDrqN53p3EFJwIYu1nGkNQABVyi0G1 LJqUuv8EuHlhVRL1jZFE4mhCL9ZP6bGAB1dLv9UO6tg4yN16f64Cyh+ute46IUixhnqM ZYlQ==
X-Gm-Message-State: AOAM530OTFUkwuTsFfV6jLf1TWHgyvaUhCIyxlot/yuWIjRAIVHxu7Uf T5SJez0t0USVQJTVIM1rN6M=
X-Google-Smtp-Source: ABdhPJznxOiGc+YtslPhNJYRvCGhQPOaMqS4/dHZ5ncl01OL89uTCIIPXVUmFQo/ZhyEPg/k9vZi2Q==
X-Received: by 2002:a63:f356:: with SMTP id t22mr4746933pgj.18.1634827367175; Thu, 21 Oct 2021 07:42:47 -0700 (PDT)
Received: from smtpclient.apple (172-125-79-142.lightspeed.sntcca.sbcglobal.net. [172.125.79.142]) by smtp.gmail.com with ESMTPSA id s17sm5518126pge.50.2021.10.21.07.42.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Oct 2021 07:42:46 -0700 (PDT)
From: Kireeti Kompella <kireeti.ietf@gmail.com>
Message-Id: <C089860C-3F9A-4477-8DD9-FD3A6A250DF7@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0D57BD95-DEC8-4DFA-BF47-93C25CA98171"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Thu, 21 Oct 2021 07:42:45 -0700
In-Reply-To: <DBAPR07MB6984AD1BF19BD11556B20AD3EBB99@DBAPR07MB6984.eurprd07.prod.outlook.com>
Cc: Kireeti Kompella <kireeti.ietf@gmail.com>, Haoyu Song <haoyu.song@futurewei.com>, Loa Andersson <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org>, "pals-chairs@ietf.org" <pals-chairs@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, DetNet Chairs <detnet-chairs@ietf.org>
To: "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>
References: <BY3PR13MB478755C56CF5982C510B9E329AB89@BY3PR13MB4787.namprd13.prod.outlook.com> <DBAPR07MB6984AD1BF19BD11556B20AD3EBB99@DBAPR07MB6984.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/jwT8DdKYmuKKy80rqUiVPOYf6Ag>
Subject: Re: [mpls] on MIAD ADI requirement draft RE: Agenda for the MPLS Open DT 2021-10-14
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
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, 21 Oct 2021 14:42:54 -0000

Hi Matthew,

On Oct 18, 2021, at 01:55, Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com> wrote:

> “The mechanism to indicate thatAncillary Data is present MUST operate in the context of the top of stack LSE.”

I’m not sure what this means, except possibly, the ADI MUST NOT be the top of stack LSE.  There were some suggestions that the FAI could be at the top of stack, accompanied by some label gymnastics to get the forwarding label.  This rules that option out (which I’m happy about).

Here’s some alternate text:

"The mechanism to indicate that Ancillary Data is present MUST allow for simple forwarding of MPLS packets based on the top of stack LSE.  A node MAY (SHOULD?) go further, though, to find the ADI within the label stack and act upon it."

> MB> This is something we need a discussion on but, in essence, what we are saying is that it must be consistent with the MPLS architecture. An LSR just does a swap of the top label, or a pop and forward, but unless it is doing something like scanning the stack looking for an ELI it doesn’t change the fundamentals of MPLS forwarding behaviour based on labels below the top of stack. Even in the ELI case, it still forwards to an ECMP next hop where that top label is valid. Besides, the ADI is for ancillary data so it is subordinate to the basic MPLS forwarding decision.

I don’t know the full scope of the Requirements doc, but the FAI has a dual purpose: to indicate that certain forwarding actions are to be taken, and to carry relevant data for those actions.  An ADI (and its data) by itself isn’t much use.  Think of the ELI carrying an Entropy Label, but without the semantics of “load balance using this”.  Pretty useless. Or, for a more current example, carrying a GISS without saying, "this is the slice indicator; take the appropriate action”.  Essentially, “here’s a 32-bit field.  Have a nice day!” :)

One can say that the action is implicit in the type of data carried, but I prefer being explicit and more general.  FAI — forwarding actions indicator — focuses on the action, indicates the associated data, and is inclusive of cases (like NFFRR) where there isn’t associated data.

:k