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

Alvaro Retana <aretana.ietf@gmail.com> Thu, 14 March 2019 03:30 UTC

Return-Path: <aretana.ietf@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 29472131262; Wed, 13 Mar 2019 20:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.737
X-Spam-Level:
X-Spam-Status: No, score=-1.737 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 vaqWBCLws3Ea; Wed, 13 Mar 2019 20:30:51 -0700 (PDT)
Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 251A113125A; Wed, 13 Mar 2019 20:30:50 -0700 (PDT)
Received: by mail-ot1-x32c.google.com with SMTP id g1so3813656otj.11; Wed, 13 Mar 2019 20:30:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=Fi0DmkwWCW1sJgQHC8FBA/3aX2nVSp1sTSvqq0Hs40Y=; b=IV/vXuh6QNbP8l95AJcWvFYqFf+mb4Og3vD/4okEPr8vc6tuLarZwtWdzqPiFmWtXG jVGT5c3AQ/8x65QcZI4v6gKPXuce/93NCRyZsUhAGFRV05PUpaeKEOkIKOi8A5kMyxHw CEi9dyKlXsUKD9qIGhK4hlaW94zSc2OO97lrpbw7tLkA6PvPGEe+Jy26OiH6FrAERLTE pmKThl+9W+HP9WB/t2kr8sSVG1cf1h50EfLgQm2lbkyIYjlBquwqAXd2m2TZvVdPTpIQ V8XRBhpeX8loBxa2Xju1jKUJrLjlnm9uTr+K+xdJXHKUmP1sqYcLqkEN1oXU1uyHDOoK 4wUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=Fi0DmkwWCW1sJgQHC8FBA/3aX2nVSp1sTSvqq0Hs40Y=; b=syp3/UGTdxJ9ynTjb4T4Kl8UksTeJxotpfGmv6NAmym4/4h/Sd04nGrNtQnaoRnRyP avjJkEYJJddnAFregSQSF5yJUXC4BcNaG3jRxsqAop6+QfbDAjZ1qEqqDCJgeyOamj3R g4Mda0iFX8JwSH3sv2mvtCzTVIGjRi/HxaF7zLkv3zmGv9N0pjH6IGwxeHS5+7ngHISx J+AJc+ZLKoBslIIMh7WhmyqTz79MKWQ6G7VWpxddy87Pvy0D61lDRq4y/0okqhUfBSBv Th4y/pYwjOFEMoEqQeXd1tAAT+qErYPPZ+SYO1cA86Gfjfc1so3I/7tWOxacsAjgLj8H wNfQ==
X-Gm-Message-State: APjAAAWqh14B3Imr09Nx+559uAE5MJlv+i9SOZ70vLzNusI2Ft51khZ5 9MeG78EIRYFr2kNOOcSP9qfB/kLTLtAf5O65ZNWF5Q==
X-Google-Smtp-Source: APXvYqwgCYCKwtJV2OnTvkxGCMjIEzKHDj7bZDdtgcMP3zTBVRyLNtRzSr8iBBrFtS1ptokGPbD9vuCKHs5YJW2xi1A=
X-Received: by 2002:a05:6830:1388:: with SMTP id d8mr30886738otq.44.1552534248077; Wed, 13 Mar 2019 20:30:48 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 13 Mar 2019 23:30:42 -0400
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2928FABB2@dggeml510-mbx.china.huawei.com>
References: <155208210011.3264.12148702952456660789.idtracker@ietfa.amsl.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2928FABB2@dggeml510-mbx.china.huawei.com>
MIME-Version: 1.0
Date: Wed, 13 Mar 2019 23:30:42 -0400
Message-ID: <CAMMESswBNuY2y6dQsdy=zL6k8kpYG3CJ4N5oEwtZgBTAnLpTDg@mail.gmail.com>
To: 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>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" <draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005bc11f0584058c39"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/Iuj1puipAanjkjICX0Drc-fUb-8>
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 03:30:53 -0000

On March 13, 2019 at 10:14:42 AM, Mach Chen (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.


...

> (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.