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> Mon, 27 April 2015 01:36 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 AF5FE1B2D1C for <mpls@ietfa.amsl.com>; Sun, 26 Apr 2015 18:36:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.301
X-Spam-Level: *
X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ZDysKVpQW13a for <mpls@ietfa.amsl.com>; Sun, 26 Apr 2015 18:36:24 -0700 (PDT)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (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 811D21B2D1A for <mpls@ietf.org>; Sun, 26 Apr 2015 18:36:23 -0700 (PDT)
Received: by lbbqq2 with SMTP id qq2so71261470lbb.3 for <mpls@ietf.org>; Sun, 26 Apr 2015 18:36:22 -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=7UFqCCC6EwV+8nl2RFPMZ+4CwhRLggbptre8Q6Co1mI=; b=X5Eq/rNaNdqt+RMLqb8H2EU/bfPLFcjGX/WGy3+HcCeCJIg9rLDS3B9EHuuxuvO56D yb5NEonLnYhghiT7CCNT9YptU5dclB/QrXbEFVYTGOP8XE7ak55c44W0GuAzBwCcLNSl KY3OlfrVQpiWM1VgtJ/xP9hhAX7ZL+eO8er7bZERdCfCKGiTfO9HhmLFRFhEFt+2RMpn Q4iBJuEq/ibcbR9v0pXSXR6yTc0JNuwBGcm4gfLO89oD5F9JeU20/vHLSXgpg+XaxLm1 WbQVylARjrZ9EZIfGfVB3TDYfd+oA9+T7a0CpCMFKr6XmFIgp3E8dALEo0htvZ9ZLhZM iDtA==
MIME-Version: 1.0
X-Received: by 10.152.45.34 with SMTP id j2mr7702911lam.99.1430098581963; Sun, 26 Apr 2015 18:36:21 -0700 (PDT)
Received: by 10.112.154.168 with HTTP; Sun, 26 Apr 2015 18:36:21 -0700 (PDT)
In-Reply-To: <008801d07f73$5cbb74e0$16325ea0$@olddog.co.uk>
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>
Date: Sun, 26 Apr 2015 18:36:21 -0700
Message-ID: <CAFqGwGs6S7cAZmawTmrwArTe5yatsssCG-t-ouF7GrcSSurxAg@mail.gmail.com>
From: Nobo Akiya <nobo.akiya.dev@gmail.com>
To: adrian@olddog.co.uk
Content-Type: multipart/alternative; boundary="001a11c2796cf8c8ee0514aac525"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/Ei5LHUIXuaAz8gBsGYgIohzcISc>
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: Mon, 27 Apr 2015 01:36:28 -0000
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> 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] > *Sent:* 25 April 2015 05:50 > *To:* adrian@olddog.co.uk > *Cc:* Loa Andersson; 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 > > > > 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> > 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] 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; > 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 > > > > 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 > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > >
- [mpls] working group last call for draft-ietf-mpl… Ross Callon
- Re: [mpls] working group last call for draft-ietf… Qin Wu
- [mpls] 答复: working group last call for draft-ietf… Dongjie (Jimmy)
- Re: [mpls] working group last call for draft-ietf… Nobo Akiya
- Re: [mpls] working group last call for draft-ietf… Nagendra Kumar Nainar (naikumar)
- Re: [mpls] working group last call for draft-ietf… Qin Wu
- Re: [mpls] working group last call for draft-ietf… Faisal Iqbal (faiqbal)
- Re: [mpls] working group last call for draft-ietf… Sam Aldrin
- Re: [mpls] working group last call for draft-ietf… Adrian Farrel
- Re: [mpls] working group last call for draft-ietf… Nobo Akiya
- [mpls] end of WGLC, RE: working group last call f… Ross Callon
- Re: [mpls] end of WGLC, RE: working group last ca… Nobo Akiya
- Re: [mpls] end of WGLC, RE: working group last ca… t.petch
- Re: [mpls] end of WGLC, RE: working group last ca… Adrian Farrel
- Re: [mpls] end of WGLC, RE: working group last ca… Nobo Akiya
- Re: [mpls] end of WGLC, RE: working group last ca… t.petch
- Re: [mpls] end of WGLC, RE: working group last ca… Nobo Akiya
- Re: [mpls] end of WGLC, RE: working group last ca… Loa Andersson
- Re: [mpls] end of WGLC, RE: working group last ca… t.petch
- [mpls] George can yu look at this - Re: end of WG… Loa Andersson
- Re: [mpls] George can yu look at this - Re: end o… Adrian Farrel
- Re: [mpls] George can yu look at this - Re: end o… Nobo Akiya
- Re: [mpls] George can yu look at this - Re: end o… Adrian Farrel
- Re: [mpls] George can yu look at this - Re: end o… Nobo Akiya
- Re: [mpls] George can yu look at this - Re: end o… Loa Andersson
- Re: [mpls] George can yu look at this - Re: end o… Adrian Farrel
- Re: [mpls] George can yu look at this - Re: end o… t.petch
- Re: [mpls] George can yu look at this - Re: end o… Nobo Akiya