Re: [mpls] Rtgdir early review of draft-ietf-mpls-bfd-directed-07

Greg Mirsky <gregimirsky@gmail.com> Tue, 04 May 2021 16:05 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8383A0FD2; Tue, 4 May 2021 09:05:36 -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 7cFs5zRs_jgY; Tue, 4 May 2021 09:05:32 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 B4ABF3A0FDA; Tue, 4 May 2021 09:05:31 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id o16so11849155ljp.3; Tue, 04 May 2021 09:05:31 -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=xB0HhhWnlPx6YWrAH7A/ZlkyWf/sMgssI4UlJY1DpH4=; b=A7rj2KPxEJqMJJr+8fgzAarp5CGwHkbWeqp1070ZGIeQWZEKqLbLmbwRhkXoQMaiWn ZcUEEhbGRxwjsWq9imRQCmPJ6vCQpvw3ISl5ba+ujuLnDLVvEzbc4ZnnFVmMxRF2pJ6h 7R6bKMTPJl5fiX5yLSMy0cHmqhW1GZQ1CzbA7I3YFTwSDSMiSXZ/BfBwbUVorhTU2gqB 7zJjTDcNjyMDmwzye+Gz3fTVOjpyN1xiV+xlbe+eRyKDSxJXj4koXhByaACIWxDyXBYU ewhppa79NvxFE9eSAZXHWBC/meTrzYFnnUK/uNNB7KmcnoMarOynBLLehnYShuWKKoUR uWvg==
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=xB0HhhWnlPx6YWrAH7A/ZlkyWf/sMgssI4UlJY1DpH4=; b=q5FUtP3m7JSco+Y+Dl+TLGPGWfDQ7PykcbnP9beqdfKde15QJCUYhXJkH4wwiTl5M9 70KRvXz/Vh1U/5jeljNwNhh1TOJacCnnhCtaSjWnmbI5hTF6kf1MduQzRtxOF1Ak2uGV ru2qmU6GspsPhISxebowz76RxLO/ANOx68uLzqetJhpkz8p+uFk+5loMjohn94fCjT+9 I99c75pCO5Yy36AGS+Yn00gIvqYg59bDqhf+5/btBQBBR5uhWD6TfWnnX5KbM4mfdz0I zod+3qSsFMDXW/uvyetTeGTXIhU+MqtNe0TKigNigRYuObFyONXyVde8BRO82v7DECtt nliQ==
X-Gm-Message-State: AOAM533ddZFyBMcGovSSDy7qSJfb0FcNYT8dL4RrefzhvqC/6tyhr9qT B3uxKD/81iiv0FaIg0YcxlDqJWUg1I9eOwzsuwI=
X-Google-Smtp-Source: ABdhPJzodNYndNCz7xDBxWn0k+uNuYrtigosX9uF0vulneSmVC1Muwsa277LyuK0K7acExK33h07XeiPFOindVFxoKo=
X-Received: by 2002:a2e:b531:: with SMTP id z17mr12513758ljm.126.1620144329219; Tue, 04 May 2021 09:05:29 -0700 (PDT)
MIME-Version: 1.0
References: <149978159930.12344.18347332855391607627@ietfa.amsl.com> <CA+RyBmUrraRZeO3mwmurfaVwZva22J=3YNOTSN77utjhZc5Osw@mail.gmail.com> <20170717090400.GC24942@pfrc.org> <CA+RyBmXZmb0tXx2Up=uyDAv2-i2sbPzHfSQ4K-ov6+K6WQy4og@mail.gmail.com> <20170717092332.GD24942@pfrc.org>
In-Reply-To: <20170717092332.GD24942@pfrc.org>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 04 May 2021 09:05:17 -0700
Message-ID: <CA+RyBmXQ-2aV-YJ13hHHueJpNjT+go4-dq9AsG6_vn=Z_j+rQw@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: Carlos Pignataro <cpignata@cisco.com>, Routing Directorate <rtg-dir@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, draft-ietf-mpls-bfd-directed.all@ietf.org, bfd-chairs@ietf.org
Content-Type: multipart/alternative; boundary="0000000000003a62fe05c1833fb8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/M-OCw2_tK_Unv6JNev2yD4jdaxY>
Subject: Re: [mpls] Rtgdir early review of draft-ietf-mpls-bfd-directed-07
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 May 2021 16:05:37 -0000

Hi Jeff,
I've checked this discussion thread and realized that I've missed
highlighting updates that I've made following our discussion on the use of
the LSP Ping with BFD Discriminator TLV. Below, please find the text added
to Section 3.1:
NEW TEXT:

   The BFD Reverse Path TLV MAY be used in the bootstrapping of a BFD
   session process described in Section 6 [RFC5884].  A system that
   supports this specification MUST support using the BFD Reverse Path
   TLV after the BFD session has been established.  If a system that
   supports this specification receives an LSP Ping with the BFD
   Discriminator TLV and no BFD Reverse Path TLV even though the reverse
   path for the specified BFD session has been established according to
   the previously received BFD Reverse Path TLV, the egress LSR MUST
   transition to transmitting periodic BFD Control messages as defined
   in Section 7 [RFC5884].

Please let me know if this text addresses your concerns.

Best regards,
Greg


On Mon, Jul 17, 2017 at 2:13 AM Jeffrey Haas <jhaas@pfrc.org> wrote:

> On Mon, Jul 17, 2017 at 02:06:01AM -0700, Greg Mirsky wrote:
> > true, the RFC 5884 does not discuss handling of subsequent LSP Ping with
> > the same BFD Discriminator value in BFD Discriminator TLV. My reference
> to
> > RFC 5884 is to point that the default, implied path for the reverse
> > direction of the BFD session is over IP network and that how this draft
> > interprets BFD Reverse Path TLV with none- sub-TLVs included. And yes,
> > nodes that would support this draft MUST handle subsequent LSP Ping Echo
> > Request with BFD Discriminator and BFD Reverse TLVs.
> >
>
> I don't believe the procedure updating 5884 to change existing session
> properties is called out in the -directed document.  I don't have a strong
> opinion about the use case of whether such updates are desired or not.
> That's a decision for the MPLS WG.  However, I do think such procedure
> needs
> to be clear if it's desired.  This is part of Carlos' point.
>
> -- Jeff
>