Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08
"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Tue, 17 May 2016 07:12 UTC
Return-Path: <ginsberg@cisco.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E3512B05C; Tue, 17 May 2016 00:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level:
X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 N-iw8x2qpkw1; Tue, 17 May 2016 00:12:02 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860CF12D09C; Tue, 17 May 2016 00:12:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7582; q=dns/txt; s=iport; t=1463469122; x=1464678722; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jpmPW3Ct0ykNElmxg8plB3dPxgsxJkHyOwFMrJZh4CM=; b=EUU+s6BWIqv0i0ENYFFD3/38W+j9tMfHJHrORQLvFF2dbNuLpGJ8wt6N MVaH0QhMXlkfP6adYxFXDLnZdd7DinUs7NAfoTQhjss8K8I7alLi6r8gO Y22quynrfTdPRKVViXZdnefnntcLW06jweNKUWYY5V+Hd282BqquG1X93 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BiAgAmwzpX/5FdJa1UCYM3VX4GuWoBDYF2IoVvAoEyOBQBAQEBAQEBZSeEQgEBAQQ6PwwEAgEIEQEDAQEBHhAyFwYIAgQBDQUIiCcOwiwBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYlhE2EEQcKAYV1BZgoAY4WgXCET4hhj0ABHgEBQoNsbgGGUDZ/AQEB
X-IronPort-AV: E=Sophos;i="5.26,324,1459814400"; d="scan'208";a="273712276"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 May 2016 07:12:01 +0000
Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u4H7C1D3005779 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 May 2016 07:12:01 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 May 2016 02:12:00 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Tue, 17 May 2016 02:12:00 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "Joe Clarke (jclarke)" <jclarke@cisco.com>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>
Thread-Topic: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08
Thread-Index: AdGgzHD5AnaTBqcTQJm4IHI17iI2lQBnClYAAieCg0AALuo+AAACzD3QAAvztwAARQFW8AARa8OAAK0WXnA=
Date: Tue, 17 May 2016 07:12:00 +0000
Message-ID: <ff3814fc58674583bb03f8b00859a10b@XCH-ALN-001.cisco.com>
References: <5afaa922862d4b4a9dc67f117ae5366a@XCH-ALN-001.cisco.com> <b8c9a8ad-6f2e-5f09-5bfd-9b39cb412959@cisco.com> <b758c78deaa54ca19375d49562576d9d@XCH-ALN-001.cisco.com> <978721df-6b95-dff7-af53-31d42a731946@cisco.com> <6dde8ef61dbf4faa98387fee01516dc3@XCH-ALN-001.cisco.com> <26dfa4d7-dd81-de1f-57b7-ae6fa9641fb5@cisco.com> <30733d2a0880449dbd5cf930c48ad6be@XCH-ALN-001.cisco.com> <be0c3cf5-e5a1-62f5-84a2-459ca9526572@cisco.com>
In-Reply-To: <be0c3cf5-e5a1-62f5-84a2-459ca9526572@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.97.36]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs/aAhQs7oub72z2xDck9SbmREKesE>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-i2rs-traceability@ietf.org" <draft-ietf-i2rs-traceability@ietf.org>, "i2rs@ietf.org" <i2rs@ietf.org>
Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 May 2016 07:12:04 -0000
Thanx Joe - looks good. Les > -----Original Message----- > From: Joe Clarke (jclarke) > Sent: Friday, May 13, 2016 8:36 AM > To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; i2rs@ietf.org > Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 > > On 5/13/16 08:17, Les Ginsberg (ginsberg) wrote: > > Joe - > > > > Something like the attached file perhaps? > > Thanks. We have posted rev -10 of this draft that should address all of your > comments. > > Joe > > > > > Les > > > > > >> -----Original Message----- > >> From: Joe Clarke (jclarke) > >> Sent: Wednesday, May 11, 2016 3:21 PM > >> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > >> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; > >> i2rs@ietf.org > >> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 > >> > >> On 5/11/16 17:39, Les Ginsberg (ginsberg) wrote: > >>> Joe - > >>> > >>> Yes - this looks better to me. > >>> > >>> What about the "shadow boxes" for Applications/Clients? > >> > >> Do you have an example draft I could look at for that? > >> > >> Joe > >> > >>> > >>> Les > >>> > >>> > >>>> -----Original Message----- > >>>> From: Joe Clarke (jclarke) > >>>> Sent: Wednesday, May 11, 2016 8:19 AM > >>>> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > >>>> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; > >>>> i2rs@ietf.org > >>>> Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08 > >>>> > >>>> On 5/10/16 18:04, Les Ginsberg (ginsberg) wrote: > >>>>> Joe - > >>>>> > >>>>> Apologies for the delayed response. I am a victim of my own email > >>>>> infilters. :-( Inline. > >>>> > >>>> Thanks, Les. Have a look at > >>>> https://www.marcuscom.com/draft-ietf-i2rs-traceability.txt-from-09- > >>>> 10.diff.html > >>>> . I added a new line to show the flow in both directions. > >>>> > >>>> Joe > >>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Joe Clarke (jclarke) > >>>>>> Sent: Friday, April 29, 2016 10:44 AM > >>>>>> To: Les Ginsberg (ginsberg); rtg-ads@ietf.org > >>>>>> Cc: rtg-dir@ietf.org; draft-ietf-i2rs-traceability@ietf.org; > >>>>>> i2rs@ietf.org > >>>>>> Subject: Re: [i2rs] RtgDir review: > >>>>>> draft-ietf-i2rs-traceability-08 > >>>>>> > >>>>>> On 4/27/16 17:39, Les Ginsberg (ginsberg) wrote: > >>>>>>> Summary: This document is a well written document - easy to > >>>> understand. > >>>>>>> My compliments to the authors. I believe there is one minor > >>>>>>> issue which I would like to see addressed before publication. > >>>>>> > >>>>>> Thanks for your comments and feedback, Les. Please see below for > >>>>>> some replies and questions. > >>>>>> > >>>>>>> In Section 5.2 there is a definition of the information which is > >>>>>>> required to be kept by an I2RS Agent for each I2RS interaction. > >>>>>>> I would like to see the addition of "Request State" into this list. > >>>>>>> Operationally each request could be in one of the following states: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> * Enqueued (or pending if you prefer) > >>>>>>> > >>>>>>> * In process > >>>>>>> > >>>>>>> * Completed > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> The lack of such a state seems to imply that both the queue time > >>>>>>> and the processing time are insignificant. While I think this > >>>>>>> may be the case for many requests, it will not always be the > >>>>>>> case. In queue time may be lengthy due to other load on the > >>>>>>> Agent. Also, some requests - particularly destructive requests > >>>>>>> which involve cleanup of resources - may take a significant > >>>>>>> amount of time to > >> complete. > >>>>>> > >>>>>> Good observation. Traceability was aimed mainly at the > >>>>>> termination of the request, but I like the idea of tracing the state > machine. > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Along with this an additional timestamp - Processing Initiated - > >>>>>>> would be useful to indicate when processing of the request > >>>>>>> actually > >>>> began. > >>>>>> > >>>>>> I don't know we need a new timestamp. Perhaps we just need to > >>>> rename > >>>>>> "Request Timestamp" and "Result Timestamp" to "Start Timestamp" > >> and > >>>>>> "End Timestamp" to denote the time within the current state. > >>>>>> What do you think? > >>>>> > >>>>> [Les:] My intent was to log the time at which the request began > >>>>> processing > >>>> so that you can see whether a long delay in completion was due to > >>>> enqueue delay or actual lengthy processing time. I am not adamant > >>>> about this so if you want to stay with the two timestamps that is OK. > >>>>> > >>>>>> > >>>>>>> s/Some notable elements on the architecture/ Some notable > >> elements > >>>>>>> of the architecture > >>>>>> > >>>>>> Fixed. Thanks! > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Figure 1 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Not clear to me why Application IDs start at 0 but Client IDs start at > 1. > >>>>>> > >>>>>> Ah. The numbers there are not IDs. They are the number of > >>>>>> actual things in the boxes above. For Applications, there may be > >>>>>> 0 to N for a given client. For Clients, you need at least 1. > >>>>>> Does that make > >> sense? > >>>>>> > >>>>> [Les:] Maybe you want to use "shadows" on the boxes to indicate > >>>>> there > >>>> can be multiple Application boxes and multiple Client boxes? > >>>>> What you say makes sense but I do not intuit that when I look at > >>>>> the ASSCII > >>>> art. > >>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Figure 1 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Is the text "Op Data V" between I2RS Agent box and Routing > >>>>>>> System box intentional? > >>>>>> > >>>>>> Yes. The 'V' is meant to be an arrow head pointed down. The > >>>>>> request and data go from Client to Agent whereas the Response > >>>>>> goes from Agent to Client. > >>>>>> > >>>>>> We are open to suggestions on how to make this clearer. > >>>>> > >>>>> [Les:] I think it would be clearer if you had two lines - one > >>>>> flowing down > >>>> associated with the Op Data and one flowing up with the result. > >>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Section 5.2 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Secondary Identity > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> This is defined to be "opaque" yet if not provided the agent is > >>>>>>> supposed to insert "an UNAVAILABLE value". This seems to be a > >>>>>>> contradiction unless we have a publicly defined value that > >>>>>>> clients are prohibited from using. Absent that you would need a > >>>>>>> "Secondary > >>>> Identity Valid" indicator. > >>>>>> > >>>>>> Good observation. I think it's fine to say that this field must > >>>>>> be logged. If there is no application, then the field will be > >>>>>> logged as empty. If there is an application, then whatever value > >>>>>> is provided will be logged. > >>>>>> > >>>>>> Do you feel strongly that we need a field to indicate Application > >> Present? > >>>>>> > >>>>> [Les:] I am fine w your changes. > >>>>> > >>>>> Les > >>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Section 7.4 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> s/establish an vendor-agnostic/establish a vendor-agnostic > >>>>>> > >>>>>> Fixed. Thanks! > >>>>>> > >>>>>> Joe > >>> > >
- [i2rs] RtgDir review: draft-ietf-i2rs-traceabilit… Les Ginsberg (ginsberg)
- Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceab… Joe Clarke
- Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceab… Alia Atlas
- Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceab… Les Ginsberg (ginsberg)
- Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceab… Joe Clarke
- Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceab… Les Ginsberg (ginsberg)
- Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceab… Joe Clarke
- Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceab… Les Ginsberg (ginsberg)
- Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceab… Joe Clarke
- Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceab… Les Ginsberg (ginsberg)