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> Tue, 03 January 2023 15:28 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 DDB2EC1522BC for <idr@ietfa.amsl.com>; Tue, 3 Jan 2023 07:28:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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_BLOCKED=0.001, 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 fNw14flz06b9 for <idr@ietfa.amsl.com>; Tue, 3 Jan 2023 07:28:29 -0800 (PST)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 35A7FC1522B1 for <idr@ietf.org>; Tue, 3 Jan 2023 07:28:28 -0800 (PST)
Received: by mail-wr1-x429.google.com with SMTP id d17so10080010wrs.2 for <idr@ietf.org>; Tue, 03 Jan 2023 07:28:28 -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=FsgpT2bnEkFjub31IvFTGkAFvuiv5eqehmTNsWKWTMQ=; b=XahkHYHut3c2QWC5DicWXB1VrFcfhoRPmsfYDQARN4vI3lzmKPVP0SNy5Nbo3nPOsy DzBk2LHHMPsMj21gsKMM4SgP9YjgipsaMBNsC93dT0BZX3o2NMjEZQA1I50QRrZ5Ht33 wYD+Y0rxk/o19Is8nK0zMhzb79Ug83NbOWQ+cnJc+6KWuzCAhC20KYkaA+nCJQf1XPBu 4gtkntBh5j0jIEJ3Qb0DeOX1MehRSDSElsLEl+2Z0bPn+Gi8hGOekQZ2AaPnAiCnQzJh ySdn+XwSn8SkWCA9nYoooqUzLHEFCYePt45nEjCsnQ1y1+ERva1RMV/FOujG18n9022+ F0GQ==
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=FsgpT2bnEkFjub31IvFTGkAFvuiv5eqehmTNsWKWTMQ=; b=lPLmgDQBVLY6FDa7wEC9lwmcQ+bNO9Z3/N1p5hL1HFxY1X2YXlwRft0TNZRtM0fz6o dN8QyCkVzTsGq2qVhDCwZYkaoRgU8/U6+LXiBAbeM6gm/i1KZmCnZh/0rOuYrbnRgXJH xAb7d+JfXaVBAW3ADK2IOsa7VxEI3E3FpBPfBbyb4F2p8sRrEH5e9pe/kwD34DMhJaBW xkvKl3Je9+xP1GW8tdKia2ILMFTaVd1LhPc3P9KbSRlW35pv01XWMNO9o/uwxNU5eGqS YZ/EuOcBTb8/SMoVkLHq/FNlqSHQess02B8wCqbT1qn+UZd1a+n4fbC85CkRUEuPw/aS aKvA==
X-Gm-Message-State: AFqh2kqH+p+9yJh658Q5SxZqV6hXOiokU9C2eISyFLEQO1EjYsIGlQt9 IJ86TUhztr36GdDHhL9ffpO6xd55bhPwzWKbi0dflcVonNFPsI6G
X-Google-Smtp-Source: AMrXdXsTHmV4o1Xh/Fi3kt2EP/kEZDdyEP1cKM+/LRxRihC1wGkkZlAxb0wyOGTXo0hW2XPEBP52KkCUrBpy7qkqbfE=
X-Received: by 2002:adf:f2c7:0:b0:283:797d:fb21 with SMTP id d7-20020adff2c7000000b00283797dfb21mr1215426wrp.438.1672759706957; Tue, 03 Jan 2023 07:28:26 -0800 (PST)
MIME-Version: 1.0
References: <BYAPR08MB4872B6B3A9AE7B008463795DB3E99@BYAPR08MB4872.namprd08.prod.outlook.com> <CABNhwV22EvjvWxkVb+geFOfLzej-c_NNSC6zJtRqj8SmG=FyLw@mail.gmail.com> <BL0PR05MB5652D74BD9EEEB3F934A86EED4F09@BL0PR05MB5652.namprd05.prod.outlook.com> <CABNhwV26XLSWnzu_BiGLjVDTSgdLvp6YL1uNpbOYKbd_LPFYbQ@mail.gmail.com> <CABNhwV2m5ux3dUGrORnXHDfiRyje-sdyidLXrn6+8N-WUABnoQ@mail.gmail.com> <BL0PR05MB5652C87F33851A2951B00FBCD4F79@BL0PR05MB5652.namprd05.prod.outlook.com> <CAOj+MMHSyUdYrrNgQLSfW_5H+momkodE2d_fiLArKM6VzaKBxA@mail.gmail.com> <BL0PR05MB5652454D272775CBAF1A2055D4F79@BL0PR05MB5652.namprd05.prod.outlook.com> <CAOj+MMGpqOqeixWpkkwQCQx6Ma5r0CE5UygtjD_shaKauCWrEw@mail.gmail.com> <BL0PR05MB5652B418922A8A101D3E2C52D4F49@BL0PR05MB5652.namprd05.prod.outlook.com> <CAOj+MMFuyaMHYzcAyk5w1gxLo1CLE-jG7E1Fd6rbjqHu8x3DjQ@mail.gmail.com> <BL0PR05MB56523302EE2028B194522ED9D4F49@BL0PR05MB5652.namprd05.prod.outlook.com> <CAOj+MMGNkCjc6Os9XTTTrJzQYFNpOKVvYaEAmSBmyab670vSFg@mail.gmail.com> <BL0PR05MB56525511F5A97092F3C3402DD4F49@BL0PR05MB5652.namprd05.prod.outlook.com>
In-Reply-To: <BL0PR05MB56525511F5A97092F3C3402DD4F49@BL0PR05MB5652.namprd05.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 03 Jan 2023 16:28:15 +0100
Message-ID: <CAOj+MMHQsorwssuNRN2joeXZscoc2CrFyHVbPqHrkpA1C-Q72w@mail.gmail.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
Cc: "idr@ietf.org" <idr@ietf.org>, Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary="00000000000020ced405f15db86f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/1d4VJ0GdWtfixhXaBsQZ2ugvYUE>
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: Tue, 03 Jan 2023 15:28:33 -0000

