Re: [spring] Understanding the replication draft

Rishabh Parekh <rishabhp@gmail.com> Thu, 16 July 2020 16:41 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 8F1F53A0C1B; Thu, 16 Jul 2020 09:41:47 -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 dn3KM_CGrNgi; Thu, 16 Jul 2020 09:41:45 -0700 (PDT)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 040A33A0C18; Thu, 16 Jul 2020 09:41:45 -0700 (PDT)
Received: by mail-wm1-x32d.google.com with SMTP id c80so10907377wme.0; Thu, 16 Jul 2020 09:41:44 -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=7PzNiMQat7z6G2c206F/9uKZ2mE16Ae1OoiLT7ovJrw=; b=nBAXnntOZ+/ZOYcbww3Ooq6LaOgWrJj7Hv+JA/EWiS8l9SLQCAKwaxtBvr0fZU+Wo5 F7jT4lcxlc8FBbJPK/TY/yZf83jpvVg4tddLSF0ZYsDmCzOA/aWNu1M6ZmS0A/JF26ub AXNkp+3vqzUqjloZALkEfdNeF/0w2sdHLOYRrR5Meaijh6mQWEqCwITVM5BGUNzUyGOb 9BU+JRauRlwYpn1EoGnQXkQYQjO6bW7Z4qwykPWQEUFhC9MaIhttNaqy7KU0E45WAYnj eXYfyytzk9HWF2R4+eiT7D/C+ok/WttVhjD3CM473dOsRjlUGIKKy7c+O6bQh586nS57 AmGQ==
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=7PzNiMQat7z6G2c206F/9uKZ2mE16Ae1OoiLT7ovJrw=; b=RwL/P5oClP2307R91NOWku4lkZIgfZV+XFNNLWqjnzB6hsVOgXLoXZsV61eUnCFrDe a635CHqTSBiuTVwINO5l7vp68s5h0+CbsP/Zut+t88sA3Xx0sHsRuumNTOJCLgXyi8wh lhzwFH6d2qL+mPYPcRa/cBkdJioPNu8MEvFyW/eO+Ju4NcN4EWrfyHYU5bvEgFPZptBB EjneJVqEBCRPjT+8mcibTAH1Nr9JNYKvpEaoWdpkMvlv523AHZC6OK8CXCcWayVT3Qct 1Zuixp3W7dMPQXMnDgexMYx2bjSG+S5TNOS5Ve0FccVYZTucrIa8SQrsmfF8WCNttmoj sVDQ==
X-Gm-Message-State: AOAM5338CA1c8agboPKwW0HQldt8ZeAzF2/7aCnbHBcWSYmW1N8akNfw Gu9Bzq7upi4nZ7aV8USnsy9G4/R+hx/57SZFMWI=
X-Google-Smtp-Source: ABdhPJxB6Vs9TuVOEuwpttX4/w7cf5tgbO6JNXo2FvVtJcaCD684bXscPfroz2faw4HwuNbwiTW8LOTwi2angB6F5Uo=
X-Received: by 2002:a1c:dd09:: with SMTP id u9mr5025893wmg.70.1594917703390; Thu, 16 Jul 2020 09:41:43 -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> <CABjMoXZDHy5duYbzJYZ39yd-=aF9oMiPXYZg32DJPGiLkuaRNQ@mail.gmail.com> <09efee93b5a04b188fd5d111ddfa5dfb@huawei.com>
In-Reply-To: <09efee93b5a04b188fd5d111ddfa5dfb@huawei.com>
From: Rishabh Parekh <rishabhp@gmail.com>
Date: Thu, 16 Jul 2020 09:41:31 -0700
Message-ID: <CABjMoXZJR7mm8hEx8-sMnM-zffz+8WjnTrHtWHkyn8nV3q+J=Q@mail.gmail.com>
To: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
Cc: "spring@ietf.org" <spring@ietf.org>, "pim@ietf.org" <pim@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002819a505aa91b7b5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/6TbOCWIfyoOI6d8oeXWOeYW-lkE>
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, 16 Jul 2020 16:41:48 -0000

