Re: [spring] Understanding the replication draft

Rishabh Parekh <rishabhp@gmail.com> Fri, 10 July 2020 20:45 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 30CE53A0967 for <spring@ietfa.amsl.com>; Fri, 10 Jul 2020 13:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.598
X-Spam-Level:
X-Spam-Status: No, score=-1.598 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, HTML_MESSAGE=0.001, PDS_BTC_ID=0.499, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 LVqGzAfgmQ5Q for <spring@ietfa.amsl.com>; Fri, 10 Jul 2020 13:45:55 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 AD2923A0965 for <spring@ietf.org>; Fri, 10 Jul 2020 13:45:54 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id g75so7398627wme.5 for <spring@ietf.org>; Fri, 10 Jul 2020 13:45:54 -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=iEfyOOyZxbLLN+ckp9eenGc+fnzggektGxo47TOEeQo=; b=RRwx+B8ED7M5wlySzGFBDG+yuNTKvLGBGbNc9sLpIbLrTK3ykoZAe/Gv/NlKGFpFZA BoGgPbxPF79k7ons8R1LsX5fDJpvEl5jK0wkObqUsPfDS4DWm8yYg4XrJI6WsMHA38FX Z5hlxhTU93Hsw3npBTUXpU00Cjvo3pcnlfVTR8UiHHAjIQK2ZHK2Jn3wDDSn/E3U4xvu 8hb+Sj1ERi1vs22q02mcY4bInsIbE3nWjXQoJsPHdaA42Npp8q/0z6UQm/dhKfMvxgru zccfiYsdr2a/UksdW4mD7OouwUFJwRGVymM8HhFS/CEMqVz5ESKf2hm8N8FcFyy6rxOm wIgQ==
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=iEfyOOyZxbLLN+ckp9eenGc+fnzggektGxo47TOEeQo=; b=fhbnLVOYFO3U9oqhYl6D2DsVwOdnz97QAPoC+nqL3DJWgv+YLRngZZUMs748Ee9ov1 IZyDpCNQEiSqZysnJFnUsKvZ8ZA/bYvoA0+468AXJJfa3RBag0Y5khMbpiVWRP/JdO5c 1u4Vc3AGcFXBglLcpNz5rgETb9cip2vdd0XSmbnF7w7Su1hnGvKNzoM9jTg3G2GvnKCX 7MmQ5mjmuAdRW+EFKjOfmguUDNDcg/BMRGKdh3QlYwRD9tzA5X4dabCUKRbMAa6HrayJ nY/sY/EfHRuQZ7fqfgVT9hKnDr5dB3giAesnmKNbswyjdSxlaOI7jaQooGBmCKAjonev lfcA==
X-Gm-Message-State: AOAM533Cn0c6OipK1pMI+13ScAGbrSWZRVD5AuX1uH32LDFY3rziNyof AKdey2nZTSM6OqZ36drn25J0+9NFEob1nCg8dVg=
X-Google-Smtp-Source: ABdhPJyWBF1MeCroIjj6UsN35Ts+DLeegNIO/VUGzBmGt6XHR0gMLRBVFVguGOz0bgHSHTC2GG9neuPgG4YyWzRnXnY=
X-Received: by 2002:a7b:c116:: with SMTP id w22mr6562342wmi.97.1594413953023; Fri, 10 Jul 2020 13:45:53 -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> <CABjMoXZaiED+++2ij6CB_MH6dqGgs=t829XgsYy+6HHC69SDrQ@mail.gmail.com> <CAB75xn7f0RaMPhmN2KH26Z--8pp-ioGCMGSC+0MOx1T=Ugp+xg@mail.gmail.com> <32104_1594114929_5F044371_32104_68_5_53C29892C857584299CBF5D05346208A48EC8CCE@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <CAB75xn6CQsTEtDfR_UoRQCfgYUAFcjDyxBn1SidZx2EwK+9WTA@mail.gmail.com> <DB7PR03MB4505877740699D5EFD4EA64A9D660@DB7PR03MB4505.eurprd03.prod.outlook.com> <3d5c2f1b-d033-41ca-a59d-6c74addcc08c@Spark>
In-Reply-To: <3d5c2f1b-d033-41ca-a59d-6c74addcc08c@Spark>
From: Rishabh Parekh <rishabhp@gmail.com>
Date: Fri, 10 Jul 2020 13:45:41 -0700
Message-ID: <CABjMoXZ=+g0+4tv=U_nG+_85h830gfG7D7mQuAw09wQOvtgTWw@mail.gmail.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: Dhruv Dhody <dhruv.ietf@gmail.com>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>, Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>, "spring@ietf.org" <spring@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004b82c905aa1c6d5b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/KWMNYl2ROU5i8eZNCtII3l6U-Xo>
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: Fri, 10 Jul 2020 20:45:59 -0000

All,
We have posted revision 04
<https://tools.ietf.org/html/draft-voyer-spring-sr-replication-segment-04>
of the draft. This addresses comments on this thread and adds an example
illustrating replication segment. Diff from rev 03:
https://tinyurl.com/y96ueb9h

