Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.

Dhruv Dhody <> Thu, 18 March 2021 12:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ADB203A294E for <>; Thu, 18 Mar 2021 05:01:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kv4nW8AkZ_IR for <>; Thu, 18 Mar 2021 05:01:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5BE2A3A294C for <>; Thu, 18 Mar 2021 05:01:55 -0700 (PDT)
Received: by with SMTP id j26so1961784iog.13 for <>; Thu, 18 Mar 2021 05:01:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ABesnHd3OoFOnFaXwg/rdIZQlcjZyT1uDAfJkKzdcD0=; b=bg0BfLWnLFrnTHSUwfTV7Lxu+KQwX7ePWaCCNSjeCE3oX/rbq1V00Z2r1B7LG3MKM+ 32ScExRpnOdIZVPfyFZr4yhn6erZGOUsfL/WskpSdfbZDoGhWFmSzIO7BX+I89+SMcq5 t/wLmIOyE0yL2p/J+DEgwJDzRQQNdJU5LzcVDkURSubOidcBi0Y/wrMbBF66Uffd9D2r 4dPacASFkhThLZ0sf2TVcXcu9apDa8nCvLhAnwBo6AFC0SCJqAmEo3nTz1dNyOzCaIUe Kfp/WUD4bFCsJ8N1HMxksMCyRNDbT77YyCsEv7YwSnwSK5h3NlD2GOjNIap0dovhO5c7 rGiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ABesnHd3OoFOnFaXwg/rdIZQlcjZyT1uDAfJkKzdcD0=; b=LdRyvWnlO1fkrky4tKaG1Lv1mA/Tf69VZe5WnzP0malQbS6UBMFEqotvo1rBgTR+Go yZjY9te7h2xZ+2NMM96eZGwV5/S/xUaPtTNs8ReeOAS2kUFmfVEmTTSbkA5kvBlQYeMk tC5JFj6NoWDkQaE2I4LOrKBpEcP8/IP7mbQxo214Nyrb1C/zgqjieQzIUhiQaHiBh5dZ lgkmCccR1GrPcNS7JIVCgjDREq3sRFb3inNq36D4ykjIfm8XAHRtPxHu6/6ImYyKGPWF i9y5WsKxU+1WCVzP9TXzKZtKsaNf0DAiYhi6f5q/6TmqKqmJYWrOZqbgM2gTVxv90exq de5w==
X-Gm-Message-State: AOAM532WKQ3E06dxd/KM1vuh8wRMFMoclOpI4PDRH2ryxBJy8F2px8Nk oMfpbODOHwV1ujhAocLM7CuEO6eQovuvrLV82QKJh4fwSMuzlQ==
X-Google-Smtp-Source: ABdhPJy9V48yn78bGjKVJHeKeNEZrktEwXmIBjTptgGUv9rTc0eOXtdijzaaPRB8HwEw+CnjVCqt+4wqO9Z0OtG1s7Q=
X-Received: by 2002:a6b:7319:: with SMTP id e25mr9387892ioh.0.1616068912787; Thu, 18 Mar 2021 05:01:52 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Dhruv Dhody <>
Date: Thu, 18 Mar 2021 17:31:15 +0530
Message-ID: <>
To: "" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Mar 2021 12:01:57 -0000


Speaking as a WG member...

Let's continue the discussion on considering the replication segment
as an LSP v/s PCECC operation.

I just wanted to quickly recap -

- We have stateful operations for RSVP-TE: RFC 8231, RFC 8281
- We then introduced SR with a minimal extension of new PST and a new
SR-ERO subobject: RFC 8664
- We supported P2MP stateful operations for RSVP-TE with RBNF change
in PCEP messages: RFC 8623

We have always tried our best to maintain consistency between RSVP-TE
and SR in PCEP.

Now, if one considers the Replication segment as an LSP operation,
IMHO it needs to be built on RFC 8623 P2MP LSP operations. The current
approach does not build on RFC 8623 instead uses the multi-path
technique (related to ECMP in P2P [1]). This would deviate from RFC
8623 significantly.

On the other hand, considering the replication segment as a PCECC/CCI
operation gives you more leeway to choose an encoding with a new CCI
Object type for the replication segment and it could be independent of
RFC 8623.

I *still* feel PCECC makes more sense at the higher level too (because
of the additional instruction to the leaves and coordination
required). Even if one disagrees with that and considers it an LSP
operation, it then needs to build on RFC 8623. The current "mashup"
approach (i.e. it is an LSP operation but does not follow P2MP LSP
encoding) does not work well in maintaining consistency within our

Dhruv (as a WG member)