Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-11: (with DISCUSS)
Balázs Varga A <balazs.a.varga@ericsson.com> Wed, 09 September 2020 17:24 UTC
Return-Path: <balazs.a.varga@ericsson.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 823B73A0B6B; Wed, 9 Sep 2020 10:24:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 fWlhFJMItVuJ; Wed, 9 Sep 2020 10:24:30 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60082.outbound.protection.outlook.com [40.107.6.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 701A83A0B98; Wed, 9 Sep 2020 10:24:29 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DpLIzYTCXGSchdjEf6Nad5+MJ153QZiPkuXwrhEw9RwhfRAqxk8/1lTl3TGERSjsTIcYD9OrlstOdUBVtSu3JC99kUldINU8NaRDLZPeANZ8asfhk52e45en+FgiSVPnB/sjs5gSEJdmMsp+s7A+RmuaIyy/oFnhfIXcYnmhgNgbWEIZ6FfOKuciSBY+aaw0hD99XIiD+RoZy8G9iCZkGZCa1FOIjJ26yayr9yx4lyIRMtCWQGu1Ac9V3ftKOFtKxeTnJiadhQbeQGGzFYt4w1Rb4CG7ONWMIviv8xvw8w4UzrOmWmpg1Gf+aLAWLSh2HhGdPWGNSLYBBF/ielZyLQ==
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=ccHmVecVPRibFPsIhwzg+6JZDSTaL4p4bAAV9ua5Pwo=; b=OkANhkUB/P6KKuCqikho+LIgYXyAPQQF7e3kgwkOSrrtmVAimJdeDM/wdC4GiDbKA9MinULE/kME06Xu59vaXHBPFx70WaX4YCLgJe3lPRNKr+cEAMlQ6uSh4Howp0BrWD0qSmLdCDHY1n7YFaEkoszBmOVAJjgd7hYmF4PJXpb3rIJo4XmtonJ0P087/91kzTpYDoT+TUlxoz6DqjG1SGAVCO9JwmRAZsR1lKJxR5Tn4Tj6Ntc4vA0+PpvOmgKifxLVK4CP+7CCbG7A97dQVgQ3iuEFZ46i2B8EYR3ZIpGD8iGJLgqvip0K9lj20LMg0QVT9NROVq4+NRFSFB54WQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ccHmVecVPRibFPsIhwzg+6JZDSTaL4p4bAAV9ua5Pwo=; b=BZ3ynWHvp2GuZ445RpS8rbIF+Sym91JhIPpkP+aaS/wNi+/aECSz/O//9LBnsp6HK1oTXpGrpEz4MIrglmnWTo04imgb/eYbxa1CYibUu43eIVpLLAORVN1s4kH/laUbTgXsC6MEU2sNLYgqyycUt8oUnrkQN8fY8Wr221pVFPQ=
Received: from AM0PR0702MB3603.eurprd07.prod.outlook.com (2603:10a6:208:22::25) by AM0PR07MB6321.eurprd07.prod.outlook.com (2603:10a6:20b:151::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.7; Wed, 9 Sep 2020 17:24:27 +0000
Received: from AM0PR0702MB3603.eurprd07.prod.outlook.com ([fe80::59ca:540d:b7f3:58b9]) by AM0PR0702MB3603.eurprd07.prod.outlook.com ([fe80::59ca:540d:b7f3:58b9%6]) with mapi id 15.20.3370.016; Wed, 9 Sep 2020 17:24:27 +0000
From: Balázs Varga A <balazs.a.varga@ericsson.com>
To: Loa Andersson <loa@pi.nu>, Stewart Bryant <stewart.bryant@gmail.com>, Lou Berger <lberger@labn.net>
CC: Magnus Westerlund <magnus.westerlund@ericsson.com>, "draft-ietf-detnet-mpls@ietf.org" <draft-ietf-detnet-mpls@ietf.org>, Toerless Eckert <tte@cs.fau.de>, The IESG <iesg@ietf.org>, "detnet-chairs@ietf.org" <detnet-chairs@ietf.org>, "eagros@dolby.com" <eagros@dolby.com>, "detnet@ietf.org" <detnet@ietf.org>
Thread-Topic: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-11: (with DISCUSS)
Thread-Index: AQHWhfINU5anfljNEEadoJDf/bCZFKlfHCQAgAE2HOCAABt0gIAABSwAgAAFgQCAAAL5AIAAFI7w
Date: Wed, 09 Sep 2020 17:24:27 +0000
Message-ID: <AM0PR0702MB36034EEFB5B1D628B9A0E3E7AC260@AM0PR0702MB3603.eurprd07.prod.outlook.com>
References: <159957776121.26189.12459072134609921207@ietfa.amsl.com> <20200908191238.GA64458@faui48f.informatik.uni-erlangen.de> <AM0PR0702MB36038CF057CF2B13B7994F9EAC260@AM0PR0702MB3603.eurprd07.prod.outlook.com> <20200909152049.GA45828@faui48f.informatik.uni-erlangen.de> <58b84865-95bb-da9e-0172-8b94cee40e76@labn.net> <C6AD0E82-1DED-4223-865A-25CF833C8DDA@gmail.com> <2b59b5be-edd0-725a-bb8a-43cfc288c218@pi.nu>
In-Reply-To: <2b59b5be-edd0-725a-bb8a-43cfc288c218@pi.nu>
Accept-Language: hu-HU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: pi.nu; dkim=none (message not signed) header.d=none;pi.nu; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [185.29.82.162]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6fbb8700-56a7-4823-998b-08d854e5341f
x-ms-traffictypediagnostic: AM0PR07MB6321:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <AM0PR07MB6321B985999589282DED4058AC260@AM0PR07MB6321.eurprd07.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: pdD9feXkKIZo1+SVcDo8I351d1w5izJV450iwuzcTlmEdBCcswfKiRS926VGt59cZoOkUQmEKKi0DouEc7zy9htXG8mRX6Y8WJ79FB8RZwvcxxNwPvWu+ZHM9Y53giX3IEnqN0Fv2+dH3xh3G6CKJjO/Fv1UB1ApmqDum+DzlqHgrLEHpKgq3oq4xIIuJaWFUxoMZW/s4U2svkbDOAQ9dksLEhC7oKhIPhv0nnIh0M3NY+NyQF8FeWEYt3lAjc07sXVHHqzWeMEG5/3TaQyq5F+L6XnrkDSBHJwi7NV4ijbix4QVvdn3rq9Q0ayIHXockOdT08KKqSHOPTYGtETQGKrKsOoXdbLAm1HPRxb3OQ5ai6FmUeo4LCtRck1V7vf3VdcYP5GztPGk45gMqYINKg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0702MB3603.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(396003)(136003)(376002)(346002)(55016002)(66946007)(5660300002)(54906003)(110136005)(64756008)(66476007)(66556008)(76116006)(9686003)(66446008)(52536014)(85202003)(85182001)(33656002)(4326008)(478600001)(8676002)(8936002)(53546011)(6506007)(71200400001)(30864003)(2906002)(186003)(7696005)(26005)(86362001)(316002)(66574015)(966005)(83380400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: oaMYuYPmhoKhadADWm1+18RF/5Ul4pgaG/IqO/qHxyBs9I8ff8zYDGQhvki7Yt0RANs2tyM5gm7dx6ki1rjCGz65sBMcpQ26BteA1rSiojTZkkU/99Cp89qt0m00y/QoirySukySoBUw3rAihZXFh5ajyYnm4lBFibBcsgPs1ssJKG9Ptm81FqL0664m+FeZ0F7C+30kJU7EVOjfedU/UWKEC2Y9GcH5EJIlf7mjAx/lYhaIQquC3IAykAsnvPf5HQFOIbjX9nVrp5I3b20/F1fHmHdGR/sJJaQPEYksVw1TfiQkaFXRhfkF06HcpWCZ6IwQGtfAiJIJ7epFNghoDXa9GuPWgjE3MPJxdvT22fZ5S/EXT0PQvDK+R8/wjGjDTUXNgzzSH2yqlghv253UXqVqUBF2uBOSfsEFaG63rJ0+Lj9SZ76tyzy18tMkWPRKjrKt4ml9VI/EicMzlUZlD2qbjIjGIjE6jXd9GXiO6ylKFu0LA8+WItqX4/y5CeqHo3HJbnFSUGfmcr2mZdBOh9VcW4UxOF3YVbFvx3Ha2359l2S/zB1cOaXGUyddxpkLc696zGP0NRw+GBIGkg+QxuLScgbRAojmQlyC/fgi8C4pIFRQSzgbr5Lz8szbITDe+O74AGoPAdeQMAng1sxOig==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR0702MB3603.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6fbb8700-56a7-4823-998b-08d854e5341f
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2020 17:24:27.1075 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Q39WPH1lQpw2B+8exZQfnG4HOFp8IC9E/7GzHVooJSex4B2Ose+lwjf8jzJAV5/yG8OYtrpWJBDScVNfbZ3O9ut9QNEp9r8KBURQXEeLLpA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6321
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/yhuWCOsifzFr3YJtQBwgX0qb24o>
Subject: Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-11: (with DISCUSS)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Sep 2020 17:24:33 -0000
Hi All, Many thanks for the suggestions. I will update the draft to match rfc8655. Cheers Bala'zs -----Original Message----- From: Loa Andersson <loa@pi.nu> Sent: Wednesday, September 9, 2020 6:10 PM To: Stewart Bryant <stewart.bryant@gmail.com>; Lou Berger <lberger@labn.net> Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>; draft-ietf-detnet-mpls@ietf.org; Toerless Eckert <tte@cs.fau.de>; Balázs Varga A <balazs.a.varga@ericsson.com>; The IESG <iesg@ietf.org>; detnet-chairs@ietf.org; eagros@dolby.com; detnet@ietf.org Subject: Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-11: (with DISCUSS) All, While I won't cry if this is dropped, I'm a little bit more than a bit concerned that every time we try to state what we can expect of a DetNet service we seem to stumble on the finish line. If it works for MPLS and is updated to match RFC 8655, I'd say we leave it in. /Loa On 09/09/2020 23:59, Stewart Bryant wrote: > I think it has to be dropped, because as the work stands I cannot see that we have a way of bounding the latency. > > I know that we are talking about MPLS, but of course we need to look at all of the data plane drafts in this respect. > > - Stewart > > > >> On 9 Sep 2020, at 16:39, Lou Berger <lberger@labn.net> wrote: >> >> The doc currently reads (asterisks indicate the sentence under discussion): >> >> 1. Introduction >> >> Deterministic Networking (DetNet) is a service that can be offered by >> a network to DetNet flows. *DetNet provides these flows with >> extremely low packet loss rates and assured maximum end-to-end >> delivery latency.* General background and concepts of DetNet can be >> found in [RFC8655]. >> >> The sentence in question was copied from the draft version of RFC8655, which now reads slightly differently: >> >> ... which provides a capability for the delivery of >> data flows with extremely low packet loss rates and bounded end-to- >> end delivery latency. >> >> I suggest either (a) updating the draft to match the RFC text or (b) dropping it altogether and let the reference to RFC8655 stand alone. >> >> Lou >> >> On 9/9/2020 11:20 AM, Toerless Eckert wrote: >>> On Wed, Sep 09, 2020 at 01:50:34PM +0000, Bal?zs Varga A wrote: >>>> Hi Toerless, >>>> >>>> Many thanks for the comments. One remark: >>>> - I disagree with your statement "DetNet like any other IP/MPLS network with per-flow forwarding provides" >>>> Just as an example, PREOF functions are not available in current MPLS networks. >>> PREOF is not subject of the sentence part in question. My concern is only about: >>> >>> ... DetNet provides zero congestion loss and bounded latency and >>> jitter >>> >>> Of course, now you mention it: The MPLS forwarding plane of this >>> spec does support PEROF, but the sentence only talks about "DetNet", >>> for which at large in my assesment this is not true (no current PREOF for IPv4/IPv6 AFAIK). >>> >>> Aka: also for the part of PREOF its better to re-scope the sentence >>> to talk only the MPLS forwarding plane of this document instead of >>> (unnecessarily?) make claims about DetNet at large. >>> >>> Cheers >>> Toerless >>> >>>> Thanks >>>> Bala'zs >>>> >>>> -----Original Message----- >>>> From: Toerless Eckert <tte@cs.fau.de> >>>> Sent: Tuesday, September 8, 2020 9:13 PM >>>> To: Magnus Westerlund <magnus.westerlund@ericsson.com> >>>> Cc: The IESG <iesg@ietf.org>; eagros@dolby.com; detnet@ietf.org; >>>> draft-ietf-detnet-mpls@ietf.org; detnet-chairs@ietf.org >>>> Subject: Re: [Detnet] Magnus Westerlund's Discuss on >>>> draft-ietf-detnet-mpls-11: (with DISCUSS) >>>> >>>> Thanks Magnus, *: >>>> >>>> Related to your comments, i would like to raise a concern about the initial sentence in the spec: >>>> >>>> ...DetNet provides zero congestion loss and bounded latency and jitter. >>>> >>>> To me, this is overselling what DetNet actually "provides" or that uniquely distinguishes DetNet from other solutions. It sounds as if DetNet provides a novel solution whereas in reality it just allows to adopt existing or new solutions. >>>> >>>> With the definitions DetNet has done today, any IP or MPLS network where end-to-end flows can be identified as e.g.: an IP 5-tuple or an LSP identifier and that manages to figure out how to implement or operationalize one of the solutions for bounded latency such as a PHB in support of rfc2212. >>>> >>>> Aka: one could equally write: >>>> >>>> ...DetNet like any other IP/MPLS network with per-flow forwarding provides zero congestion loss and bounded latency and jitter. >>>> >>>> Which would be equally true and equally misleading. >>>> >>>> So, here is proposed IMHO more technically correct text to replace the IMHO misleading "marketing" sentence segment: >>>> >>>> ...DetNet MPLS sets up point-to-point LSPs end-to-end across DetNet domains. >>>> >>>> Because of this, DetNet MPLS can integrate with pre-existing and/or >>>> future Per-Hop-Behavior >>>> (PHB) (such one derived from RFC2212) that can provide per-flow (e.g.: LSP) bounded latency, bounded jitter and no congestion loss, as long as such a PHB does not require additional network packet header information beside the flow/LSP identification. >>>> >>>> Cheers >>>> Toerless >>>> >>>> On Tue, Sep 08, 2020 at 08:09:21AM -0700, Magnus Westerlund via Datatracker wrote: >>>>> Magnus Westerlund has entered the following ballot position for >>>>> draft-ietf-detnet-mpls-11: Discuss >>>>> >>>>> 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-detnet-mpls/ >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------ >>>>> ---- >>>>> DISCUSS: >>>>> ------------------------------------------------------------------ >>>>> ---- >>>>> >>>>> I like to thank the TSV-ART reviewer for helping me consider one >>>>> aspect of the issue I see needing some discussion for this document. >>>>> >>>>> This relates to Section 4.2.2.2. and 4.2.2.3. >>>>> >>>>> So both of these section discuss the use of the sequence number >>>>> for removing packet duplicates and handling reorder. As the text >>>>> discusses there can be a configured limit for how deep the buffer >>>>> and state are for performing these operations. We all know that >>>>> the implementation of this will have a practical limit in both >>>>> buffer space for reordering as well as state for tracking which >>>>> sequence numbers that have been forwarded. I think that should be >>>>> more clearly expressed in the document that these practical limits >>>>> exists. Thus, the implementations will have tracking and determination of what are new packets (increasing sequence number within a window higher than previous largest seen. >>>>> And consider sequence number form currently highest seen and a bit >>>>> backwards as older packets. Thus how this is implemented will >>>>> impact how this acts in cases of disruptions of the packet flow. >>>>> Thus, I wonder if there is actually need to be a bit more >>>>> specific in how classification should be done. Especially if the >>>>> wrap-around of the sequence number space approaches a small multiple of round trip times for the path which is likely for the 16-bit space. >>>>> >>>>> Then sections fails to discuss how the duplication removal, the >>>>> reordering buffering and bound latency interacts and affet each other. >>>>> So if the latency is bounded then the reordering has an hard time >>>>> limit for the maximum delay. If there is a boundary for reordering >>>>> then there are no point in de-duplicating packets that will not be >>>>> forwarded due to the reordering. And even if there are no bounded >>>>> latency the reordering buffer size will still impact the depth of >>>>> de-duplication. These practical limits will also be limitations on the guarantees that can be provided. >>>>> >>>>> Thus, from my perspective there is need for more text on the >>>>> requirements of the implementation of these functions and their >>>>> interactions of creating limitations. >>>>> >>>>> Another point on 4.2.2.2: >>>>> >>>>> When configured, the >>>>> implementation MUST track the sequence number contained in received >>>>> d-CWs and MUST ensure that duplicate (replicated) instances of a >>>>> particular sequence number are discarded. >>>>> >>>>> That second MUST I think is possible to meet given that one >>>>> discard all packets outside of the current window where one have >>>>> information if a packet sequence number have been forwarded or >>>>> not. Given that a very late packet beyond the amount of state for >>>>> the flow likely anyway have little utility that is likely the >>>>> right choice. However, I think it needs to be made explicit that this is okay. >>>>> >>>>> In Section 4.2.2.3: >>>>> >>>>> When configured, the >>>>> implementation MUST track the sequence number contained in received >>>>> d-CWs and MUST ensure that packets are processed in the order >>>>> indicated in the received d-CW sequence number field, which may not >>>>> be in the order the packets are received. >>>>> >>>>> I think this part needs to be explicit that packets that are to >>>>> fare out of order for the implementation to handle will/shall be dropped. >>>>> >>>>> Note that an implementation MAY wish to constrain the maximum number >>>>> of out of order packets that can be processed, on platform-wide or >>>>> per flow basis. Some implementations MAY support the provisioning of >>>>> this number on either a platform-wide or per flow basis. The number >>>>> of out of order packets that can be processed also impacts the >>>>> latency of a flow. >>>>> >>>>> If there exists a latency requirement then that will interact with >>>>> this when it comes to reordering. In fact a significant issue here >>>>> is that if the packet flow is not periodic at a steady pace the >>>>> maximum latency in the reordering buffers based on packet sequence >>>>> numbers can not be ensured. Instead some form of time limit needs to exist also. >>>>> If that time limit is only local then there exists a risk that >>>>> over multiple reordering buffers if multiple independent service >>>>> labels are used the jitter and latency becomes cumulative. If the >>>>> goal is to avoid this then the individual packets would need to >>>>> carry a time stamp to ensure that from ingress of the service label path until the egress a maximum latency is added. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> detnet mailing list >>>>> detnet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/detnet >>>> -- >>>> --- >>>> tte@cs.fau.de > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert loa.pi.nu@gmail.com Bronze Dragon Consulting phone: +46 739 81 21 64
- [Detnet] Magnus Westerlund's Discuss on draft-iet… Magnus Westerlund via Datatracker
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Stewart Bryant
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Stewart Bryant
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Stewart Bryant
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Toerless Eckert
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Magnus Westerlund
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Magnus Westerlund
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Balázs Varga A
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Magnus Westerlund
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Toerless Eckert
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Lou Berger
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Stewart Bryant
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Loa Andersson
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Jeff Tantsura
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Balázs Varga A
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Toerless Eckert
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Toerless Eckert
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Uma Chunduri
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Janos Farkas
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Loa Andersson
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Magnus Westerlund
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Janos Farkas
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Lou Berger
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Magnus Westerlund
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Lou Berger
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Balázs Varga A
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Balázs Varga A
- Re: [Detnet] Magnus Westerlund's Discuss on draft… Magnus Westerlund