Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT)

Loa Andersson <loa@pi.nu> Thu, 14 March 2019 05:38 UTC

Return-Path: <loa@pi.nu>
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 8F8BF127994; Wed, 13 Mar 2019 22:38:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 U0k_uLcElZt6; Wed, 13 Mar 2019 22:38:20 -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 6044B12705F; Wed, 13 Mar 2019 22:38:20 -0700 (PDT)
Received: from [192.168.1.20] (unknown [119.94.169.156]) (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 48F351801556; Thu, 14 Mar 2019 06:38:16 +0100 (CET)
To: Alvaro Retana <aretana.ietf@gmail.com>, Alvaro Retana via Datatracker <noreply@ietf.org>, The IESG <iesg@ietf.org>, Mach Chen <mach.chen@huawei.com>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" <draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>
References: <155208210011.3264.12148702952456660789.idtracker@ietfa.amsl.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2928FABB2@dggeml510-mbx.china.huawei.com> <CAMMESswBNuY2y6dQsdy=zL6k8kpYG3CJ4N5oEwtZgBTAnLpTDg@mail.gmail.com>
From: Loa Andersson <loa@pi.nu>
Message-ID: <9ede1e5e-319a-7b39-4700-202139fce4d6@pi.nu>
Date: Thu, 14 Mar 2019 13:38:10 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <CAMMESswBNuY2y6dQsdy=zL6k8kpYG3CJ4N5oEwtZgBTAnLpTDg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/i1M4ePb2neEC8Mu91m-mL0ZDJEQ>
Subject: Re: [mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT)
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: Thu, 14 Mar 2019 05:38:24 -0000

Alvaro,

On 2019-03-14 11:30, Alvaro Retana wrote:
> On March 13, 2019 at 10:14:42 AM, Mach Chen (mach.chen@huawei.com 
> <mailto:mach.chen@huawei.com>) wrote:
> 
> Mach:
> 
> Hi!
> 
> ...
>> > (2) §6: "Otherwise, if the responder does not know the LSR Capability TLV, an 
>> > MPLS echo reply with the return code set to "One or more of the TLVs was
>> > not understood" MUST be sent back to the initiator LSR." Given that this is
>> > the case where the new TLV is not known, then we can't Normatively direct
>> > those nodes to do anything (since they probably don't implement anything in
>> > this document). s/MUST/must + add a reference to rfc8029 (where the
>> > behavior is
>> > specified) [The same text appears again in §3 and §3.2. Writing the
>> > specification is one place is enough.]
>>
>> It's more accurate to call it a "Mandatory" TLV that does not require 
>> an implementation has to implement it, but will result in return code 
>> when a node does not support it, as specified in RFC8029.

>> Maybe we could just remove the "optional", and make it clear to the 
>> IANA section, the code point of this TLV should be allocated from the 
>> Mandatory range. How do you think?
> 
> I think that optional should explicitly be replaced with mandatory…. 
> And, the IANA section should be clarified to indicate the range.
> 
> 

No, I think this is wrong - the code point will be allocated from the
range 0-16383 where code points are allocated by "Standards Action".
This range is for mandatory TLVs or for optional TLVs that require an 
error message if not recognized.

The difference between the two ranges is not that one is for "mandatory"
TLVs and the for optional, but one is for TLVs that need a response if
not recognized, the other can be silently dropped.

The TLV we are discussing is optional.

I have for a long time been aware of the there are some glitches in the
description of the LSP Ping registries, and I'm preparing a draft to
address this.

/Loa




> ...
> 
>> > (3) This document doesn't talk about what should be done if a response is
>> > not received, at any point in the process. I searched in rfc8029, but didn't
>> > find anything related to timeouts...only §4.8 (Non-compliant Routers), which
>> > includes a process on what to do if a reply is not received. That process
>> > doesn't seem to apply to this document -- what should an initiator do if a
>> > reply is not received? I am specially interested in the discovery phases.
>>
>> Normally, the timeout process is left the implementation (e.g., 
>> through timers).
>>
>> If a reply cannot be received within a certain period, the initiator 
>> will return timeout. That means there some issues along the path, 
>> operator should intervene then.
> 
> Ok..so a log/notification of some kind should be raised.
> 
> During the discovery process, it looks like some things could be 
> specified without operator intervention.  For example, the capabilities 
> may be discovered (§3), but the request about the LAG may not be 
> answered.  It seems to me that the initiator could simply retry…maybe 
> after some retries the log/notification can be raised.  Just thinking 
> out loud… Either way is fine with me...
> 
> Thanks!
> 
> Alvaro.
> 
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> 

-- 


Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64