Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt

Greg Mirsky <gregimirsky@gmail.com> Thu, 22 March 2018 16:18 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F032B124B18; Thu, 22 Mar 2018 09:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 P3hOFKP4566T; Thu, 22 Mar 2018 09:18:45 -0700 (PDT)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 905D21200A0; Thu, 22 Mar 2018 09:18:44 -0700 (PDT)
Received: by mail-lf0-x230.google.com with SMTP id l4-v6so9702366lfg.12; Thu, 22 Mar 2018 09:18:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vU8A2gBYGQEBtjXeTfSWfkihOTPMabBxumpyzcyDS4E=; b=o/65hRF6J7s6eq5YwXuDeErcer7sxQmJuEjpdT8gjm9O0Ks8w7VROMbbwfCtS5MXrC ze/9JRnUtl40gTlLtp4XARwWUXZU+URoT8QayLsAiNKbCTyj7MOKZVDCqcj5UlyXMOHL Mo8eP/XPlEBtpptW2+qroLY7PIhot8Cv9mj3QyEPhrgaFI/0hIUwmfMM3LbJVb2AKBvX wDXINgI9ifKW+/rC/w0rGhh/eotab85TYEG7t2NCZoeol6mKikv5mdP7UMpYOVwJjY9w W+dh9s4G+vfTMf/auXB4CKmTvFzRjfa/7VVGCcRJLfimR7Dn/BvuW1F7MDs6ifKllRTr 38vQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vU8A2gBYGQEBtjXeTfSWfkihOTPMabBxumpyzcyDS4E=; b=ETX976QgqAzGwKCC5N9M/X3HHELcWrhVpYs2EZNNpPOUWU2hBdGhPDOBGhwi6sBKud HTYV3SgUJ5RPnxJ1d43JnATwcfFBQY4R6RMf9o4uP7NZpUKNZ0RiVJQhD6AGKJ0/h+rT RnCY7JM9ydJD4lkiTVXjegbW1QGTThS1NHStTxDumAwHb5BWJRa6n4sAvLvkuBdYA1b2 zQYAdYE6jiA7ZB/UbTXYYfDBJXwZ27oVaoxnqSSZodGSfKwAJtH1FBsotioPTTUOyMzL pQxBOVK9WXL7nCgboyfPyn4ePLl9lItOaMpeqzCSiRCsaE+bxHBhQgv8QgZsCO2++LJ3 R60w==
X-Gm-Message-State: AElRT7GJsUKQvDUZt0inTbAtU/dymJJCrHFqRrteK1NxhxjynyJofkz/ uLIJRXeHHSMxBwz9FwR5D9OpcEv8khH9dfhpGk+rqA==
X-Google-Smtp-Source: AG47ELsOCqQeH1WEauNF8qYCuSjgsvGMK6ABG6SZs5GmoBKjabkZuaMtTMyozNQtvNom4UvWMl1f6Hae9WsDk1SfeXA=
X-Received: by 2002:a19:e511:: with SMTP id c17-v6mr17900483lfh.106.1521735522666; Thu, 22 Mar 2018 09:18:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.145.195 with HTTP; Thu, 22 Mar 2018 09:18:42 -0700 (PDT)
In-Reply-To: <15EBD5DA-382A-448C-945D-8C3B1ACFAA88@cisco.com>
References: <150833078446.12462.3050923622769989740.idtracker@ietfa.amsl.com> <CA+RyBmUnB6jaMMytXtiUZf98RnLG8f6LusmDdAXHYkb2y1AE5A@mail.gmail.com> <D0AA7372-C4D2-416B-AAA3-3A0229E639AB@cisco.com> <CA+RyBmV85xh_Et5VQVkyVN_eOEjSKiAmmaTHjVSDreOOcFpaWA@mail.gmail.com> <5F91613C-194E-4C0C-ABC0-2C27E9AFAB4B@cisco.com> <15EBD5DA-382A-448C-945D-8C3B1ACFAA88@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 22 Mar 2018 16:18:42 +0000
Message-ID: <CA+RyBmWz-oKXJuPTxDLyfRUXjAQ6OvT68MPaMRKXDMobbGDFGw@mail.gmail.com>
Subject: Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
Cc: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, "mpls@ietf.org" <mpls@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000454d18056802a93e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/MG3XN7-SiQXxwh1N6Z_0NANarkg>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Mar 2018 16:18:48 -0000

Hi Reshad,
your analysis of the text is absolutely correct. My concern is the possible
analysis of the Discriminator by ingress LER and it comparing to My
Discriminator of the received BFD control packets. According to the RFC
5884 both must match but because LSP Echo reply does not provide sufficient
information the most likely outcome will be - no matching BFD session found
and thus the text fails. (Yes, it would be rather naive implementation but
...). Thus I propose to add explicit statement for ingress LER not to use
information if received Discriminator TLV in Echo reply.

Regards,
Greg

On Thu, Mar 22, 2018 at 3:39 PM, Reshad Rahman (rrahman) <rrahman@cisco.com>
wrote:

> Hi,
>
>
>
> In the BFD meeting yesterday there was discussion about lack of clarity on
> what the spec says wrt to the discriminator TLV being sent by the egress
> node in the echo reply and that this causes interop issues. From RFC 5884:
>
>
>
> The egress LSR MAY respond with an LSP Ping Echo
>
>    reply message that carries the local discriminator assigned by it for
>
>    the BFD session.
>
>
>
> In the errata:
>
> The LSP Ping
>
> Echo reply message generated by the egress LSR MAY carry the local
>
> discriminator assigned by it for the BFD session, as specified in
>
> section 6.1.
>
> So I think it’s clear that this cannot be the discriminator of the ingress
> node. I agree that this information is useless but still don’t see how it
> can cause any harm, and any implementation which interprets the
> discriminator in the echo reply differently is buggy IMHO.
>
>
>
> Regards,
>
> Reshad (hat off).
>
>
>
> *From: *Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of "Reshad Rahman
> (rrahman)" <rrahman@cisco.com>
> *Date: *Tuesday, March 20, 2018 at 5:49 PM
> *To: *Greg Mirsky <gregimirsky@gmail.com>, "Carlos Pignataro (cpignata)" <
> cpignata@cisco.com>
>
> *Cc: *"mpls@ietf.org" <mpls@ietf.org>, "rtg-bfd@ietf.org" <
> rtg-bfd@ietf.org>
> *Subject: *Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd-
> bootstrap-clarify-00.txt
>
>
>
> Hi,
>
>
>
> While I agree that the echo reply is not needed to bootstrap BFD, and that
> the BFD Disc TLV is not needed in the reply, doing this doesn’t break
> anything. So I don’t see the proposed changes as being necessary.
>
>
>
> Does anyone remember why RFC5884  has the echo reply, was it to
> potentially save an echo request from egress for bidirectional case?
>
>
>
> Also, if we do go ahead with the proposed changes in this draft, we’ll
> have to fix this errata <https://www.rfc-editor.org/errata/eid5085>.
>
>
>
> Regards,
>
> Reshad (speaking as individual contributor).
>
>
>
> *From: *Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Greg Mirsky <
> gregimirsky@gmail.com>
> *Date: *Friday, October 20, 2017 at 4:19 PM
> *To: *"Carlos Pignataro (cpignata)" <cpignata@cisco.com>
> *Cc: *"mpls@ietf.org" <mpls@ietf.org>, "rtg-bfd@ietf.org" <
> rtg-bfd@ietf.org>
> *Subject: *Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd-
> bootstrap-clarify-00.txt
>
>
>
> Hi Carlos,
>
> thank you for taking interest in the proposal, much appreciated. Please
> find my notes in-line and tagged GIM>>.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Fri, Oct 20, 2017 at 5:54 AM, Carlos Pignataro (cpignata) <
> cpignata@cisco.com> wrote:
>
> Greg,
>
>
>
> This document seems to say “use “Do not Reply” reply mode, and even if you
> reply do not use the BFD Disc TLV, because it is not used.
>
> GIM>> To be precise it says "SHOULD use "Do not Reply" thus preserving
> compliance of implementations that do otherwise.
>
>
>
> Wouldn’t it be simpler to say “follow RFC 8029, and the ingress does not
> care about the BFD Disc TLV in the reply”? This would not suddenly make
> uncompliant existing implementations, potentially.
>
> GIM>> I agree that normative language on handling echo reply is bit
> restrictive. My goal is to have good discussion and see what others think.
>
>
>
> Also I wonder if this should be bfd-mpls instead of mpls-bfd, given where
> RFC 5884 was advanced.
>
> GIM>> Probably it should be the way you've suggested. Hope it is not a big
> problem for individual draft.
>
>
>
> Thanks,
>
>
>
> —
> Carlos Pignataro, carlos@cisco.com
>
> *“Sometimes I use big words that I do not fully understand, to make myself
> sound more photosynthesis."*
>
>
>
> On Oct 18, 2017, at 8:50 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:
>
>
>
> Dear All,
>
> this new document proposes clarification of two questions brought up in
> course of recent discussion of RFC 5884:
>
>    - use of Return mode values in bootstrapping BFD session echo request;
>    - inclusion of BFD Discriminator TLV in echo response to the
>    bootstrapping echo request.
>
> Your comments, questions are always welcome and greatly appreciated.
>
>
>
> Regards,
>
> Greg
>
>
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> Date: Wed, Oct 18, 2017 at 5:46 AM
> Subject: New Version Notification for draft-mirsky-mpls-bfd-
> bootstrap-clarify-00.txt
> To: Gregory Mirsky <gregimirsky@gmail.com>, Yanhua Zhao <
> zhao.yanhua3@zte.com.cn>
>
>
>
> A new version of I-D, draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt
> has been successfully submitted by Greg Mirsky and posted to the
> IETF repository.
>
> Name:           draft-mirsky-mpls-bfd-bootstrap-clarify
> Revision:       00
> Title:          Clarifying Use of LSP Ping to Bootstrap BFD over MPLS LSP
> Document date:  2017-10-18
> Group:          Individual Submission
> Pages:          4
> URL:            https://www.ietf.org/internet-
> drafts/draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-mirsky-mpls-bfd-
> bootstrap-clarify/
> Htmlized:       https://tools.ietf.org/html/draft-mirsky-mpls-bfd-
> bootstrap-clarify-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-mirsky-mpls-
> bfd-bootstrap-clarify-00
>
>
> Abstract:
>    This document, if approved, updates RFC 5884 by clarifying procedures
>    for using MPLS LSP ping to bootstrap Bidirectional Forwarding
>    Detection (BFD) over MPLS Label Switch Path.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>
>
>
>