Re: [ippm] Adoption call for draft-mirsky-ippm-stamp-option-tlv
"Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com> Sat, 20 July 2019 18:45 UTC
Return-Path: <rgandhi@cisco.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC97A12006E; Sat, 20 Jul 2019 11:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=YyblT30p; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=EO0Fl17n
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 2nUmLQjUe73I; Sat, 20 Jul 2019 11:44:59 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE0312001B; Sat, 20 Jul 2019 11:44:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=71735; q=dns/txt; s=iport; t=1563648299; x=1564857899; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+dsPs+5HbhQ+NfE1Qbwe7Qc8T8rThKgOjNHpJvFosJY=; b=YyblT30pgls3rAyGCe81/4qnkpYMls4SBBX9ENW8E1VSnwL+ygQEq/kp bEe7NHmobywv2G36G/rrv7z83Pjrbl18rYftm66trsxvlnxykhv1nKNy2 T3f6s9Gq8l4T6dZeVdYxnY+ODYcyp0hIPtPrS+WyqEPR15OL1YQHOIG9p k=;
IronPort-PHdr: 9a23:FonSCxSzh/k+wlZpu5E3avw/stpsv++ubAcI9poqja5Pea2//pPkeVbS/uhpkESXBdfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH15g640NmhA4RsuMCEn1NvnvOjY1FcJOVF5N9HCgOk8TE8H7NBXf
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AIAAA/YDNd/4oNJK1mGgEBAQEBAgEBAQEHAgEBAQGBUwUBAQEBCwGBFC8kBScDbVUgBAsqhB2DRwOEUoksgluJVI18gS4UgRADUAQJAQEBDAEBGAEKCgIBAYRAAheCOyM0CQ4BAwEBBAEBAgEGbYUeDIVKAQEBAQMBARALBh0BASwLAQ8CAQgQAQMBAQEhAQYDAgICHwYLFAkIAgQBDQUigwABgR1NAx0BAgyfVgKBOIhgcYEygnkBAQWBNgIOQYJ8DQuCEwMGgTQBhHGGbReBQD+BEScfgU5+PoIaRwEBAgEBgSoBEgEJHRAJDQmCVTKCJowmglKEfpYxQAkCghmGWIlAg3QUB4IthyWOOIxWCVaHSIF1jhMCBAIEBQIOAQEFgVA4Z3FwFTsqAYJBgkIJGoEDAQKCSIUUhT9yAYEojGiCQwEB
X-IronPort-AV: E=Sophos;i="5.64,288,1559520000"; d="scan'208,217";a="303652331"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Jul 2019 18:44:58 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x6KIiw5f028265 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 20 Jul 2019 18:44:58 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 20 Jul 2019 13:44:57 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 20 Jul 2019 13:44:57 -0500
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 20 Jul 2019 13:44:56 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CWbHHH/nkjJ9iRGweI1yZcou9meku21AcxVbBOckt05/ZsXP10JDAAwsPBaPiKo9Zv8zRQo53TpaIlZJ/VOoVUZ49YOmBZqD2eOCV/30yMcl2Gd7VGZOAyKzCVNBukovRxBz8QKoTpG6m0FcINZa+FVy/R27bDIpzmZC8oeCVDlAk/nvPslddYy7bO3kS6HYhRgFgutt359KteKIdA1rns8zfOb4+PFn3w2Uxz0Gk+rm5ZGtgALAUNMWAuCwuJnkBQmis5ov0bWsbpgUiG6/VG7W09m6t8GOyZ1e5OgGxQo3uaRsh/1blKniFBmI4LzapFR+nwYPZP2UcrjXp4PveA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+dsPs+5HbhQ+NfE1Qbwe7Qc8T8rThKgOjNHpJvFosJY=; b=lTavuBzLb0lBg6m9UbMEURc6ZgCiBsE4FKx90Wbysz/g72X6AWPlHPmWApMjXO/Mrtt7DtoWO2aY1VUlaa4wX8JWF2hD8jdcMqznOv8+VgMP6rgDBm7iJCQpC5ryE3U0bVSX44RFMxFG4mxTPQrxXTq4iKO57oAbZZcxK5m4K6vWxtuTq8vFNzY7X9NaGzKhGm+1G0y85ssrIOWViOo8tjeQzhCzZd9v0ICfv58IHS+bJJkNmmsLkfoVvTgNXnTAQPb1JRmONGJtJta/g1Nyi4x2erk63S3WfRSPBw8ZpL55uyDgQgmXK3k+AueVNID+NNJgEQNMyS2eO3F1G5IriQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+dsPs+5HbhQ+NfE1Qbwe7Qc8T8rThKgOjNHpJvFosJY=; b=EO0Fl17nOHlGfT9NMs805QQ9uHPx0klaHDnARXUmyLu4bae4sDfiBMYDVSSZdeUpzuhmTD7/ytBILaIfYStRg22Cx8V2KdGRq3VSdmIGXLvpDT+dW6ZSFzBQUj1j3vRbWn+t33vg72KD6Ga1ZgDiRfUIkHexIQbqnFpVx6TXYR0=
Received: from SN6PR11MB3278.namprd11.prod.outlook.com (52.135.109.11) by SN6PR11MB2767.namprd11.prod.outlook.com (52.135.92.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.15; Sat, 20 Jul 2019 18:44:54 +0000
Received: from SN6PR11MB3278.namprd11.prod.outlook.com ([fe80::d97f:e2dd:1ea6:303f]) by SN6PR11MB3278.namprd11.prod.outlook.com ([fe80::d97f:e2dd:1ea6:303f%5]) with mapi id 15.20.2094.013; Sat, 20 Jul 2019 18:44:54 +0000
From: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
To: Tianran Zhou <zhoutianran@huawei.com>, Rakesh Gandhi <rgandhi.ietf@gmail.com>
CC: "draft-mirsky-ippm-stamp-option-tlv@ietf.org" <draft-mirsky-ippm-stamp-option-tlv@ietf.org>, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, IETF IPPM WG <ippm@ietf.org>
Thread-Topic: [ippm] Adoption call for draft-mirsky-ippm-stamp-option-tlv
Thread-Index: AQHVNd/4ZT4mB0oOTEGVzr7heg3KP6bLzN6AgADN9QCAAJ0jgIAA2EqAgAWXYAA=
Date: Sat, 20 Jul 2019 18:44:54 +0000
Message-ID: <E2F2DB75-FC35-4E00-B196-59ACCB3C4330@cisco.com>
References: <C3852A60-4580-47E9-A998-C0026D36523B@apple.com> <CAMZsk6eWTiGcAC0ONQ6HnqoZa-JFJHM+i4Q1ePG3XcJxgtrFMw@mail.gmail.com> <BBA82579FD347748BEADC4C445EA0F21BEEA6029@NKGEML515-MBS.china.huawei.com> <CAMZsk6egsu1rNYbJb=_dz_r9VBxmuVS0n0PUbhry+hY0N1UPpQ@mail.gmail.com> <BBA82579FD347748BEADC4C445EA0F21BEEA6F73@NKGEML515-MBS.china.huawei.com>
In-Reply-To: <BBA82579FD347748BEADC4C445EA0F21BEEA6F73@NKGEML515-MBS.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.c.190715
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rgandhi@cisco.com;
x-originating-ip: [2001:420:c0c8:1003::2c2]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5b57b63a-4e99-4a0c-7280-08d70d425b2b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:SN6PR11MB2767;
x-ms-traffictypediagnostic: SN6PR11MB2767:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: <SN6PR11MB2767CDB993AC47C4247BE4B4BFCA0@SN6PR11MB2767.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0104247462
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(346002)(376002)(366004)(136003)(45074003)(189003)(199004)(6486002)(14454004)(2906002)(99286004)(76176011)(966005)(478600001)(36756003)(54906003)(6436002)(68736007)(110136005)(58126008)(86362001)(256004)(7736002)(6506007)(53546011)(606006)(9326002)(102836004)(316002)(8936002)(81166006)(81156014)(186003)(486006)(6116002)(46003)(66556008)(6246003)(236005)(66476007)(33656002)(66946007)(71190400001)(446003)(25786009)(8676002)(11346002)(229853002)(6512007)(5660300002)(54896002)(6306002)(66446008)(64756008)(76116006)(4326008)(476003)(2616005)(53936002)(53946003)(71200400001)(91956017)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR11MB2767; H:SN6PR11MB3278.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: WS/Hbjdd2vE6moAUHCS8oWdiEfzCJtmfFYirak6/u172mRm0PnB1xOb8Kk1F1rPnA3Ia+A9EKGCijPnpqElicSsw8xXHPNsqyhF3JYz4M/L/vGu9ftQDQVpLVR9Rq+60lrfCHKp2kmU6WLsxSWtGC/QNVSrvd9U70o/zJqPi92OiG488bAkI5vTrtgMVKggdgv8qiwdMciup7I8W9bgVZvr0XP1Krnhp0L75Gp9oG+KX7Op4CC3u7FQiqiIUxHNu0Qn4J9G7hcrtDaJN2ihK8Q2gxRTwoel35pKA9ANRNTZZqS6mHM5Y6n9o42GiGB8yBZ+geFuU9y1hJAD3mfSBWlRIDI0x0BZeWOyuQOPXlfizDmVRdOTaXXWuec58sUl2fi/QU7BNKEzSuAvvzAAhRELAri1V21PJ5AQ+4ZjHyCw=
Content-Type: multipart/alternative; boundary="_000_E2F2DB75FC354E00B19659ACCB3C4330ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5b57b63a-4e99-4a0c-7280-08d70d425b2b
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2019 18:44:54.3002 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rgandhi@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2767
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/RbEb8FaEgJfnedno5nrpgUmMqds>
Subject: Re: [ippm] Adoption call for draft-mirsky-ippm-stamp-option-tlv
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jul 2019 18:45:04 -0000
Hi Tiaran, Please see inline with <RG>.. From: ippm <ippm-bounces@ietf.org> on behalf of Tianran Zhou <zhoutianran@huawei.com> Date: Tuesday, July 16, 2019 at 9:23 PM To: Rakesh Gandhi <rgandhi.ietf@gmail.com> Cc: "draft-mirsky-ippm-stamp-option-tlv@ietf.org" <draft-mirsky-ippm-stamp-option-tlv@ietf.org>, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, IETF IPPM WG <ippm@ietf.org> Subject: Re: [ippm] Adoption call for draft-mirsky-ippm-stamp-option-tlv Hi Rakesh, I think my point is that since stamp tlv may not be optimal for the hardware processing, it’s better not to apply it in that case. So I do not think it’s necessary to consider the hardware capability. <RG> I think with a simple rule of having the Direct Loss TLV as the first one, this should be applicable. On the other hand, stamp only takes small part of the traffic, it will not badly impact the forwarding performance. <RG> Some ASIC may not be able to load the entire payload data to modify it (especially with many TLVs including padding TLVs and LM TLV happens to be the last one). Thanks, Rakesh The timestamp is another story. Slow path processing will introduce the “observer effect”. So that the measurement will not be accurate. Thanks, Tianran From: Rakesh Gandhi [mailto:rgandhi.ietf@gmail.com] Sent: Tuesday, July 16, 2019 8:28 PM To: Tianran Zhou <zhoutianran@huawei.com> Cc: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>; draft-mirsky-ippm-stamp-option-tlv@ietf.org; IETF IPPM WG <ippm@ietf.org> Subject: Re: [ippm] Adoption call for draft-mirsky-ippm-stamp-option-tlv Hi Tianran, Yes, in some use-cases the TLV can carry the counters from the CPU processing (e.g. control-plane). In other use-cases, as the counters for the direct-mode LM (for actual data traffic) are in the hardware itself, the hardware can counter-stamp the probe packets just like time-stamping for DM Thanks, Rakesh On Mon, Jul 15, 2019 at 11:05 PM Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>> wrote: Hi Rakesh, I am not clear why the direct loss test need to be hardware friendly. It seems the STAMP is end to end over UDP. It could be CPU processing. Tianran From: ippm [mailto:ippm-bounces@ietf.org<mailto:ippm-bounces@ietf.org>] On Behalf Of Rakesh Gandhi Sent: Monday, July 15, 2019 10:48 PM To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org<mailto:40apple.com@dmarc.ietf.org>> Cc: draft-mirsky-ippm-stamp-option-tlv@ietf.org<mailto:draft-mirsky-ippm-stamp-option-tlv@ietf.org>; IETF IPPM WG <ippm@ietf.org<mailto:ippm@ietf.org>> Subject: Re: [ippm] Adoption call for draft-mirsky-ippm-stamp-option-tlv Hi Authors, There were couple of items discussed on the mailing list and have added them below for convenience. Like to see them addressed in the adopted draft. Thanks, Rakesh ------------------------------ Regarding the size of the padding, yes, it's good to use the same size payload for query and response. However, the STAMP payload with TLV extension (draft-mirsky-ippm-stamp-option-tlv-01) has slightly different padding size of 30 MBZ vs 27 ( or > 29)in draft-ietf-ippm-stamp. Is there a way to make them compatible? Does it mean that for STAMP with TLV, Server Octets is set to 1, but it says MBZ 0 for all 30 bytes.. If the responder supports Server Octets and see the size > 27, it may find the Server Octet size of 0 confusing? -------------------------- The direct measurement TLV proposed in the draft may not be hardware friendly for actual data traffic loss measurement due to the need to search the presence of the TLV and the counter offset not always fixed due to the variable length payload. Also, it overloads the delay measurement probes just for measuring packet loss which complicates the implementation. GIM>> The Direct Loss TLV is intended to immediately follow the STAMP test packet and thus its location is known. We'll work on the text to guide implementations to be more HW friendly and support efficient testing. <RG> Revised format looks like following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Estimate | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | MBZ (30 octets) | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Direct Measurement Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session-Sender Tx counter (S_TxC) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session-Reflector Rx counter (R_RxC) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session-Reflector Tx counter (R_TxC) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ On Mon, Jul 8, 2019 at 6:53 PM Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org<mailto:40apple.com@dmarc.ietf.org>> wrote: Hello IPPM, This message begins an adoption call for draft-mirsky-ippm-stamp-option-tlv, "Simple Two-way Active Measurement Protocol Optional Extensions”. The document has been discussed on the list recently, with good input and reviews from the group. We’d like to get the working group’s input on if this document should be adopted and worked on by the group. The current status and text of the document can be found here: https://datatracker.ietf.org/doc/draft-mirsky-ippm-stamp-option-tlv/ https://tools.ietf.org/html/draft-mirsky-ippm-stamp-option-tlv-05 Please respond to this email by Tuesday, July 23 to indicate whether or not you think IPPM should adopt and work on the extensions and extension mechanism described in this draft. Best, Tommy (as IPPM co-chair) _______________________________________________ ippm mailing list ippm@ietf.org<mailto:ippm@ietf.org> https://www.ietf.org/mailman/listinfo/ippm
- [ippm] Adoption call for draft-mirsky-ippm-stamp-… Tommy Pauly
- Re: [ippm] Adoption call for draft-mirsky-ippm-st… Jeff Tantsura
- Re: [ippm] Adoption call for draft-mirsky-ippm-st… xiao.min2
- Re: [ippm] Adoption call for draft-mirsky-ippm-st… Tianran Zhou
- Re: [ippm] Adoption call for draft-mirsky-ippm-st… guo.jun2
- Re: [ippm] Adoption call for draft-mirsky-ippm-st… Henrik Nydell
- Re: [ippm] Adoption call for draft-mirsky-ippm-st… Giuseppe Fioccola
- Re: [ippm] Adoption call for draft-mirsky-ippm-st… Greg Mirsky
- Re: [ippm] Adoption call for draft-mirsky-ippm-st… Jai Kumar
- [ippm] R: [EXT] Adoption call for draft-mirsky-ip… Cociglio Mauro
- Re: [ippm] Adoption call for draft-mirsky-ippm-st… David Sinicrope
- Re: [ippm] Adoption call for draft-mirsky-ippm-st… David Sinicrope
- Re: [ippm] Adoption call for draft-mirsky-ippm-st… Foote, Footer (Nokia - CA)
- Re: [ippm] Adoption call for draft-mirsky-ippm-st… Rakesh Gandhi
- Re: [ippm] Adoption call for draft-mirsky-ippm-st… Tianran Zhou
- Re: [ippm] Adoption call for draft-mirsky-ippm-st… Rakesh Gandhi
- Re: [ippm] Adoption call for draft-mirsky-ippm-st… Greg Mirsky
- Re: [ippm] Adoption call for draft-mirsky-ippm-st… Greg Mirsky
- Re: [ippm] Adoption call for draft-mirsky-ippm-st… Tianran Zhou
- Re: [ippm] Adoption call for draft-mirsky-ippm-st… Rakesh Gandhi (rgandhi)
- Re: [ippm] Adoption call for draft-mirsky-ippm-st… Rakesh Gandhi
- Re: [ippm] Adoption call for draft-mirsky-ippm-st… Tommy Pauly
- Re: [ippm] Adoption call for draft-mirsky-ippm-st… J Ignacio Alvarez-Hamelin