Re: [mpls] Mirja Kühlewind's No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT)
Mirja Kühlewind <ietf@kuehlewind.net> Tue, 07 March 2017 13:32 UTC
Return-Path: <ietf@kuehlewind.net>
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 2C40112965F for <mpls@ietfa.amsl.com>; Tue, 7 Mar 2017 05:32:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 bb1HT9nuUUPh for <mpls@ietfa.amsl.com>; Tue, 7 Mar 2017 05:32:50 -0800 (PST)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59387129B78 for <mpls@ietf.org>; Tue, 7 Mar 2017 05:32:47 -0800 (PST)
Received: (qmail 32063 invoked from network); 7 Mar 2017 14:26:04 +0100
Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 7 Mar 2017 14:26:04 +0100
To: Greg Mirsky <gregimirsky@gmail.com>
References: <148838693301.7079.14351576385669069452.idtracker@ietfa.amsl.com> <CA+RyBmUdQVjEcsYuKEqoK5eW_0F3p_u4k9rnmjD6wBy4qMuPCA@mail.gmail.com> <EF923ED1-114F-43BA-95C1-F81864946788@kuehlewind.net> <CA+RyBmXTu=u9AHV75b7=j=X_wwkcgB-GCcfeUmEv7RK4QgPp8g@mail.gmail.com> <15C3695F-D11A-4F35-A405-CB71D914DC5F@kuehlewind.net> <CA+RyBmW2-g5zdxVMPBXAGp7oVX4hWXuFqXDUOzgDO0pcYQDHDg@mail.gmail.com>
From: Mirja Kühlewind <ietf@kuehlewind.net>
Message-ID: <6383944e-4453-c6c4-6e94-1e4a5e382fd3@kuehlewind.net>
Date: Tue, 07 Mar 2017 14:26:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <CA+RyBmW2-g5zdxVMPBXAGp7oVX4hWXuFqXDUOzgDO0pcYQDHDg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/0pbWo7ECnziBbXHwdzCo3gKwHoI>
Cc: mpls-chairs@ietf.org, draft-ietf-mpls-residence-time@ietf.org, "mpls@ietf.org" <mpls@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [mpls] Mirja Kühlewind's No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 07 Mar 2017 13:32:52 -0000
Still not convinced because you can just use an new RTM TLV for this case. On 06.03.2017 23:58, Greg Mirsky wrote: > Hi Mirja, > we use sub-TLV in Figure 2 as future proofing approach in case someone may > need to define different sub-TLV that MUST precede the PTP packet. > Would you agree that it is reasonable design choice? > > Regards, > Greg > > On Fri, Mar 3, 2017 at 11:19 AM, Mirja Kuehlewind (IETF) <ietf@kuehlewind.net > <mailto:ietf@kuehlewind.net>> wrote: > > Hi Greg, > > two quick replies below. > > Mirja > > > Am 03.03.2017 um 20:10 schrieb Greg Mirsky <gregimirsky@gmail.com > <mailto:gregimirsky@gmail.com>>: > > > > Hi Mirja, > > thank you for your comments and very helpful discussion. My notes > in-lined and now tagged with GIM2>> > > > > Regards, > > Greg > > > > On Fri, Mar 3, 2017 at 1:46 AM, Mirja Kuehlewind (IETF) > <ietf@kuehlewind.net <mailto:ietf@kuehlewind.net>> wrote: > > Hi Greg, > > > > see inline. > > > > Mirja > > > > > > > Am 03.03.2017 um 03:47 schrieb Greg Mirsky <gregimirsky@gmail.com > <mailto:gregimirsky@gmail.com>>: > > > > > > Hi Mirja, > > > thank your for the review and the comments, most helpful. > > > Please find my answers in-line tagged GIM>>. > > > > > > Regards, > > > Greg > > > > > > On Wed, Mar 1, 2017 at 8:48 AM, Mirja Kühlewind <ietf@kuehlewind.net > <mailto:ietf@kuehlewind.net>> wrote: > > > Mirja Kühlewind has entered the following ballot position for > > > draft-ietf-mpls-residence-time-14: No Objection > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut this > > > introductory paragraph, however.) > > > > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > <https://www.ietf.org/iesg/statement/discuss-criteria.html> > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/ > <https://datatracker.ietf.org/doc/draft-ietf-mpls-residence-time/> > > > > > > > > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > High level comment: > > > Maybe extend the security section a bit and describe what can happen in > > > the worse case if the value has been modified to a too high or too low > > > value; and maybe even given some guidance on performing additional checks > > > to figure out if a given value is reasonable for a given path or not. > > > > > > Questions: > > > - Can you explain why PTPType, Port ID, and Sequence ID are needed in the > > > PTP Sub-TLV format if those values are already in the PTP packet itself > > > that follows? > > > GIM>> We propose to copy these values as they uniquely identify PTP > control message as these are required for two-step mode and suggesting > inspection of the PTP payload would cause layer violation. > > > > I see. Maybe add a sentence that these field are use to identify the > packet. However, when you copy them, you also have to inspect the payload > and that’s the same layer violation. Also not sure if duplicating > information in the packet is the best approach. Why don’t use just add an > own identifier to the packet instead? > > GIM2>> Will the following, when added at the very end of Section 3.1, work: > > Tuple of PTPType, Port ID, and Sequence ID uniquely identifies PTP > > control packet encapsulated in RTM message and are used in two-step > > RTM mode Section 2.1.1. > > > > GIM2>> The RTM message created by egress or the first on the LSP > two-step RTM node. Thus other RTM nodes don't need to look into PTP > control message but use the PTP sub-TLV. Creating new identifier is > certainly an alternative but I believe that will require more state > coordination between LERs on the same RTM LSP. Re-using existing > characteristic information, in my view, is simpler solution. > > Yes the new text helps. I don’t see why there is any more coordination > needed if you use an identifier. If you are in two-step mode, you simply > remember the identifier of the packet that you use to measurement > together with your measurement and wait for the next packet with the same > identifier. I don’t think that’s any different than using the PTP > information as identifier. Anyway that’s not an big issue. > > > > > > > > > - Why is it necessary to define PTP sub-TLV (and have a registry for one > > > value only)? Are you expecting to see more values here? What would those > > > values be? > > > GIM>> We may have another protocols or applications to use RTM and these the most likely will have their specific set of parameters to uniquely identify control session for two-step mode. One obvious case would be NTP when on-path support is defined. But since we don't know which parameters will uniquely identify cotrol session we don't request code point allocation. > > > > My understanding was that a new protocol would be a different RTM TLV in the registry in section 7.2. That’s fine. I don’t understand why your PTP sub-TLV needs ANOTHER TLV scheme: figure 2 and registry in sec 7.3. > > GIM2>> RTM TLV differentiates between different encapsulation types, e.g. Ethernet, IPv4 or IPv6 but sub-TLV doesn't have to. Do you see this as a problem? > > I still don’t fully understand this. You can use the same sub-TLV even if > that sub-TLV is not extensible. All I’m saying is that I don’t understand > why the sub-TLV in figure 2 has again a type and a value. I don’t think > those two field are needed. > > > > > > - Similar to Spencer's question: Why don't you also define a Sub-TLV > > > format for NTP? > > > GIM>>Hope that above answer addresses this question. > > > > Actually not really. Why don’t you know which parameters to use? > > > > > - sec 4.3: "RTM (capability) - is a three-bit long bit-map field with > > > values > > > defined as follows: > > > * 0b001..." > > > Maybe I don't understand what a bit-map field is here but these are > > > more then 3 bits...? > > > GIM>> '0b' identifies binary format as '0x' identifies hexadecimal > format of notation. > > Ah sorry, fully overview that. > > > > > - also sec 4.3.: "Value contains variable number of bit-map fields so > > > that overall > > > number of bits in the fields equals Length * 8." > > > However there is no field 'Value' in the figure... > > > GIM>> Thank you for pointing. I'll update Figure 4 and Figure 5 to > add Value tag on the field immediately following RTM field. > > > > There are more questions here: > > > > > Also the following > > > explanation about future bit-maps is really confusing to me; why don't > > > you just say that the rest as indicated by the length field must be > > > padded with zeros...? > > GIM2>> The description follows RFC 7794 Section 2.1 > > > - Should section 4.8 maybe be a subsection of 4.7? This part confused me > > > a bit because the example seems to be generic but the rest is RSVP-TE > > > specific, right? Maybe move the example as a separate section before or > > > after the whole section 4...? > > GIM2>> Thank you, I agree it is more logical flow. With the change > suggested by Ben it will look like this: > > 4. Control Plane Theory of Operation . . . . . . . . . . . . . . 10 > > 4.1. RTM Capability . . . . . . . . . . . . . . . . . . . . . 10 > > 4.2. RTM Capability Sub-TLV . . . . . . . . . . . . . . . . . 11 > > 4.3. RTM Capability Advertisement in Routing Protocols . . . . 11 > > 4.3.1. RTM Capability Advertisement in OSPFv2 . . . . . . . 11 > > 4.3.2. RTM Capability Advertisement in OSPFv3 . . . . . . . 13 > > 4.3.3. RTM Capability Advertisement in IS-IS . . . . . . . . 13 > > 4.3.4. RTM Capability Advertisement in BGP-LS . . . . . . . 13 > > 4.4. RSVP-TE Control Plane Operation to Support RTM . . . . . 14 > > 4.4.1. RTM_SET TLV . . . . . . . . . . . . . . . . . . . . . 15 > > > > > > > > Nits: > > > - Maybe change to title to: Residence Time Measurement (RTM) in MPLS > > > network > > > - There are (still) some not spelled out abbreviations (LDP, PW); > > > GIM>> Since both are used only once - expanded > > > in turn > > > others are extended twice (e.g. PTP)... > > > GIM>> Cleaned. > > > - In figure 1, I would rename 'Value' to 'Sub-TLV' and maybe also > > > indicate it as optional in the figure: Sub-TLV (optional) > > > GIM>> Agree > > > > > > > > >
- [mpls] Mirja Kühlewind's No Objection on draft-ie… Mirja Kühlewind
- Re: [mpls] Mirja Kühlewind's No Objection on draf… Greg Mirsky
- Re: [mpls] Mirja Kühlewind's No Objection on draf… Mirja Kuehlewind (IETF)
- Re: [mpls] Mirja Kühlewind's No Objection on draf… Greg Mirsky
- Re: [mpls] Mirja Kühlewind's No Objection on draf… Mirja Kuehlewind (IETF)
- Re: [mpls] Mirja Kühlewind's No Objection on draf… Greg Mirsky
- Re: [mpls] Mirja Kühlewind's No Objection on draf… Mirja Kühlewind
- Re: [mpls] Mirja Kühlewind's No Objection on draf… Greg Mirsky