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

Greg Mirsky <gregimirsky@gmail.com> Wed, 10 May 2017 21:23 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 5228B12969E; Wed, 10 May 2017 14:23:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, 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 Yllkkmvxjcs6; Wed, 10 May 2017 14:23:49 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 3CD80128616; Wed, 10 May 2017 14:23:49 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id h4so9668819oib.3; Wed, 10 May 2017 14:23:49 -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=XmLmZFClzQl4W5En6nXjPzagHeKL0YyYwY/lRSR2smM=; b=DXpuEcSS0evaG1oIdEzzT2DsqoPkzukQuW5Kj2g+ClitogZZ0WL/SmuxofSC01g12B e9hbDaxqDiqTaTp6yrP3HstY7K5cYoJUTHSvwf1A4o3PiblnNNTIZubbgKrOTkLaJiQh Kd8fxs4FZ33K0S/3GRvqjubuFjzH4i7yHEcOnrnnlqCStaDK4PbqEBRDYpluQah/DLt+ L8WNXiIAKZdXAEXkCCRO/LDjHwYIBzW+EgasQwvkbKWe7vaViuO/fikUcaL7dT3zwvJC R3JaOnfPp0x6yl3rqWbHDBT+9OSqd+ZYGeg4RKK0Nz4L2UO2XY1iUoVMKarRMXmL+QKK JvNg==
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=XmLmZFClzQl4W5En6nXjPzagHeKL0YyYwY/lRSR2smM=; b=iXB5HrCN9cYIjGA915j0Ck1U5QPyCWRTmV2zsnTLTrQ7JYopFVmg0/RjMdiIpM3ujV iLwAInu8CMgn69cmfRh7OKaAvRqWzeDLs0c9teHBAgfzATXLaUTwOtN0QbtGo76LC1cN 4qeA08/MUOFjAgj97oyqzQs8guXeA9s2k7LGOnUAwzkUiaWkJ3PP/EAowfNIG//4cLea zp6Q+hyJ8UkTKfZ3hlGWc8jh+a1DYAu41Oba6XTVG3r0ggB8n2/gh4Zg/5iD80Z6J7kb KDalOM7hmOLNzNKAsSHRpVpq95+iZMECy5YxSmODg7K3WlUTZFZEI6H1oAH8qN5ZEefB c7wg==
X-Gm-Message-State: AODbwcAYWur589ELpMPazCuIdW44fONZ7qszcvOAUK9e/VUZx9wRhrOK wLxdvLEqOm9rwkygwx66GY5rx/WmEw==
X-Received: by 10.157.47.70 with SMTP id h64mr3909430otb.23.1494451428547; Wed, 10 May 2017 14:23:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.52.246 with HTTP; Wed, 10 May 2017 14:23:48 -0700 (PDT)
In-Reply-To: <F1E0BFDF-7072-4B26-96BC-4F47FE8FEDCB@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> <CA+RyBmX6GEDhD-A-DkLdABepOzeEqFB4DEKh+JKYyhz27O8J=A@mail.gmail.com> <9D886964-6C21-427C-8733-7731D5A996D3@cisco.com> <CA+b+ER=Bb2v6u9KtK7HpkHb1shS8WOWHBmJk5su0BU1PrJUiMg@mail.gmail.com> <CA+b+ERm6Q-s1umcPa-WkPpBJw+arMpPp29=5_qZvu=yCpgZfPQ@mail.gmail.com> <F1E0BFDF-7072-4B26-96BC-4F47FE8FEDCB@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 10 May 2017 14:23:48 -0700
Message-ID: <CA+RyBmWAoB-zizPASdtRH=JdQ3yKC-Spr=H8oLzX3V1a2Ek7Cg@mail.gmail.com>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Cc: Robert Raszuk <robert@raszuk.net>, "mpls@ietf.org" <mpls@ietf.org>, "spring@ietf.org" <spring@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Content-Type: multipart/alternative; boundary=94eb2c04713888651a054f32160f
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/dFCLu19ipSymPY_64nTwRwtCiQ8>
Subject: Re: [mpls] New Version Notification for draft-mirsky-spring-bfd-00.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 10 May 2017 21:23:51 -0000

Hi Carlos,
RFC 7110 defined sub-TLVs by extensively re-using TFS sub-TLVs. Even more,
they've referenced explanations of fields to the TFS-defining RFCs. I guess
only Flags field was introduced in RFC 7110 with Primary and Secondary bit
flag fields being defined.

As, I've said in the discussion on BFD directed, this is proposal, it make
sense to me as the head-end has all the information already. I always
welcome technical comments and appreciate well-argumented discussion. What
would be the reason not to use the proposed approach but do it TFS-like
style?

Regards,
Greg

On Wed, May 10, 2017 at 1:01 PM, Carlos Pignataro (cpignata) <
cpignata@cisco.com>; wrote:

> You are right — sorry about that! “TFS” is not used in any of those RFCs
> or drafts, although it is used on email discussions about LSP Ping.
>
> Indeed, TFS for “Target FEC Stack” from Section 3.2 of RFC 8029.
>
> Thanks,
>
> — Carlos.
>
> On May 10, 2017, at 3:41 PM, Robert Raszuk <robert@raszuk.net>; wrote:
>
>
> Never mind .. I guess you made it up from "Target FEC Stack" :)
>
>
>
> On Wed, May 10, 2017 at 9:40 PM, Robert Raszuk <robert@raszuk.net>; wrote:
>
>> Hi Carlos,
>>
>> Sorry what is "TFS" ?
>>
>> RFC 7110 does not even use such abbreviation neither do
>> draft-ietf-mpls-bfd-directed :) Google also seems to be pretty clueless
>> about it.
>>
>> Just curious as you keep using this term in each email :)
>>
>> Thx,
>> R.
>>
>> On Wed, May 10, 2017 at 9:24 PM, Carlos Pignataro (cpignata) <
>> cpignata@cisco.com>; wrote:
>>
>>> Greg,
>>>
>>> In the MPLS data plane, FECs are also instantiated through a label
>>> stack. But RFC 7110 does not use numeric label values, it uses TFSs. That
>>> does not create any additional state. E.g.,: https://www.ietf.org/ma
>>> il-archive/web/mpls/current/msg16091.html
>>>
>>> Thanks,
>>>
>>> — Carlos.
>>>
>>>
>>>
>>> On May 9, 2017, at 3:43 PM, Greg Mirsky <gregimirsky@gmail.com>; wrote:
>>>
>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>