[mpls] George can yu look at this - Re: end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01

Loa Andersson <loa@pi.nu> Thu, 23 April 2015 12:59 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 68E061ACD13 for <mpls@ietfa.amsl.com>; Thu, 23 Apr 2015 05:59:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level:
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, 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 pV1uemM32Fi0 for <mpls@ietfa.amsl.com>; Thu, 23 Apr 2015 05:59:21 -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 2E7C61A92F4 for <mpls@ietf.org>; Thu, 23 Apr 2015 05:59:07 -0700 (PDT)
Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (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 A437C1801127; Thu, 23 Apr 2015 14:59:05 +0200 (CEST)
Message-ID: <5538EC97.8050204@pi.nu>
Date: Thu, 23 Apr 2015 14:59:03 +0200
From: Loa Andersson <loa@pi.nu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "t.petch" <ietfc@btconnect.com>, Nobo Akiya <nobo.akiya.dev@gmail.com>
References: <BY1PR0501MB14303A3E86F750CF628B7234A50E0@BY1PR0501MB1430.namprd05.prod.outlook.com> <BY1PR0501MB143031F1768A8854BA4CB30EA5E70@BY1PR0501MB1430.namprd05.prod.outlook.com> <CAFqGwGuKaR-pRiCS9hnzD0mGmY1dRWd2LANgaBf4MJdT+MYRpQ@mail.gmail.com> <001901d0786b$0c1ceb40$4001a8c0@gateway.2wire.net> <CAFqGwGsq2hZOnQWpzZuwvqAnGvNdmkE3bUkxk6LS9NZ6VOf10Q@mail.gmail.com> <00f701d07a80$44770e00$4001a8c0@gateway.2wire.net> <CAFqGwGuxK85W3anJ6omabHw+16HhUtSdw_yrsdt-weS1Z-abNw@mail.gmail.com> <55379EE5.8000801@pi.nu> <033c01d07db5$0ecb4720$4001a8c0@gateway.2wire.net>
In-Reply-To: <033c01d07db5$0ecb4720$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/Njn4kGqoX_Ne6D9U1PT-ZdrtUk8>
Cc: Ross Callon <rcallon@juniper.net>, mpls <mpls@ietf.org>, mpls-chairs@tools.ietf.org, draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org
Subject: [mpls] George can yu look at this - Re: end of WGLC, RE: working group last call for draft-ietf-mpls-lsp-ping-reply-mode-simple-01
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: <http://www.ietf.org/mail-archive/web/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, 23 Apr 2015 12:59:23 -0000

Tom,

The question you and Adrian asks is what to do if the Reply Mode
Order TLV is missing.

There is something fishy here, I'd like George to look at this.

The LSP Ping design says that TLVs from this range may be silentsly
dropped, my take is that we don't need to specify anything more
than that.

Now, we say that it MUST be present, and after thinking around a bit
I wonder if the TLV should be assigned from the mandatory range instead?

Or if the MUST be present means that the message will be malformed if
it is not there, and the message should be discarded.

OK - now I'm confused.

/Loa

On 2015-04-23 13:02, t.petch wrote:
> ---- Original Message -----
> From: "Loa Andersson" <loa@pi.nu>
> Sent: Wednesday, April 22, 2015 2:15 PM
>
>> Tom,
>>
>> On 2015-04-20 00:07, Nobo Akiya wrote:
>>>      <tp>
>>>
>>>      Yes but ... I think that it is a change of meaning.  Is is
> enough just
>>>      to ignore the TLV or should the whole PDU be discarded?  I find
> it
>>>      difficult to know but don't feel strongly about that choice so
> will go
>>>      with what you suggest.
>>>
>>>      </tp>
>>
>> So I don't misunderstand what you are saying. It seems to me like the
>> comments made by Adrian and you actually requires a "change of
> meaning",
>> that is kind of essence of a "comment", right?
>>
>> As for what to do with if the TLV is not recognized, it is
>> intentionally requested from a space where it can be silently dropped
>> (i.e. "ignored").
>>
>>      The new TLV Type value should be assigned from the range
>>      (32768-49161) specified in [RFC4379] section 3 that allows the TLV
>>      type to be silently dropped if not recognized.
>>
>>        Type   Meaning                            Reference
>>        ----   -------                            ---------
>>        TBD1   Reply Mode Order TLV               this document
>>
>> What is it that I miss?
>
> Nothing serious.  My initial thought was to echo Adrian, that, at least
> in this context, there should be an indication what to do if a MUST or
> SHOULD was violated without just then having a clear sense of what it
> should be instead.
>
> The I-D did require (MUST) one entry in the TLV and wanted (SHOULD)
> more.  Adding what to do if that did not happen I was seeing as
> clarification.  I then read Nobo as proposing going a bit further saying
> requires (MUST) one or more.  Which might lead to boxes taking a
> simplistic approach and always putting in the new TLV with a single
> entry and ignoring the traditional TLV.  Not a problem just a change
> from what others might think that they have consented to.
>
> On the question of what to do when the rules are violated, again I did
> not initially think of what the action should be.  On reflection, I am
> still unsure.  I understand that the Reply Mode Order TLV  is optional
> and so can be ignored when not understood; that's fine.  But if it is
> understood and can be seen to be defective, should the box with that
> knowledge discard just that TLV and accept the remainder of the message?
> Or should it argue that if this TLV is defective, then likely the rest
> is as well and should be ignored?  I am unsure.
>
> If there is scope for a breach of security, or taking a hit in
> performance, then ignore is the right policy. If the requirement is to
> get as much data as possible from a failing network, then use it is the
> right policy.  As long as the I-D is clear, I am not too fussed which
> way it goes.  I am content with the changes that Nobo has proposed.
>
> Tom Petch
>
>> /Loa
>>
>> --
>>
>>
>> Loa Andersson                        email: loa@mail01.huawei.com
>> Senior MPLS Expert                          loa@pi.nu
>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>

-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64