Re: [spring] Understanding the replication draft

Rishabh Parekh <rishabhp@gmail.com> Tue, 07 July 2020 15:42 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 E2CCB3A0E65 for <spring@ietfa.amsl.com>; Tue, 7 Jul 2020 08:42:32 -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 UBW_hQKziHsg for <spring@ietfa.amsl.com>; Tue, 7 Jul 2020 08:42:31 -0700 (PDT)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 B80BC3A0DED for <spring@ietf.org>; Tue, 7 Jul 2020 08:42:30 -0700 (PDT)
Received: by mail-wr1-x435.google.com with SMTP id j4so43261300wrp.10 for <spring@ietf.org>; Tue, 07 Jul 2020 08:42:30 -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=ifBwXzMItfvFLgVZ9E2f9ppN3dnmzdgiklq4Zv9xCXw=; b=u0F7lKx7hTlVodmETT/U9v7DSNgI9NtHS8Hk9fQO1pbVTrJR3NPpYI9ZwyjBMC/LQa +1e6AWaHd/pqPkaNKM5arVuvE8ktJ7h9VkvPu4UdZNrbrVc2lLuIVgRXGFKrWkRN8DYB ezlNUoFlHp4/HSIrVyZA/nsIKvI9qV8r/xSs7cpYxvDju5rzgZDmi1e6KZFEHYaNhiPK cGsbHXenc3RNhSUA2AQ5pFg6vK/puenFCKuKkjnBMWFzWoW0B/4nnYNgYwl+Owr/qUOe M5aqB17jfEbNEy0PE2BezqcUOwvbMJA7ks7XnRiibWlbdXrgpl+F5XdLkRahgu9zm+Dr dBUw==
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=ifBwXzMItfvFLgVZ9E2f9ppN3dnmzdgiklq4Zv9xCXw=; b=Hl/NbayMMiHu7SKf1fDY/kDQQdqbM4e4xDeJbf4+XxG5JXWWsWqj60lXowGWtDDT9B eqRnwslhFJDzc94Sqsd4EM9RciVMEvtcvEWtgy6poBJUH/a8d3WrqDsPP+GN+TwQDD5Z hHl7gEw2K86uLho32yvWHYTi7c26GTGKHqISuo+d0qf8jOnxDUDR+cbsC8mKJ1uSuF0g Rbx+JJVyEvG/aukacP67eSqV5CM+SX7HdN7MEhUCblD+OMPBOjA2pouNos7USVW3JNyz +C1BZ4vcDBGNS08p5Qj+rhTgtFa7zogZmKEKi2+zSF6Qi86YTauwHj9YpmHY1Sp8e5uD qE5A==
X-Gm-Message-State: AOAM532H0Zlm3mRbyC4Cjg59tkXq2vAICM7fLVAO8g7uitf8Nz1BVXvj VeEC3ls+RO47lw6LDSsbk3OzCyb4WcWnWbh2ZuQ=
X-Google-Smtp-Source: ABdhPJxD5ghZ4qKGZldQW2glc6h8qE8lwNOup+CLWvRxkguC1EFJxjRn2nA19TMIPNbtl1jZrAWtK9Fi2GfneIFxmBE=
X-Received: by 2002:adf:f452:: with SMTP id f18mr53816207wrp.389.1594136549106; Tue, 07 Jul 2020 08:42:29 -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>
In-Reply-To: <32104_1594114929_5F044371_32104_68_5_53C29892C857584299CBF5D05346208A48EC8CCE@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
From: Rishabh Parekh <rishabhp@gmail.com>
Date: Tue, 7 Jul 2020 08:42:17 -0700
Message-ID: <CABjMoXbiN+icPRMY42HO2HudifsKiL8Dh6OHxw+5MKqvA-K99Q@mail.gmail.com>
To: bruno.decraene@orange.com
Cc: Dhruv Dhody <dhruv.ietf@gmail.com>, "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/8iz2Jlbj-VCbwDvAb_fpDR0XyDk>
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: Tue, 07 Jul 2020 15:42:33 -0000

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

We are working onthe  next revision of the draft that will clarify
some text and illustrate and example. We shall post it soon.

-Rishabh

On Tue, Jul 7, 2020 at 2:42 AM <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://datatracker.ietf.org/doc/draft-voyer-pim-sr-p2mp-policy/
> > [2]
> > https://mailarchive.ietf.org/arch/msg/pim/YyF7I02aaRtpZngf7uTno69IB90/
> >
> >
> >
> > 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>om>,
> > 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 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
>
> _________________________________________________________________________________________________________________________
>
> 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://www.ietf.org/mailman/listinfo/spring