Re: [Detnet-dp-dt] changes to document pushed & some questions...

Lou Berger <lberger@labn.net> Wed, 28 June 2017 02:29 UTC

Return-Path: <lberger@labn.net>
X-Original-To: detnet-dp-dt@ietfa.amsl.com
Delivered-To: detnet-dp-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FC312969E for <detnet-dp-dt@ietfa.amsl.com>; Tue, 27 Jun 2017 19:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 Y_zxeYrPMa5p for <detnet-dp-dt@ietfa.amsl.com>; Tue, 27 Jun 2017 19:29:28 -0700 (PDT)
Received: from gproxy2.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 9C381127ABE for <Detnet-dp-dt@ietf.org>; Tue, 27 Jun 2017 19:29:28 -0700 (PDT)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id F178E1E0D55 for <Detnet-dp-dt@ietf.org>; Tue, 27 Jun 2017 20:29:17 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id e2VD1v01B2SSUrH012VGYr; Tue, 27 Jun 2017 20:29:17 -0600
X-Authority-Analysis: v=2.2 cv=Z7GcJDZA c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=LWSFodeU3zMA:10 a=pGLkceISAAAA:8 a=wU2YTnxGAAAA:8 a=0FD05c-RAAAA:8 a=48vgC7mUAAAA:8 a=_xqE2kgHBPCb2U0Ay0AA:9 a=qo-d2C3W8oscdiXB:21 a=_CnuEQJq-yZK0Jnz:21 a=QEXdDO2ut3YA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=l1rpMCqCXRGZwUSuRcM3:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=q7HNfeBXZthFfSw5F0lUWfjR8IKZG7KWkxve0xWc7/w=; b=UOIJgGCEHDz12BsRTFeATBgslG G6wJ7Vh3090gny3Z2ysmdEcOkRIW5gA7lfo0dHwxGnxKZyzOJErt9Eg3r4959C02mq606uP1U9aY0 CCUepdtdINF+k+XXEE61koY+P;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:47800 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <lberger@labn.net>) id 1dQ2jB-000MD1-Ke; Tue, 27 Jun 2017 20:29:13 -0600
To: Jouni <jouni.nospam@gmail.com>, Detnet-dp-dt@ietf.org
References: <a05d7a04-0768-07bc-d76e-620dcab64b54@labn.net> <DBXPR07MB1286C571697E6F1988FB28FACDF0@DBXPR07MB128.eurprd07.prod.outlook.com> <8096bddd-91c0-fecb-7f72-f182ac4817e5@labn.net> <DBXPR07MB12853204AD0E951EC499038ACDC0@DBXPR07MB128.eurprd07.prod.outlook.com> <5c96e587-493b-88ca-9a8c-12c7abcaca51@labn.net> <f8171209-0fa3-f529-767d-17df7ef947ee@labn.net> <02bd01d2ef96$feb36bf0$fc1a43d0$@gmail.com> <15cebc83ea0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <02eb01d2ef9f$3939bf10$abad3d30$@gmail.com> <02ec01d2ef9f$bbbc3d00$3334b700$@gmail.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <a8f465e7-ba92-5e9b-c8f4-40772672b298@labn.net>
Date: Tue, 27 Jun 2017 22:29:10 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <02ec01d2ef9f$bbbc3d00$3334b700$@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dQ2jB-000MD1-Ke
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:47800
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet-dp-dt/urCCI3vf00vO_N7IXpK4qNaMUyU>
Subject: Re: [Detnet-dp-dt] changes to document pushed & some questions...
X-BeenThere: detnet-dp-dt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DetNet WG Data Plane Design Team <detnet-dp-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet-dp-dt>, <mailto:detnet-dp-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet-dp-dt/>
List-Post: <mailto:detnet-dp-dt@ietf.org>
List-Help: <mailto:detnet-dp-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet-dp-dt>, <mailto:detnet-dp-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Jun 2017 02:29:32 -0000

Done - also changed to STD track vs informational.  I don't have any
more planned comments to discuss or changes to make.

Lou

