Return-Path: 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 In-Reply-To: References: <155208210011.3264.12148702952456660789.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Date: Wed, 13 Mar 2019 23:30:42 -0400 Message-ID: To: Alvaro Retana via Datatracker , The IESG , Mach Chen Cc: "mpls@ietf.org" , "mpls-chairs@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005bc11f0584058c39" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 03:30:53 -0000 --0000000000005bc11f0584058c39 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On March 13, 2019 at 10:14:42 AM, Mach Chen (mach.chen@huawei.com) wrote: Mach: Hi! ... > (2) =C2=A76: "Otherwise, if the responder does not know the LSR Capabilit= y 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 =C2=A73 and =C2=A73.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=E2=80=A6= . 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 =C2=A74.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 (=C2=A73), but the request about the LAG may not be answered. I= t seems to me that the initiator could simply retry=E2=80=A6maybe after some = retries the log/notification can be raised. Just thinking out loud=E2=80=A6 Either= way is fine with me... Thanks! Alvaro. --0000000000005bc11f0584058c39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On March 13, 2019 at 10:14:42 AM, Mach Chen (mach.chen@huawei.com) wrote:
=

Mach:

Hi!

...
> (2) =C2=A76: "Otherwise, if t= he responder does not know the LSR Capability TLV, an=C2=A0
> MPLS echo reply with the return code set to "O= ne or more of the TLVs was=C2=A0
> not understood" MUST be sent back to the initiator LSR.&quo= t; Given that this is=C2=A0> the case where the new TLV is not known, then we can't Normativel= y direct=C2=A0
> those n= odes to do anything (since they probably don't implement anything in=C2=A0
> this document). s/= MUST/must + add a reference to rfc8029 (where the=C2=A0
> behavior is=C2=A0
> specified) [The same text appears again in = =C2=A73 and =C2=A73.2. Writing the=C2= =A0
> specification is one place is enough.]=C2=A0

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 i= t, as specified in RFC8029.=C2=A0

Maybe we could just remove the &q= uot;optional", and make it clear to the IANA section, the code point o= f this TLV should be allocated from the Mandatory range. How do you think?<= span class=3D"Apple-converted-space">=C2=A0

I think that optional should explicitly be replaced with ma= ndatory=E2=80=A6. And, the IANA section should be clarified to indicate the= range.


...

> (3) This document doesn't talk abou= t what should be done if a response is=C2=A0
> not received, at any point in the process. I searche= d in rfc8029, but didn't=C2=A0
> find anything related to timeouts...only =C2=A74.8 (Non-compli= ant Routers), which=C2=A0
&= gt; includes a process on what to do if a reply is not received. That proce= ss=C2=A0
> doesn't s= eem to apply to this document -- what should an initiator do if a=C2=A0
> reply is not received? I = am specially interested in the discovery phases.=C2=A0

Normally, the timeout process is left the i= mplementation (e.g., through timers).= =C2=A0

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.= =C2=A0

Ok..so a log/notifica= tion of some kind should be raised. =C2=A0

During the discovery proce= ss, it looks like some things could be specified without operator intervent= ion.=C2=A0 For example, the capabilities may be discovered (=C2=A73), but t= he request about the LAG may not be answered.=C2=A0 It seems to me that the= initiator could simply retry=E2=80=A6maybe after some retries the log/noti= fication can be raised.=C2=A0 Just thinking out loud=E2=80=A6 Either way is= fine with me...

Thanks!=C2=A0

Alvaro.

--0000000000005bc11f0584058c39--