Re: [spring] Understanding the replication draft

Rishabh Parekh <> Wed, 01 July 2020 19:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8947D3A0C9D for <>; Wed, 1 Jul 2020 12:40:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZYFL0CV5446p for <>; Wed, 1 Jul 2020 12:40:02 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E76DD3A07C5 for <>; Wed, 1 Jul 2020 12:40:01 -0700 (PDT)
Received: by with SMTP id j18so23796329wmi.3 for <>; Wed, 01 Jul 2020 12:40:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RJXwXgZhRXob+vK0Jvlr4OGxVtgFcFNeY0SUMuwc7Xw=; b=gG8IBJvONbB505LaJdq89eGvWiVu0ymyWc+TiFsnriMvI9yqcM5KM7bUX+2/VYZ+sn HRxfG+5E3/8Ge8ua+lOCqzxgWm159kVMC7JZxqoQIO5mc8Zw1LyvMJ9I2hDCSLAiA14a haTDQrz/0TXlOwJUHpe+eJviMk2yJ6b8jUq+oVXTvT7WI8ChCvYXjUIsmMGSXLIT/bpY dSaZURFRJwTR9+EG6nceC77ACgndT4zVhGlaCXFN4caV6SYVQOv8gE/U6CUlFgWBHomI hkNDKNrDQyf2CMwQDT2yyUDnJWI3IqgbqthDdWz0l0XBJ7z07HDNLmHmSgU7MKmEcF/y pW7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RJXwXgZhRXob+vK0Jvlr4OGxVtgFcFNeY0SUMuwc7Xw=; b=gd2ta0piDF7djmTBWKZxp4z3cAANiwsrTfdEy4CK4WNyCK+k0TTxqxXj8aIuXfNKpD eDRgY+b3u97mcNhal9kI0Jn+KQcwenLI2rjl3Tw69Kfd2M1CDsajcZvCr+e6vY+QwQ5g fNrAoEcIN2ASLVOukKBLo4wcBevs/n3loDVWa7ic5Ib1uUNl+609jzsPgJaXJhJWmqx1 PTplGpfhxdKnmM4/T/VhgURbaPIRZqqpSKEJ58SpKb8GNimSr3yqdPX7gGJg1cblqJ8n t/nWHGPLXTGkoDh67Pue1gagGZ+Eb1l7ZGyHD0xa+aKzSi/VHyBTdmz2mxk+DuBwUrq6 M11Q==
X-Gm-Message-State: AOAM531wMtnM0UcWYWJ8RwWFH+QoP2uVi/eAbmU75PiZTKYGFT3yC9NH ADLM52UyQG+byVzsQrCwg0KNRNYQZD5K5PmuSah4kODo4e4=
X-Google-Smtp-Source: ABdhPJz95Y/OgqJMAPocPHzTKOSSkjtEoJ+OTOzryNcqs9eUT+g+Bqc7z0dwV+THqF9TYwuC7dbgVXElY/9Zyexntxw=
X-Received: by 2002:a1c:dd09:: with SMTP id u9mr27000309wmg.70.1593632400285; Wed, 01 Jul 2020 12:40:00 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Rishabh Parekh <>
Date: Wed, 1 Jul 2020 12:39:47 -0700
Message-ID: <>
To: Robert Raszuk <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [spring] Understanding the replication draft
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Jul 2020 19:40:04 -0000


>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.


On Wed, Jul 1, 2020 at 12:27 PM Robert Raszuk <> 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.