Re: [mpls] I-D Action: draft-smack-mpls-rfc4379bis-02.txt

Loa Andersson <loa@pi.nu> Mon, 28 September 2015 07:39 UTC

Return-Path: <loa@pi.nu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823A21A9244 for <mpls@ietfa.amsl.com>; Mon, 28 Sep 2015 00:39:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.318
X-Spam-Level:
X-Spam-Status: No, score=-0.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 rb6XUfs7eO40 for <mpls@ietfa.amsl.com>; Mon, 28 Sep 2015 00:39:34 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C692B1A888B for <mpls@ietf.org>; Mon, 28 Sep 2015 00:39:33 -0700 (PDT)
Received: from [192.168.1.10] (unknown [49.149.184.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 59AE318013BE; Mon, 28 Sep 2015 09:39:29 +0200 (CEST)
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
References: <20150926205215.13666.17143.idtracker@ietfa.amsl.com> <DB3PR03MB0780A8DC1B838F19F1C8056C9D400@DB3PR03MB0780.eurprd03.prod.outlook.com> <912ED43A-A93F-4508-A6A6-9D79D437A20B@cisco.com>
From: Loa Andersson <loa@pi.nu>
Message-ID: <5608BB41.2050805@pi.nu>
Date: Mon, 28 Sep 2015 12:00:01 +0800
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <912ED43A-A93F-4508-A6A6-9D79D437A20B@cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/XVWQDjpSepgmSfJNbCzw66HIR-I>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "Nagendra Kumar Nainar (naikumar)" <naikumar@cisco.com>
Subject: Re: [mpls] I-D Action: draft-smack-mpls-rfc4379bis-02.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 28 Sep 2015 07:39:36 -0000

Carlos,

On 2015-09-28 05:58, Carlos Pignataro (cpignata) wrote:
> Hi Sasha,
>
> Thanks for asking!
>
> If you don't mind, let me start with some context: the idea of 4379bis has been there for some time, but the catalysts for this work was a comment made by an AD (I believe it was Alia) in a Rtg-chairs (or Rtg-Dir) meeting in Prague: to push (WGs to push) specs up maturity levels as it made sense.
>
> With that context, we are diving this work in a few steps:
> 1. Get the source from the Rfc Editor, convert it to XML, clean up glitches. This will give us a baseline to work from.
> 2. Integrate errata and similar fixes, in chunks (make it new revision addressing one specific item or area)
> 3. Discuss which RFCs updating 4379 make sense to integrate in (trying to maximize the RFCs integrated into the bus)
>
> We are now in between 1 and 2. Ready to start engaging the WG more actively and with a goal of something for Japan.
>
> Loa,
>
> Thinking about this, it would make sense to get this under the pen of the WG earlier rather than later -- when should this be called for adoption?

Agree that we need to do this "early", which is probably after Yokohama.

/Loa
>
> Sasha,
>
> Please find more thoughts inline.
>
> Thumb typed by Carlos Pignataro.
> Excuze typofraphicak errows
>
>> On Sep 27, 2015, at 02:12, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:
>>
>> Hi all,
>> I have a comment regarding draft-smack-mpls-rfc4379bis-02.
>>
>> According to the draft, its purpose is "take LSP Ping to an Internet  Standard". As part of this work the authors address all the outstanding Errata to the original RFC 4379, and update the references.
>>
>> I fully agree with the goal that the authors have set to themselves.
>
> Thanks! Although to be fair, chairs drove setting that goal for the WG.
>
>>
>> However, I have noticed that there is quite a long list of RFCs  that update RFC 4379, and it would be nice to understand whether these updates have been incorporated or not.
>>
>
> Well, they have not been incorporated now, because we are at the point of mirroring 4379 + errata.
>
> The plan is for the WG to discuss which ones make sense to incorporate.
>
>> Specifically:
>> 1.  RFC 6424 states that it "deprecates the Downstream Mapping TLV in favor of a new TLV".
>> 2. RFC 6426 extends applicability of LSP Ping to MPLS-TP thus introducing new  address types and new TLVs
>> 3. RFC 6289  extends LSP Ping to PWs signaled with LDP sessions running on top of IPv6 and introduces new sub-TLVs
>> 4. RFC  7506 clarifies the use of IPv6 Router Alert option for LSP Ping.
>> 5. RFC  7537 has introduced new IANA  registries for various aspects of LSP Ping.
>>
>
> Let me answer with a question: what do you think? Which ones should be incorporated?
>
> I have my views (as many as possible as it makes sense), but we should discuss this openly as a WG.
>
>> Neither of these RFCs is mentioned anywhere in draft-smack-mpls-rfc4379bis-02.
>>
>
> Right. We are not there. We would not incorporate these without having the WG discussion first, which you initiated on our behalf. So, which ones should the final work mention?
>
>> Does this mean that if/when the draft is published as an RFC, all the  documents  updating RFC 4379 would equally update a new RFC?
>>
>
> Of course not. It means this doc is not ready to be published as an RFC.
>
>> And what would happen to all the TLVs, sub-TLVs and procedures that are defined in these documents?
>>
>> I honestly do not know what is the right way to proceed here, but I think that silence is definitely not the best way to address the problem.
>
> Sasha,
>
> Let's walk before we run, let's crawl before we walk...
>
> As I mentioned (in this email and in a separate note to the WG), we are now getting a baseline to be able to have that discussion.
>
> It would be much messier to talk "on the air" without a document to capture the outcome of the discussion on.
>
> Do you suggest we break silence and have a discussion on the list, without a document to update?
>
> I think you can understand the timing chosen. And of course we more than welcome your help and contributions and hear your suggestions if there is a better approach.
>
> Carlos.
>
>>
>> My 2c,
>> Sasha
>> ________________________________________
>> From: I-D-Announce <i-d-announce-bounces@ietf.org> on behalf of internet-drafts@ietf.org <internet-drafts@ietf.org>
>> Sent: Saturday, September 26, 2015 11:52 PM
>> To: i-d-announce@ietf.org
>> Subject: I-D Action: draft-smack-mpls-rfc4379bis-02.txt
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>>
>>         Title           : Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
>>         Authors         : Carlos Pignataro
>>                           Nagendra Kumar
>>                           Sam Aldrin
>>                           Mach(Guoyi) Chen
>>         Filename        : draft-smack-mpls-rfc4379bis-02.txt
>>         Pages           : 49
>>         Date            : 2015-09-26
>>
>> Abstract:
>>    This document describes a simple and efficient mechanism that can be
>>    used to detect data plane failures in Multi-Protocol Label Switching
>>    (MPLS) Label Switched Paths (LSPs).  There are two parts to this
>>    document: information carried in an MPLS "echo request" and "echo
>>    reply" for the purposes of fault detection and isolation, and
>>    mechanisms for reliably sending the echo reply.
>>
>>    This document obsoletes RFC 4379.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-smack-mpls-rfc4379bis/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-smack-mpls-rfc4379bis-02
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-smack-mpls-rfc4379bis-02
>>
>>
>> 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.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>