Re: [spring] Understanding the replication draft

Rishabh Parekh <rishabhp@gmail.com> Wed, 01 July 2020 18:51 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 3C20D3A0BD3 for <spring@ietfa.amsl.com>; Wed, 1 Jul 2020 11:51:48 -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 stsVRrgDPhZB for <spring@ietfa.amsl.com>; Wed, 1 Jul 2020 11:51:46 -0700 (PDT)
Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (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 08BD53A0BCC for <spring@ietf.org>; Wed, 1 Jul 2020 11:51:46 -0700 (PDT)
Received: by mail-wm1-x344.google.com with SMTP id w3so12035131wmi.4 for <spring@ietf.org>; Wed, 01 Jul 2020 11:51:45 -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=fiZaBE+JW+TRS4RZO16t0lWHADs4QaQbUceKKCca6hE=; b=tb+jgpjo1VKW/Qyv6fpYzyxpWLZtfHRj0V9iAjIvv9I3KsE0uKMYllF9ttFHbtHFGM r9quNoGcI47C4o7L49/ZUeJyPZqIqpD1pWPfi/HadE5KbBwqvYvJkXAy8kOFfTjrv827 aC9qDQKP37ficLmSSCzZP5IvLIq5niI2cyO8AYdq8lnbrVWkGC4JVQPD6frQKLJSBR9T UpVSPsy0GpQlgL15TpKBPpVjnyT7SbPp2HsMthOtEwF87drnIO/H+YWee3+d4rFo9SIF QPAhGTy+0Q9A2F1S48FOMLOf+QpkfbCu/iQJPRHMI9Ry6WnKuSr88bVsG6FG8qJbOi3v SEhg==
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=fiZaBE+JW+TRS4RZO16t0lWHADs4QaQbUceKKCca6hE=; b=jcP82txiYw3V0EjRVEb+wuPEIPJxtrA26RRXGS6ma0XVmp9Gj4Hg7LjoaO29NWfdRq c+oSgHpR5tPDSFZfcs9ah9luhSJoKwfDDFpGpdP60DfAxvM3d1dgqJ8f6LDT7e78UjGK MawpIMapQUkAF2cSrJNc3J7wVJkTU43wvsmPPiCZR/Lmh4V9baN5HoXMFUeKpx1aaTms dUbE5mFcErIGS2SfJ4zT6Ffm61FLVANg/eUEUz1qcaPFsXp+/K+s9Y75MmtnVLoAZo2J pFtj0EJdyRERW3XIzcdbrgk/3loqgvp5WVW9RPYDWRG+oT3rJWKVi/NHJlM6co+kmeQM ukhw==
X-Gm-Message-State: AOAM532dpsdB8mN0Otx1Esh7X9YeTCT6xtPgGZp1roA6WKrW8dzlMeV8 x3EwkFn8lvIt9GFVKySdd/HP/DIoe3SSpzuSDZlp9w==
X-Google-Smtp-Source: ABdhPJwcVkVNWccBZMNTiOzaTf6rJDtwmWGK+eXmQ/btyPJqU3eEDXSDaaJbqJbsG/LqgYroJv9iooIwRZrheSBsNoQ=
X-Received: by 2002:a7b:c952:: with SMTP id i18mr29758934wml.65.1593629504433; Wed, 01 Jul 2020 11:51:44 -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>
In-Reply-To: <b3aaaa47-af61-6fc0-1086-bfd59efea061@joelhalpern.com>
From: Rishabh Parekh <rishabhp@gmail.com>
Date: Wed, 1 Jul 2020 11:51:31 -0700
Message-ID: <CABjMoXY5S1Bx3rQM-0eyJfzh9iOgAZoGshs1wFqebnkVZ++G0w@mail.gmail.com>
To: Joel Halpern Direct <jmh.direct@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/lSmI5NTOTSNg1vDscW1E3ZJajj8>
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 18:51:48 -0000

Joel,
I now understand the question better with the example you provided.

The draft states that replication SID must be still part of the stack
so that downstream node can process it appropriately. In your example,
if replication SID is the same at all nodes, R-SID-1 will be in the
label stack and will be the active SID when the packet reaches a given
downstream node. In the use cases we describe, either the replication
SID is the last SID in the stack and performs either a NEXT operation
to process the payload, or a CONTINUE operation to stitch the packet
to another replication segment as described in PIM WG draft, or both
NEXT and CONTINUE. But the draft does not preclude NEXT operation of
R-SID1 with the label stack in your example. 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.

Although the use cases are not intended to cover the scenario you
describe, maybe we can document this "explosion" in security
considerations of the draft.

-Rishabh


On Wed, Jul 1, 2020 at 9:24 AM Joel Halpern Direct
<jmh.direct@joelhalpern.com> wrote:
>
> I am not sure I understand the answer.  I do see that the local
> processing is described in the draft.  But that is not what I am asking.
>
> I am going to try to simplify the conventions to ask the question.  I
> will list SIDs in the order they will be visited.  And mark G-SID-X for
> a global SID, and R-SID-X for a replication SID.
>
> Suppose the stack looks like
>
> G-SID-1
> R-SID-1
> G-SID-2
> G-SID-3
> R-SID-2
> G-SID-4
>
> So the packet gets delivered to the node identified by G-SID-1.  Great.
> That node sees an R-SID which it understands.  So presumably it
> replicates the packet, and sends the packet (possibly with some
> prepended labels, presumably different prepended labels for different
> destination, controlled by policy.  No problem with that part.)
>
> Now each of the packets geet to the end of the prepended labels, and
> each copy sees G-SID-2.  At which point all of these various nodes that
> have received copies of the packet all send it to the node identified by
> G-SID-2.  Huh?  We just bombarded a node with useless and potentially
> harmful copies of the packet.  then all those copies go to G-SID-3,
> which then processes R-SID-2, and replicates each and every copy to some
> set of destinations.  Which then eventually bombard the node identified
> by G-SID-4.
>
> If the document said that the replication SID when it appears in the
> stack must be the last SID in the stack, and was either terminal for SID
> processing or was a binding SID, the above problem would be avoided.
> But the draft does not say that.  Nor does your reply.
>
> Is there some other way this explosion is avoided?  This seems to need
> to be described in the SPRING draft in order for any of us to understand
> if the approach is what we want as a starting point.  just the idea of
> replication segments is not, in my personal view, enough clarity or
> value to be adopted as a working group document.
>
> Yours,
> Joel
>
> On 7/1/2020 12:06 PM, Rishabh Parekh wrote:
> > 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
> >
> > _______________________________________________
> > spring mailing list
> > spring@ietf.org
> > https://www.ietf.org/mailman/listinfo/spring
> >