Re: [pim] [spring] WGLC for draft-ietf-spring-sr-replication-segment

Rishabh Parekh <rishabhp@gmail.com> Sun, 11 December 2022 19:03 UTC

Return-Path: <rishabhp@gmail.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E467EC14CF0F; Sun, 11 Dec 2022 11:03:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.094
X-Spam-Level:
X-Spam-Status: No, score=-7.094 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkufKCOKBG2Z; Sun, 11 Dec 2022 11:03:55 -0800 (PST)
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B8E2C14F735; Sun, 11 Dec 2022 11:03:55 -0800 (PST)
Received: by mail-ej1-x62d.google.com with SMTP id tz12so313528ejc.9; Sun, 11 Dec 2022 11:03:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=OIa8/lF5V0Ku1XzgbYHVUeYROst+II2XAOZXeJ6iwSU=; b=OwIcxlVLZqxH0n5vzkEHMTD5FnM4ogLrnoECY5pp3BH9WCKr996FYpzCTeK5IXb4ZP QttBClMO4FHyRCaMoQLXyhP9qzq4ZOc+vHr2pE5xWFY1ACrrlAvka9Q1x++jeoAQvFku o4IMjXtVPmq6PZCq+e6jAQpAaQEc7IsBHgdmz4QEX3xAi4phuJyqhp6Pps2YPTpGEbXq 8pq3DFgSg0iwP/hvF88Tl9IahnKx1gWX6SK848K+EOr8/jJC511zKxWhF8vdPqcO0YlE edILT8PrWws45lP7DCWkKUBFY3izmWqDYsRTc1O8IFMlbuaDyD4hJWU6dCE0abEc/xgp 5VXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OIa8/lF5V0Ku1XzgbYHVUeYROst+II2XAOZXeJ6iwSU=; b=nvr/tyfzaiJZXem4vXoR9/pAgxhv5uta8GFxEQwgIw2neAEAcVQyrY6xfECpXIbcAH 60bB5TAcKAubDfUvzSk2iQZDrIqUQRKNkCU+rbQT/UDwG6/lSQK7ryDZPly07bR5JZfL Wqd3T/1MampwASEN0JwfbvUo+CQ1bljP417SyUSfScadO/LLWlc5CerwV7EXNojvbkeZ tgmHlwl/vuQ7lUzVE0K46S+ziHLWwVxof/UsqUtnZKsuOEZjQ9H7+E+4zntzNjZZ26BW YK23qZ5ZvQX0FXaEdq/4goPkeJiJ6edImqOzLsYr3Ktvw58xvfXEwK4lYyKLaWJFM4Xk 0EbA==
X-Gm-Message-State: ANoB5plSlOl2OJJkSJqnnje4iJYGOQn8YWrZAjcepjoxYtCGhW3JVGpe S8EWnPcHv1D+toVAG/iXBHXiJCwebyuu6psfr58=
X-Google-Smtp-Source: AA0mqf7eTd5eZ2ZIISi02BtT9gVVUivrePljnIUVDv+t8oL98zhqUjom/Bbb2h6dK3CwAujNlZSR+GcrBgKMB8/VcRo=
X-Received: by 2002:a17:906:d929:b0:7c1:4ce1:2482 with SMTP id rn9-20020a170906d92900b007c14ce12482mr923852ejb.67.1670785432400; Sun, 11 Dec 2022 11:03:52 -0800 (PST)
MIME-Version: 1.0
References: <MN2PR13MB4206452A228FA4873780507CD2289@MN2PR13MB4206.namprd13.prod.outlook.com> <PH0PR03MB63006359E2C73E62E6EC3A71F61E9@PH0PR03MB6300.namprd03.prod.outlook.com> <PH0PR03MB6300B3271202478F22F7DD7EF61E9@PH0PR03MB6300.namprd03.prod.outlook.com>
In-Reply-To: <PH0PR03MB6300B3271202478F22F7DD7EF61E9@PH0PR03MB6300.namprd03.prod.outlook.com>
From: Rishabh Parekh <rishabhp@gmail.com>
Date: Sun, 11 Dec 2022 11:03:39 -0800
Message-ID: <CABjMoXac+2FjRV9V_B818GCLtwDpi2tDZJB9vp+tUntQAjivsQ@mail.gmail.com>
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
Cc: "draft-ietf-spring-sr-replication-segment.authors@ietf.org" <draft-ietf-spring-sr-replication-segment.authors@ietf.org>, "pim@ietf.org" <pim@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>, SPRING WG <spring@ietf.org>, James Guichard <james.n.guichard@futurewei.com>, Nitsan Dolev <Nitsan.Dolev@rbbn.com>, Michael Gorokhovsky <Michael.Gorokhovsky@rbbn.com>, Ron Sdayoor <Ron.Sdayoor@rbbn.com>
Content-Type: multipart/alternative; boundary="00000000000031b5e105ef920cd0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/6Xk-iX_PVuyGDSiwyNBIpVqvf50>
Subject: Re: [pim] [spring] WGLC for draft-ietf-spring-sr-replication-segment
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Dec 2022 19:03:59 -0000

