Re: [spring] Understanding the replication draft

Rishabh Parekh <rishabhp@gmail.com> Wed, 01 July 2020 16:07 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 C24643A110E for <spring@ietfa.amsl.com>; Wed, 1 Jul 2020 09:07:02 -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 4k3jtY52s4PO for <spring@ietfa.amsl.com>; Wed, 1 Jul 2020 09:07:01 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 21E723A0AA0 for <spring@ietf.org>; Wed, 1 Jul 2020 09:07:01 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id f18so23844622wml.3 for <spring@ietf.org>; Wed, 01 Jul 2020 09:07:00 -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; bh=Z6Pa8A65o1PdCcuTp81A6iVmuDG1XX1TztRnZ2B0fAI=; b=mxJaLxsUgSw/XFcCLtLvRX9oBnX1TYaxcdU/bZjH2ZsNabktSqMVYiAzMBONGRTx4s CxqlWcnpA2bFnRplortJTu4oZRhRBuhct3UWohkFr1NFSI4oGcFZqGU9PmDG6BSoMkCW q0d/bqOut9tNtOeQLixUC3QjSbiLFH481kW/N6sBsaxpTe1zQi9RcDy0ln48MlyvVRtF /nxSkQIAcH0sLhxTja8kbQa2Oe+vTuWJv0OhJefSmhhBD30i0+iqarEXOsNu/OtnIrsl qYCb+UyM9ebSINTiRr2PXX+gkFT3bp4DygE9G+l++RCdgSvUNDtUpAUeB2fB9qAGSX2D 9Nvw==
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=Z6Pa8A65o1PdCcuTp81A6iVmuDG1XX1TztRnZ2B0fAI=; b=C1Fu7A3XtM0e76eDnCCd0WPKYKX9vHg8CxLoeBJ90dBSV7JvoPpntph6bL5XexD+b0 Jf0ZRX38cZvBO3hyPZ3cJ3YZLLc8kJDJs+wfktCw6eePmaaf4xRjDzveaLNoAHbqMTB1 sQxuVKgZt6vq9a3lVoZRknjiACNeFCz6r//pu/XrHxJeAakbCy/Zhbw/gLbHQU65jttj 7idEK2/AwactcPLbuIZq8TIey8Udd1F9Pw0hm8h1DCENLqLxrMTPv75SoGG9f6l26qqe ehAvCgyEYLpq5UntiEEn9PoUB8sxTuMJNeE3ra8UtELoTjK8T2z3leFSW82xfQvwWrpa rdqQ==
X-Gm-Message-State: AOAM5311PK5Gvetj17zFYFVsxRwueJ0GQ5eDnG7aNGI26Dz46hg8rNaE Chykp22X4Oha6Oax1b+OFPpRJiAMUXmrlRgIGE0y6g==
X-Google-Smtp-Source: ABdhPJygAa4sUyJYyaxzgVnCd8zkCl8watr6NkOIGi3ApUTywxyLaeK2ea2CIlr3sDp4wkJOxicbU2fNMCPloL/Rcm8=
X-Received: by 2002:a1c:dd09:: with SMTP id u9mr26254913wmg.70.1593619619384; Wed, 01 Jul 2020 09:06:59 -0700 (PDT)
MIME-Version: 1.0
References: <94415742-fc4e-1774-bf96-01eac3672bfb@joelhalpern.com>
In-Reply-To: <94415742-fc4e-1774-bf96-01eac3672bfb@joelhalpern.com>
From: Rishabh Parekh <rishabhp@gmail.com>
Date: Wed, 01 Jul 2020 09:06:46 -0700
Message-ID: <CABjMoXYCsXb-iP55PsNWHBG187Lm7-2PXfgD3qRn_aD6ppDuMw@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: "spring@ietf.org" <spring@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/XSd7PAUIZotMrPHdo_Vyi8i7fU0>
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 16:07:03 -0000

Joel,
Your request was not "lost", but it fell between the cracks :)

Anyway, responses inline.

On Mon, Jun 29, 2020 at 3:17 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
>
> I asked the authors a version of this question, but apparently my
> request got lost.
>
> For now, this is speaking as an individual.  And I sincerely hope that I
> am merely missing something obvious.
>
> I can not figure out from the current draft how the replication segment
> works in a SID (or label) stack.
> Is there an unstated requirement that the segment must be the last one
> in the stack?
> If not, how is a global SID after teh replication SID understood?

[RP] Replication SID does not need to be the last segment in the
stack. Although Section 2 of draft does not state this explicitly, If
there are other non-replication SIDs following the Replication SID,
the NEXT operation at a downstream node of the segment should process
those SIDs as normal.

> Or is a replication SID implicitly also a binding SID, replacing the
> rest of the stack no matter where it is in the stack?
>     In which case it is implicitly effectively last?

[RP] At a root or a Replication SID, when the active segment is a
Replication SID, it does act like a Binding SID in that it steers the
packet into the Replication segment towards downstream nodes. Note
that additional SIDs might be added on top of the Replication SID to
steer the packet from Root to a given downstream node. The Replication
SID will be at bottom of any such SIDs added to steer the packet, but
again it does not have to be the bottom most SID in the stack.

> Given taht a replication segment is qualified to a node, what happens if
> there is more than one in a stack?  Is it ignored when it hits a node it
> does not apply to?

[RP] On a given node, if an active SID in the stack is a Replication
SID that the node does not understand, it cannot process the packet.
This would be similar to any other kind of SID for which a node does
not have any state.
>
> Do I believe this can be made to work?  Yes.
> But I can not understand how the WG could adopt the work with its
> current lack of clarity.
> And this appears to me to be fundamental enough stuff that it can't be
> left to documents in other WGs.  It seems central to the definition and
> processing of replication SIDs.
>

[RP] Section 2 does specify behavior associated with Replication SID
at different nodes in terms of PUSH, CONTINUE or NEXT operations. If
it is not clear, we can enhance the text.
>
> Yours,
> Joel - speaking as a participant
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring