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

Greg Mirsky <gregimirsky@gmail.com> Tue, 09 May 2017 19:43 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 25C1A1295A0; Tue, 9 May 2017 12:43:58 -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 ye9bWEJv03xO; Tue, 9 May 2017 12:43:55 -0700 (PDT)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 9C79D129477; Tue, 9 May 2017 12:43:55 -0700 (PDT)
Received: by mail-oi0-x22d.google.com with SMTP id l18so12511189oig.2; Tue, 09 May 2017 12:43:55 -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=HfyriXuk6qw3zG8RgGrsFjfIh4fDS3nL7fTX9iZc1Sw=; b=X+Syb4gHHVzNyfs4UZWIX7jx0oajICpwjq80hQHnIAsQcaEtLIy7p1L8bffnv3OqTO xfgwIGIS6rBtNRVlw/+vcVfmYNWPuaYqzgy6nnsoGjEcYunPhVkZCIDx8CEblpGuaN4G IZd4n4k0h8EMhKG9DBBjfgG7s2E/PgHHjicWvvib6suUrJ2w7t+/OnyhAs62OSniFjzv MriMpqdu2f/WHRT2cizbEWyUrqabiv5kbheTWmSCYeuwqRxb5c7eTHMJMh9YoGlKIJ8B A2VxKn3TtIlb00pvJA6ZLuXAzItODp45/CBMSMjLRyYU+w/LVNLXwnPprlRMFrNHx2Pc KDsg==
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=HfyriXuk6qw3zG8RgGrsFjfIh4fDS3nL7fTX9iZc1Sw=; b=lotx8monuhdUj0vmICRQjW0r3Lufrzc3da1K5+i+2rE0soohl1PEVerHZ4iIOk9Aol wkRSCQ0QoUf64ZrS9rn+ilp+hxjPE28MPKQq3yajtzXi/OF+ehnpmzuBefsGFcZYCwxZ Act+pfPGKBhXQQkEUHI5BvYSL9FPqpS1lq4PaLrUwPZkOiLaRoSVzrprMDCRaXucoaV4 BPa/djTlVhhwrMwXh4NbQZU85FZxnOC1k8E7cKqkxE7kmtv4gTQmnBBNkNH/K+DzmsIE gkexet8nrGieAfNQyr6treX9NQnFE8jmSwPSq9fYqKp78GMBDj504D+rqZ6GQOOnYK95 /Flw==
X-Gm-Message-State: AODbwcAhctKVefbI4VxF/050WzLeAdX/1Sa9F3JqT2lM2oYnor4OlNT0 y93gxtF9NmAhGgzTDgyeKqjiI9f98g==
X-Received: by 10.202.198.208 with SMTP id w199mr708191oif.115.1494359034868; Tue, 09 May 2017 12:43:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.52.246 with HTTP; Tue, 9 May 2017 12:43:54 -0700 (PDT)
In-Reply-To: <F3C093E0-FE4E-41C0-B9EB-0CA1CB52DBE7@cisco.com>
References: <149430058880.24107.8628199428997673992.idtracker@ietfa.amsl.com> <CA+RyBmVA3G8eucX2Q0=bHGdr+awmiXAd44BOMkdOmTQkeA6aYQ@mail.gmail.com> <1C12E162-6B5C-4EF2-A3CB-3621C72BCFE9@cisco.com> <CA+RyBmXgfmL7+Bx-KxFcm=3tTtsCALmRhrhyX=uqF8kuDFw2nw@mail.gmail.com> <F3C093E0-FE4E-41C0-B9EB-0CA1CB52DBE7@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 09 May 2017 12:43:54 -0700
Message-ID: <CA+RyBmX6GEDhD-A-DkLdABepOzeEqFB4DEKh+JKYyhz27O8J=A@mail.gmail.com>
Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Cc: "spring@ietf.org" <spring@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="001a1134fbb470c137054f1c9329"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/dM5Tygm-Yr0JZhad6cYVYK_mjJ4>
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: Tue, 09 May 2017 19:43:58 -0000

Hi Carlos,
I probably would characterize anything that starts with Why not as a
technical comment but rather as a question.
According to draft-ietf-spring-segment-routing-mpls, "In the MPLS dataplane,the
SR header is instantiated through a label stack".
At the same time, one of advantages of SR is that "per-flow state only
[maintained] at the ingress node to the SR domain".
Thus, for the case of monitoring unidirectional SR tunnels, I consider that
there's no need to create any additional state on the egress node.
Of course, if there were bidirectional SR tunnels, then control of the
reverse direction of the BFD session would not require use of the Return
Path sub-TLV.
As for LSP-Ping, I just propose that the Segment Routing MPLS Tunnel
sub-TLV MAY be used Reply Path TLV defined in RFC 7110. I viewed the
proposal as invitation to technical discussion.

Regards,
Greg

On Tue, May 9, 2017 at 9:07 AM, Carlos Pignataro (cpignata) <
cpignata@cisco.com> wrote:

> Thank you Greg!
>
> Since https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 seems quite
> similar to the text removed at https://tools.ietf.org/
> rfcdiff?url2=draft-ietf-mpls-bfd-directed-05.txt, then the complete set
> of outstanding technical comments that triggered the removal of that text
> from draft-ietf-mpls-bfd-directed-05.txt might peek your interest :-)
>
> One that I recall is: why use label values when every other return-path
> sub-TLV for BFD and for LSP-Ping, including draft-ietf-mpls-bfd-directed,
> uses TFSs?
>
> Best,
>
> — Carlos.
>
> On May 9, 2017, at 12:00 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Dear Carlos,
> I've decided to re-start the discussion and am interested to hear
> technical comments to the proposed solution.
>
> Regards,
> Greg
>
> On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro (cpignata) <
> cpignata@cisco.com> wrote:
>
>> Dear Greg,
>>
>> Cursorily scanning through this, it seems that most concerns raised and
>> comments made about the SR sections of draft-ietf-mpls-bfd-directed-0N
>> (with N < 5) apply to your new draft.
>>
>> This is one of those: https://www.ietf.org/ma
>> il-archive/web/mpls/current/msg15860.html — the list archive shows a few
>> more. The copy/paste did not address the comments.
>>
>> Best,
>>
>> — Carlos.
>>
>> On May 8, 2017, at 11:33 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
>>
>> Dear All,
>> perhaps this new draft may is of interest to you.
>> Your comments, suggestions are most welcome and greatly appreciated.
>>
>> Regards,
>> Greg
>>
>> ---------- Forwarded message ----------
>> From: <internet-drafts@ietf.org>
>> Date: Mon, May 8, 2017 at 8:29 PM
>> Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt
>> To: Gregory Mirsky <gregimirsky@gmail.com>
>>
>>
>>
>> A new version of I-D, draft-mirsky-spring-bfd-00.txt
>> has been successfully submitted by Greg Mirsky and posted to the
>> IETF repository.
>>
>> Name:           draft-mirsky-spring-bfd
>> Revision:       00
>> Title:          Bidirectional Forwarding Detection (BFD) in Segment
>> Routing Networks Using MPLS Dataplane
>> Document date:  2017-05-08
>> Group:          Individual Submission
>> Pages:          7
>> URL:            https://www.ietf.org/internet-
>> drafts/draft-mirsky-spring-bfd-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/
>> Htmlized:       https://tools.ietf.org/html/draft-mirsky-spring-bfd-00
>> Htmlized:       https://datatracker.ietf.org/
>> doc/html/draft-mirsky-spring-bfd-00
>>
>>
>> Abstract:
>>    Segment Routing architecture leverages the paradigm of source
>>    routing.  It can be realized in the Multiprotocol Label Switching
>>    (MPLS) network without any change to the data plane.  A segment is
>>    encoded as an MPLS label and an ordered list of segments is encoded
>>    as a stack of labels.  Bidirectional Forwarding Detection (BFD) is
>>    expected to monitor any kind of paths between systems.  This document
>>    defines how to use Label Switched Path Ping to bootstrap and control
>>    path in reverse direction of a BFD session on the Segment Routing
>>    network over MPLS dataplane.
>>
>>
>>
>>
>> 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
>>
>>
>>
>
>