Re: [spring] Understanding the replication draft

Jeff Tantsura <jefftant.ietf@gmail.com> Thu, 02 July 2020 00:50 UTC

Return-Path: <jefftant.ietf@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260703A1261 for <spring@ietfa.amsl.com>; Wed, 1 Jul 2020 17:50:10 -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 KOFkQDHqhWie for <spring@ietfa.amsl.com>; Wed, 1 Jul 2020 17:50:08 -0700 (PDT)
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 77AA93A1295 for <spring@ietf.org>; Wed, 1 Jul 2020 17:50:08 -0700 (PDT)
Received: by mail-pg1-x52c.google.com with SMTP id d194so9211220pga.13 for <spring@ietf.org>; Wed, 01 Jul 2020 17:50:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=Q1ioKH0Zm+/87HDaL/YsFvp4/OgkZ0EslKEKIol/ndQ=; b=jpts6ac12/fIIwJot5/2rDKrc3fM6UBXE3MS+KbJvDdmDaEGGyQX+nLGqXj5hHZYWF Qpe26fUEw8GgegTsuCjj6/2xdWKMmfr2d5NS9cBXS2PoOmrnCaVaCr0cK4jzDQ2QdhEj qBUuBgiBGJEXl5kA3faWk//rYSXbw5bc1yadMdzHd92Swz371J555ijvgVxVL5Tw5jzE USMG+btaYToRrSgkaNiQH1n98bnk1B4WnnKynQo11EFgg/V0qqsb7+hMjrz3stKGspLy KtJWu2tKTwRu59Yt3lqnPfIZ1kHwCZpEpTlVWWlVBB614wHQwdJYt0a0FakmBJXDA2Bn IQIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=Q1ioKH0Zm+/87HDaL/YsFvp4/OgkZ0EslKEKIol/ndQ=; b=Mrpo9LgxrUTkaZM7BUz8ToGOflqMM9Q6LU0n/WNix2+oJkFZqlusnjU5GU+94+Wlrt sDmji6sQ4f602eXv0JUBhxnHiTH0dQ7ljx8JdorXZt+UtOAaGvgechQJK2RZczrlaeis tAXzu5gnAQVdVpr4U8nftRa32Y20+PcPLAUP6tlunuD3l7jCaa8+A2y4E8IlQrFzbzgF 1YTSr3m8tStI1aYEXWLxlt9sgZLLn6S+dy4hZAAOWF1vUp2Bdu8fhK/EiMSPpzJngeRB 63TwBf9VKfjmB5DwC4gobjn9qk0gwtrVXjPFYTCp9rg5R/9ZrWWn5XNJogGr8iNEDeg6 S2Rw==
X-Gm-Message-State: AOAM5337AjxIibvXAnOz6KS2FQNiJOMghNFtNoCTf72rcOZbmIcqJDAn yBnFlgoJeba/t6MlivOcACg=
X-Google-Smtp-Source: ABdhPJzToLKS1BpXJibozS2dSX5foedTpQbjGqgiE0oNEfv+b1ItoPQc4StWeigjhD2k2P4lmq9uDQ==
X-Received: by 2002:a63:5461:: with SMTP id e33mr12577501pgm.321.1593651007863; Wed, 01 Jul 2020 17:50:07 -0700 (PDT)
Received: from [192.168.1.3] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id mu17sm6646674pjb.53.2020.07.01.17.50.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Jul 2020 17:50:06 -0700 (PDT)
Date: Wed, 1 Jul 2020 17:49:48 -0700
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: Robert Raszuk <robert@raszuk.net>, Rishabh Parekh <rishabhp@gmail.com>
Cc: "=?utf-8?Q?spring=40ietf.org?=" <spring@ietf.org>
Message-ID: <baaf7a09-f20d-4863-b7f7-36118e11cc4b@Spark>
In-Reply-To: <CABjMoXbka+L3STNd4EPOfT5KA35ECZQt3jk=g0m=GU9VUj9csA@mail.gmail.com>
References: <94415742-fc4e-1774-bf96-01eac3672bfb@joelhalpern.com> <CABjMoXYCsXb-iP55PsNWHBG187Lm7-2PXfgD3qRn_aD6ppDuMw@mail.gmail.com> <b3aaaa47-af61-6fc0-1086-bfd59efea061@joelhalpern.com> <CABjMoXY5S1Bx3rQM-0eyJfzh9iOgAZoGshs1wFqebnkVZ++G0w@mail.gmail.com> <CAOj+MMFsjRCgbY1V5idoKmqKR7W5gwM7ui7cp6W12GQm0XEHyQ@mail.gmail.com> <CABjMoXbka+L3STNd4EPOfT5KA35ECZQt3jk=g0m=GU9VUj9csA@mail.gmail.com>
X-Readdle-Message-ID: baaf7a09-f20d-4863-b7f7-36118e11cc4b@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5efd2f3d_520eedd1_11d67"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/Cl8RWoLESu6J-E1neen2sg1oXKE>
Subject: Re: [spring] Understanding the replication draft
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jul 2020 00:50:10 -0000

Rishabh,

Transport SID with a service on top can’t be a BoS label, there’s s service label below, since a service is associated with a particular node, there would be at least a N-SID associated with the service node.
It seems like B-SID behavior is the correct one, when R-SID is looked up and popped, it would yield: replication  (as programmed by a controller, since there’s no state) + new label stack associated with the new, post replication/branching path that is imposed on top of existing label stack, so service label ( + optionally more transport labels) are preserved.

Cheers,
Jeff
On Jul 1, 2020, 12:40 PM -0700, Rishabh Parekh <rishabhp@gmail.com>om>, wrote:
> Robert,
>
> > A) Firmly state that replication SID MUST be the last one on the stack
> > B) Instead of real SID after the replication SID provide a binding SID which locally will be mapped to a different SID list imposed to each replicated flow.
>
> We would be fine with A), but we don't want to exclude possibility of
> something like what you describe in B.
>
> -Rishabh
>
> On Wed, Jul 1, 2020 at 12:27 PM Robert Raszuk <robert@raszuk.net> wrote:
> >
> > Hi Rishabh,
> >
> > > Of course, care must be
> > > taken to avoid the "explosion" as you describe it. G-SID-2 has to map
> > > to a unique node; for example, it may be an Anycast-SID that takes
> > > packet to distinct nodes from each of the downstream node, or the
> > > downstream nodes can be border nodes connecting to other segment
> > > routing domains where G-SID-2 resolves to distinct nodes in each
> > > domain.
> >
> > I think you are stretching it too thin.
> >
> > See even if G-SID-2 is anycast SID you have zero assurance that physical nodes packets will land on would be at all diverse.
> >
> > Likewise crossing domains yet providing identical global SID now to be a different node in each such domain to me is not a realistic example.
> >
> > I think we have two options:
> >
> > A) Firmly state that replication SID MUST be the last one on the stack
> >
> > B) Instead of real SID after the replication SID provide a binding SID which locally will be mapped to a different SID list imposed to each replicated flow.
> >
> > What is currently in the draft seems to be very counterintuitive and IMHO will result in operational difficulties.
> >
> > Thx a lot,
> > R.
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring