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

Dhruv Dhody <dd@dhruvdhody.com> Mon, 22 March 2021 04:48 UTC

Return-Path: <dd@dhruvdhody.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1475A3A11A4 for <pce@ietfa.amsl.com>; Sun, 21 Mar 2021 21:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.004
X-Spam-Level:
X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=dhruvdhody-com.20150623.gappssmtp.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 j0HtCPMfF15G for <pce@ietfa.amsl.com>; Sun, 21 Mar 2021 21:48:43 -0700 (PDT)
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 5C1AA3A1230 for <pce@ietf.org>; Sun, 21 Mar 2021 21:48:43 -0700 (PDT)
Received: by mail-pj1-x102b.google.com with SMTP id ha17so7734927pjb.2 for <pce@ietf.org>; Sun, 21 Mar 2021 21:48:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OzQXbkGyINXhLIaIpeCvMsSPUkg5oKNnGnJ0yNHgh0c=; b=wRA38emhAOF+8KVse6Q8ReoE7O6Fb11W7usGc8/KMdQ8Yety9wX2EgCTX5Z1eLqPA6 Og3g5lRQA1hTzljmfLMoaq4ibFGf/GPCQntLxv3IXCjoBNtZ1Le555SVcTR4jUQO+Pky b3/+gT5wcIHFevgnC+6soXfVS1m17FfOHrVXmTq4NhCcPBXVsU/uLahCpv9GE+pVqvOq OrUg30u6UmBkK3P7mjlu1DV2inhde2cpFypwPWIA7E57YGwvG/nUyJorLXk65W8dCuwM BRQQh1YbR7RtQYj1cGUAuxDoriiBA09kWZisRj7uE76WMSqjZtBz6X+OW1kjEUVwTO5k ebYQ==
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=OzQXbkGyINXhLIaIpeCvMsSPUkg5oKNnGnJ0yNHgh0c=; b=nu0C0lZYZIXq/s6ICbUQiODIsx3e1SWNJp95ySvNZffkmGx8ozj0eDCMfP/xzK/Cmi kjKV0dgJqWUD9J2fiVf7ebxZislf8Vg9FgVX2KWvuOj12pISfZWB4maG9PdyNmvgstD6 A/B4kCFB6lP7yeHgSX0JM6fYj23RCGhMlsUvG1GwbvODzCG3jv8tgjAbGdStTYzdBK+J BpjdBKVlS9wWaRkUhTUEiaPNJu20g3RPQ7ccCGX5uewK+deJGOLDBdbXlITQQwzU+Gh0 yJKbljddMphBmAaa4AN/1w18I5HrU9iGBnUeb1fnG+3LdIMKBv8P7ShCseWsbZHC2QMb 1zSg==
X-Gm-Message-State: AOAM533KiMSP9YUOYiByH4z9ms3ULfEiJ+Kc/Qe7PvtigJRFKhJ6nSDZ v5ZcqwFPgbPugH1lp7eExm8IgmBdhl46RlyQl2ZqUQ==
X-Google-Smtp-Source: ABdhPJziuiPjk8Zc8ihmUyxki0e+TLXEJ+rlYD8MrIR5/VArYgTKekafFLAmrhCvz/JE9AOdeH01+IUEwBwBV6NOFbM=
X-Received: by 2002:a17:902:8685:b029:e6:5ff6:f7df with SMTP id g5-20020a1709028685b02900e65ff6f7dfmr25348725plo.40.1616388521792; Sun, 21 Mar 2021 21:48:41 -0700 (PDT)
MIME-Version: 1.0
References: <DM6PR08MB3978834687ACFA7C599AF90C91A10@DM6PR08MB3978.namprd08.prod.outlook.com> <CAP7zK5YUG2HhDqwCXbhAzO27P18GEL6Rdr6nkYBvW9yzCHLHjQ@mail.gmail.com> <DM6PR08MB3978524B94C0FB4D21B6A1CF918E9@DM6PR08MB3978.namprd08.prod.outlook.com> <CAP7zK5buVgy=HhT-+ZnhYZcE1AYRmOxK9-Md=4FJxqu7BLK3Zg@mail.gmail.com> <DM6PR08MB39780572111C11CDF6EFC7D4918B9@DM6PR08MB3978.namprd08.prod.outlook.com> <CAP7zK5YjxiMTnUT7zVHYDeYqxvQR8ESQf7ydngPYObVPHLU8uA@mail.gmail.com> <DM6PR08MB397847235D7ADDF7C4B7D028919B9@DM6PR08MB3978.namprd08.prod.outlook.com> <CAB75xn7sR7wRTxamEzDJ2baaCq+iNmd1pNA+u+BGit4o4gBo6Q@mail.gmail.com> <DM6PR08MB39783882B8AA6A607416AA4E91999@DM6PR08MB3978.namprd08.prod.outlook.com> <CAB75xn4rAdTk3VQg5OVJB-NxXuPRv3NJ_M8rKC-Gw8WHpmvDog@mail.gmail.com> <DM6PR08MB39782584E9BBB2A30879DAF091989@DM6PR08MB3978.namprd08.prod.outlook.com> <CAB75xn67U9iMraEFh=8t2bc+0rGQ703sQgDtvOVck3=3pf2bqw@mail.gmail.com> <DM6PR08MB39789457277EEBE3BE6E950B91919@DM6PR08MB3978.namprd08.prod.outlook.com> <18062086-5dc2-5fee-b5d8-704d37e47a2e@orange.com> <CAB75xn4GY6BgKHsoX9YbELu_b9fF41tHWgDFzDYuOhjuUR8wcA@mail.gmail.com> <DM6PR08MB39782173FED5F234B21B92D191699@DM6PR08MB3978.namprd08.prod.outlook.com>
In-Reply-To: <DM6PR08MB39782173FED5F234B21B92D191699@DM6PR08MB3978.namprd08.prod.outlook.com>
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Mon, 22 Mar 2021 10:18:05 +0530
Message-ID: <CAP7zK5ZsAaA_HTja85bk2Ye6v6FXk-=T4=FvAhzuW81uCYUh=A@mail.gmail.com>
To: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <hooman.bidgoli@nokia.com>
Cc: Dhruv Dhody <dhruv.ietf@gmail.com>, "pce@ietf.org" <pce@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a9282d05be18c762"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/R8f7tN8MTsrhtP1-yNe10yNUiBA>
Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Mar 2021 04:48:48 -0000

