Re: [spring] Understanding the replication draft

Robert Raszuk <robert@raszuk.net> Wed, 01 July 2020 21:56 UTC

Return-Path: <robert@raszuk.net>
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 A79303A0E1B for <spring@ietfa.amsl.com>; Wed, 1 Jul 2020 14:56:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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=raszuk.net
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 gwqXh4EhAeNI for <spring@ietfa.amsl.com>; Wed, 1 Jul 2020 14:56:55 -0700 (PDT)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 330113A0E1A for <spring@ietf.org>; Wed, 1 Jul 2020 14:56:55 -0700 (PDT)
Received: by mail-ed1-x532.google.com with SMTP id e22so21436986edq.8 for <spring@ietf.org>; Wed, 01 Jul 2020 14:56:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K9XKadjufMepDQg7piGxPMefMMxH4hQify8zi8DZ49g=; b=KKxhi89uG6pFW4UfeOmYyZ5U+WfpNP5ZD/+mJcIN0uFNkms2guNDxSenNaEQyptXKJ cCGZoYvBO13mn4GQTo0HXQcm6/tK9wa6M7f+HBc4H27SE1xP+PTK4pzvUnuXJ5Fuwyr1 RjmC3CHuxto7pIeN0Sev95ljRHadMH/3PUepDLHT8qvobgtKDmi/GYIOU7o+eBIjMPdN y+HCXkkRMD5bi175FJrqRaOTAJsLmKDlab51akuDewZtO3XNXu9syqD3XPTs4ahl6vUf swa50FHH6/hVtFAqj+cZ/X3AQ9XWbkiK8viztSD9VEME7fOjMw0B0OaLQS6+392GkjwD CVSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K9XKadjufMepDQg7piGxPMefMMxH4hQify8zi8DZ49g=; b=DsOuepSN76og1qVYzxPNHV7SY3nXjla9N5YVQIvDkAVFfa2dYMGKCw1xUuIw/uhFao W4Dn+gf2BfXaAsJFi9GArpL8sNl8q0XIXUafPZKfYPK3f+1Xdf8cCLxX/DGIdWHMihsT 2KiUXEqDK14tnRE9zcKzzR3uI/iMOtE0uE6JoMrpxVlqaYtHCqjNxNt2tRNWpD/tlrk6 T42cDsTGjv6cHrrESzgJxkKrjmV+DUpCkPnGQaXyQpjtyjVm87Va9Cq7+7+w3RujCA+z yQyfTIs32XMgpSKVqwlVNbf6Mw0n+I/bi0quoez4JSk67ul+SAQv1/PaCIsVpx8HXud7 0Fmg==
X-Gm-Message-State: AOAM533damEyWpUq4qOzXsAaT3PXRXtbwaX3WFr4r8+4XHH8LtbRdLsF 9GkH5kUVwl8PbjtYrof6kds0Psx52ZivmRljybGlIA==
X-Google-Smtp-Source: ABdhPJzZ5DZTxfmuOBt4aLqiYhpzv2GTUIoBc5pCkxthv03aH4ePBi3wM6F9ASGONKWZQlWLzTEULcWqPSLNXAzhSQ4=
X-Received: by 2002:a50:cd1a:: with SMTP id z26mr32582896edi.120.1593640612266; Wed, 01 Jul 2020 14:56:52 -0700 (PDT)
MIME-Version: 1.0
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> <AM0PR03MB4499F08DA8589EAEA4A048C29D6C0@AM0PR03MB4499.eurprd03.prod.outlook.com>
In-Reply-To: <AM0PR03MB4499F08DA8589EAEA4A048C29D6C0@AM0PR03MB4499.eurprd03.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 1 Jul 2020 23:56:43 +0200
Message-ID: <CAOj+MMFYcvAUP_Nh_K=6gBMVAQst_+mc0rADn7_j-yO4kyVC2Q@mail.gmail.com>
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
Cc: Rishabh Parekh <rishabhp@gmail.com>, Joel Halpern Direct <jmh.direct@joelhalpern.com>, "spring@ietf.org" <spring@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000981eaa05a9685e85"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/trPxszWji6nu8Sau8asK-y7mHuo>
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: Wed, 01 Jul 2020 21:56:58 -0000

Hi Alexander,

Do we really know how to build MDTs as source routed chains ?

If that is the goal here IMHO it deserves a whole separate document ....

In general when we replicate we take a packet and copy it to interfaces A,
B ... Z. That's a local rule I presume executed for flows containing
R-SID-n. But we just can't send the packet with identical list of SIDs from
that point on any outgoing interface as results will be rather poor.

We need custom list for each outbound interface and that is something I am
not seeing in the draft. Till this is explained I would keep thinking that
building MDTs should be more of as control plane task.

Thx.
R.

On Wed, Jul 1, 2020 at 9:42 PM Alexander Vainshtein <
Alexander.Vainshtein@rbbn.com> wrote:

> Robert, Rishabh and all,
> I concur with Robert but would like to add that Option A woild effectively
> eliminate the possibility of building MDTs with more than one level using
> Replication Segments.
>
> Which is probably not the intent of the draft.
>
> My 2c.
>
> Get Outlook for Android <https://aka.ms/ghei36>
>
> ------------------------------
> *From:* spring <spring-bounces@ietf.org> on behalf of Robert Raszuk <
> robert@raszuk.net>
> *Sent:* Wednesday, July 1, 2020, 22:27
> *To:* Rishabh Parekh
> *Cc:* Joel Halpern Direct; spring@ietf.org
> *Subject:* Re: [spring] Understanding the replication draft
>
> 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.
>
>
>
> ------------------------------
> Notice: This e-mail together with any attachments may contain information
> of Ribbon Communications Inc. that is confidential and/or proprietary for
> the sole use of the intended recipient. Any review, disclosure, reliance or
> distribution by others or forwarding without express permission is strictly
> prohibited. If you are not the intended recipient, please notify the sender
> immediately and then delete all copies, including any attachments.
> ------------------------------
>