Re: [Idr] WG adoption of draft-zzhang-idr-tunnel-encapsulation-label-stack-01 - 12/23/2022 to 1/13/2023

Robert Raszuk <robert@raszuk.net> Wed, 28 December 2022 19:51 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B056C14CF00 for <idr@ietfa.amsl.com>; Wed, 28 Dec 2022 11:51:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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=raszuk.net
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 B1Xub97AYbv7 for <idr@ietfa.amsl.com>; Wed, 28 Dec 2022 11:51:08 -0800 (PST)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 96411C14CEE1 for <idr@ietf.org>; Wed, 28 Dec 2022 11:51:08 -0800 (PST)
Received: by mail-wm1-x329.google.com with SMTP id c65-20020a1c3544000000b003cfffd00fc0so14986574wma.1 for <idr@ietf.org>; Wed, 28 Dec 2022 11:51:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aR92jfEpCsPFD2Wfs3tDey6ab6OPeka0Z1Bu1CwY44I=; b=LtTN3gqViDr64tAQ4sfynfbHfYgtsKNCta4wGwCv3I2ydk+oGSgx0INDR0ZTa/Wx4P UfdL9TcSO7ZDoz1wMvPUnn2jvFbVjY37LUBWup2loPAGNLk3zXq6eTiI6imuSFlqnXRC Mo/Di72HmkxeqPBQMYX1PQ0vibdq+TurkSM4FruO1IF3h1MtOakmabsUZuQJQIW3ShX8 8haB2l+i9Iqt+6b+WYnLoKQ8FHVESf9HPIeFGcn60MKy0nolkFi/orPLpqE4fZkJV1bs SaAXwTuI9urUWxIGIQ8w19Z32WOCn8kWlSCI/mna2KvVnV+mL9gNF8FN0VNGBYoMrHHO u90w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aR92jfEpCsPFD2Wfs3tDey6ab6OPeka0Z1Bu1CwY44I=; b=4xV5o2DFhiKMiNSu5cvOlaKd8w9kaowLrqnuniI86PjjTDQUVhlk45rOgLbZmj0Y9K wDaMbzJEbOwm3HW3snEBKLBtIDC4X2WuAQB55g+SQFCr/Th1qn8cdt7J17phvWQl/u0m gmqHN6ObffD2ayB9up2tMRXTonuiEwQMI9I7LVoJ4Qpw+Hc9Qf7640uf4kIrYqVLobEH yH5sFLyatrTz6JP3JyDTjI/jizCLs+t6t7u9HdK0/i2nA7I5Uz7ZeV3Tlgv7MoaWAHRw e0dTEigNxRnpGjVIISrRjD9qiG1tOIsnZC4pqG1VOZGuqyfDwBjvnhSD921vjE2WVjaH MfVQ==
X-Gm-Message-State: AFqh2krWQXl1kJD+/xydhXHSL5VPdcYg9Fo19HZAMpcddVpDJcxeUjPI RmMJLAR4q/rfjXx/5rjzDW9xpOcPn7bncV0RmqHziCkET9aCfA==
X-Google-Smtp-Source: AMrXdXv9HZkTQ87gg/sqSE/IUT5tytAQ49SNgWiBrQweAsOxgwdukQUjUv0eDg2VUfOJnJaRVsqKm1K54m4oQabPMuU=
X-Received: by 2002:a05:600c:501f:b0:3d1:de6e:8afb with SMTP id n31-20020a05600c501f00b003d1de6e8afbmr1755771wmr.92.1672257066340; Wed, 28 Dec 2022 11:51:06 -0800 (PST)
MIME-Version: 1.0
References: <BYAPR08MB4872B6B3A9AE7B008463795DB3E99@BYAPR08MB4872.namprd08.prod.outlook.com> <CAOj+MMGkimvyy3kA36Pn=VzbdTB8ZHDeEhzArsFEVE3P8W2Mug@mail.gmail.com> <BL0PR05MB565243B34F92752FA6E8B397D4ED9@BL0PR05MB5652.namprd05.prod.outlook.com> <CAOj+MMEbjJaFc-arh4ujfSEtnpACwvN2uofKafO6oWUx3-O_BA@mail.gmail.com> <BL0PR05MB5652CB8141DF3A1CD9FF1A9BD4F29@BL0PR05MB5652.namprd05.prod.outlook.com> <CAOj+MMFSP2oThW4C9GezQYK-eU_qRSfNVk+RPib8_spmtWmSzQ@mail.gmail.com> <BL0PR05MB5652D4B1E085D764C57B19E5D4F29@BL0PR05MB5652.namprd05.prod.outlook.com>
In-Reply-To: <BL0PR05MB5652D4B1E085D764C57B19E5D4F29@BL0PR05MB5652.namprd05.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 28 Dec 2022 20:50:55 +0100
Message-ID: <CAOj+MMFWVrvtF=f+sx+Y6pMUJQL_5MYKPiXXRRcG0WWM05JAjA@mail.gmail.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
Cc: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000069a89105f0e8b066"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/cdE2CekdEscwEB99-DMmoD2xH8E>
Subject: Re: [Idr] WG adoption of draft-zzhang-idr-tunnel-encapsulation-label-stack-01 - 12/23/2022 to 1/13/2023
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Dec 2022 19:51:13 -0000

Hi Jeffrey,


> RR2>  So let's zoom into your use case #2 - "Traffic Steering to the
> Tunnel Endpoint" You want egress to signal the path from Ingress to itself
> ? But how is this possible if the nature of BGP is p2mp routing information
> distribution and you do not have any idea which node will be the ingress of
> the traffic ?
>
>
>
> Zzh3> What if the label stack only specifies the common part from those
> ingress PEs?
>

What is "the common part" of the transport tunnel in a label stack when
such an encap starts on 100 different ingress PEs ?


> At best you could signal constraints and let ingress compute paths meeting
> those constraints, but not MPLS label stack. In fact outside of SR-MPLS and
> domain wide labels which is already covered in a bunch of other documents
> egress can not even create such label stack as it has no information about
> labels signalled to each ingress.
>
>
>
> Zzh3> Why can’t this be used for SR-MPLS where a controller to signal
> state to individual ingress PEs?
>


Now you are introducing "controller" to this picture as a consumer of
encoded label stacks in the proposed sub-TLVs.

So such controller(s) will get Tunnel Encapsulation Attribute along with
service routes and based on contained Tunnel Encapsulation Attributes
sub-TLVs take the label stacks, process this and signal to ingress PEs
"optimal" SR-MPLS paths for each ingress PE ?

Honestly a real example illustrating this "common part" known to egress and
encoded label stack would be very helpful. IMHO if such use case is real it
is very much topology dependent.

But I must admit one point here ... if you are trying to use such a
mechanism instead of using BGP-LS from egress PEs to controllers you have
my full support :)  But if so I would recommend to take a broader view and
instead of stuffing such partial information into Tunnel Encapsulation
Attribute define a completely new attribute and carry with service routes
to controller(s).

Many thx,
Robert