IETF Logo Mail Archive

Re: [mpls] What percentage will carry indicator/ancillary data in the future

Kireeti Kompella <kireeti.ietf@gmail.com> Mon, 11 October 2021 18:22 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 3C25D3A0773 for <mpls@ietfa.amsl.com>; Mon, 11 Oct 2021 11:22:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level:
X-Spam-Status: No, score=-1.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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 X7oxDpJ1QJmk for <mpls@ietfa.amsl.com>; Mon, 11 Oct 2021 11:22:47 -0700 (PDT)
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 BD4783A0768 for <mpls@ietf.org>; Mon, 11 Oct 2021 11:22:47 -0700 (PDT)
Received: by mail-pj1-x1036.google.com with SMTP id om14so1999336pjb.5 for <mpls@ietf.org>; Mon, 11 Oct 2021 11:22:47 -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=b/F5oxHXUoW89vhJMB9gSHRbK9o0DGfLQee7kSn2qBg=; b=GqT8qUkXhn5IISlEc4eFTXo9el9vMajadFG+HBnwFAeDy1sPK6Zs9XnK2ihgWg+0s2 cNviHZqrHE0zhOixr9NkGroTTT+JpoP1Qt0U2Rtu2B5TSL32jL+c5wyyQZadwA/oZH9M DuyOWIGcqlsKUvwpL0PF0y8kzqseZctzH50bPYaOl8c8+g8mXoIYC0g7a3XNPfoiRMSH M+lhSRMtF2p5MNghVwT6Agywp7b901TAti9hTHpTI2/orTQjZPG3Lx26qUN9D27dfGyU JKXRCzC8jJ0a8VSHXG6wuaEG4/GFhDT2ekNh0K53lTq0ytlmfKvudaqMmecDs5dac7TF WLsg==
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=b/F5oxHXUoW89vhJMB9gSHRbK9o0DGfLQee7kSn2qBg=; b=nYD1NxR8epp/8RD+sg+7EaUSw6r20WRXZGk628ecTxsqKAHzYKth2UJneMxP5UUe4F 7ew7OxaJYEgct4Aw7NDvQ7d/Hja0LitdFYN7REXgmP4DYalsjNiEKxZM/kWQ2920iSUO nlTaXQbu+5mkoGIqWCVM2BnBFeTpqSyjRecUDjdd0CFGw+5zAaPZKXI9JJnJDOkMiYPz hcVsUrp1f6rgq5igGngvO/p7IatDIozIc25hxWzTB4IKaW7C4dEdS04VmiWcLlDkUOMk oRSJ9mxr2dehD0wAXNfxNzrH0sfY8Vq8YxHVivLVY4nDDzg7lMFu5cgSnPVx/+x7+j85 sO8g==
X-Gm-Message-State: AOAM531GqHvQiAl2SFsZiuu+dyyijcWGH7ATl14nrVy1DYs2Jly0dAhK dTAEPxPEDWah6h10RsNL7jw=
X-Google-Smtp-Source: ABdhPJy7NTWCwvK/jZ1tmvdDY1p9FS4ZmyskI34FEYJazryk5+Poo9K0SPXs3LccsGoWWDDp+Ki7gw==
X-Received: by 2002:a17:90a:7d11:: with SMTP id g17mr603756pjl.19.1633976566944; Mon, 11 Oct 2021 11:22:46 -0700 (PDT)
Received: from smtpclient.apple ([66.129.239.12]) by smtp.gmail.com with ESMTPSA id c8sm222952pgn.72.2021.10.11.11.22.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Oct 2021 11:22:46 -0700 (PDT)
From: Kireeti Kompella <kireeti.ietf@gmail.com>
Message-Id: <8406C791-B84E-4F89-8F0D-607C7674D56E@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B47B139B-D453-4BE8-8E3C-BAD2AD70A083"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Mon, 11 Oct 2021 11:22:45 -0700
In-Reply-To: <305E9D87-ECCE-4E64-930D-19F9CD104F02@gmail.com>
Cc: Kireeti Kompella <kireeti.ietf@gmail.com>, Loa Andersson <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org>
To: Greg Mirsky <gregimirsky@gmail.com>
References: <f419b94c-b55b-d6b2-ca91-23c8f31f2677@pi.nu> <CA+RyBmW3eaSo2gUi5=KYHp8qAF0E+ykf1=ojaTmSZF0m=eoMHg@mail.gmail.com> <305E9D87-ECCE-4E64-930D-19F9CD104F02@gmail.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/cMBpboysFLariNIUvRRhLneOGtM>
Subject: Re: [mpls] What percentage will carry indicator/ancillary data in the future
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: Mon, 11 Oct 2021 18:22:52 -0000

Here’s what I’m thinking for the next iteration of the draft.  We’ll burn two bits for hbh and e2e.  I propose the following encoding:
00 — No PSD (go back to sleep)
01 — if you are a transit or end node, you SHOULD look at the PSD
10 — if you are a transit or end node, you MUST look at the PSD (use with care)
11 — if you are a transit node, nothing interesting for you in the PSD; if you are an end node, look at the PSD.  (i.e., no hbh, only e2e PSD).

Note that in the naive approach:
00 — no PSD
01 — only hbh PSD
10 — only e2e PSD
11 — both hbh & e2e PSD

The action for 01 and 10 is pretty much the same.

Thoughts?

Kireeti.

> On Oct 11, 2021, at 10:48, Kireeti Kompella <kireeti.ietf@gmail.com> wrote:
> 
> Hi Greg,
> 
> There were separate indicators for h-by-h and e2e.  The e2e was removed following discussion in the DT; it will return in the next revision.
> 
> Of course, the PSD carried and the processing needed will be different in the two cases as they carry different types of data.  Processing h-by-h will also have to deal with traversing a potentially large label stack (and occurs on many nodes), whereas processing e2e PSD will deal with a small label stack and just one node (the egress).
> 
> :k
> 
>> On Oct 11, 2021, at 09:27, Greg Mirsky <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> wrote:
>> 
>> Hi Loa,
>> I have a clarification question. As I understand it, FAI is to signal ancillary data that is processed in hop-by-hop or end-to-end manner (John proposed to have a separate indicator for each use case). The impact on transit nodes is, likely, different. Do you think we need to consider these cases separately?
>> 
>> Regards,
>> Greg
>> 
>> On Sat, Oct 9, 2021 at 10:43 AM Loa Andersson <loa@pi.nu <mailto:loa@pi.nu>> wrote:
>> Design Team,
>> 
>> I have one thing that I been thinking about.
>> 
>> If we consider future mpls encapsulated packet, what percentage will 
>> carry indicators and ancillary data?
>> 
>> /Loa
>> -- 
>> 
>> Loa Andersson                        email: loa@pi.nu <mailto:loa@pi.nu>
>> Senior MPLS Expert                          loa.pi.nu@gmail.com <mailto:loa.pi.nu@gmail.com>
>> Bronze Dragon Consulting             phone: +46 739 81 21 64
>> 
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org <mailto:mpls@ietf.org>
>> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org <mailto:mpls@ietf.org>
>> https://www.ietf.org/mailman/listinfo/mpls
>

v2.23.0 | Report a Bug | By Email