Sasha,
Inline @ [RP]

On Sun, Dec 11, 2022 at 3:43 AM Alexander Vainshtein <
Alexander.Vainshtein@rbbn.com> wrote:

> Hi all,
>
> More questions regarding the definition of the Replication State of a
> Replication Segment:
>
>
>
> The draft states that:
>
>
>
> If a Downstream Node is an egress (aka leaf) of the multi-point service,
> i.e. no further replication is needed, then that leaf node's Replication
> segment will not have any Replication State…
>
>
>
> IMHO this is not aligned with the definition of the elements of the
> Replication Segment (already quoted below) and Replication State. It would
> be more appropriate to express the behavior of a Leaf node by stating that
> its Replication state (defined as quoted below) is *an empty list of
> branches*.
>
>
>
> With this approach a Replication SID of a bud node of a service could be
> defined as  an SID with the Replication state including,  as one of the
> branches – but not the only branch in the list - a Replication SID with
> itself as the Node-ID and with an empty list of branches.
>

[RP] The text " leaf node's Replication segment will not have any
Replication State…" effectively means an empty list of branches with an
indicator of Leaf role in a Replication Segment. A bud node is a combination

> My question is:
>
>
>
> Can the same "Downstream Replication ID in a given "Downstream Node"  be
> included/ in the Replication state of multiple Replication segments,
> especially of Replication segments identified by different Node IDs?
>

[RP] I assume you meant to ask  "Can the same Downstream Replication *SID*
in a given ...." .

>
>
> I have not found any answer to this question in the text of the draft. At
> the same time I think that a positive answer to my question would
> contradict the definitions in Section 3.1 of the MVPN and EVPN with SR
> P2MP and Ingress Replication draft
> <https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp-06#name-mpls-label>
> because these definitions assume that the Replication SID can be used as
> the "context label" for resolving the context label space space for looking
> up the upstream allocated label advertised in the PTA attribute of the
> suitable Mutlicast VPN route (in the case of aggregated P-tunnels).
>
>
>
> IMHO and FWIW an explicit and unambiguous answer to my question should be
> provided by the authors in order to advance the draft.
>

[RP] The answer is theoretically yes, but that would be like trying to
share a Replication Segment across different SR-P2MP trees (described in
PIM WG SR P2MP draft). This requires a complex set of conditions that have
to be met to make it work and hence we have kept it out of scope of this
draft, PIM SR P2MP draft and the BESS MVPN/EVPN draft.

Just to clarify, Section 3.1 of BESS MVPN/EVPN covers the case where a
*single* SR-P2MP tree is shared across two or more MPVNs and hence an
upstream (or centrally) assigned "context" is required in packet encoding
to resolve the MVPN in which payload is processed. When a SR-P2MP tree is
associated with only one MPVN, this upstream "context" not required in
packet; the Replication SID at Leaf/Bud is sufficient to provide the MVPN
context in which payload is processed.

I hope I have answered your questions,
-Rishabh