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

Lou Berger <lberger@labn.net> Tue, 27 June 2017 22:59 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 006CB129B0A for <detnet-dp-dt@ietfa.amsl.com>; Tue, 27 Jun 2017 15:59:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 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, URIBL_BLOCKED=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 PqjpdcVUW4Uj for <detnet-dp-dt@ietfa.amsl.com>; Tue, 27 Jun 2017 15:59:55 -0700 (PDT)
Received: from gproxy5.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 11504126B7F for <Detnet-dp-dt@ietf.org>; Tue, 27 Jun 2017 15:59:55 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id F16B2140621 for <Detnet-dp-dt@ietf.org>; Tue, 27 Jun 2017 16:59:53 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id dyzq1v00Z2SSUrH01yztq8; Tue, 27 Jun 2017 16:59:53 -0600
X-Authority-Analysis: v=2.2 cv=QYgWhoTv 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=48vgC7mUAAAA:8 a=0FD05c-RAAAA:8 a=R1ONJYNxS-loyRCmeDIA:9 a=i5i6kNXdsvnBCyKR:21 a=hhlz_VbaNw0MmDsy:21 a=QEXdDO2ut3YA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 a=w1C3t2QeGrPiZgrLijVG:22 a=l1rpMCqCXRGZwUSuRcM3: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:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:To:From: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=HHN1dxcZXuuvK0mUjjyRUTH1nS0tQ7NueqNVrlZDyJo=; b=0IfbUTeOKemqsyzYvwp0URY5q9 ymIcC5l3/7f/mmlMfSVaEnpU/qEmuSoH8GO+kqIWAgi4tZXmXdiHGJjejlz0CwxYM4n0/C5uRxNEy dFganDAcwY7We6nNm4E7w7Hpt;
Received: from [172.58.185.45] (port=31738 helo=[IPV6:2607:fb90:64ea:b3df:0:4c:e7dd:4d01]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <lberger@labn.net>) id 1dPzSY-000KuR-64; Tue, 27 Jun 2017 16:59:50 -0600
From: Lou Berger <lberger@labn.net>
To: Jouni <jouni.nospam@gmail.com>, =?UTF-8?B?J0JhbMOhenMgVmFyZ2EgQSc=?= <balazs.a.varga@ericsson.com>, <Detnet-dp-dt@ietf.org>
Date: Tue, 27 Jun 2017 18:59:48 -0400
Message-ID: <15cebc83ea0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <02bd01d2ef96$feb36bf0$fc1a43d0$@gmail.com>
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>
User-Agent: AquaMail/1.10.0-403 (build: 101000001)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"
Content-Transfer-Encoding: 8bit
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: 172.58.185.45
X-Exim-ID: 1dPzSY-000KuR-64
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([IPV6:2607:fb90:64ea:b3df:0:4c:e7dd:4d01]) [172.58.185.45]:31738
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet-dp-dt/DN-CLuMvyn4Ai2oi7RV-Lof3laA>
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: Tue, 27 Jun 2017 22:59:58 -0000

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>om>; 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>om>;
>> >> 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