Re: [spring] Understanding the replication draft

Rishabh Parekh <rishabhp@gmail.com> Wed, 01 July 2020 22:55 UTC

Return-Path: <rishabhp@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 810C13A0F1C for <spring@ietfa.amsl.com>; Wed, 1 Jul 2020 15:55:43 -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, FREEMAIL_FROM=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 h7RI2U4H_Hjd for <spring@ietfa.amsl.com>; Wed, 1 Jul 2020 15:55:42 -0700 (PDT)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 C9A8A3A0F1A for <spring@ietf.org>; Wed, 1 Jul 2020 15:55:41 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id l2so23859308wmf.0 for <spring@ietf.org>; Wed, 01 Jul 2020 15:55:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=M09ruuL0xrqg8oAtqQmRzn/ik9h1oRWDF/vl0MiA1B0=; b=plGi/qGv5sPqSn4v7hrE+O9vyojryTh1S/EBT7FM4/gpsxBzT7B7JdEf87sG/CYMJZ Jqg8zxau+KWtT9Xp1UpiOf8zyVJHv+iWmZfhafv4lugbH8KixMNyRohC5KP8LGVGSEwX 4x9wQv8c1tA/blfMbCmxw4VRh/dYAvBZzbBBM9bo1dStV59VpgrmHZJ6hYi8CnYjLSQU YGCIohIJd6PsUB9miGC2RkAsjP3lHHenMU33OQ1yPxHmfuGXNoMLzPLg2qVHyGVBBmyF GcyrJ3TZMjFnQljjStAkHmZK35ChUX2XbBTXp0j8+1VdpsnkD8KKdOYafpF6a50sObMH 86gA==
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:content-transfer-encoding; bh=M09ruuL0xrqg8oAtqQmRzn/ik9h1oRWDF/vl0MiA1B0=; b=KsjHg450SxT12eBPoBsXx7//N+Ohu6eVzI6q1eFGsgO0v0xNRBxtt0KxXUWm9vFw4b EcwUhdp2a7QuEkhmCCVp0wmhSTz0YIOq+y7KZk/NV/8rXHOGUZu252wELa7i3+zR6z2+ QlYhN2UANALDc+BKCOAyFVsdHKV3IDz14xwSwFms0DaZhVntp60LKsfDLkae+Dx2nHgY DXTJZwunVVqPMQfBAGLzCVDUjJwMln99oWlmvjWRchNGJRQQrxaDPq7nyIIVwESR0igD NGAearJysjo0uLGYdLye6u5qlveItgKyvx7ftDSjPHF3FHGbLndX/ZCWPrDg6Db9yhg2 5NuA==
X-Gm-Message-State: AOAM531vK7sqU7XECJqAxZnxhdSoMACEtua6Se4/4VnKwgorU6PQvmaw xNYPbME1Ys7UseY8fC1HZkzV9LozuPZpnWFe3QlzxZ7ZzMx6MA==
X-Google-Smtp-Source: ABdhPJzaSzY1Jia4RZW5LkpkHSPXmFwjZuaa3BJaj+EDLpfVQGhCuWwkPPh7kAeq/rVFTMPgPV08t7vCTlH+/HyIQ9E=
X-Received: by 2002:a1c:4d11:: with SMTP id o17mr28054750wmh.134.1593644140242; Wed, 01 Jul 2020 15:55:40 -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> <CAOj+MMFYcvAUP_Nh_K=6gBMVAQst_+mc0rADn7_j-yO4kyVC2Q@mail.gmail.com>
In-Reply-To: <CAOj+MMFYcvAUP_Nh_K=6gBMVAQst_+mc0rADn7_j-yO4kyVC2Q@mail.gmail.com>
From: Rishabh Parekh <rishabhp@gmail.com>
Date: Wed, 01 Jul 2020 15:55:29 -0700
Message-ID: <CABjMoXb2=dO+NgGLSCO8jaOvzroo5gTsBejNPvjPqYHvZKJcDA@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>, Joel Halpern Direct <jmh.direct@joelhalpern.com>, "spring@ietf.org" <spring@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/B08R2QqrBAXdrZPNkFr0QTskSHM>
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 22:55:44 -0000

Sasha,
I agree with Robert. Building MDTs for services is covered in a
separate draft in BESS:
https://datatracker.ietf.org/doc/draft-parekh-bess-mvpn-evpn-sr-p2mp/

-Rishabh

On Wed, Jul 1, 2020 at 2:56 PM Robert Raszuk <robert@raszuk.net> wrote:
>
> 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
>>
>> ________________________________
>> 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.
>> ________________________________