IETF Logo Mail Archive

[pim] Re: pim wglc for draft-ietf-pim-mofrr-tilfa-03

Gyan Mishra <hayabusagsm@gmail.com> Fri, 10 May 2024 03:14 UTC

Return-Path: <hayabusagsm@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 752C7C14F696 for <pim@ietfa.amsl.com>; Thu, 9 May 2024 20:14:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.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_NONE=-0.0001, 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 YHFt4T_joyzk for <pim@ietfa.amsl.com>; Thu, 9 May 2024 20:14:52 -0700 (PDT)
Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 91C7FC14F682 for <pim@ietf.org>; Thu, 9 May 2024 20:14:52 -0700 (PDT)
Received: by mail-pf1-x433.google.com with SMTP id d2e1a72fcca58-6f28bb6d747so1368603b3a.3 for <pim@ietf.org>; Thu, 09 May 2024 20:14:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715310892; x=1715915692; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jH3bgICE8pzEBz9XpacZrM25hyKY+yfoDnfBu/g+0no=; b=YLkkMmAfVe/gbf5Lg602hkX02Dg2DtWsgUjmKkr7jnhkkvO+oYVcds0D7jEvwlPNLQ 9vEFVPJPGfPHyVSLziY+3n4tT0Kx6YmvzqP68mWLnaYF7rPSFWhbTG+Nr0UpxSA6cbd0 peIIxFyTuG0pflT32DyXouePaMu60U6KqTTWOP9rYk0HogYWf823tJbeIKe3aDiYjukt 9WQeVlsIRxJBncz6WupQJXTdT5mMFD/O29IVrcxHrXDvV7TZYO7No+aE7i1UnyagMmxg WF4Z0cRVR5dHpy7lWuX5jJnMMsDbew979FLo6KqGcnrfCqqScP2j7y5naCDLPF5sYW0u EI1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715310892; x=1715915692; 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=jH3bgICE8pzEBz9XpacZrM25hyKY+yfoDnfBu/g+0no=; b=R3HMnGMnCa7qD9LuddeP2tQq8i4dqHiHOsmea9byBjYG3/f7EWSujbKfx9WftY23Ig qvhw3r0E+P7cKhZhYAnTws2oeik2qOZ4pcPFsrh9Ou5IBs2gx46rzPQTiyLqu8HJ2Syp wxJ55k37BniFwL/cljWZM6y/le+pIyHjXomaJu0NKOavtGGnPXQthkrkH0MXZs20SYwb UaGO5/XEReKTlshobVfZIq2TLCS+hHl+Ybk+WgDbH0WZ4bIYiVdqbfyMkrO4s0DTRVMh 6dwg/1WTmjL0fK9j6R+JP3ySA0M1rGP9iDsSvAVv2KOsqHU8C6FvfkL5rEN19ApXhMRt uAYQ==
X-Gm-Message-State: AOJu0Yw1RGc4L0bTe75FwUyxf8rXwxKxJt9gKOS3AxkFRyH3RMxou1e4 b6/ae6nwnbmtp6xFxLuXa3AmoNiKsXEu5FRMdGbTmd5q0Ys0RuCXsf2ZvwYu5aEXXDR06V2gZKq s5OsRsjC8QFQN/m9Jvifnp5cd3nOtJkna
X-Google-Smtp-Source: AGHT+IFLdm/yX949+JDoW2SK7EDOFrXTgn5sJa4rfjKPdwZURHrLBQ53DU1Xc3aeb9qmadbHc+RgGPrUxIko0z95Lmo=
X-Received: by 2002:a05:6a21:1aa:b0:1af:cd45:598b with SMTP id adf61e73a8af0-1afde10f2c3mr2034822637.34.1715310891750; Thu, 09 May 2024 20:14:51 -0700 (PDT)
MIME-Version: 1.0
References: <CAHANBtL7+mUXheBoQGHBT=1CwewWhUMnfy9dKKTDXLjR7CTOGg@mail.gmail.com>
In-Reply-To: <CAHANBtL7+mUXheBoQGHBT=1CwewWhUMnfy9dKKTDXLjR7CTOGg@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Thu, 09 May 2024 23:14:40 -0400
Message-ID: <CABNhwV2kd5T8XiV6TMvnfRiJnyg=C+0jPCvGz=0CfVs3_bX_AA@mail.gmail.com>
To: Stig Venaas <stig@venaas.com>
Content-Type: multipart/alternative; boundary="00000000000061de16061810f006"
Message-ID-Hash: 63I72KDMT2GJRZ3SMBE4SZX4S3JYNI6W
X-Message-ID-Hash: 63I72KDMT2GJRZ3SMBE4SZX4S3JYNI6W
X-MailFrom: hayabusagsm@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-pim.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: pim@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [pim] Re: pim wglc for draft-ietf-pim-mofrr-tilfa-03
List-Id: Protocol Independent Multicast <pim.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/oagS8OV0LsqMsPb6W4pDaFhaJT4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Owner: <mailto:pim-owner@ietf.org>
List-Post: <mailto:pim@ietf.org>
List-Subscribe: <mailto:pim-join@ietf.org>
List-Unsubscribe: <mailto:pim-leave@ietf.org>

I support  publication.

I have a few questions about the draft.


MoFRR is typically used for mLDP FRR on backup path protection.

TI-LFA is relevant for SR based networks for Local LFA and RLFA protection
for unicast flows and in this draft  we are showing that for PIM network
that TI-LFA Multicast FRR being relevant.

SR based networks would be stateless and not have PIM enabled and would use
SR P2MP policy with Tree SID.

Would this draft be relevant for SR P2MP Policy with Tree SID?

AFAIK since TI-LFA mechanism is being used for both unicast and multicast
FRR protection for SR P2MP Policy head end node with intermediate P nodes
using Mo-TILFA, I would think we can drop the MoFRR and call it multicast
FRR.

AFAIK since we are talking PIM network in the draft and not PIM free core,
are we  referring to scenario with RFC 6037 MDT SAFI for MVPN RFC 6514 PTA
3-SSM, 4-SM, 5-BIDIR.

It’s possible we can have mLDP enabled or even SR in parallel overlays
which is typical operator scenario that SR is used for unicast and in cases
where operator does not choose to use SR P2MP Policy due to scale issue and
wants to keep mLDP for multicast and uses MoFRR for backup path failover
and utilizes RFC 7473 SAC selective mLDP label advertisement for multicast
labels only so that LDP labels are not advertised for unicast.  In this
scenario MoFRR is used with mLDP which is the problem statement.  But this
would be for pim free core and in the use case described is a RFC 6037 pim
core. In this scenario multicast would be over mLDP and not SR network.  So
here MoFRR-TILFA would not apply.

Thanks

Gyan

On Wed, Apr 24, 2024 at 2:16 PM Stig Venaas <stig@venaas.com> wrote:

> Dear wg
>
> Today begins a two week wglc for
> https://datatracker.ietf.org/doc/draft-ietf-pim-mofrr-tilfa/
>
> In Brisbane we had 5 saying it was ready, and none against.
>
> Please respond with any comments you may have on the draft, whether
> you think it's ready or not, and any review comments you may have by
> May 8th.
>
> Regards,
> Stig
>
> _______________________________________________
> pim mailing list
> pim@ietf.org
> https://www.ietf.org/mailman/listinfo/pim
>

v2.29.0 | Report a Bug | By Email | System Status