Re: [spring] Understanding the replication draft

Rishabh Parekh <rishabhp@gmail.com> Wed, 15 July 2020 20:46 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 8141F3A0FD4 for <spring@ietfa.amsl.com>; Wed, 15 Jul 2020 13:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 yZztNGKbBgkn for <spring@ietfa.amsl.com>; Wed, 15 Jul 2020 13:46:31 -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 991343A0FD1 for <spring@ietf.org>; Wed, 15 Jul 2020 13:46:31 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id f18so7477683wml.3 for <spring@ietf.org>; Wed, 15 Jul 2020 13:46:31 -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=Rvw5hbtRS0dTrFmi/PuNRjonQjP50gsJIAzfW1ASH0A=; b=Ex9D8qdA0ipP5iu2jYCUXwIj6eZxKyF4vIt37uSIT2vM7V0W90Dn8NJQHGddD37AfR enjeCJ5HUsNWGq8OfIW+D4KpSPSr6mSGHbvZJSSRpBIDFTT5QikZNRstZ0E6Yf9tW/wm et3gxJt7Pv6cUaeJPOHbVzqzcR5mZzsGQ20Hg9vBB53oSqRGEqZFizjxo5CchhsELG/a KI+arfrV3t/hOAyMilzHilSxk0sQAycD1/ZAfQOBccjB/e5zeOGYx7cI99xwIhMisjLK KJpk1QJGzrjXe27Qm4bvl/eqqiWBNrp1GE7qySjt8W2s3m5Tj/yXH6cs9GU0PNFfiGqJ iJdg==
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=Rvw5hbtRS0dTrFmi/PuNRjonQjP50gsJIAzfW1ASH0A=; b=IxjfiJ5BA2KQJbbNwsQU8dFvy2WrtIxgYnNDGaGHG/UGLAo0CTlXoDjanv2k6gyhLU w+flG8HxTSdUP3CXvRTPzf41xLDswSQavw/ydAefnyiZFQM0ZlUkiawR3QQ4sQeseceV JFXObuUGHbqn3h9EA/TY0JOcjRboeJfSHXyzmZP+ZhfQOfOShaHu/6nK8c1ftAwpAjiu AmAyNwH/ACVPQeL+HPMfFO1eR5n2CadOd9J9/UFH+Xx1d9Zere9G4kILhBDoLhRZNITu fILfbJEhb1yHLp/uSLegwXPaXx2GLDrUYz0QzzwZc7hwPLzdiJRNez5FFzFFuNu63XFM ICeQ==
X-Gm-Message-State: AOAM531EqjrjbbwiObVtiLblnbv5L2FgFlwLqiYp6JNSoNxD48OuW1kK /vC1cUgaRTA6OyhJMkgD20UqCWvqY1TxAdw2BSY=
X-Google-Smtp-Source: ABdhPJy4t3nSE/LQxs+kBDKgEqZ1WORnbqDYvZJzF0K5RfJpyOfZZ4NMepYy/fLlslpq1aStojg9Q2OyBt1zKN1zSmM=
X-Received: by 2002:a05:600c:2483:: with SMTP id 3mr1284467wms.120.1594845989562; Wed, 15 Jul 2020 13:46: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> <CAB75xn6CQsTEtDfR_UoRQCfgYUAFcjDyxBn1SidZx2EwK+9WTA@mail.gmail.com> <DB7PR03MB4505877740699D5EFD4EA64A9D660@DB7PR03MB4505.eurprd03.prod.outlook.com> <3d5c2f1b-d033-41ca-a59d-6c74addcc08c@Spark> <CABjMoXZ=+g0+4tv=U_nG+_85h830gfG7D7mQuAw09wQOvtgTWw@mail.gmail.com> <c9f68faa7ff8480c832cdc60bb2c98b0@huawei.com> <CABjMoXYbNdjJLQs8y+f8oUgKVKs1psiYK7j9SZW_SbPoiJtYdw@mail.gmail.com> <f6f94fddd4ca4e9dac51db4742b06bc9@huawei.com>
In-Reply-To: <f6f94fddd4ca4e9dac51db4742b06bc9@huawei.com>
From: Rishabh Parekh <rishabhp@gmail.com>
Date: Wed, 15 Jul 2020 13:46:17 -0700
Message-ID: <CABjMoXZDHy5duYbzJYZ39yd-=aF9oMiPXYZg32DJPGiLkuaRNQ@mail.gmail.com>
To: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
Cc: Jeff Tantsura <jefftant.ietf@gmail.com>, Dhruv Dhody <dhruv.ietf@gmail.com>, "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "spring@ietf.org" <spring@ietf.org>, Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
Content-Type: multipart/alternative; boundary="000000000000adeba205aa810490"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/4P1tVEo8tgEMSuV8oWSzqQFHbbg>
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, 15 Jul 2020 20:46:34 -0000

Jingrong,

Replies inline.

1)       About the distinction of Replication-ID and Replication-SID, and
> their usage.
>
> If there is an SID block specially reserved for the P2MP Transport on each
> of the Replication Node, and such SID block (on each Replication Node) is
> advertised through west-east protocol like IGP/BGP,
>
> and then the north-south controller (like PCE) can use the
> “Replication-ID” and “Node-ID” only, but don’t need to use
> “Replication-SID” when populating the “Tree” information to each
> “Replication Node” ?
>
> In that way, the Controller doesn’t need to allocate (and manage) each of
> the Replication-SID (Say 1000 Replication-SID)  for  each Replication Node
> (Say 100 nodes).
>
>
As we try to make the distinction clear in the draft, Replication segment
is a logical segment that needs to be explicitly instantiated on the node
either by PCE or by some other mechanism (maybe local config?). The
Replication SID has to be assigned when the Replication segment (with a
Replication-ID) is created on the node. Note Replication Segments can be
created and deleted over time. and So, there is no pre-allocated block of
Replication SIDs that can be announced in IGP or BGP. Effectively, the
entity managing Replication segments has to manage the Replication SIDs.


> 2)       About the Replication Segment illustration.
>
> The rev-04 add a section “Illustration of a Replication Segment” in
> appendix, it is very clear and useful.
>
> To me, the “Replication State” is more like a “forwarding state”, and I
> think it will be helpful to understand the whole solution if:
>
> a) there is a description/Illustration about the building procedure of the
> “forwarding state” ---- What’s the information each Replication Node
> receives from the controller, and how each node builds its own forwarding
> state.
>
> b) there is a description/Illustration about the processing of multicast
> packet on the whole path of the P2MP tree.
>
>
Illustrations of how packets and handed on a P2MP tree built by stitching
Replication segments have been added in latest revision 02 of PIM WG draft:
https://datatracker.ietf.org/doc/draft-voyer-pim-sr-p2mp-policy/
We have drafts on PCEP and BGP protocol extensions to instantiate
Replication segments.


>
>
> 3)       About the applicability of SR-MPLS and SRv6.
>
> The rev-04 says “Replication segments apply equally to both SR-MPLS and
> SRv6 instantiations of Segment Routing.”.
>
> I am not sure if this document will cover SRv6 as well, but if it does,
> then I would like to see the same level of consideration as SR-MPLS.
>
>
>

 Yes, we will have the same level of details for SRv6 Replication too.

-Rishabh