Re: [Detnet] IPv6 encapsulation in dataplane doc

Lou Berger <lberger@labn.net> Fri, 09 February 2018 16:24 UTC

Return-Path: <lberger@labn.net>
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 9B0DD1200FC for <detnet@ietfa.amsl.com>; Fri, 9 Feb 2018 08:24:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 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=-0.001, 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 ypHgQ4J9a2ld for <detnet@ietfa.amsl.com>; Fri, 9 Feb 2018 08:24:04 -0800 (PST)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 AA468127698 for <detnet@ietf.org>; Fri, 9 Feb 2018 08:24:04 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id 6415B21622C for <detnet@ietf.org>; Fri, 9 Feb 2018 09:24:01 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id 8gPx1x00R2SSUrH01gQ0bF; Fri, 09 Feb 2018 09:24:01 -0700
X-Authority-Analysis: v=2.2 cv=Rf/gMxlv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=N659UExz7-8A:10 a=Op4juWPpsa0A:10 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=tXgZ3comtnjozD6G2RIA:9 a=XFIlFAS8EZXNdVKt:21 a=ItGC48zCHhYOLUnc:21 a=pILNOxqGKmIA:10 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=ikfWTxDl2Z7JJ9oX9tgFOKU8sFvZa7N+vXWxubTj67s=; b=LH5LlNVqC8lyJz4iP2q7HQf+oC Fi8bfOw6F3Dh0bCdVPCyW3pXL7tYiO2x9cYaT9YHlHhaJmqDchUWYdxac/A7hct5o9qVdaGp3VdpC 6cN+tVJXku5GwfMsoSCH/ncGe;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:60316 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from <lberger@labn.net>) id 1ekBSv-001Gbq-I1; Fri, 09 Feb 2018 09:23:57 -0700
To: Jouni <jouni.nospam@gmail.com>, "'Pascal Thubert (pthubert)'" <pthubert@cisco.com>, detnet@ietf.org
References: <cff50c52d2f945cfa8eff149f5242fb0@XCH-RCD-001.cisco.com> <16170c78f30.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <22c101d3a0bc$5795b080$06c11180$@gmail.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <b17a1c79-010d-b4a0-aa07-8182b72f2577@labn.net>
Date: Fri, 09 Feb 2018 11:23:56 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <22c101d3a0bc$5795b080$06c11180$@gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Language: en-US
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: 100.15.86.101
X-Exim-ID: 1ekBSv-001Gbq-I1
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net (fs2.dc.labn.net) [100.15.86.101]:60316
X-Source-Auth: lberger@labn.net
X-Email-Count: 6
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/ifU-jEonm9uUtzjh0oj5HZS5vHE>
Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.22
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, 09 Feb 2018 16:24:07 -0000

Hi Jouni,


On 02/08/2018 04:08 AM, Jouni wrote:
> Hi,
> 
>  
> 
> Yes, we discussed this to an extent in the last call. I’ve been thinking
> this a bit more lately (cross country skiing conditions have been great
> thus you got a lot of time while on the skiing tracks ;) Few
> concerns/points to think I see here are:

I'm jealous!

> 
> * End systems cannot participate to DetNet service layer packet
> elimination & duplication business. If they still do e.g. using DetNet
> DstOpt that is separate from subnet/transport layer provided service.

True, end station participation in PREF wouldn't be possible in this
simplified approach for IP, but the end stations *could* still
participate in the equivalent function provided by a sub-net layer such
as TSN. So end to end detnet traffic protection is not possible, but it
doesn't mean it can't be provided by lower network layers.  The gain
here is a simplified and unified IP solution and simplified host
processing/support, albeit with a loss of one of the three end to end
detnet service attributes.


> * Different subnet/transport layer segments in the DetNet domain are
> likely to use their own sequencing and duplication & elimination
> solutions. I am not sure how independent those will be e.g., is the
> sequence numbering unified across or only per segment. The former is not
> IMO easy and the latter easily reduces to single points between segments
> to handle number book keeping properly.  

Agreed.  The question for the WG is this a reasonable compromise in
order to in our *initial* solution defined by the WG.  -- Nothing says
we can't come back and improve on this in the future, but it will allow
us to get *something* useful defined with less complexity.

 
> 
> Regardless the above I am keen to explore this alternative approach..
> 

Great - look forward to hear the results!
Lou
  