On 6/27/2017 7:47 PM, Jouni wrote:
> Meant as a co-author ;)
>
>> -----Original Message-----
>> From: Jouni [mailto:jouni.nospam@gmail.com]
>> Sent: Wednesday, June 28, 2017 02:44 AM
>> To: 'Lou Berger' <lberger@labn.net>; 'Balázs Varga A'
>> <balazs.a.varga@ericsson.com>; Detnet-dp-dt@ietf.org
>> Subject: RE: [Detnet-dp-dt] changes to document pushed & some questions...
>>
>> Done my small thingies.
>>
>> Lou, add yourelf as a editor.
>>
>> - Jouni
>>
>>> -----Original Message-----
>>> From: Lou Berger [mailto:lberger@labn.net]
>>> Sent: Wednesday, June 28, 2017 02:00 AM
>>> To: Jouni <jouni.nospam@gmail.com>; 'Balázs Varga A'
>>> <balazs.a.varga@ericsson.com>; Detnet-dp-dt@ietf.org
>>> Subject: Re: [Detnet-dp-dt] changes to document pushed & some
>> questions...
>>> Yes. I'm done done. Sorry...
>>>
>>>
>>> On June 27, 2017 6:45:37 PM "Jouni" <jouni.nospam@gmail.com> wrote:
>>>
>>>> Lou,
>>>>
>>>> Are you now done with your edits? I was working on the same section
>>>> and dropped my stuff in a favor of yours ;) I'll still want to
>>>> revisit Section
>>>> 6 before statingnthe draft is ready for adoption.
>>>>
>>>> - Jouni
>>>>
>>>>> -----Original Message-----
>>>>> From: Detnet-dp-dt [mailto:detnet-dp-dt-bounces@ietf.org] On Behalf
>>>>> Of Lou Berger
>>>>> Sent: Wednesday, June 28, 2017 00:36 AM
>>>>> To: Balázs Varga A <balazs.a.varga@ericsson.com>;
>>>>> Detnet-dp-dt@ietf.org
>>>>> Subject: Re: [Detnet-dp-dt] changes to document pushed & some
>>> questions...
>>>>> I just added a few word into to section 6 to highlight that it
>>>>> applies to
>>>>> v6 and mpls:
>>>>>
>>>>>
>>>>>    This section applies equally to DetNet flows transported via
>>>>> IPv6
>>> and
>>>>>    MPLS.  While flow identification and some header related
>> processing
>>>>>    will differ between the two, the considerations covered in this
>>>>>    section are common to both.
>>>>>
>>>>> feel free to check in what ever changes you want to this.
>>>>>
>>>>> Also I added the following comment:
>>>>>
>>>>>     <!-- LB: I think there needs to be more text on how PREF works
>> with
>>>>>          IPv6 flows. -->
>>>>>
>>>>> Lou
>>>>>
>>>>> On 6/27/2017 1:39 PM, Lou Berger wrote:
>>>>>> On 6/27/2017 7:44 AM, Balázs Varga A wrote:
>>>>>>> Hi Lou,
>>>>>>>
>>>>>>> - Bidirectional: proposed change is fine with me.
>>>>>> okay, I'll make this and the s-label change
>>>>>>
>>>>>>> - PREF and IPv6: It is not clear for me why the PREF support is
>>>>> considered to be different.
>>>>>>> From data plane perspective the PREF related chapters are
>>>>>>> formulated to be encapsulation independent. The only difference
>>>>>>> is that in case of IPv6 the flow-ID does not change during the
>>>>>>> transport ("src-IPv6 + Flow-label" remains unchanged), whereas
>>>>>>> it may change in case of MPLS (PW-label value may change on a
>>>>>>> PREF node). But the rest is the same
>>>>> from data plane function perspective (i.e., eliminate duplicates
>>>>> based on seq-num; do replication).
>>>>>> I didn't get this from reading the document the first time.  I'll
>>>>>> reread and suggest clarifications if needed.
>>>>>>
>>>>>>> Have I missed something? Do You mean different control plane
>>>>> requirements?
>>>>>> No, I was thinking data plane.
>>>>>>
>>>>>> Thanks,
>>>>>> Lou
>>>>>>> Cheers
>>>>>>> Bala'zs
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Detnet-dp-dt [mailto:detnet-dp-dt-bounces@ietf.org] On
>>>>>>> Behalf Of Lou Berger
>>>>>>> Sent: 2017. június 26. 17:55
>>>>>>> To: Balázs Varga A <balazs.a.varga@ericsson.com>;
>>>>>>> Detnet-dp-dt@ietf.org
>>>>>>> Subject: Re: [Detnet-dp-dt] changes to document pushed & some
>>>>> questions...
>>>>>>>
>>>>>>>
>>>>>>> On 6/26/2017 11:00 AM, Balázs Varga A wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I have reviewed all the changes. I am fine with almost all of
>>>>>>>> them with the remarks below:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Figure4: In my view it should be the same figure as Figure 3,
>>>>>>>> as DetNet End Systems are connected.
>>>>>>>>
>>>>>>>> In this case the End Systems generate IPv6 packets with
>>>>>>>> included seq-num and are connected to
>>>>>>>>
>>>>>>>> Relay nodes, what results in no difference regarding the DetNet
>>>>>>>> functionalities.
>>>>>>>>
>>>>>>> It's my understanding that there is major difference in PREF
>>>>>>> support in
>>>>> this case.
>>>>>>>> It would be a more interesting figure where IPv6 DetNet End
>>>>>>>> Systems are connected
>>>>>>>>
>>>>>>>> to an MPLS based DetNet domain, but it is similar from DetNet
>>>>>>>> function perspective to Figure 2.
>>>>>>>>
>>>>>>>> Let's list the possible combinations:
>>>>>>>>
>>>>>>>> - We have three End System types: (1) TSN, (2) IPv6 and (3)
>>>>>>>> MPLS-capable
>>>>>>>>
>>>>>>>> - We have two PSN encapsulations: (1) IPv6 and (2) PWoMPLS
>>>>>>>>
>>>>>>>> There are six possible combinations, however they result in 2
>>>>>>>> major variants from DetNet functions
>>>>>>>>
>>>>>>>> perspective:
>>>>>>>>
>>>>>>>> (1) End System type <> PSN type (TSN + IPv6, TSN + PWoMPLS,
>>>>>>>> IPv6
>>>>>>>> + PWoMPLS, MPLS-capable + IPv6)
>>>>>>>>
>>>>>>>> Edge node needed to ensure PSN specific encapsulation
>>>>>>>>
>>>>>>>> (2) End System type = PSN type  (IPv6 + IPv6, MPLS-capable +
>>>>>>>> PWoMPLS)
>>>>>>>>
>>>>>>>> No need for Edge node as the encapsulation does not change.
>>>>>>>>
>>>>>>>> (Note: I think we should treat "MPLS-capable + IPv6" as an
>>>>>>>> invalid combination ... )
>>>>>>>>
>>>>>>>> Figure 2 and Figure 3 are the representation of these two major
>>>>>>>> variants. So do we really need Figure 4?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> 522       DetNet composite flow, perhaps even when both LSPs
>>> appear
>>>>>>>> on the
>>>>>>>>
>>>>>>>> 522       DetNet compound flow, perhaps even when both LSPs
>> appear
>>> on
>>>>> the
>>>>>>>>
>>>>>>>>
>>>>>>>>> doesn't the above (sec 5.2.2.) imply the PREF with IPv6 is
>>>>>>>>> always
>>>>>>>> end-to-end, ...
>>>>>>>>
>>>>>>>> I think this needs further discussion. The intention is to make
>>>>>>>> PREF independent of domain borders and
>>>>>>>>
>>>>>>>> domain encapsulations.
>>>>>>>>
>>>>>>> It would be good to describe how this works in the v6 case
>>>>>>>>
>>>>>>>>> 1033 7.4.  Bidirectional traffic
>>>>>>>> This chapter is very much MPLS focused, however the findings
>>>>>>>> are also valid for IPv6. Should we make that
>>>>>>>>
>>>>>>>> more clear?
>>>>>>>>
>>>>>>> My objective in the first paragraph was to introduce the
>>>>>>> co-routed and
>>>>> associated concepts/terminology and then say how.  How about
>>>>> changing the last paragraph to:
>>>>>>>
>>>>>>>    While the IPv6 and MPLS data planes must support
>>>>>>> bidirectional
>>>>> DetNet flows, there
>>>>>>>    are no special bidirectional features with respect to the
>>>>>>> data
>>> plane
>>>>>>>    other than need for the two directions take the same paths.
>>> Note,
>>>>>>>    that there is no stated requirement for bidirectional DetNet
>>>>>>> flows
>>>>> to
>>>>>>>    be supported using same IPv6 Flow Label or MPLS Labels in
>>>>>>> each
>>>>> direction.
>>>>>>>    Control mechanisms will need to support such bidirectional
>>>>>>> flows for
>>>>> both IPv6 and MPLS, but
>>>>>>>    such mechanisms are out of scope of this document.
>>>>>>>
>>>>>>> Lou
>>>>>>>
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>>
>>>>>>>> Bala'zs
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Detnet-dp-dt [mailto:detnet-dp-dt-bounces@ietf.org] On
>>>>>>>> Behalf Of Lou Berger
>>>>>>>> Sent: 2017. június 21. 4:25
>>>>>>>> To: Detnet-dp-dt@ietf.org
>>>>>>>> Subject: [Detnet-dp-dt] changes to document pushed & some
>>> questions...
>>>>>>>>
>>>>>>>>
>>>>>>>> All,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I made a bunch of changes based on going though the document.
>>>>>>>> Most of the comments I discussed.  I put non-discussed ones in
>>>>>>>> their own commits so it would be easier to eliminate them.
>>>>>>>> Changes are as
>>>>> follows:
>>>>>>>>     commit f79188034b23c80dab2985dc359176e93855376e
>>>>>>>>
>>>>>>>>                 Update txt to match change set
>>>>>>>>
>>>>>>>>     commit 01a1798e4645518bb61acf42444b17466c3b56c1
>>>>>>>>
>>>>>>>>                 Make capitalization of section headings
>> consistent.
>>>>>>>>                 Not saying I agree with what's there, but now
>>>>>>>> it's consistent.
>>>>>>>>
>>>>>>>>     commit 27103f9af301d1a270ca7d6c9bd59a358dc9d1b0
>>>>>>>>
>>>>>>>>                 Revise CoS and QoS sections
>>>>>>>>
>>>>>>>>     commit c98c0efda04c714db22a1cea6eefb77f04d10c4b
>>>>>>>>
>>>>>>>>                 General edits:
>>>>>>>>
>>>>>>>>                     Fix some capitalization and minor nits
>>>>>>>>
>>>>>>>>                     Add intro paragraph and pointer to arch
>>>>>>>> doc, and basic scope of
>>>>>>>>
>>>>>>>>                        document
>>>>>>>>
>>>>>>>>                     Add not on why not using PW over IP
>>>>>>>>
>>>>>>>>                     Add placeholder for IP native service
>>>>>>>> figure
>>>>>>>> (4)
>>>>>>>>
>>>>>>>>                     Start clarification on congestion
>>>>>>>> protection and latency control
>>>>>>>>
>>>>>>>>                     Add some comments
>>>>>>>>
>>>>>>>>     commit 5355f195f205d944d21d8242738fab0a6a8363ba
>>>>>>>>
>>>>>>>>                 Cleanup L-label and T-label language
>>>>>>>>
>>>>>>>>     commit 78e937b1a25f07618b4b221140fc7fcfc2a43d02
>>>>>>>>
>>>>>>>>        Move Time Sync into it's own section (new 8)
>>>>>>>>
>>>>>>>>     commit 42bcb46dde2384cb4e3f76406780137086904bae
>>>>>>>>
>>>>>>>>        Use arch defined terms DetNet compound flow and DetNet
>>>>>>>> member flow
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I also came up with following specific questions/comments,
>>>>>>>> which are also captured in comments in the file:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> WRT the title:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>     <!-- LB: doesn't "Encapsulation" better fit the scope of
>>>>>>>> the current
>>>>>>>>
>>>>>>>>          document than "Solution"? -->
>>>>>>>>
>>>>>>>>     <title abbrev="DetNet Data Plane Solution">
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>     WRT L-Label
>>>>>>>>
>>>>>>>>     <!-- LB: why is this called L-Label, I think it'll be
>>>>>>>> confused with
>>>>>>>>
>>>>>>>>          the current DiffServ L-LSPs, perhaps a using "(S)vc"
>>>>>>>> would be
>>>>>>>>
>>>>>>>>          better and is aligned with Figure 12 of RFC5921  -->
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>   <!-- LB: unclear what the following means.  Perhaps restate
>>>>>>>> or
>>> drop.
>>>>>>>> -->
>>>>>>>>
>>>>>>>>   However, transit nodes may have limited capabilities to
>>>>>>>> recognize DetNet
>>>>>>>>
>>>>>>>>   specific fields (e.g., in case of MPLS the PW label).
>>>>>>>> Therefore, identifying each
>>>>>>>>
>>>>>>>>   individual DetNet flow on a transit node may not be achieved
>>>>>>>> in some network
>>>>>>>>
>>>>>>>>   scenarios.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>   in Section 5.2.1
>>>>>>>>
>>>>>>>>     <!-- possibly reference new interworking considerations
>>>>>>>> section
>>>>>>>> -->
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>   In section 5.3.2
>>>>>>>>
>>>>>>>>     <!-- LB: doesn't the above (sec 5.2.2.) imply the PREF with
>>>>>>>> IPv6 is
>>>>>>>>
>>>>>>>>          always end-to-end, or are you PREF domains with
>>>>>>>> replication of
>>>>>>>>
>>>>>>>>          incoming packets and scoped domain elimination? I
>>>>>>>> think this
>>>>>>>>
>>>>>>>>          should be explicitly discussed either way -->
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I ran out of steam at the end, but this is enough -- I think...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Lou
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> PS given that I now have contributed text to the document, I
>>>>>>>> should be added as a contributor (or author) but I didn't do
>>>>>>>> this as there was no contributor section...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>>
>>>>>>>> Detnet-dp-dt mailing list
>>>>>>>>
>>>>>>>> Detnet-dp-dt@ietf.org <mailto:Detnet-dp-dt@ietf.org>
>>>>>>>>
>>>>>>>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Detnet-dp-dt mailing list
>>>>>>> Detnet-dp-dt@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Detnet-dp-dt mailing list
>>>>>> Detnet-dp-dt@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>>>>> _______________________________________________
>>>>> Detnet-dp-dt mailing list
>>>>> Detnet-dp-dt@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>>>> _______________________________________________
>>>> Detnet-dp-dt mailing list
>>>> Detnet-dp-dt@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>
> _______________________________________________
> Detnet-dp-dt mailing list
> Detnet-dp-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt