Re: [Detnet] Some initial comments on draft-dt-detnet-dp-sol-00
Balázs Varga A <balazs.a.varga@ericsson.com> Tue, 13 June 2017 16:15 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 CBF76131926; Tue, 13 Jun 2017 09:15:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 I8kNplZaY2eg; Tue, 13 Jun 2017 09:15:50 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 D80F5131A1E; Tue, 13 Jun 2017 09:06:55 -0700 (PDT)
X-AuditID: c1b4fb30-874f69a000003fda-83-59400d9d1c13
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id BC.C8.16346.D9D00495; Tue, 13 Jun 2017 18:06:54 +0200 (CEST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.45) with Microsoft SMTP Server (TLS) id 14.3.339.0; Tue, 13 Jun 2017 18:06:48 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BjwOTaXx+ahwSdsiqyjXAUQpxdHPvGXAJ+ZjX0TNxXk=; b=gzqjZt+dLcVesBaxzQIAwaYxWYJXK8jjyzTMErBGz8prrQIh2vuqGUCtk+6IidtXwt8Zgy5+OSGBNdu5VuKVHxLeerPgw90MEWXLryQBEGNaDZEaPLflTzKm1MzuYc7DdHEE6oLBa08K0rAGYG7tIJ0jpSsvQaZ8q7MhhBIk2/0=
Received: from DBXPR07MB128.eurprd07.prod.outlook.com (10.242.138.156) by DBXPR07MB270.eurprd07.prod.outlook.com (10.141.10.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.5; Tue, 13 Jun 2017 16:06:48 +0000
Received: from DBXPR07MB128.eurprd07.prod.outlook.com ([fe80::d1ca:c63d:b633:7aea]) by DBXPR07MB128.eurprd07.prod.outlook.com ([fe80::d1ca:c63d:b633:7aea%27]) with mapi id 15.01.1178.008; Tue, 13 Jun 2017 16:06:47 +0000
From: Balázs Varga A <balazs.a.varga@ericsson.com>
To: Stewart Bryant <stewart.bryant@gmail.com>, "draft-dt-detnet-dp-sol@ietf.org" <draft-dt-detnet-dp-sol@ietf.org>, "detnet@ietf.org" <detnet@ietf.org>
Thread-Topic: Some initial comments on draft-dt-detnet-dp-sol-00
Thread-Index: AQHS3jaeFtbHg1YzQECG1WdYRHsNrqIYA5nQgArS6nA=
Date: Tue, 13 Jun 2017 16:06:47 +0000
Message-ID: <DBXPR07MB1284A20FEEC9215FC2BB75AACC20@DBXPR07MB128.eurprd07.prod.outlook.com>
References: <abacca1f-a8a1-10f4-101f-f3ef08990d3f@gmail.com> <AMXPR07MB117C587758F3AE9915AC5CDACCB0@AMXPR07MB117.eurprd07.prod.outlook.com>
In-Reply-To: <AMXPR07MB117C587758F3AE9915AC5CDACCB0@AMXPR07MB117.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.a.varga@ericsson.com;
x-originating-ip: [188.143.73.100]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DBXPR07MB270; 7:Iq2KKthMd1pt2RLhOOzCRaFB7haV1lukRQKFNyHe04NTgMKWE1LHXNdesCDjqtWfpc7Yp1ikHU1l3uO224uWVzUAvmYweDuyS2LprpnEUlV3Zm5LftPDZ9RzKS0j3ltHTDZ9tZwah7IUbTz3fLy2QzFrXG7jIY+ImeqYg+1b4ANx+x54E9mJn7pv7X+jKJx7uIcAzMwjBf75IxaHZGq5WpB3oFic8hMEkYkNdejQWoQOgbH40If+Sv5Czi8H3vxruBfjrMMbE+GsEDP458+k60FjnvRje0bJeFJKEZQWJla+2XyFQPGPNKlB7Shzc8rxt4WPA7bst9XV0WN1yLENPQ==
x-ms-office365-filtering-correlation-id: 9d3d2a12-8587-42db-ae89-08d4b27631a1
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:DBXPR07MB270;
x-ms-traffictypediagnostic: DBXPR07MB270:
x-microsoft-antispam-prvs: <DBXPR07MB27063854C9A6287D5D22EB6ACC20@DBXPR07MB270.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(278428928389397)(131327999870524)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DBXPR07MB270; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DBXPR07MB270;
x-forefront-prvs: 0337AFFE9A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39410400002)(39400400002)(39850400002)(39860400002)(39450400003)(189002)(51914003)(65554003)(52314003)(51444003)(199003)(8676002)(81166006)(81156014)(68736007)(7696004)(106356001)(8936002)(85202003)(9326002)(105586002)(3846002)(790700001)(102836003)(229853002)(66066001)(6116002)(7736002)(50986999)(53546009)(25786009)(5250100002)(74316002)(86362001)(76176999)(189998001)(2501003)(54356999)(2201001)(39060400002)(85182001)(6246003)(2906002)(33656002)(14454004)(6506006)(6436002)(101416001)(97736004)(478600001)(53936002)(53946003)(38730400002)(55016002)(99286003)(2900100001)(9686003)(5660300001)(6306002)(54896002)(236005)(2950100002)(561944003)(230783001)(3660700001)(3280700002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB270; H:DBXPR07MB128.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DBXPR07MB1284A20FEEC9215FC2BB75AACC20DBXPR07MB128eurprd_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2017 16:06:47.3399 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB270
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHee6Lu46Wtzn1YPXBW1aKb4mQhOkGfvBDQUgf1My65c2NdNq9 S2YgmCTi1EhSyKlpYZhvKUvKVnM6pamYimGaaKkJIiFoRmKGa9td4Lff+f/POX/Ow0Ph8m4y kNJodRyvZbMZLylRm/ImPPyJTJkaNWaSxu7+rCNiW8d8Y0cXWSWe9Na4IElqbt7BLmJp0rhM LluTz/GR8dek6o2JfpTX00Hq71ve4UVo1kgakDcFdAzYByskBiSl5PQQgi9zy6RYDCMYWRxH roKgK3GwzDow0anB4NvmV0+xhOClocW9zItOhF5TvXteQdchaJhuRy7Dl06Az+NlXi5W0Eoo 3dj18FmYb9tw9lDOjGBYns9xyTI6DVZn1pEYUInAuvjKHeBNX4Y/xUOEixHtD9ujHZiLcToA 5lYaMfEiGprfT+Ai+8Ha9z1S7M+AXWuRR2fAbHjq6T8KU43l7jCgy3EY6OqRiMYFePzX5hl4 gGCrN03kELjX2O7RNeCwPUcip0P1o25MXNRPQtXsHiEaR2Bm3CERjW0v2DK1uaPlNActnSXo IQo17rtC5Fz4Pb1AGN3PcQhGalecTDn1EOgyR4otQVBdviQR+RSU1DdI9utNSNKG/AROuJ6T FR0dwfGaG4KQq43QcjoTcv6jgZ7dqF60tqqyIZpCzAGZfTshVU6y+UJBjg0BhTMKWalUmSqX ZbIFdzk+9yp/J5sTbOgwRTABMlXfZIqczmJ13C2Oy+P4/y5GeQcWoRNXfqiDJyctFcNNhE77 qS9M8DHarWemTxbLyqY+1MQPB9gLTQ7FZmiPnmyr6nDoo5tYZlmVvPOsDn89cFsXfbDTwl8y p31cKiuoPe5TqiSDXiALyQUmnzcXxmC/4tl+4tycSs2v+0vism7mpU8yx8KCW/UZ89ZEffOg giEENXs6FOcF9h895fEdQwMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/FQjYkzhs6JSWAqPQHZy-q2OV9NI>
Subject: Re: [Detnet] Some initial comments on draft-dt-detnet-dp-sol-00
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: Tue, 13 Jun 2017 16:15:55 -0000
Hi Stewart, Further feedback on your detailed notes inline in your original mail. Cheers Bala’zs From: Balázs Varga A Sent: 2017. június 6. 18:51 To: 'Stewart Bryant' <stewart.bryant@gmail.com>; draft-dt-detnet-dp-sol@ietf.org; detnet@ietf.org Subject: RE: Some initial comments on draft-dt-detnet-dp-sol-00 Hi Stewart, Thanks for the detailed review. Based on several good comments in the Chicago meeting we have started to update the draft. The major changes are: 1, changing encapsulation - PW-based encapsulation: The PW-based data plane can be run over an MPLS PSN. - Native-IP encapsulation: This solution is based on IP header fields, namely on IPv6 Flow label and a new DetNet Control Word extension header option. It is targeted for native IPv6 networks. 2, PW-label specific requirement is simplified (regarding uniqueness): - DetNet flows that need to undergo PREF processing MUST have the same PW Label when they arrive at the DA-*-PE node. We have also identified that sequence numbering related functions may be challenging, however it is a must for the PREF (Packet Replication and Elimination Function) implementation. PREF provides per packet level redundancy and not the so far defined per-PW-segment redundancy. Similarly, your concerns on constraining DetNet packets to a path and an interface in a pure IP network, is absolutely a candidate topic for further improvements. I will be back soon with further feedback regarding your detailed notes. Thanks & Cheers Bala’zs From: Stewart Bryant [mailto:stewart.bryant@gmail.com] Sent: 2017. június 5. 22:02 To: draft-dt-detnet-dp-sol@ietf.org<mailto:draft-dt-detnet-dp-sol@ietf.org>; detnet@ietf.org<mailto:detnet@ietf.org> Subject: Some initial comments on draft-dt-detnet-dp-sol-00 I took an initial look at the detnet dp document. I think that PWs are certainly a good way to go, but I am concerned about a number of aspects of the proposal. My biggest concern is doing the sequence number checking. There have not been many attempts to do this, and from work that we have done in the OAM space all the feedback I get is that this is a hard problem. It might be useful if you constrained the packets to a path and an interface using MPLS-TP or MPLS-TE, however I don't see a practical way to do that in a pure IP network. You could of course do it with SR, but that is v6 only, and the packets could potentially need a very large SR header. Please see the notes inline. -Stewart The PW-based data plane can be run over either an IP or MPLS [RFC4448][RFC6658] Packet Switched Network (PSN). SB> I comment on this in detail later ============ 5.1. DetNet Control Word The DetNet control word (d-CW) is identical to the control word defined for Ethernet over MPLS networks in [RFC4448]. The DetNet control word is illustrated in Figure 4. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| reserved - set to 0 | 16 bit Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: DetNet Control Word [Editor's note: Shoudl we care about high speed links, here 16 bits of sequence number wraps fast? For example, in a case of 100Gb/s link, 16 bits of sequence number will wrap in ~6.6ms assuming 1250 octets of packets and ~3.3ms for 625 octets packets. Both numbers mean quite long fiber distances, though.] SB> This worries me. Doing read modify write on the sequence number is SB> difficult in the general case, particularly without path constraint SB> since a packet can arrive on any interface, and this interface can SB> change. SB> SB> Are you thinking that there will be so few DN PWs that you can SB> put the counters in registers? That might fly at the T-PEs, but SB> I would be worried at the S-PEs. SB> SB> BTW shouldn't you consider much smaller packets, or do you imagine SB> that DN will be constrained to applications using large packets. [Balázs Varga A] Yes, Doing read modify write on the sequence number is difficult in the general case. However here we do write only at ingress node (e.g., T-PE). No modify operation defined. Read operation is needed on S-PE nodes, doing replication and elimination and they need a counter per flow. That is the tax of per packet redundancy. Not all flow may require PREF function of DetNet. Resources have to be considered during flow setup. =========== 5.3. DetNet encapsulation The DetNet data plane follows PW encapsulation. This document specifies a single encapsulation that can be used over both MPLS and IP packet switched Networks (PSN). The DetNet data plane encapsulation consists of a o DetNet control word (d-CW): contains sequencing information for packet replication and duplicate elimination purposes. There is a separate sequence number space per each DetNet label. SB> Do you mean per DetNet flow ID, or per PW label? [Balázs Varga A] In case of MPLS DetNet flow ID = PW label. o DetNet flow-ID (f-ID): uniquely identifies a DetNet flow within a DetNet network. Multiple DetNet PWs with different PW labels may have the same f-ID, which then implies the PWs are actually subflows of one compound flow. SB> I am not sure I understand the definition of a DetNet network yet. SB> I presume that it is Fig 5 from the architecture draft, which SB> is a tunnel between two service instances. SB> However I am having difficulty understanding the scope of the SB> uniqueness. It sounds as if it needs to be unique between a SB> pair of service instances is that the case, or does the SB> uniqueness have greater scope? SB> PWs are not subflows, they are "A mechanism that carries the SB> essential elements of an emulated service from one PE to one or SB> more other PEs over a PSN." [Balázs Varga A] the scope of the uniqueness is that it needs to be unique between a pair of service instances. [Balázs Varga A] In DetNet, PWs are used to transport the subflows (replica flows) of a compound flow. Inline with your quoted definition. o PseudoWire Label (PW Label;): a standard PW label that identifies a PW Instance within a (DA-)T-PE or (DA-)S-PE device. SB> Just so we are all clear the PW label changes at S-PEs [Balázs Varga A] Yes, the PW label may change. =========== o DetNet topology overlay label (L-label): an optional label used between (DA-)T-PE or (DA-)S-PE nodes. The main use of L-labels is to tunnel PWs through a PE node and therefore effectively making a PE node to behave like a P node. SB> This needs more thought. The reason that S-PEs were created SB> was to minimise the burden of running PWs between different SB> administrative domains. To make this feasible it was necessary SB> for the T-PEs to allocate their own PW label and have the SB> S-PEs swap, that way only the boundary nodes (S-PEs) needed SB> be worried about the mapping between the PE identity and the SB> PW label in the data-plane. SB> If a data-plane identifier is used, then we don't really need SB> S-PEs as such. So I think that we have to define the new SB> purpose of the S-PE more clearly when they are used for Detnet. [Balázs Varga A] There is dedicated chapter in the new data-plane draft version to describe in more detail S-PE nodes. I think that will be a good starting point for further clarification. In a case of MPLS-based PSN, the tunnel labels between LSRs are referred as T-labels. SB> I think that they are really LSP labels. [Balázs Varga A] Yes, they are LSP labels. The DetNet CW and the Detnet flow-ID together constitute the DetNet PseudoWire encapsulation header. [Editor's note: The current design has the DetNet flow-ID as part of the every DetNet flow packet. The flow-ID identifies the flow uniquely within the DetNet network and together with the sequence number information from the DetNet control word is used for PREF purposes. The flow-ID makes is easy for the DA-*-PE node to associate different PWs into one compound flow and perform the elimination of duplicate packets. SB> I am not sure this is needed. The DA-*-PE knows the relationship SB> between the PW labels and can make the decision based on that. [Balázs Varga A] That is a point where the design team had a long discussion. Table lookups were calculated and resulted in this note. I agree it may be implementation specific, so further details would be great to discuss. The flow-ID would point at the node internal construct that holds the received packet history for Korhonen, et al. Expires September 14, 2017 [Page 8] Internet-Draft DetNet data plane solution March 2017 each DetNet flow of interest. However, it could also be possible to associate multiple PWs into one DetNet flow just using the control plane provided information. In this case different PWs (using any PW label) would be mapped internally within a node to a local-ID (or similar construct), which again points at the internal per DetNet flow received packets history construct. SB> I think you have to do this anyway The explicit in-band flow-ID is easy from the processing and control plane point of view. SB> Isn't this a bigger change to the forwarder? What normally SB> happens is you vector to the instructions and context using SB> the PW label as the identifier. So I think the flow-ID just adds SB> complexity. Given that it needs to be unique and known at SB> each PW node on the path, I do not see what has been gained in SB> terms of reduction in control plane activity. [Balázs Varga A] That would be worth for further discussions with chip vendors onboard. The local-ID approach does not need the in- band information (thus has less overhead) but requires more from the control plane and the mapping information has to be stored into the LFIB. Current design decision is the in-band flow-ID but may be changed to local-ID if there is a strong reason to do the change.] Figure 6 illustrates a DetNet PseudoWire encapsulation using an MPLS PSN. Similarly, Figure 7 illustrates the DetNet PseudoWire encapsulation when IP PSN is used. The encapsulation is uniform above the PSN. Depending on the network topology the "overlay label" (L-label) may be part of the label stack. The L-label tunnels guarantee PW labels remain unchanged between DA-*-PE nodes. SB> Please see earlier Furthermore, L-labels tunnels allow selectively exposing the PW label to DA-*-PE nodes, which means some overlay topologies may just pass through specific DA-S-PEs without any DetNet specific processing. SB> They can do this anyway. At an SPE we normally just swap the SB> PW label, and other than for OAM reasons (trapped by TTL expiry) SB> we do no processing. So if you do not teach an SPE that the PW SB> is to be processed, it will just pass through. SB> SB> I think that you need to look seriously at deleting this component SB> of your design and building something much closer to a normal SB> PW design. [Balázs Varga A] This component is optional. There are some scenarios when it can be useful. E.g., on Flow identification for OAM purposes. We have discussed some troubleshooting scenario, where it was necessary on a link to being able to distinguish which DetNet packet belongs to which sub-flow of a compound flow. Example: sub-flow1: A --> D sub-flow2: B --> D So on link C-D we can NOT distinguish packets of the two sub-flow, as they have the same PW-label. A--+ \ C-----D / B--+ One possible solution is the use of the "Topology overlay Label". =============== When IP PSN is used, the label stack it transports is only inspected when the IP packet destination address equals to the IP address of a DA-*-PE or a P node. Essentially there are one more IP tunnels between a number of DA-*-PE and/or P nodes. The LFIB and the forwarding information base (FIB) combination determines whether a PW gets terminated at the node or forwarded to another node within a new IP tunnel. SB> So, setting aside for the moment the work that we are doing on SB> unifying SRv6 and MPLS SR, work which as yet has no official status SB> you should understand that there really is no deployment of SB> MPLS-PW over IP. All of the deployed PWs are either pure PW over SB> MPLS, or LT2Pv3. L2TPv3 has no concept of an S-PE. SB> SB> Now I think the unified approach is the right one, but so far SB> there are no real specifications. SB> SB> Also you need to think about whether you want ECMP or not, because SB> if you do you really do need the interstitial UDP layer (RFC7510) SB> shown below. [Balázs Varga A] This is fixed now in the new version of the draft. See my previous mail. ============== 6.1. Forwarded clarifications [Editor's note: The Detnet-aware "extended forwarder" does the heavy lifting on maintaining the sequence numbers associated with the DetNet labels. Extended forwarder is also responsible for packet replication and duplicate elimination. See the excerpt from RFC3985 Section 4.2.1. about forwarder's functions. We extend that to PREF: Some applications have to forward payload elements selectively from one or more ACs to one or more PWs. In such cases, there will also be a need to perform the inverse function on PWE3-PDUs received by a PE from the PSN. This is the function of the forwarder. ] SB> But note that forwarder function only appears in the T-PE, we SB> never included it in the S-PE which can be better thought of SB> as a two layer MPLS switch - it's not how it works although SB> a modern two label lookup MPLS system could do it like that SB> but all that happens in an SPE is that you swap two labels SB> simultaneously - the LSP label and the PW label. The DetNet specific new functionality in a DA-*-PE PW processing is the packet replication and duplication elimination function (PREF). This functional is a part of the "extended" forwarder. The PREF processing is triggered by the LFIB actions i.e., not all PWs receive Korhonen, et al. Expires September 14, 2017 [Page 11] Internet-Draft DetNet data plane solution March 2017 DetNet specific processing. Basically the LFIB has to be extended with a "PREF enabled" boolean configuration switch that is associated with the normal label actions (e.g., swap, push, pop, ..). The output of the PREF elimination function is always a single packet. The output of the PREF replication function is always one or more packet (i.e., 1:M replication). The replicated packets MUST share the same DetNet PW control word sequence number and flow identity word flow-id. The complex part of the DetNet PREF processing is tracking the history of received packets for multiple PWs. These PWs do not have the same PW label value while they still share the same PW sequence number counter and the history information. That is where the DetNet encapsulation header flow-ID plays an important role and binds the control word sequence number to the flow specific shared counter and history information within the PREF function. SB> That is certainly one way of doing it, although given that you need SB> to provision the PW anyway, I an not sure it is needed. [Balázs Varga A] This is fixed in the new version. PWs of the same compound flow have the same PW label. The DetNet flow word contains a D flag bit (see Section 5.2), which makes the DA-*-PE node aware of the direction the flow-ID arrived from. If the node, based on the local policy, checks for the D bit setting that effectively means the sequence number history has to contain also the D bit information. SB> I am really not sure why you need the D bit a PW received on a given PW SB> label only goes one way. [Balázs Varga A] If I remember correctly the scenario was for rings with clockwise and anticlockwise directions. ============== 7. Other DetNet considerations 7.1. Class of Service [Editor's note: Discuss the CoS.. and how that is archived when using MPLS or IP PSN.] SB> Don't all your packets need to go on the highest class of service? [Balázs Varga A] It is scenario and network operator specific. One may decide that some OAM traffic may have higher precedence than anything else. =========== 7.3. Time synchronization o PTP with on-path support: in this approach PTP packets are sent as DetNet flows, and intermediate nodes take part in the protocol as Transparent Clocks or Boundary Clocks [IEEE1588]. The on-path PTP support by intermediate nodes provides a higher degree of accuracy than the previous approach. The actual accuracy depends on whether all intermediate nodes are PTP-capable, or only a subset of them. SB> RFC8169 shows how to do TC in an MPLS network. SB> I am not sure anyone knows how to do this in an IP network. [Balázs Varga A] I think for IP hop-by-hop PTP support would be preferred. =========== 7.4. Bidirectional traffic Some DetNet applications generate bidirectional traffic and may require symmetric flows. There are already mechanisms that can be used to create bidirectional tunnels at the transport network level, such as MPLS-TP. The data plane solution SHOULD allow establishing bidirectional symmetric flows. Control plane mechanisms would need to also support this, though this is out of scope of this document. [Summary of existing mechanisms to create bidirectional tunnels that can be used.] SB> PWs are always bidirectional of course. [Balázs Varga A] Yes. 8.1. PW Label assignment and distribution The PW label distribution follows the same mechanisms specified for MS-PW [RFC6073]. SB> This will need extensions to support DETNET [Balázs Varga A] Yes.
- [Detnet] Some initial comments on draft-dt-detnet… Stewart Bryant
- Re: [Detnet] Some initial comments on draft-dt-de… Andrew G. Malis
- Re: [Detnet] Some initial comments on draft-dt-de… Balázs Varga A
- Re: [Detnet] Some initial comments on draft-dt-de… Stewart Bryant
- Re: [Detnet] Some initial comments on draft-dt-de… Balázs Varga A