> it is clear that the service routes are **not** using any SR policy.

This is going in circle ...

We have already established that SR Policy is an explicit path which you
are proposing to attach to TEA attribute without use of SAFI 73 from
controllers.

Now you are also presumably reusing IGP extentions to ISIS and OSFP to
signal domain wide labels .. no ?

Yet you are keep claiming this is not SR ...

I rest my case here.

Cheers,
R.

On Tue, Jan 3, 2023 at 4:18 PM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
wrote:

> SAFI 73 is for setting up a policy (like a tunnel) on the ingress. That
> policy may be used for **many** purposes; all kinds of traffic can be
> steered into that SR policy – even for traffic beyond the tunnel endpoint.
>
>
>
> With **existing mechanism**, traffic for some service routes can be
> steered into an MPLS tunnel by using a TEA attached to the service routes.
> That does NOT involve SR policy at all.
>
>
>
> Now we’re just adding one enhancement to the above, by encoding a label
> stack for steering the traffic along the tunnel.
>
>
>
> There is **no** collision, whether SR policy is used in the same network
> or not. If you want some service routes to use a particular SR policy,
> you’ll somehow have to specify which SR policy to use. When you use TEA
> with an MPLS tunnel in it (with or without the tunnel label stack proposed
> in this draft) for some service routes, it is clear that the service routes
> are **not** using any SR policy.
>
>
>
> Jeffrey
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk <robert@raszuk.net>
> *Sent:* Tuesday, January 3, 2023 9:48 AM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* idr@ietf.org; Susan Hares <shares@ndzh.com>
> *Subject:* Re: [Idr] WG adoption of
> draft-zzhang-idr-tunnel-encapsulation-label-stack-01 - 12/23/2022 to
> 1/13/2023
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> > Why do we need/want to exclude traffic steering to tunnel endpoint from
> the “MPLS tunnel in a TEA” use case?
>
>
>
> Because that use case is already covered in SAFI 73.
>
>
>
> You want to introduce parallel signalling and deal with cases of
> collisions without clear definition if TEA in service routes itself should
> be less or more important then SR Policy of SAFI 73 with TEA .
>
>
>
> Thx,
>
> R.
>
>
>
> On Tue, Jan 3, 2023 at 3:39 PM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> wrote:
>
> Hi Robert,
>
>
>
> Your argument was “TEA has been standardized to signal parameters of the
> tunnel egress point to all ingress nodes. No more no less”
>
>
>
> I pointed out “draft-ietf-idr-segment-routing-te-policy is directly
> against that” – meaning, TEA does NOT have to be restricted to what is
> specified in RFC9012. Any protocol mechanisms can be enhanced and extended.
>
>
>
> Why does it matter that draft-ietf-idr-segment-routing-te-policy is about
> a new SAFI?
>
>
>
> Why do we need/want to exclude traffic steering to tunnel endpoint from
> the “MPLS tunnel in a TEA” use case?
>
>
>
> Jeffrey
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk <robert@raszuk.net>
> *Sent:* Tuesday, January 3, 2023 9:28 AM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* idr@ietf.org; Susan Hares <shares@ndzh.com>
> *Subject:* Re: [Idr] WG adoption of
> draft-zzhang-idr-tunnel-encapsulation-label-stack-01 - 12/23/2022 to
> 1/13/2023
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
>
>
> On Tue, Jan 3, 2023 at 3:19 PM Jeffrey (Zhaohui) Zhang <zzhang=
> 40juniper.net@dmarc.ietf.org> wrote:
>
> Hi Robert,
>
>
>
>    - TEA has been standardized to signal parameters of the tunnel
>    egress point to all ingress nodes. No more no less.
>
>
>
> The draft-ietf-idr-segment-routing-te-policy that you pointed to is
> directly against the above statement.
>
>
>
> But this is only within context of new SAFI 73 ... note:
>
>
>
> "The use of SR Policy Tunnel-type is applicable only for the AFI/SAFI
> pairs of (1/73, 2/73)."
>
>
>
> You are proposing to use it in any SAFI that is a significant difference.
>
>
>
>
>
>
>
>
>
>