Re: [spring] Understanding the replication draft
Rishabh Parekh <rishabhp@gmail.com> Thu, 02 July 2020 06:35 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 1047B3A0D70 for <spring@ietfa.amsl.com>; Wed, 1 Jul 2020 23:35:00 -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 z9kSZ0HyfxBk for <spring@ietfa.amsl.com>; Wed, 1 Jul 2020 23:34:58 -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 486B03A0CD4 for <spring@ietf.org>; Wed, 1 Jul 2020 23:34:58 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id l17so25410587wmj.0 for <spring@ietf.org>; Wed, 01 Jul 2020 23:34:58 -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=P1ipIjq17Axx34ROnzOe1GkOqnMGKPmQ+ZzdDrelZ3I=; b=KJ5QGlSq0rd6HGTc/k0j6+5upbUzJwWWi8n5fkUYM5SwyiBqJyCJ3bUakZ+yTEIp0N +FawwX00479p2Bmue811ZZ7WlbZEaoC9LDblApLQ9QIzyob9UkURJxnBpcMPMR8+ItI6 OWp0qRmGS6CvXt26JDByCBkBrcmmhwEyd7e9bQxu7wNQfBmxIGYg2rWvQy9K2/gh8gj/ N9sjjTQ6XspVzBsPhdkrDmMm91Kf71IHUl9UJs7wXGuS2oDgAnoBW2DeBIhrXAywB7Pd zCRNbpu7M9+CWmov515Lafq1buLNZWdaE3l4n/zeHyhthLYeoREkVGv/BIsdFe3CVUPi QzFA==
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=P1ipIjq17Axx34ROnzOe1GkOqnMGKPmQ+ZzdDrelZ3I=; b=mRioZ9vaQqF07zOLPazxFV8rUw6dytOfnIEQYG5Lb948C2wtGcgfT4aDDOYhoT1aCJ NZiRRM/N0CAccYebWfXvFaZBPce4dvQaVCZhL4+v1CaNoqiA1OJhotT2XEn26sq53Gqi D++M7cdEFxZefs1aV3R7lksyIa2G4ngXa0UM1QigFEfbrjSnyQXNTngBucGIqXEisxcl AIhcq3Zpjoy/X34/qPCZH/uFoITWlj4N+xWvosZ5fyXPFzo7LSDh2XDU+nLU2/zUtGm1 rr0TKs0SY/zWLXO/WpnmktOO8kNz2Q+HgrH0TgssNz0XaDRYmP211jpUFGYkOZJG9GAy nE8w==
X-Gm-Message-State: AOAM533W8dCvilfLl+KCejwIzcclHYzsJyn8QSzlQQ7GkuOwm+LvN8bp 12tv7xk3BLW01JZA/m18ZCLgns8VNOtKKcU5pZc=
X-Google-Smtp-Source: ABdhPJxWkGMKS9T3OqXJi12yc+DQks+eFEnhP0IHHp6RWV6Yh+CqHRbK/B3IGtadtm/WloN/Gs16Vg7XGqAGNtBx0bo=
X-Received: by 2002:a7b:ca43:: with SMTP id m3mr22986888wml.120.1593671696644; Wed, 01 Jul 2020 23:34:56 -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> <CABjMoXbka+L3STNd4EPOfT5KA35ECZQt3jk=g0m=GU9VUj9csA@mail.gmail.com> <baaf7a09-f20d-4863-b7f7-36118e11cc4b@Spark>
In-Reply-To: <baaf7a09-f20d-4863-b7f7-36118e11cc4b@Spark>
From: Rishabh Parekh <rishabhp@gmail.com>
Date: Wed, 01 Jul 2020 23:34:45 -0700
Message-ID: <CABjMoXZaiED+++2ij6CB_MH6dqGgs=t829XgsYy+6HHC69SDrQ@mail.gmail.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: Robert Raszuk <robert@raszuk.net>, "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/vutE3bmLAhEVeIuiFyWfvVHsy0o>
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: Thu, 02 Jul 2020 06:35:00 -0000
Jeff, Your explanation of distinct Transport SIDs and service labels (which appear at BoS) applies to Point-to-Point services. Same model can be applied when a Point-to-Multipoint service is realized by one end-to-end replication segment; "Downstream Replication SID" as specified in draft is effectively the service label at a specific downstream node of a Replication segment with Transport SIDs imposed on top to take replicated packet to that node. However, when a Point-to-Multipoint service is over replication segments stitched together to form a P2MP tree, as described in PIM WG draft, this model no longer holds since all service egress nodes would have to agree on one common service label. So P2MP services implicitly map the P2MP transport label (Replication SID at BoS in this case) to the P2MP service. Of course, this implies one-to-one association between a P2MP service and a P2MP transport. There are techniques to share one P2MP transport across different P2MP services using either upstream assigned label or a global context from "Domain-wide Common Block" (draft-ietf-bess-mvpn-evpn-aggregation-label). These and other gory details are described in Section 2 of PIM WG draft and to some extent in BESS MVPN-EVPN draft. -Rishabh On Wed, Jul 1, 2020 at 5:50 PM Jeff Tantsura <jefftant.ietf@gmail.com> wrote: > > Rishabh, > > Transport SID with a service on top can’t be a BoS label, there’s s service label below, since a service is associated with a particular node, there would be at least a N-SID associated with the service node. > It seems like B-SID behavior is the correct one, when R-SID is looked up and popped, it would yield: replication (as programmed by a controller, since there’s no state) + new label stack associated with the new, post replication/branching path that is imposed on top of existing label stack, so service label ( + optionally more transport labels) are preserved. > > Cheers, > Jeff > On Jul 1, 2020, 12:40 PM -0700, Rishabh Parekh <rishabhp@gmail.com>, wrote: > > Robert, > > 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. > > -Rishabh > > On Wed, Jul 1, 2020 at 12:27 PM Robert Raszuk <robert@raszuk.net> 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. > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring
- [spring] Understanding the replication draft Joel M. Halpern
- Re: [spring] Understanding the replication draft Rishabh Parekh
- Re: [spring] Understanding the replication draft Joel Halpern Direct
- Re: [spring] Understanding the replication draft Rishabh Parekh
- Re: [spring] Understanding the replication draft Rishabh Parekh
- Re: [spring] Understanding the replication draft Robert Raszuk
- Re: [spring] Understanding the replication draft Rishabh Parekh
- Re: [spring] Understanding the replication draft Joel M. Halpern
- Re: [spring] Understanding the replication draft Joel M. Halpern
- Re: [spring] Understanding the replication draft Robert Raszuk
- Re: [spring] Understanding the replication draft Rishabh Parekh
- Re: [spring] Understanding the replication draft Joel M. Halpern
- Re: [spring] Understanding the replication draft Jeff Tantsura
- Re: [spring] Understanding the replication draft Rishabh Parekh
- Re: [spring] Understanding the replication draft Dhruv Dhody
- Re: [spring] Understanding the replication draft bruno.decraene
- Re: [spring] Understanding the replication draft Dhruv Dhody
- Re: [spring] Understanding the replication draft Alexander Vainshtein
- Re: [spring] Understanding the replication draft Rishabh Parekh
- Re: [spring] Understanding the replication draft Jeff Tantsura
- Re: [spring] Understanding the replication draft Rishabh Parekh
- Re: [spring] Understanding the replication draft Xiejingrong (Jingrong)
- Re: [spring] Understanding the replication draft Rishabh Parekh
- Re: [spring] Understanding the replication draft Xiejingrong (Jingrong)
- Re: [spring] Understanding the replication draft Rishabh Parekh
- Re: [spring] Understanding the replication draft Xiejingrong (Jingrong)
- Re: [spring] Understanding the replication draft Rishabh Parekh
- Re: [spring] Understanding the replication draft Xiejingrong (Jingrong)