Re: [lisp] Magnus Westerlund's No Objection on draft-ietf-lisp-gpe-17: (with COMMENT)
"Fabio Maino (fmaino)" <fmaino@cisco.com> Tue, 14 July 2020 15:35 UTC
Return-Path: <fmaino@cisco.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C2B3A089B; Tue, 14 Jul 2020 08:35:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.62
X-Spam-Level:
X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=V7BCDXwF; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=GO5o7IgU
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 HhReEaDXsOL8; Tue, 14 Jul 2020 08:35:53 -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 65E653A088A; Tue, 14 Jul 2020 08:35:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14214; q=dns/txt; s=iport; t=1594740953; x=1595950553; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NHCJBqcDjRDgEtcwkJguCv7uUHEDuH/ypncSe/ekmyQ=; b=V7BCDXwFhVl+Cm6ADmmka3Fuu67NrxgtdY0g+m21yTHEJh1qaftHiSoP NPN7zeIedIKW1nTNU0w4iDl5x7HddpMr36kAkb/SHIo98Roj+7kuIse1u gxSu2hsYUxetoVNh0afMYoW4mbA7/Z2KEg1AmVo88QG66PRpVYhRavX5N g=;
IronPort-PHdr: 9a23:szhD5Rcpd1i+X0Gf2hCh13jGlGMj4e+mNxMJ6pchl7NFe7ii+JKnJkHE+PFxlwaTBdfW8fNPkPHRtebrXmlTqZqCsXVXdptKWldFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBr2ez5iUJHRO5Pg1wdaz5H4fIhJGx0Oa/s5TYfwRPgm+7ZrV/ZBW7pAncrI8Ym4xnf60w0RDO5HBPfrdb
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AeAAAi0A1f/5ldJa1gGQEBAQEBAQEBAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFAgTkBAQEBAQELAYFRUQdvWC8sCoQpg0YDjVGYXoFCgREDVQsBAQEMAQEjCgIEAQGETAIXgXACJDcGDQECAwEBCwEBBQEBAQIBBgRthVsMhXABAQEDEhERDAEBNwENAgIBCBgCAiMDAgICGRcUARACBAENBSKDBAGCSwMuAQ6eTQKBOYhhdoEygwEBAQWBRkGDBhiCDgMGBYEJKgGCaYNVhjMagUE/gREnHIJNPoJcAgECAYEmARIBIReCfzOCLY8RCA8CCoMUiVuZBgqCXYhTjBuEbAMegnaJOYUljWCRcYFmf4c/lFMCBAIEBQIOAQEFgWkkZ1gRB3AVZQGCPlAXAg2OHoNxhRSFQnQCNQIGAQcBAQMJfI4/ATFfAQE
X-IronPort-AV: E=Sophos;i="5.75,350,1589241600"; d="scan'208";a="543189759"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jul 2020 15:35:52 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 06EFZqZN000558 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Jul 2020 15:35:52 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 14 Jul 2020 10:35:51 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 14 Jul 2020 10:35:51 -0500
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 14 Jul 2020 10:35:50 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Gjmv8z+b5CQTqtpvsDir8bQbyR5MouCvjoecQceVTMszQ2vldIEncv892I/ehAzBd9Qe6rEfkkUMwwmH0BJ1jHvh36F0HhIzTr63JAEAmse//f6ZWdsAnjNtfwqzKuDG34M+XI+sUiEW5C1FUCNyx/hHcSHyMMYV+ydr1kUspPwm6O39FMLTDvoeiYCdaBW6m55o0hSc1IRUqXuJ69jFbXGsUSgGrbi8OM2G0AvlUkgszJxiDXjaxxXk3Ai/3V463/R6U6aLFMKmEyG1NBulAkuPJ0QlqdwC0OOB7SHukzViXjK1Zsh9PUsGSiZMIi0ItTLh/JQv3BvY0g0PFDRT7w==
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=NHCJBqcDjRDgEtcwkJguCv7uUHEDuH/ypncSe/ekmyQ=; b=QgR7CyJW7zVZsj/POHwEc0qNcH1HOa6HFsVKoPwkuIIYWK2N6infj+i8+ogvfMOmd1kCV13SdnVDIVeIOTPj0ylwnGc9PcetQbRIzPzxA+rn18wVL+Afpkb6iu+F6uKHQFmN0xBA40gVmq9ySJ6OUzofnYuDt8ahVG28UqFans10qBLMQc7ZUHNpQm09UWwIlruR4fVJFRndsckc+Q6vuVZ/w9Jf1Uhoe5IjQQET6ZUsT5uo3MDO5HPkjlQ/31fz9EKolS9emT6uNu06JSDnTtdrcLgGjnpmuRaFrjfUDJbZ+CXqJm3FZ2p429kPUuJ/VXGMoark9ivo4jz8V7mfsQ==
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=NHCJBqcDjRDgEtcwkJguCv7uUHEDuH/ypncSe/ekmyQ=; b=GO5o7IgUORqKF6vTHYQ26uqt8CKnpets1I1SuwEDEU9m2y1f/mE3+/CzlVBQo4dkczJ4RMTiZtxXZhAaiYGkcUSwCaytSlh75WrkYuvgjaRLp+PNkS5x4HhXB/VpvuS9RY8/QZpxaeo9RadeDcHfgo3f4wBo6TFLex8cDZc988s=
Received: from BY5PR11MB4420.namprd11.prod.outlook.com (2603:10b6:a03:1c9::20) by BYAPR11MB3576.namprd11.prod.outlook.com (2603:10b6:a03:b4::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.17; Tue, 14 Jul 2020 15:35:49 +0000
Received: from BY5PR11MB4420.namprd11.prod.outlook.com ([fe80::d05d:f20e:c1a4:75b]) by BY5PR11MB4420.namprd11.prod.outlook.com ([fe80::d05d:f20e:c1a4:75b%6]) with mapi id 15.20.3174.026; Tue, 14 Jul 2020 15:35:49 +0000
From: "Fabio Maino (fmaino)" <fmaino@cisco.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "jmh@joelhalpern.com" <jmh@joelhalpern.com>, "iesg@ietf.org" <iesg@ietf.org>
CC: "draft-ietf-lisp-gpe@ietf.org" <draft-ietf-lisp-gpe@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>, "ggx@gigix.net" <ggx@gigix.net>, "lisp-chairs@ietf.org" <lisp-chairs@ietf.org>
Thread-Topic: Magnus Westerlund's No Objection on draft-ietf-lisp-gpe-17: (with COMMENT)
Thread-Index: AQHWVe6TrPTH1MNYQEGxO6dEGUBD7aj/AT+AgACFqYCAAAH5AIABTleAgASYSoCAAWuPgP//7J0A
Date: Tue, 14 Jul 2020 15:35:49 +0000
Message-ID: <B736D154-817D-4D55-8EAC-C466F6B97765@cisco.com>
References: <159429861569.12326.4735174452265776723@ietfa.amsl.com> <1464C8A8-747A-45CB-8F62-9E96373C0D67@cisco.com> <54ee2cbb0c528b6c5aa36f88a8cf78d2d7d0ff09.camel@ericsson.com> <f6a3ce17-1033-01c3-2995-089845df1524@joelhalpern.com> <0bf2d991265c7d6db61b9a0493b5911e1bd6190c.camel@ericsson.com> <5D3EC015-D57E-4C39-AF8C-0592C2D72601@cisco.com> <c7b541053c33290d3a0b81d3a6e79bf618bf1e32.camel@ericsson.com>
In-Reply-To: <c7b541053c33290d3a0b81d3a6e79bf618bf1e32.camel@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.38.20061401
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [75.25.137.103]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c9f11812-c49c-48c0-731f-08d8280b958d
x-ms-traffictypediagnostic: BYAPR11MB3576:
x-microsoft-antispam-prvs: <BYAPR11MB35761AABE53043EE5236D9CCC2610@BYAPR11MB3576.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Yu0O7M12ZQSd6Gzxcn/MjhjMDqOWVztxcSGhe/SwaVIGzWXlpT8R7EGz6Qp05DpeM0Hc0fT46VyNh3hiuWbAH1Y2O/w5BviNGhpmzSIRywow0cdE7rky1XYBFIXZuNpVrU7t5HE/7VCPUM7IDKMs9u/+/vkrMbwbDGXtTizhvnxazeVpvWilMH4Ur5lFGA2eL9VmNys0nayKdd4bIg2Dsbz9npEdnnTNMWTHlU/M6amQVjXRxOaEehf4+S2pMFsw4onqTn4ylUlh8SEYVthE9XDPHbotShvsP0R6D0wdOzh+12NWcQZUVc6pzVnp3ztDfue9/6meNGl3WiPknPFtHUSmnVh2OHwBw6utlMLv6XCxhwYq3wykIamzDt5b6T9rGs+vIoK66HhnjU0N84JlgA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4420.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(136003)(396003)(376002)(39860400002)(366004)(478600001)(8936002)(2906002)(71200400001)(83380400001)(6512007)(6506007)(33656002)(53546011)(36756003)(316002)(6486002)(4326008)(26005)(66946007)(110136005)(76116006)(186003)(966005)(54906003)(66446008)(5660300002)(64756008)(8676002)(66476007)(2616005)(66556008)(86362001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: BiVlIjEeK4gQQxc/4vlXjf+BbZWR+33oo9SW87zeiGJ/VBjirE9GlmB/4I7J1xGiJPqoQe7exFp0U8QAwPTvDwf2RHP1oWyB7/1QJPiAPhF7L3mXw6/7AaLvuSm0Y1kRoUId/9t4mQl99q2k5I76kh/LapZ72yxy+ACAMX4ChBByQuesMogqDxcxJiUkFwU25KNqC22VC3oXULPAnkaclH1c2eFC1aWK4DSTfmlESWRTkRgEeL9uPh7G2YO+87bgdI9Q1yZ/a/EpTGxQu8tpqwYK3294euPp5Wpx7MuZy5a0xrnMADHlsDKA2pkTlumCWMw38YBc2YcCOG52/ECxa/B4Cf3xNCsrEbALWcTDYYojlIDmJr8MX96mQEy7C34vXxp/UZRxT05IORzjm5SQz2Q43DFzLM1OD854jJz4iNhK07gt54RgyVVLAYjdX51THmYaSFKrwW4lKRZ/YYGIespjSzeagjlLqGw9AzWmaXY=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <E7F7E661A6C71441BB48EFF764180972@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4420.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c9f11812-c49c-48c0-731f-08d8280b958d
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2020 15:35:49.0172 (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: b3z0zB8BUJRqD++svLdu+E4DuIZRcgaP0ZPuwdUUhJEP4u8qS+fhfEu54B/HsV/vgjyvLNjyYCDjiGbAvihgrQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3576
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/nihN001moBc0Wa9fhIf1OKV67dY>
Subject: Re: [lisp] Magnus Westerlund's No Objection on draft-ietf-lisp-gpe-17: (with COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jul 2020 15:35:56 -0000
Hi Magnus, sounds good, I'll update that text as soon the publication window reopens. Thanks! Fabio On 7/14/20, 2:45 AM, "Magnus Westerlund" <magnus.westerlund@ericsson.com> wrote: Hi, From my perspective the below is still a normative reference formulation. You have to read the reference to be able to determine if you SHOULD follow them or not. Maybe adopting the paragraph which draft-ietf-tsvwg-ecn-encap-guidelines proposes to update RFC 3819 with: By following the guidelines in [RFCXXXX], subnetwork designers can enable a layer-2 protocol to participate in congestion control without dropping packets via propagation of explicit congestion notification (ECN [RFC3168]) to receivers. Into the below text can make it inforamtive. Keeping in mind the recommendation above, new encapsulated payloads, when registered with LISP-GPE, should be designed for explicit congestion signals to propagate consistently from lower layer protocols into IP. Then the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Such new encapsulated payloads, when registered with LISP-GPE, MUST be accompanied by a set of guidelines derived from [RFC6040]. Following the guidelines in [I-D.ietf-tsvwg-ecn-encap-guidelines], designers of new LISP-GPE encapsualtions can enable LISP GPE and the encapsulated payload to participate in congestion control without dropping packets via propagation of explicit congestion notification (ECN [RFC3168]) to receivers. Please word smith. I still think this is borde line case for a informative reference but at least it is not directly part of an RFC 2119 language sentence. Cheers Magnus On Mon, 2020-07-13 at 19:04 +0000, Fabio Maino (fmaino) wrote: > Magnus, > here is how we modified the latest version of the draft trying to reflect your > concerns, and to deal with the status of the ecn-encap-guidelines draft. > > 4.2. Congestion Control Functionality > > LISP-GPE does not natively provide congestion control functionality > and relies on the payload protocol traffic for congestion control. > As such LISP-GPE MUST be used with congestion controlled traffic or > within a network that is traffic managed to avoid congestion (TMCE). > An operator of a traffic managed network (TMCE) may avoid congestion > by careful provisioning of their networks, rate-limiting of user data > traffic and traffic engineering according to path capacity. > > Keeping in mind the recommendation above, new encapsulated payloads, > when registered with LISP-GPE, should be designed for explicit > congestion signals to propagate consistently from lower layer > protocols into IP. Then the IP internetwork layer can act as a > portability layer to carry congestion notification from non-IP-aware > congested nodes up to the transport layer (L4). Such new > encapsulated payloads, when registered with LISP-GPE, MUST be > accompanied by a set of guidelines derived from [RFC6040] and SHOULD > follow the guidelines defined in [I-D.ietf-tsvwg-ecn-encap-guidelines]. > > > Thanks, > Fabio > > On 7/10/20, 6:54 AM, "Magnus Westerlund" <magnus.westerlund@ericsson.com> > wrote: > > On Thu, 2020-07-09 at 13:57 -0400, Joel M. Halpern wrote: > > Magnus, while it is possible we will still get hold ups on the LISP > > documents, I would really prefer to avoid creating a normative > > dependency on something that at best is 6 months away. Particularly > > since the TSVWG has not cared enough to maintain the document. > > I can understand that. So then think you need to figure out what > requirements > from that document that you thought was relevant to say that they MUST be > included in a future specification and include them in the GPE document so > that > the ecn-encap-guidelines would only be inforamtional reference. > > Cheers > > Magnus > > > > > Yours, > > Joel > > > > On 7/9/2020 1:50 PM, Magnus Westerlund wrote: > > > Hi, > > > > > > No, RFC 3819 is not a good replacement for the draft. I would note > that only > > > a > > > minor part of RFC 3819 is updated by draft-ietf-tsvwg-ecn-encap- > guidelines. > > > > > > So I contacted the TSVWG chairs to try to get an update on when the > document > > > could be ready. The WG has not abandonded it. Actually I found an > updated > > > version from March that simply failed to make it into the public > archive at > > > that > > > point. > > > > > > I will also note that the document has gone through one WG last call > and > > > appear > > > to be in descent shape. The only issue is that the main author been > busy > > > with > > > L4S that is a hot topic in TSVWG. > > > > > > We have requested an estimate for an update from Bob Briscoe so that > we can > > > get > > > this document going forward. > > > > > > So it might be possible to get this document approved before the end > of the > > > year. > > > > > > As an alternativ there might be possible that you can reformulate the > > > sentence > > > so that the high level requirement that the reader is expected to > derive is > > > expressed in your document, and then you can get to a state where the > > > reference > > > would only be informative? > > > > > > Cheers > > > > > > Magnus > > > > > > > > > > > > On Thu, 2020-07-09 at 16:51 +0000, Fabio Maino (fmaino) wrote: > > > > Hi Magnus, thanks for your comments. > > > > > > > > Wrt I-D.ietf-tsvwg-ecn-encap-guidelines it turns out that the draft > is > > > > expired, so making it normative might not be an option. > > > > > > > > Since it is meant to replace RFC3819, should we refer to RFC3819 > instead? > > > > > > > > Thanks, > > > > Fabio > > > > > > > > > > > > > > > > On 7/9/20, 5:43 AM, "Magnus Westerlund via Datatracker" < > noreply@ietf.org > > > > > > > > > wrote: > > > > > > > > Magnus Westerlund has entered the following ballot position for > > > > draft-ietf-lisp-gpe-17: 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 > > > > 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-lisp-gpe/ > > > > > > > > > > > > > > > > --------------------------------------------------------------- > ------ > > > > - > > > > COMMENT: > > > > --------------------------------------------------------------- > ------ > > > > - > > > > > > > > Section 4.2: > > > > > > > > To me it looks like this is normative reference: > > > > > > > > Such new encapsulated payloads, when registered with LISP- > > > > GPE, MUST be accompanied by a set of guidelines derived from > > > > [I-D.ietf-tsvwg-ecn-encap-guidelines] and [RFC6040]. > > > > > > > > Section 4.3.1: > > > > > > > > Thanks for writing relevant guidance on how to mitigate the > risks > > > > with > > > > zero > > > > checksum. Especially the one on traffic separation from other > traffic > > > > so > > > > that > > > > it can be caught on the boundaries of the network to prevent > the risk > > > > to > > > > other > > > > networks from corrupted traffic. > > > > > > > > > > > > > > > > > > > > > -- > Cheers > > Magnus Westerlund > > > ---------------------------------------------------------------------- > Networks, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > > -- Cheers Magnus Westerlund ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- [lisp] Magnus Westerlund's No Objection on draft-… Magnus Westerlund via Datatracker
- Re: [lisp] Magnus Westerlund's No Objection on dr… Fabio Maino (fmaino)
- Re: [lisp] Magnus Westerlund's No Objection on dr… Magnus Westerlund
- Re: [lisp] Magnus Westerlund's No Objection on dr… Joel M. Halpern
- Re: [lisp] Magnus Westerlund's No Objection on dr… Magnus Westerlund
- Re: [lisp] Magnus Westerlund's No Objection on dr… Fabio Maino (fmaino)
- Re: [lisp] Magnus Westerlund's No Objection on dr… Magnus Westerlund
- Re: [lisp] Magnus Westerlund's No Objection on dr… Fabio Maino (fmaino)
- Re: [lisp] Magnus Westerlund's No Objection on dr… Fabio Maino (fmaino)
- Re: [lisp] Magnus Westerlund's No Objection on dr… Magnus Westerlund