Jingrong,
Your understanding is essentially correct. Think of a Replication function
at a node represented by the function portion of SRV6 SID with Replication
context either in arg or in the function itself. In the simplest case,as
you illustrated, replication to a downstream node is just constructing a
SRv6 SID with downstream locator + downstream replication function +
replication context (optional) and putting it in the DA of IPv6 packet. If
the downstream node is remote and the packet has to take a specific path
(not the IGP shortest path) to the node, the downstream replication SID
will be somewhere in SRH.

-Rishabh

On Thu, Jul 16, 2020 at 3:45 AM Xiejingrong (Jingrong) <
xiejingrong@huawei.com> wrote:

> (Though it is in a PIM WG draft (cc’ed), but the terminologies in RFC8402
> are used and are the key to understand, so I would  expect points from the
> SPRING WG).
>
>
>
> Hi Rishabh,
>
>
>
> Thanks for your response!
>
>
>
> Let me try to understand the applicability of SRv6 first, and move to the
> other points afterwards.
>
>
>
> I read the appendix A.1 in <draft-voyer-pim-sr-p2mp-policy-02>, and still
> have difficulty to understand the processing of multicast packet.
>
>
>
>    o  R2, as Leaf, performs NEXT operation, pops T-SID1 label and
>
>       delivers the payload.  For replication to R6, R2 performs a PUSH
>
>       operation of N-SID6, to send <N-SID6,T-SID1> label stack to R3.
>
>       R3 is the penultimate hop for N-SID6; it performs penultimate hop
>
>       popping, which corresponds to the NEXT operation and the packet is
>
>       then sent to R6 with <T-SID1> in the label stack.  For replication
>
>       to R7, R2 performs a PUSH operation of N-SID7, to send
>
>       <N-SID7,T-SID1> label stack to R4, one of IGP ECMP nexthops
>
>       towards R7.  R4 is the penultimate hop for N-SID6; it performs
>
>       penultimate hop popping, which corresponds to the NEXT operation
>
>       and the packet is then sent to R7 with <T-SID1> in the label
>
>       stack.
>
>
>
> When considering SRv6, The “PUSH operation of N-SID6” and the “PUSH
> operation of N-SID7” are not clear to me.
>
>
>
> Seems that <N-SID6,T-SID1> and <N-SID7,T-SID1> are only for SR-MPLS, where
> T-SID1 is locally meaningful, and N-SID is globally reachable.
>
>
>
> I try to understand what’s the shape of each packet – pkt12, pkt23, pkt36,
> pkt25, pkt47 in this example when using SRv6.
>
>
>
>                     R3----(pkt36)----R6
>
>                     /
>
>                  (pkt23)
>
>                   /
>
> R1----(pkt12)----R2----(pkt24)----R4----(pkt47)----R7
>
>
>
> And this is my assumption:
>
> Pkt12: (SA=R1, DA=R2_RepSID) (C-multicast pkt)
>
> Pkt23/Pkt36: (SA=R1, DA=R6_RepSID) (C-multicast pkt)
>
> Pkt24/Pkt47: (SA=R1, DA=R7_RepSID) (C-multicast pkt)
>
>
>
> Is that correct ?
>
>
>
> Thanks
>
> Jingrong
>
>
>
> *From:* Rishabh Parekh [mailto:rishabhp@gmail.com]
> *Sent:* Thursday, July 16, 2020 4:46 AM
> *To:* Xiejingrong (Jingrong) <xiejingrong@huawei.com>
> *Cc:* Jeff Tantsura <jefftant.ietf@gmail.com>om>; Dhruv Dhody <
> dhruv.ietf@gmail.com>gt;; bruno.decraene@orange.com; spring@ietf.org;
> Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
> *Subject:* Re: [spring] Understanding the replication draft
>
>
>
> 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
>