Hi Hooman,

On Thu, Mar 18, 2021 at 10:06 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <
hooman.bidgoli@nokia.com> wrote:

> Hi Dhruv
>
> I am very confused by your messaging.
>
> Originally it was pointed out that the draft should follow PCECC/CCI.
> The authors explained why they feel that is not a good fit.
>
> Now you are mentioning get in part with RFC 8231, 8281 etc... which is a
> new input. Thank you.
>
>
I apologize if I was not clear. As I said in the mail, I still feel PCECC
is the way to go. What I want to highlight is that if you consider it as an
LSP operation instead, then it should be built on RFC 8623 (P2MP) instead.

The 'recap' was to show how the extensions in PCEP have been done for SR
and P2MP in the past in a consistent way.



> The authors/co-authors have  tried to keep the draft in par with all the
> RFCs that you mentioned as much as possible. As it is mentioned in the
> draft clearly. That said this is new concept and there is a need for a new
> PCE concept and deviation, hence the draft ūüėä and the purpose of IETF.
>
> RSVP-TE P2MP is built via S2Ls.
> Replication segment is nothing like S2L, replication segment can be
> connected via unicast SR.
>
>
If you claim that the replication segment can not use RFC 8623, that gives
it more of a reason to not consider it as an LSP operation in the first
place.


> Again we are open for any constructive feedback on how this draft can be
> improved, in the boundary of
> https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/
> https://datatracker.ietf.org/doc/draft-ietf-pim-sr-p2mp-policy/
>
>
Just to clarify, my feedback is on your choice of PCEP procedure and
encoding for the replication segment taking existing PCEP
extensions/procedures in mind.  Hope the discussion was useful, it was for
me...

Thanks!
Dhruv (as a WG member)


> Regards
> Hooman
>
>
> -----Original Message-----
> From: Pce <pce-bounces@ietf.org> On Behalf Of Dhruv Dhody
> Sent: Thursday, March 18, 2021 8:01 AM
> To: pce@ietf.org
> Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.
>
> Hi,
>
> 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
> extensions.
>
> Thanks!
> Dhruv (as a WG member)
> [1] https://datatracker.ietf.org/doc/draft-koldychev-pce-multipath/
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>