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