Re: [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

Nobo Akiya <nobo.akiya.dev@gmail.com> Sat, 02 May 2015 04:03 UTC

Return-Path: <nobo.akiya.dev@gmail.com>
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 BDE411A0390 for <mpls@ietfa.amsl.com>; Fri, 1 May 2015 21:03:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] 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 hemuTBhNZdWt for <mpls@ietfa.amsl.com>; Fri, 1 May 2015 21:03:01 -0700 (PDT)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (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 7B5C71A037E for <mpls@ietf.org>; Fri, 1 May 2015 21:03:00 -0700 (PDT)
Received: by labbd9 with SMTP id bd9so74592318lab.2 for <mpls@ietf.org>; Fri, 01 May 2015 21:02:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NNdJQHxlwwcbMDGZlLuSu0MJa4M/HG/xqjju3UIYcdQ=; b=AF710zeK8akHdct9ArIdflxBbh1qfFd8uqvb9cmU3bcRIM/78esXolRyXSG6PMsSVX LkbofnrLIjeLRnGff/9/JsF+IxIrcAzHFZ4OF1JG4Q6fOCS5dHk1SIz4HQpmG5XJ5x/s Vkhi2njxEAsnKOP8wkBBgF+M6sVjigsza3oQAynG3OQanGoD/Ft5+6CWxNs9hYQ+M39V 2tFcDygKJH08wBsb8Q+PNnXwY9xHXUgG4QfYDeeFTas4aToqpDaAEG+0br2aYKhNKriU mu5Y5a+ZdFl/gLRRbK5SwBx/43TPpPWHQeL6QNz8/cGz4AjLDQu/w6KY4EBzfQCPMP6G G6ZQ==
MIME-Version: 1.0
X-Received: by 10.152.44.167 with SMTP id f7mr2430611lam.48.1430539378937; Fri, 01 May 2015 21:02:58 -0700 (PDT)
Received: by 10.112.154.168 with HTTP; Fri, 1 May 2015 21:02:58 -0700 (PDT)
In-Reply-To: <048c01d081dc$82451ca0$4001a8c0@gateway.2wire.net>
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> <5538EC97.8050204@pi.nu> <020701d07e1e$a79bf940$f6d3ebc0$@olddog.co.uk> <CAFqGwGtt72yTA7yDd_yHG5ad6=HhpRg_1VE2Xtziguqf=KbUUg@mail.gmail.com> <008801d07f73$5cbb74e0$16325ea0$@olddog.co.uk> <CAFqGwGs6S7cAZmawTmrwArTe5yatsssCG-t-ouF7GrcSSurxAg@mail.gmail.com> <553F8193.8040506@pi.nu> <011c01d081bb$843f9010$8cbeb030$@olddog.co.uk> <048c01d081dc$82451ca0$4001a8c0@gateway.2wire.net>
Date: Fri, 01 May 2015 21:02:58 -0700
Message-ID: <CAFqGwGsErusC_eSk6EU_KafpKOz_7whjWmgikK80mpN1qRxOOw@mail.gmail.com>
From: Nobo Akiya <nobo.akiya.dev@gmail.com>
To: "t.petch" <ietfc@btconnect.com>
Content-Type: multipart/alternative; boundary="089e0158c40e84d4f905151167b4"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/fo3CIAChPv05IpCbiw8WgbRn0Eg>
Cc: mpls <mpls@ietf.org>, "draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org" <draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org>, Ross Callon <rcallon@juniper.net>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Subject: Re: [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: Sat, 02 May 2015 04:03:07 -0000

Hi Adrian, Tom, Loa,

Thanks again!

New revision (-03) has been posted.

-Nobo

On Tue, Apr 28, 2015 at 10:55 AM, t.petch <ietfc@btconnect.com> wrote:

> Me too
>
> Tom Petch
>
>
> ----- Original Message -----
> From: "Adrian Farrel" <adrian@olddog.co.uk>
> To: "'Loa Andersson'" <loa@pi.nu>; "'Nobo Akiya'"
> <nobo.akiya.dev@gmail.com>
> Cc: "'t.petch'" <ietfc@btconnect.com>; "'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>
> Sent: Tuesday, April 28, 2015 2:59 PM
>
>
> I'm OK with what Nobo said.
>
> A
>
> > -----Original Message-----
> > From: Loa Andersson [mailto:loa@pi.nu]
> > Sent: 28 April 2015 13:48
> > To: Nobo Akiya; adrian@olddog.co.uk
> > Cc: t.petch; Ross Callon; mpls; mpls-chairs@tools.ietf.org;
> draft-ietf-mpls-lsp-
> > ping-reply-mode-simple@tools.ietf.org
> > Subject: Re: [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
> >
> > Nobo,
> >
> > I think this is fine.
> >
> > Bullet 4 says what to do if the Reply Mode Order TLV is mal-formed.
> >
> > Bullet 6-9 describe the mal-formednesses.
> >
> > Is it "invalid" rather than "not valid"?
> >
> > Tom and Adrian are you OK with this?
> >
> > /Loa
> >
> > On 2015-04-27 03:36, Nobo Akiya wrote:
> > > Hi Adrian,
> > >
> > > Many thanks for very helpful comments. I have carefully read your
> > > comments and made modifications to section 3.2 in my private copy.
> > >
> > > [OLD]
> > >
> > >     1.  The Reply Mode Order TLV MAY be included in MPLS echo
> request.
> > >
> > >     2.  The Reply Mode Order TLV MUST NOT be included in MPLS echo
> reply.
> > >
> > >     3.  The Reply Mode field of an MPLS echo request MUST be set to
> a
> > >         valid value even when supplying the Reply Mode Order TLV.
> The
> > >         initiator LSR SHOULD set the Reply Mode field of MPLS echo
> > >         request to a value that corresponds to a return path which
> most
> > >         likely to be available, in case the responder LSR does not
> > >         understand the Reply Mode Order TLV.
> > >
> > >     4.  If a responder LSR understands the Reply Mode Order TLV but
> the
> > >         TLV is not valid (due to conditions described in the items
> 6, 8
> > >         and 9 immediately below), then the responder LSR MUST only
> use
> > >         the value described in the Reply Mode field of received MPLS
> echo
> > >         request.
> > >
> > >     5.  If a responder LSR understands the Reply Mode Order TLV and
> the
> > >         TLV is valid, then the responder LSR MUST consider the Reply
> Mode
> > >         values described in the TLV and MUST NOT use the value
> described
> > >         in the Reply Mode field of received MPLS echo request.  In
> other
> > >         words, a valid Reply Mode Order TLV overrides the value
> specified
> > >         in the Reply Mode field of received MPLS echo request.
> > >
> > >     6.  Reply Mode Order TLV MUST contain at least one Reply Mode
> value,
> > >         and SHOULD contain at least two Reply Mode values.
> > >
> > >     7.  A Reply Mode value, except for Reply Mode value 5 (Reply via
> > >         Specified Path), MUST NOT be repeated (i.e., MUST NOT appear
> > >         multiple times) in the Reply Mode Order TLV.
> > >
> > >     8.  The Reply Mode value 5 (Reply via Specified Path) MAY be
> included
> > >         more than once in the Reply Mode Order TLV.  However, in
> such
> > >         case a Reply Path TLV MUST be included for all instances of
> the
> > >         Reply Mode value 5 included in the Reply Mode Order TLV.  In
> > >         other words, 3 instances of the Reply Mode value 5 in the
> Reply
> > >         Mode Order TLV will require 3 instances of the Reply Path
> TLVs.
> > >
> > >     9.  The Reply Mode value 1 (Do not reply) MUST NOT be used in
> the
> > >         Reply Mode Order TLV.
> > >
> > >     If a responder LSR receives a Reply Mode Order TLV which does
> not
> > >     comply to the rules described above, then the responder LSR MUST
> > >     ignore the Reply Mode Order TLV.
> > >
> > >
> > > [NEW]
> > >
> > >     1.  The Reply Mode Order TLV MUST NOT be included in MPLS echo
> reply.
> > >         If the initiator LSR receives an MPLS echo reply with the
> Reply
> > >         Mode Order TLV, the initiator LSR MUST ignore the whole
> Reply
> > >         Mode Order TLV and MUST only use the value from the Reply
> Mode
> > >         field of the received MPLS echo reply.  It may be beneficial
> for
> > >         implementations to provide counters and/or loggings, with
> > >         appropriate log dampening, to record this error case.
> > >
> > >     2.  The Reply Mode Order TLV MAY be included in MPLS echo
> request.
> > >
> > >     3.  The Reply Mode field of an MPLS echo request MUST be set to
> a
> > >         valid value even when supplying the Reply Mode Order TLV.
> The
> > >         initiator LSR SHOULD set the Reply Mode field of MPLS echo
> > >         request to a value that corresponds to a return path which
> most
> > >         likely to be available, in case the responder LSR does not
> > >         understand the Reply Mode Order TLV.
> > >
> > >     4.  If a responder LSR understands the Reply Mode Order TLV but
> the
> > >         TLV is not valid (due to conditions described in the items
> 6, 7,
> > >         8 and 9 immediately below), then the responder LSR MUST
> ignore
> > >         the whole Reply Mode Order TLV and MUST only use the value
> from
> > >         the Reply Mode field of the received MPLS echo request.  It
> may
> > >         be beneficial for implementations to provide counters and/or
> > >         loggings, with appropriate log dampening, to record this
> error
> > >         case.
> > >
> > >     5.  If a responder LSR understands the Reply Mode Order TLV and
> the
> > >         TLV is valid, then the responder LSR MUST consider the Reply
> Mode
> > >         values described in the TLV and MUST NOT use the value
> described
> > >         in the Reply Mode field of received MPLS echo request.  In
> other
> > >         words, a valid Reply Mode Order TLV overrides the value
> specified
> > >         in the Reply Mode field of received MPLS echo request.
> > >
> > >     6.  Reply Mode Order TLV MUST contain at least one Reply Mode
> value.
> > >
> > >     7.  A Reply Mode value, except for Reply Mode value 5 (Reply via
> > >         Specified Path), MUST NOT be repeated (i.e., MUST NOT appear
> > >         multiple times) in the Reply Mode Order TLV.
> > >
> > >     8.  The Reply Mode value 5 (Reply via Specified Path) MAY be
> included
> > >         more than once in the Reply Mode Order TLV.  However, in
> such
> > >         case a Reply Path TLV MUST be included for all instances of
> the
> > >         Reply Mode value 5 included in the Reply Mode Order TLV.  In
> > >         other words, 3 instances of the Reply Mode value 5 in the
> Reply
> > >         Mode Order TLV will require 3 instances of the Reply Path
> TLVs.
> > >
> > >     9.  The Reply Mode value 1 (Do not reply) MUST NOT be used in
> the
> > >         Reply Mode Order TLV.
> > >
> > >
> > > Thanks!
> > >
> > > -Nobo
> > >
> > >
> > > On Sat, Apr 25, 2015 at 9:17 AM, Adrian Farrel <adrian@olddog.co.uk
> > > <mailto:adrian@olddog.co.uk>> wrote:
> > >
> > >     Hi Nobo,____
> > >
> > >     __ __
> > >
> > >     Let's come back to my original review comments.____
> > >
> > >     __ __
> > >
> > >     > Section 3.2 gives clear instructions and guidance on forming
> the Reply____
> > >
> > >     > Mode Order TLV but not on what to do if a received TLV
> deviates from
> > the____
> > >
> > >     > MUST and MUST NOT instructions. Options might include ignoring
> > errors,____
> > >
> > >     > ignoring the TLV, ignoring the message. But presumably not
> sending
> > an____
> > >
> > >     > error response (because how would you know how to send
> it?)____
> > >
> > >     __ __
> > >
> > >     You responded:____
> > >
> > >     __ __
> > >
> > >     | [NOBO] That’s a good point. What the document really state is
> that
> > >     The____
> > >
> > >     | Reply Mode value 5 (Reply via Specified Path) MAY be repeated
> but
> > >     all ____
> > >
> > >     | other Reply Mode values MUST NOT be repeated. Will update
> the____
> > >
> > >     | document to make it clear.____
> > >
> > >     __ __
> > >
> > >     That's a fine thing to say, but doesn't answer my question about
> how
> > >     an implementation is supposed to behave when a received Reply
> Mode
> > >     Order TLV is "malformed".____
> > >
> > >     __ __
> > >
> > >     You posted draft-ietf-mpls-lsp-ping-reply-mode-simple-02.
> Section
> > >     3.2 swapped the order of points 4 and 5, and enhanced the text
> to
> > >     read...____
> > >
> > >     __ __
> > >
> > >     4.If a responder LSR understands the Reply Mode Order TLV but
> the____
> > >
> > >     TLV is not valid (due to conditions described in the items 6,
> 8____
> > >
> > >     and 9 immediately below), then the responder LSR MUST only
> use____
> > >
> > >     the value described in the Reply Mode field of received MPLS
> echo____
> > >
> > >     request.____
> > >
> > >     __ __
> > >
> > >     That seems to cover most bases. Good.____
> > >
> > >     It might also be helpful to say "...the responder LSR MUST
> silently
> > >     ignore the whole Reply Mode Order TLV and MUST only use the
> value
> > >     from the Reply Mode field of the received MPLS echo
> request."____
> > >
> > >     Saying this helps clarify the behavior.____
> > >
> > >     __ __
> > >
> > >     The only things I don't find covered are:____
> > >
> > >     __ __
> > >
> > >     a. how to handle a violation of the seventh point____
> > >
> > >     __ __
> > >
> > >     7.A Reply Mode value, except for Reply Mode value 5 (Reply
> via____
> > >
> > >     Specified Path), MUST NOT be repeated (i.e., MUST NOT appear____
> > >
> > >     multiple times) in the Reply Mode Order TLV.____
> > >
> > >     __ __
> > >
> > >     I think you can address this by adding "7" to the list of
> conditions
> > >     in point 4.____
> > >
> > >     __ __
> > >
> > >     b. how to handle a violation of the second point____
> > >
> > >     __ __
> > >
> > >     2. The Reply Mode Order TLV MUST NOT be included in MPLS echo
> > reply.____
> > >
> > >     __ __
> > >
> > >     I think this will need additional text.____
> > >
> > >     __ __
> > >
> > >     I note that after the numbered bullets you also now have the
> > >     following text...____
> > >
> > >     __ __
> > >
> > >     If a responder LSR receives a Reply Mode Order TLV which does
> not____
> > >
> > >     comply to the rules described above, then the responder LSR
> MUST____
> > >
> > >     ignore the Reply Mode Order TLV.____
> > >
> > >     __ __
> > >
> > >     This is better than point 4 and covers everything.____
> > >
> > >     You might consider whether "ignore" means "silently ignore" or
> > >     whether you want to give advice about logging. It seems probable
> > >     that (because of the nature of ping) if you do suggest logging,
> you
> > >     also want to describe some form of thresholding or damping.____
> > >
> > >     __ __
> > >
> > >     __ __
> > >
> > >     To address Loa's concern...____
> > >
> > >     The TLV is from the optional range. It can be ignored if it is
> not
> > >     understood, and does not require to be included.____
> > >
> > >     Loa asserted that the document says that the TLV MUST be
> included,
> > >     but I don't find this in -02.____
> > >
> > >     Therefore, I think this is all fine.____
> > >
> > >     __ __
> > >
> > >     Adrian____
> > >
> > >     __ __
> > >
> > >     *From:*Nobo Akiya [mailto:nobo.akiya.dev@gmail.com
> > >     <mailto:nobo.akiya.dev@gmail.com>]
> > >     *Sent:* 25 April 2015 05:50
> > >     *To:* adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>
> > >     *Cc:* Loa Andersson; t.petch; Ross Callon; mpls;
> > >     mpls-chairs@tools.ietf.org <mailto:mpls-chairs@tools.ietf.org>;
> > >     draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org
> > >
> <mailto:draft-ietf-mpls-lsp-ping-reply-mode-simple@tools.ietf.org>
> > >     *Subject:* Re: [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____
> > >
> > >     __ __
> > >
> > >     Hi Adrian, Tom, Loa,____
> > >
> > >     __ __
> > >
> > >     This extension is currently structured such that it allows for
> > >     backwards compatibility (i.e., transit LSR not supporting this
> > >     mechanism will not return "malformed request" ... because the
> TLV is
> > >     optional).____
> > >
> > >     __ __
> > >
> > >     The result is that this mechanism becomes a best effort
> mechanism,
> > >     and we will not get the full benefit until all LSRs along the
> LSP
> > >     (and other LSRs which could falsely receive the echo request)
> > >     implements this extension.____
> > >
> > >     __ __
> > >
> > >     One way to allow the initiator LSR to determine whether or not
> the
> > >     responder LSR understood this TLV, and still keeping the
> backwards
> > >     compatibility, is that we keep the Reply Mode Order TLV as an
> > >     optional TLV, but require (i.e., MUST) the responder LSR
> > >     understanding this TLV to include the Reply Mode Order TLV in
> the
> > >     echo reply, potentially with result of parsing/handling that
> TLV.____
> > >
> > >     __ __
> > >
> > >     However, that's probably not the path we want to go, as all (or
> > >     most) optional TLVs will have to do something similar (i.e.,
> include
> > >     the same TLV in the echo reply). This will quickly result in
> echo
> > >     reply packet bloat ... we should prevent that as echo reply
> usually
> > >     tends to include more information (ILS, DSMAP/DDMAP per nexthop,
> > >     multipath Sub-TLVs per nexthop, etc).____
> > >
> > >     __ __
> > >
> > >     To me, the right way to solve this is to create a capability TLV
> > >     that mandates the reponder LSR to return which features it
> supports
> > >     in bitmaps or something very compact. But this can be done in a
> > >     separate effort/draft.____
> > >
> > >     __ __
> > >
> > >     In short, my preference for this document is to go as is (after
> > >     incorporating comments from Tom).____
> > >
> > >     __ __
> > >
> > >     Thanks!____
> > >
> > >     __ __
> > >
> > >     -Nobo____
> > >
> > >     __ __
> > >
> > >     On Thu, Apr 23, 2015 at 4:38 PM, Adrian Farrel
> <adrian@olddog.co.uk
> > >     <mailto:adrian@olddog.co.uk>> wrote:____
> > >
> > >     Thanks Loa,
> > >
> > >     You captured it. The edge cases need to be nailed down.
> > >
> > >     Personally I have no particular preference for where it is
> nailed,
> > >     but I don't
> > >     want it flapping in the breeze.
> > >
> > >     A
> > >
> > >      > -----Original Message-----
> > >      > From: mpls [mailto:mpls-bounces@ietf.org
> > >     <mailto:mpls-bounces@ietf.org>] On Behalf Of Loa Andersson
> > >      > Sent: 23 April 2015 13:59
> > >      > To: t.petch; Nobo Akiya
> > >      > Cc: Ross Callon; mpls; mpls-chairs@tools.ietf.org
> > >     <mailto:mpls-chairs@tools.ietf.org>;
> > >     draft-ietf-mpls-lsp-ping-reply-
> > >      > mode-simple@tools.ietf.org
> <mailto: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
> > >      >
> > >      > 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 <mailto: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 <mailto:loa@mail01.huawei.com>
> > >      > >> Senior MPLS Expert loa@pi.nu <mailto:loa@pi.nu>
> > >      > >> Huawei Technologies (consultant)     phone: +46 739 81 21
> 64
> > >     <tel:%2B46%20739%2081%2021%2064>
> > >      > >
> > >     >
> > >     > --
> > >     >
> > >     >
> > >     > Loa Andersson
> email:loa@mail01.huawei.com
> > <mailto:loa@mail01.huawei.com>
> > >     > Senior MPLS Expertloa@pi.nu <mailto:loa@pi.nu>
> > >     > Huawei Technologies (consultant)     phone:+46 739 81 21 64
> > <tel:%2B46%20739%2081%2021%2064>
> > >     >
> > >     > _______________________________________________
> > >     > mpls mailing list
> > >     >mpls@ietf.org <mailto:mpls@ietf.org>
> > >     >https://www.ietf.org/mailman/listinfo/mpls____
> > >
> > >     __ __
> > >
> > >
> >
> > --
> >
> >
> > Loa Andersson                        email: loa@mail01.huawei.com
> > Senior MPLS Expert                          loa@pi.nu
> > Huawei Technologies (consultant)     phone: +46 739 81 21 64
>
>