> 
> -          Jouni
> 
>  
> 
>  
> 
> *From:* detnet [mailto:detnet-bounces@ietf.org] *On Behalf Of *Lou Berger
> *Sent:* Wednesday, February 7, 2018 17:00 PM
> *To:* Pascal Thubert (pthubert) <pthubert@cisco.com>; detnet@ietf.org
> *Subject:* Re: [Detnet] IPv6 encapsulation in dataplane doc
> 
>  
> 
> Pascal/all,
> 
> At the last interim a proposal was made to simplify IP processing, at
> least for the initial detnet solution, by leaving PREF to the
> subnet/transport layers (i.e., TSN and MPLS) and providing DetNet flow
> identification based on typical IP 5-tuple perhaps + dscp. This approach
> has several benefits beyond simplification, notably it will work for
> both ipv4 and IPv6, and doesn't require any modification to
> encapsulation / formats.
> 
> It would be really valuable to get feedback from the whole working group
> if this simplification is acceptable or has unacceptable limitations.
> 
> Lou
> 
> On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)"
> <pthubert@cisco.com <mailto:pthubert@cisco.com>> wrote:
> 
>     Dear all
> 
>      
> 
>     This is about the IPv6 encapsulation and more precisely
> 
>      
> 
>                             Therefore, if a DetNet-aware end system only
> 
>        inserted the DetNet Destination Option into the IPv6 but e.g., a
> 
>        DetNet Edge node is configured to enforce an explicit route for the
> 
>        IPv6 packet using a source routing header, then it has no other
> 
>        possibility than add an outer tunneling IPv6 header with required
> 
>        extension headers in it.  The processing of IPv6 packets in a DetNet
> 
>        Edge node is discussed further in Section 6.4.1
>     <https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-01#section-6.4.1>.
> 
>      
> 
>      
> 
>     With the current spec, a source sends a DetNet packet as
> 
>      
> 
>                         +---------------------------------+
> 
>                         |                                 |
> 
>                         |           DetNet Flow           |
> 
>                         |             Payload             |
> 
>                         |                                 |
> 
>                         /---------------------------------\
> 
>                         H   Optional DetNet DstOpt Hdr    H
> 
>                         \---------------------------------/
> 
>                         |          IPv6 header            |
> 
>                         |     (with set Flow label)       |
> 
>                         +---------------------------------+
> 
>      
> 
>     And then the ingress node needs to re-encapsulate as
> 
>      
> 
>                         +---------------------------------+
> 
>                         |                                 |
> 
>                         |           DetNet Flow           |
> 
>                         |             Payload             |
> 
>                        |                                 |
> 
>                         /---------------------------------\
> 
>                         H        DetNet DstOpt Hdr        H
> 
>                         \---------------------------------/
> 
>                         |          IPv6 header            |
> 
>                         |     (with set Flow label)       |
> 
>                         +=================================+
> 
>                         |          Routing header         |
> 
>                         /---------------------------------\
> 
>                         H        DetNet DstOpt Hdr        H
> 
>                         \---------------------------------/
> 
>                         |          IPv6 header            |
> 
>                         |     (with set Flow label)       |
> 
>                         +---------------------------------+
> 
>      
> 
>     This creates a duplication of the DetNet Destination Option.
> 
>      
> 
>     There are alternatives
> 
>      
> 
>     a)  whereby the packet is tunneled from the source to the detnet
>     ingress, and based on its state the DetNet ingress accepts the
>     packet, processes it and then resends it. The tunneled version of
>     this could be:
> 
>      
> 
>                         +---------------------------------+
> 
>                         |                                 |
> 
>                         |           DetNet Flow           |
> 
>                         |             Payload             |
> 
>                         |                                 |
> 
>                         +---------------------------------+
> 
>                         |          IPv6 header            |
> 
>                         |   (dest = final destination)    |
> 
>                         /=================================\
> 
>                         H   Optional DetNet DstOpt Hdr    H
> 
>                         \---------------------------------/
> 
>                         |          IPv6 header            |
> 
>                         |   (dest = DetNet ingress edge)  |
> 
>                         |     (with set Flow label)       |
> 
>                         +---------------------------------+
> 
>      
> 
>     Which allows the ingress to tunnel to the egress as follows:
> 
>                         +---------------------------------+
> 
>                         |                                 |
> 
>                         |           DetNet Flow           |
> 
>                         |             Payload             |
> 
>                         |                                 |
> 
>                         +---------------------------------+
> 
>                         |          IPv6 header            |
> 
>                         |      (to final destination)     |
> 
>                         +=================================+
> 
>                         |          Routing header         |
> 
>                         /---------------------------------\
> 
>                         H   Optional DetNet DstOpt Hdr    H
> 
>                         \---------------------------------/
> 
>                         |          IPv6 header            |
> 
>                         |   (dest = DetNet egress edge)   |
> 
>                         |     (with set Flow label)       |
> 
>                         +---------------------------------+
> 
>      
> 
>      
> 
>     b)  whereby the PREF is done by the end nodes and the tunnel is
>     transport only, meaning that there are 2 tunnels A and B and that
>     the source sends twice a packet like this:
> 
>      
> 
>                         +---------------------------------+
> 
>                         |                                 |
> 
>                         |           DetNet Flow           |
> 
>                         |             Payload             |
> 
>                         |                                 |
> 
>                         /---------------------------------\
> 
>                         H   Optional DetNet DstOpt Hdr    H
> 
>                         \---------------------------------/
> 
>                         |          IPv6 header            |
> 
>                         |   (dest = DetNet ingress edge X)|
> 
>                         |     (with set Flow label)       |
> 
>                         +---------------------------------+
> 
>      
> 
>     And then the ingress node needs to re-encapsulate as
> 
>      
> 
>                         +---------------------------------+
> 
>                         |                                 |
> 
>                         |           DetNet Flow           |
> 
>                         |             Payload             |
> 
>                        |                                 |
> 
>                         /---------------------------------\
> 
>                         H        DetNet DstOpt Hdr        H
> 
>                         \---------------------------------/
> 
>                         |          IPv6 header            |
> 
>                         |   (dest = final destination)    |
> 
>                         |     (with set Flow label)       |
> 
>                         +=================================+
> 
>                         |          Routing header         |
> 
>                         +---------------------------------+
> 
>                         |          IPv6 header            |
> 
>                         |   (dest = DetNet egress edge X) |
> 
>                         |     (with set Flow label)       |
> 
>                         +---------------------------------+
> 
>      
> 
>     Cheers,
> 
>      
> 
>     Pascal
> 
>     _______________________________________________
>     detnet mailing list
>     detnet@ietf.org <mailto:detnet%40ietf.org>
>     https://www.ietf.org/mailman/listinfo/detnet
>