Some WG  members also wanted to understand how Replication segments are
stitched together to form a P2MP tree based on SR P2MP policy in the PIM
draft. We have posted revision 02
<https://tools.ietf.org/html/draft-voyer-pim-sr-p2mp-policy-02> of PIM P2MP
policy draft that adds examples of how these things tie together. I hope
that helps clarify the relationship. Diff from rev 01:
https://tinyurl.com/yban2jp6

Please review,
-Rishabh


On Tue, Jul 7, 2020 at 2:16 PM Jeff Tantsura <jefftant.ietf@gmail.com>
wrote:

> Thanks Rishabh!
> +1 to the above comments and looking forward to the updated draft.
>
> Cheers,
> Jeff
> On Jul 7, 2020, 7:35 AM -0700, Alexander Vainshtein <
> Alexander.Vainshtein@rbbn.com>, wrote:
>
> Dhruv, Bruno and all,
> Regarding the statement " What is missing in the spring I-D is some very
> high level discussion in terms of architecture on how replication segment
> and SR P2MP policy come together" - I cannot agree more.
>
> My 2c,
> Sasha
>
> Office: +972-39266302
> Cell: +972-549266302
> Email: Alexander.Vainshtein@ecitele.com
>
>
> -----Original Message-----
> From: spring <spring-bounces@ietf.org> On Behalf Of Dhruv Dhody
> Sent: Tuesday, July 7, 2020 1:02 PM
> To: bruno.decraene@orange.com
> Cc: spring@ietf.org
> Subject: Re: [spring] Understanding the replication draft
>
> Hi Bruno,
>
> Yes, thanks! I was just making sure that we have an agreement that PIM is
> the right place to define SR P2MP Policy.
>
> What is missing in the spring I-D is some very high level discussion in
> terms of architecture on how replication segment and SR P2MP policy come
> together. The current I-D tries to define a replication segment as an
> independent entity that could be used on its own but it makes it difficult
> to visualize without some high level text or an example.
>
> Thanks!
> Dhruv
>
> On Tue, Jul 7, 2020 at 3:12 PM <bruno.decraene@orange.com> wrote:
> >
> > Hi Dhruv,
> >
> > > -----Original Message-----
> > > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Dhruv
> > > Dhody
> > > Subject: Re: [spring] Understanding the replication draft
> > >
> > > Hi WG,
> > >
> > > Reading the I-D and based on the discussion on this thread I believe
> > > more description is required. As Joel pointed out, clarity on what
> > > is legal/illegal (or out of scope for now) is needed.
> >
> > I leave this for the authors to reply.
> >
> > > I have no strong opinion if that needs to be done before or after
> adoption!
> > >
> > > I do not follow PIM closely and just realized that the SR P2MP
> > > Policy in the PIM I-D [1] is adopted by the PIM WG, but not yet posted
> [2].
> > > I wanted to make sure that it has been decided that PIM is the right
> > > place to define SR P2MP policy (discussed either in the WG and/or
> > > between chairs/AD)?
> >
> > draft-voyer-pim-sr-p2mp-policy-00 is to be worked in the PIM WG.
> > The PIM WG is waiting for the SPRING WG to adopt
> draft-voyer-spring-sr-replication-segment, since the -pim- document has a
> dependency on the -spring- document.
> >
> > Quoting the PIM chairs: "We have solid support to adopt this draft..
> [...] We are waiting to hear back from the spring chairs as to the wg
> status of the local replication draft of which your draft is dependent.. So
> please hold off on submitting the new draft-ietf-pim-sr-p2mp-policy until
> they give us the green light."
> >
> > Does this answer your question?
> >
> > --Bruno
> >
> > > Thanks!
> > > Dhruv
> > >
> > > [1]
> > > https://clicktime.symantec.com/36sxrNPFssiaB8jE9mzzZDd6H2?u=https%3A
> > > %2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-voyer-pim-sr-p2mp-policy%2F
> > > [2]
> > > https://clicktime.symantec.com/3LtBxbxRK3NkuKYc3FC7rr46H2?u=https%3A
> > > %2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fpim%2FYyF7I02aaRtpZngf7uTn
> > > o69IB90%2F
> > >
> > >
> > >
> > > On Thu, Jul 2, 2020 at 12:05 PM Rishabh Parekh <rishabhp@gmail..com>
> > > wrote:
> > > >
> > > > 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://clicktime..symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https
> <https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https>
> > > > > %3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
> > > >
> > > > _______________________________________________
> > > > spring mailing list
> > > > spring@ietf.org
> > > > https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https%3
> > > > A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
> > >
> > > _______________________________________________
> > > spring mailing list
> > > spring@ietf.org
> > > https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https%3A%
> > > 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
> >
> > ______________________________________________________________________
> > ___________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que
> les pieces jointes. Les messages electroniques etant susceptibles
> d'alteration, Orange decline toute responsabilite si ce message a ete
> altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have
> been modified, changed or falsified.
> > Thank you.
> >
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
>
> https://clicktime.symantec.com/3U9X5zkPbKst7T8373JWnS6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>
>
> ------------------------------
> 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.
> ------------------------------
> _______________________________________________
> 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
>