IETF Logo Mail Archive

Re: [mpls] Poll 2: New SPL vs re-purposed ELI for carrying Network Action Indicators

Robert Raszuk <rraszuk@gmail.com> Fri, 17 June 2022 18:41 UTC

Return-Path: <rraszuk@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 02CFAC15AE30; Fri, 17 Jun 2022 11:41:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 J2wydSusP1Ez; Fri, 17 Jun 2022 11:41:02 -0700 (PDT)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 10A47C157B37; Fri, 17 Jun 2022 11:41:02 -0700 (PDT)
Received: by mail-qk1-x729.google.com with SMTP id p63so3746278qkd.10; Fri, 17 Jun 2022 11:41:02 -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=0YxKJZtRZLnjSuLcyZ7QEKb71X0OqRTT9eenZ/BTbkg=; b=KnsD72b7POlQJ8NaS5Ua5+5I34KwDNMyD777bfTVV8P2cYCVLlQTZBwi9H93h2Udw/ NkclGmEdt5zdHH+2TBK2iQsAvqQRNIsM2qC3VM59StS3BxpG8hU2fpvt8PMStQHYqcle MqjRN3pkhZPgKC+uD/RhRSVJeeYRQykQbv6Mu8PtvtTr4CE5kaBcbdiiEYivhnjtlS5S g9FUilwAQUa/YmwpDuEB64y6Svph/rt7+WZPjiqM8tsaGhoI2uD7cFQwODI1O0kLXeU8 rmgc7l7Z70gTQw3V53RENLAN3TN9CMrfPonoTixBAhPT0I2qq1CdVMiHAn4pw8xYuJzx Cnfw==
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=0YxKJZtRZLnjSuLcyZ7QEKb71X0OqRTT9eenZ/BTbkg=; b=c3WhFy+KuMC2bzoXdExjtPfg0y4pRVosWE1GY0iMTPmXhCEr4jGPNCnQrotrlfu469 XQjnaymaqiJehEKUEMq/jxzIWQtYun+2Z6XE+CJ9+Uoq4EVQetYZ3Ve3m3Pt37V9LGsy r6jVut5Ox25VHTq7USn3mVj4VvhYffoGyURP22glZsA8y5lHjI+S9dOmPS7tI9jPOm2R C1XQgFaFS3DuvHLKEVwKyE8VXbJsuEvC1sjLVPpsVNQ1CsMexGHGX1hp1SWuciNlGxWW 5zcJCKYGS4KVOlzQIwJQt584x5CtJygCbMeGb1+satqf9S58qhENZYG2p5Ctfcu2MUqP gM9Q==
X-Gm-Message-State: AJIora++B9HN+CSkQk6enCHU9LoxsOGy/xrBnCnpruFE+i+pybl6d1Ga ozo1AgG3bq+mulQl+r5uB9o0D10PJGe+QS3RuNQ=
X-Google-Smtp-Source: AGRyM1vtlpFyF0MzlFGU1vw7CezKGoEtKDRU2TpZpqXj+mXLgbcoFfmidClDRm47yxuEQ1W2wcvFQFI79TDCLHENB5E=
X-Received: by 2002:a37:e304:0:b0:6a6:a784:6276 with SMTP id y4-20020a37e304000000b006a6a7846276mr8353910qki.778.1655491259749; Fri, 17 Jun 2022 11:40:59 -0700 (PDT)
MIME-Version: 1.0
References: <6e5c6fa9-539f-80c3-7c92-5b97ad67560c@pi.nu> <447_1654704927_62A0CB1F_447_309_1_1f59cd955500419a988e2218a3f2246e@orange.com> <9F79E3D5-7ACE-4D15-83D7-8BF3FF60F671@gmail.com> <C9D1FD4A-2549-49C0-8904-84E3F559E85C@cisco.com> <988F5CAF-1A12-4209-92B5-B9AE75477B5C@tony.li> <4D3BA352-6E89-489D-A849-2B72A5D0DC1F@cisco.com> <1F0A4345-C258-4BE6-92D4-C846C0B77048@tony.li> <7111_1655456559_62AC432F_7111_124_1_196adfdc44ba4f44bd7e59deb7e6410a@orange.com> <CB42DAF5-9E23-4F41-BF3D-9945A6274921@tony.li> <7FF1D291-49F1-4132-A7A5-59DCAE4E1786@cisco.com> <D5CE51A5-4C24-4360-8C90-AE52FFDA9E57@tony.li> <CA+b+ERkiOZBiC0_VUJSiGTdaayWoysbMMfsPS7kYmMQyggbmUQ@mail.gmail.com> <CA+RyBmUEMWt1Duyop4gE+S7FRr-qW4g_V3wjXRwghaSV6tLpvQ@mail.gmail.com>
In-Reply-To: <CA+RyBmUEMWt1Duyop4gE+S7FRr-qW4g_V3wjXRwghaSV6tLpvQ@mail.gmail.com>
From: Robert Raszuk <rraszuk@gmail.com>
Date: Fri, 17 Jun 2022 20:40:48 +0200
Message-ID: <CA+b+ERmqY=dizGWtj0Jx9kmDGs=sfthbKkA2LRUsy7XVjads-g@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: Tony Li <tony.li@tony.li>, "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>
Content-Type: multipart/alternative; boundary="0000000000007758cb05e1a9189f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/DVPhWpiSqTNFENoFsAiMLODK6Cw>
Subject: Re: [mpls] Poll 2: New SPL vs re-purposed ELI for carrying Network Action Indicators
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: Fri, 17 Jun 2022 18:41:06 -0000

Hi Greg,

RFC9197 is clear what protocols can be used to realize it.

Quote:

   Data-Fields can be encapsulated into a variety of protocols, such as
   Network Service Header (NSH), Segment Routing, Generic Network
   Virtualization Encapsulation (Geneve), or IPv6.

I do not see any L2.5 protocol suitable to be used for IOAM extension.

So the way I would see this applicable to the topic is via local punt
indication and IOAM data would sit in packet payload (PSD) not within the
label stack.

Slice_ID would be programmed among other things to execute IOAM on a
packet.

Many thx,
Robert



On Fri, 17 Jun 2022 at 18:28, Greg Mirsky <gregimirsky@gmail.com> wrote:

> Hi Robert,
> could you please clarify why you believe that ioam "is just control plane
> on how to handle a slice"? Do you believe that support of RFC 9197
> <https://datatracker.ietf.org/doc/rfc9197/> does not command any change
> in a respective data plane and can be achieved with a common extension(s)
> in the control plane? Also, could you kindly explain how IOAM Trace Data
> could be collected?
>
> Regards,
> Greg
>
> On Fri, Jun 17, 2022 at 8:47 AM Robert Raszuk <rraszuk@gmail.com> wrote:
>
>> HI,
>>
>>
>>> * * entropy*
>>> * * slice id*
>>>       * nffrr
>>>       * ioam
>>>       * detnet
>>>       * sfc
>>>       * np
>>>       * aan
>>>
>>> I count 8.
>>>
>>
>> I count 2.
>>
>> entropy as is and slice_id
>>
>> Rest is just control plane on how to handle a slice. Exactly as described
>> in my RAF proposal.
>>
>>
>>> Zero room for growth.
>>>
>>
>> Infinite room for grow.
>>
>> Our job is to think farther ahead.
>>>
>>
>> Our job is to also think holistically on what we are transporting. And
>> that is real user's data - not SP's instructions.
>>
>> Many thx,
>> R.
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>

v2.23.0 | Report a Bug | By Email