Re: [Detnet] draft-varga-detnet-pof (sorry, lot of input)

Balázs Varga A <balazs.a.varga@ericsson.com> Fri, 10 September 2021 14:08 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 69A5F3A005F for <detnet@ietfa.amsl.com>; Fri, 10 Sep 2021 07:08:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level:
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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 WGMBZ_Z_h4FZ for <detnet@ietfa.amsl.com>; Fri, 10 Sep 2021 07:08:35 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80079.outbound.protection.outlook.com [40.107.8.79]) (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 6D3CF3A00AE for <detnet@ietf.org>; Fri, 10 Sep 2021 07:08:35 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BQS9lxqTA0yt6ARpr+RdZxNXdB0MWc+N1u0GNDPB+e1/R7RdT8VpkmQgN/CK5LyPs9s1PymtjJQ20Zud9ZFKeO7Xnpd5pPDtd1Rx6UboGo/66vNa974QUguooSx02qUvi0Uj/TE85XwCFanY+Zl3KbNZ+UKi+CDQp1Erz58hnVub89PnoEDJBDb8Ycic5x5650A8VhN0RZVEOFe2xtW3453nnLgSzyz6ThnmIA8fCZ5Q4uaRUsgXfirnKYRv82rBcYhf+i1nZf9JJF/q9K1NREnVN430Wn0cnSiEv6Km+xgVynWgP6Ej8OVsMaSO7WS7D0VHdaLNHrMUK6uKxwfSgQ==
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; bh=Q2cnywyec+l07yQinmpRGp44hU/93OPR6kmatyQp4Yk=; b=PRp3O7oWkRRhqqOu4EyDZGKy4EkR91Y4Di68cxU95o41mqwLGHJ93yPg8lg2C6Nnr928D95ZuSKTbt7kL54pN9y6db8WI4H+BNx0vC4C9c1hrZGoFQF3HvIVsfTdNGvw+6o8/5b4jBVrHuTuoDp5dPKKgRI3K0ythfTCt5bgdIHz+qmxeaP2dfZsPrRc3qKZiYUmClmmptiMMwRNgg0JCLfg3jAKCyCpi7ukDejkg4Mpq6/C4F56+ToOGe2c2eU9SkFU7od2Z0Jcla6S37UoVifcIu16vT3+HkP14425s9LjnH1NXdtSkNZxZqt2D7cuo9yevq6aJHhKHlwT6bJ6FA==
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=Q2cnywyec+l07yQinmpRGp44hU/93OPR6kmatyQp4Yk=; b=rNbTM/wIK79509QcL7EVn7NA2V3Be8OBGXk6hTW0JwAHuYr7wQ0h6Ne+ghQ+hL6RzAH0YKPJgIQWvno27iKyIoY0NoGPgvHzucUNSyN/6J3M1vf8HjdqW1PDcPn7VWPfP+TRNe5/gCZgzSH4QaCZZQOmhmuKkd4m1nVRD2XgUb4=
Received: from AM0PR07MB5347.eurprd07.prod.outlook.com (2603:10a6:208:e7::31) by AM0PR0702MB3586.eurprd07.prod.outlook.com (2603:10a6:208:25::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.10; Fri, 10 Sep 2021 14:08:31 +0000
Received: from AM0PR07MB5347.eurprd07.prod.outlook.com ([fe80::1d98:dcfa:1e23:d14e]) by AM0PR07MB5347.eurprd07.prod.outlook.com ([fe80::1d98:dcfa:1e23:d14e%6]) with mapi id 15.20.4500.012; Fri, 10 Sep 2021 14:08:31 +0000
From: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= <balazs.a.varga@ericsson.com>
To: Toerless Eckert <tte@cs.fau.de>
CC: "detnet@ietf.org" <detnet@ietf.org>
Thread-Topic: [Detnet] draft-varga-detnet-pof (sorry, lot of input)
Thread-Index: AQHXhZQEM3TQClWJVk247trXVZKWzatjEZaQgDe02v2AAsPHUA==
Date: Fri, 10 Sep 2021 14:08:31 +0000
Message-ID: <AM0PR07MB53471A558FB580F07803B357ACD69@AM0PR07MB5347.eurprd07.prod.outlook.com>
References: <20210730224049.GB9775@faui48e.informatik.uni-erlangen.de> <AM0PR07MB53470FA231A1BEF81A8F7396ACF19@AM0PR07MB5347.eurprd07.prod.outlook.com> <20210811214924.GA1823@faui48f.informatik.uni-erlangen.de> <YTkQqY7UV4bBDsYp@faui48e.informatik.uni-erlangen.de>
In-Reply-To: <YTkQqY7UV4bBDsYp@faui48e.informatik.uni-erlangen.de>
Accept-Language: hu-HU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cs.fau.de; dkim=none (message not signed) header.d=none;cs.fau.de; dmarc=none action=none header.from=ericsson.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 06ee4628-dc3c-4371-b7a7-08d97464786f
x-ms-traffictypediagnostic: AM0PR0702MB3586:
x-microsoft-antispam-prvs: <AM0PR0702MB35867BA595745D3DF7E49F96ACD69@AM0PR0702MB3586.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: tO8G3zpmq7fhK1+Lw3jgcnMf0r/uiqNx3AUM5FqW63Jo9HwkygYnz/ZWneHh9LnsS0fgRXgybC66TscMDTN9Mzkd+3tUjdBMX1/+PzsrjtFHAtJSJUzKELWNqcTZBNH6Amw/A1jW5QOdTuTCPDk+OS6WXQkc53N+ZRWPoMPDUvL13p7s1/XZtCbXJJSyuL1rFG1mdOBwJQmn9XXrLvWp7HFlVlu+leyySJP6aV4Nzay4MAu1RVSbcPs28oaFiHMYJD/ZslE+nL8Y6WlwsZ7rjgVlIhR9inuKtyzCCYkmC2pIGjq/XlpmaLptJujbhVF2eaXikNHtOoSNATCxZcDV97Mtga3WgyI9AUz+fAiprq0fhiwpeGYNzvxKujtkgEyqxRHu9R5NRCJV0itbql+jyxqNEoi7N/9vTocDjGp4Y9IL/W+MIpyhEA9jmPsuc2FlAATCIFpXzNQK3U8fjTZP3/ndkJA81+iTSQQSgN57GBdJY5vKTL6NI98jhIcbn81Cu8g4bt/ym9891rbgH+VxhgCpY3FQLJcJeoWoJ5xQo73tAzwm/+/d/xhVOPGpeQYcAyj2FrFBGqjCxS3Sbcpfanxqf5ggFP2fuajQdYodVNFl3uPnk2wxfPmbFPR9ugPDxRcBuXa+PrWjnAKIb4gQhwHUQ0mox9lQdkoSssUE0Mqu+haDqAaQHvHPnqEkJ/BWcw38Z4yq7B3iJrIXzonHyGAtOWNjzPltJAZ2NMvPEM6LbdaBrg63f9HUaclHUea9H7/XXGFYsgajJs0WiEBSRtik5i3mLZLOolGN+V0AbpQ=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB5347.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(396003)(39860400002)(136003)(376002)(8936002)(71200400001)(4326008)(52536014)(186003)(6916009)(26005)(478600001)(7696005)(5660300002)(83380400001)(8676002)(38070700005)(55016002)(53546011)(6506007)(33656002)(2906002)(122000001)(38100700002)(66446008)(64756008)(66556008)(316002)(86362001)(966005)(66574015)(9686003)(66946007)(76116006)(66476007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?sGoKmXzTZpj9eR93ktD/g2k36wKARPIjjKAoCE8pnsl+dr5vuEJPLPC2wj?= =?iso-8859-1?Q?XXV4BeRqagWWvi0g5BPjiR5HUUaKuAQw8NrlnJ2kEIJ2DS0t8x/YkFU8Ky?= =?iso-8859-1?Q?idEbF3snIhsvIjwejCxqksYBmR0fd90FZak2KIy+dVWp4HDcoJhsYqO/h3?= =?iso-8859-1?Q?wYHUDLh7SINs7+pJ5MlxA8PgWKk8JXnM0rzAyeaTfki2oyd5iCuS09CEHT?= =?iso-8859-1?Q?rXqnmkYrP745z7Nx0Kr7RwJ+2NAKur4ZqJjYxQFm+YcbIAvnOxbFRNvELK?= =?iso-8859-1?Q?Xoq4hnS+Z1DqkVNnN8DcXlKvYD/SfMgL+6CbL2cbldbANCtRcLZrGiS9kv?= =?iso-8859-1?Q?x0+NLyYSShQhIHxeZ5Wcshf/FtlL7QN9bDzl5B4okVROBlZGp2TmYMrQcu?= =?iso-8859-1?Q?69AGWx1FzQ8LF6KtHd/ZLQpPTLxVS8AJpwaAFWtw0/65ku2DKLEoxCdDbu?= =?iso-8859-1?Q?6wB2fcQk+BPDSKn3MH8oUrRFfQPS02txxJFt3oq27AB1X7i4rPAAIgwj9W?= =?iso-8859-1?Q?yEe/TYtKXMJu48jTgGfkzdIA2igrvhaSutohyoGkUq6y+X+nd6KpUxyVpM?= =?iso-8859-1?Q?DCNL/ZoXp2PqS9bidrDyDmn6i2V7BZbQ4pZ3F293QM7ime0b6hhNYegqfX?= =?iso-8859-1?Q?OZXWC5nGvvO0U2Ii41YTaV/VXsP3s8kV8A6ZJJGMjbN+AtcwHb4WHMeBuv?= =?iso-8859-1?Q?GCBYP0VWWtumM7aCaWDFiCXDEN3dIcnvmgMmJO3d8JvuoHz/jbHGOHtsOA?= =?iso-8859-1?Q?5FOQ787G4Y0uEknDMIyIfXEJ5IyeqqzfCuzB2yEWakMvp7CQnCVwPnhA3w?= =?iso-8859-1?Q?XCV+BMjrhm/iSVe+goLSP035OBe1YM5Rn0bPpb7XpGUtDhOXeeRW4HItLL?= =?iso-8859-1?Q?D1kfs1iG3m6uyD74emUYtchkcURoy+Mc16bR7gQ3U8cCoCukgwqumP9ElW?= =?iso-8859-1?Q?aMP/Ko4vR7zUXZOkuJuYQtlxFEVVC2i5BnUc9dU7DNLNqzLIsGmcQ67Vxt?= =?iso-8859-1?Q?nmWPnNFIs/Q6LNoaO4pg2pLppw9jt0BbFvH+cQr4eqWEngqc/9spV8TbX+?= =?iso-8859-1?Q?vHbJu9dCIhnEth8l0VKLV+vpINo+NvTfeZ2zDN6OD1J4v1paJ3FQjO/Z7I?= =?iso-8859-1?Q?S4Rvl9ZzstYy1CvP+vpR1IvhSWFwUbj2dbnlA8hz2yfwLRS1MyS5XkYjPT?= =?iso-8859-1?Q?b+lJOwqUnvwze+Rl0LjRqbyIsCw85zwljSjMNB5risR3uy2Kfe054Y0o+Q?= =?iso-8859-1?Q?wkH3wP8RciLVr9oZdQUPYyaatbRr+IY7AfPs3/F8Bm/SS6h3aiFyU9y6f7?= =?iso-8859-1?Q?aFplWPQYnONiWT2a8fQVzFD0xe8zP1N3AZ8P06VvyieQRymJI1jGt1Ab8r?= =?iso-8859-1?Q?wRQsd1cSwv?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB5347.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 06ee4628-dc3c-4371-b7a7-08d97464786f
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2021 14:08:31.4575 (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: aJkWg5vYQnYX6epdzxjgJndzZ1LcF8haK6d317TlBqZrEzgspTunkg7EGKKgSWZwhFlhiwaifuewLTWv//HcrN2yC2vZ+EUsEyfpRzt1HR0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0702MB3586
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/kUFwBBVSC9NZ2cp9YqGoAIORzUs>
Subject: Re: [Detnet] draft-varga-detnet-pof (sorry, lot of input)
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: Fri, 10 Sep 2021 14:08:42 -0000

Hi Toerless,

Yes, POF/PEF may cause burst at the DetNet service sub-layer, 
but DetNet forwarding sub-layer provides the functions to cope 
with those bursts. 

Adding additional buffering to PEF/POF would be a duplication 
of functions and increase latency.

Please note that TSN/DetNet consider always the worst case 
scenario. That means practically, resource allocation based on
PCR. 

Cheers
Bala'zs

-----Original Message-----
From: Toerless Eckert <tte@cs.fau.de> 
Sent: Wednesday, September 8, 2021 9:36 PM
To: Balázs Varga A <balazs.a.varga@ericsson.com>
Cc: detnet@ietf.org
Subject: Re: [Detnet] draft-varga-detnet-pof (sorry, lot of input)

Being a bit delayed by the draft i was promising, i just wanted to bring up in the context of your work one point i stumbled across:

Lets say we have:

      T-PE1 -> S-PE1 -> LSR-P -> S-PE2 -> T-PE2

Lets assume the detnet domain runs from T-PE1 to T-PE2 But now (and i think/hop this is covered by the DetNet architecture), i want to do Packet Duplication Function on S-PE1 and Packet Elimination Function of S-PE2.

When i do introduce Packet Ordering Function in conjunction with Packet Elimination on S-PE2, i think that this could create bursts of packets that can exceed the traffic contract known to the owner of the flow (e.g.: CIR/PIR etc..), because this burstyness depends for example on the differential latency of the for example two paths/copies sent between S-PE1 and S-PE2.

In effect, i think that one can not simply rely on the bounded latency iand buffering model of any pre-existing boundd latency algorithm as long as that only takes the flow CIR/PIR etc into account. 

Aka: In your POF model, where PEF is first performed, those bursts go into the POF, and if we want to hide all this POF/PEF impact from some bounded-latency operation happening after the POF, i think we need to include into the POF some more buffering functionality that reduces burstyness to what the egres bounded latency function can hanle without becoming yet another more complex ingres-edge "gate"
function.

Cheers
    Toerless

On Wed, Aug 11, 2021 at 11:49:24PM +0200, Toerless Eckert wrote:
> High level answer:
> 
> If we would start to describe the management interface, e.g.:
> what we want be able to configure and observe about all of PREOF 
> (maybe starting with POF), then i think we will immediately get to the 
> point that we expect a much more explicit description of what 
> PREOF/POF has to do so that it can comply with that management 
> inerface.
> 
> I am saying this because when i did design features in the past it did 
> work out best by first starting to think about how the operator should 
> see the feaure. Otherwise a lot was forgotten. In the IETF i did 
> admittedly wiggle myself around doing this 100% correctly, by just 
> informally referring to the CLI/config aspects (such as RFC8994), but 
> that was primarily because for that work the manaement work is really 
> big, so it didn't first. Writing a yang module into a POF draft itself 
> should be rather painless in comparison.
> 
> From there on out, we can start to see how well we could describe the 
> per-hop-behavior, if that is how we are allowed to call it.
> 
> Details hat may be missing are about stuff like: what if a packet 
> arrives whose sequence number does not fall into the window of 
> sequence numbers that the POF currently accepts ? Ok, we discard it. 
> We update a counter tracking these events. Do we update our POF state 
> machinery ? Maybe that needs to be configurable.
> Should the window-size of sequence number be configurable, etc. pp
> 
> Good info about TSN. Thanks
> 
> Toerless
> 
> 
> On Wed, Aug 04, 2021 at 10:15:15AM +0000, Balázs Varga A wrote:
> > Hi Toerless,
> > 
> > Many thanks for the comments. Some clarifications/reactions:
> > 
> > a) "per hop behavior"
> > In general I agree, "unexpected behavior of DetNet products" must be avoided.
> > We have already POF specifics in DetNet RFCs:
> > - RFC8655: introduces the term POF
> > - RFC8938: gives some characteristics of POF (uses sequence numbers, 
> > range of packet order protection, buffer resources)
> > - RFC8964: defines POF packet processing (section 4.2.2.3) What is 
> > missing in your view?
> > 
> > Regarding terminology I also dislike "input vs. outbut timing for 
> > traffic " as POF is not about explicit timing but order of packets.
> > 
> > b) Management interface
> > Yes, management is an important topic. If I understand your comment 
> > correctly You are more concerned about the operation/maintenance 
> > related counters/parameters. I think it is a valid comment, but in 
> > my view it might be better to discuss it in the OAM related drafts.
> > In this draft all the POF algorithm's specific parameters are 
> > defined. E.g., required buffer space can be derived from these parameters and the network/flow specifics.
> > 
> > c) TSN standards about ordering function There were discussions 
> > about ordering in TSN, but nothing standardized.
> > 
> > d) "Another algorithm option: configure for every packet copy path a fixed time delay"
> > I think this topic needs more clarification. Some comments:
> > - I do not see differences in topologies used by TSN and by DetNet. 
> > Rings are also typical in TSN networks.
> > - We have a path specific delay parameter defined in section "4.4. 
> > The Advanced POF Algorithm", namely "POFMaxDelay_i".
> > - I am not sure your proposal is a POF function or a PDF (Packet Delay Function).
> > 
> > Again, thanks for the review and the comments.
> > 
> > Cheers
> > Bala'zs
> > 
> > -----Original Message-----
> > From: detnet <detnet-bounces@ietf.org> On Behalf Of Toerless Eckert
> > Sent: Saturday, July 31, 2021 12:41 AM
> > To: detnet@ietf.org
> > Subject: [Detnet] draft-varga-detnet-pof (sorry, lot of input)
> > 
> > Balazs, *:
> > 
> > I very much support work on POF, however:
> > 
> > I think we should aim higher than informational guidelines
> > 
> > I think we can build a normative document on two interfaces:
> > 
> > a) "per hop behavior"
> > 
> >    We can stanardize the externally observable behavior
> >    between arriving and sent packets on the node.
> > 
> >    This was regularily done for DiffServ Traffic Classes in
> >    TSVWG, where it is calle Per Hop Behavior. When i tried
> >    to apply this term to the input vs. outbut timing for
> >    traffic from what today is an IntServ flow (DetNet),
> >    David Black was somewhat concerned about re-use of the
> >    term, which is why i wrote "per hop behavior". IMHO,
> >    it is perfectly valid to also call this PHB, but i will
> >    leave it up to David to recommend appropriate terminology.
> > 
> >    I am only interested to be able to get as little as possible
> >    unexpecte behavior of DetNet products, and we can only 
> >    arrive that if we standardize the behavior.
> > 
> > b) Management interface
> > 
> >    Yang module specifying what the operator 
> >    can observe about the function about the POF function, e.g: 
> > 
> >    "static" parameters such as how many buffers there are available,
> >      algorithm (you do have algorithm in the draft)
> >     - maybe read/write if configurable.
> > 
> >    "dynamic parameters" - read-only for monitoring, troubleshooting:
> >      - buffers dynamically used,
> >      - latency between first and further copies
> >      - missing packets
> >      - ...
> > 
> > Now wrt to other content:
> > 
> > c) It would be lovely to have a section summarizing what if anythng
> >    TSN did standardize about their ordering function for all those
> >    IETF participants too lazy to read all that documentation
> >    and/or rejecting the notion of having to pay money to read a document.
> > 
> >    (informational, appendix).
> > 
> > d) I think it would be great to have anoher algorithm option
> >    by which one could configure for every packet copy path
> >    (assuming we can identify that in the forwardin plane)
> >    a fixed time delay.
> >   
> >    The reason for this, and why i think it was not an issue in
> >    TSN (with its typical topologies) is that in DetNets
> >    we much more likely will have rings with significant path 
> >    latency differences between A and B path,
> >    and whenever the A (shorter) path looses a packet, we would wait
> >    until the B path packet arrives, resulting in a lot of
> >    jitter. If the DetNet controller could configure 
> >    the B-A pah lateny difference as a delay, we could get rid
> >    of this problem.
> > 
> > Still have to dig deeper into the algo details you proposed for more comments.
> > 
> > Cheers
> >     Toerless
> > 
> > _______________________________________________
> > detnet mailing list
> > detnet@ietf.org
> > https://www.ietf.org/mailman/listinfo/detnet
> 
> --
> ---
> tte@cs.fau.de

--
---
tte@cs.fau.de