Re: [mpls] [Detnet] DetNet: draft-eckert-detnet-mpls-tc-tcqf-03 request for feedback

[Toerless Eckert <[e-mail]>]

On Wed, Aug 03, 2022 at 06:53:23AM +0000, Pascal Thubert (pthubert) wrote:
> I’m also interested in seeing this work progress., Toerless. I need to find time for a good review.

If you're busy, hold your breath a little while, after David's remark in Philadelphia
i am planning to add the text for use of DSCP so we also have it working for the
IP/IPv6 data plane in DetNet. Something i think a lot of the asian networks are a lot
more interested in than MPLS (i started with MPLS because its the best fully built 
data plane we have).

> In the meantime I’d wish to progress on the architecture question of which layer or sub layer the shaper fits in. 

Well, someone correct me, but so far we hacve no bounded latency functionality
in either the forwarding nor the service-layer. Instead, AFAIK so far we
only have it in the subnet layer. Aka: RFC9023/RFC9024/RFC9037 relying on
TSN bounded latency in the subnets.

[ Btw: The DetNet pictures could kina be improved to show the "subnet layer"
in the hosts and relays below the forwarding layer because the way the
pictures are now, it almosst looks as if the subnet functionality does
not happen in the DetNet Relay nodes, but only in intervening (e.g.: TSN) switches.
I am quite certain this would only be pictorial improvemenets, and it was always 
understood that a DetNet Relay with TSN does of course also have the TSN subnet layer functions.]

If we don't want DetNet to rely on the subnet layer to provide bounded latency,
then i think it clearly belongs into the DetNet forwarding layer. Thats i think
also what i read from the DetNet RFCs.

> So far it was L2, DetNet did not cover it. If the application did not already shape its data according to the DetNet ingress expectation, the end to end service would not be rendered.

Well, i think in the host it would also be the TSN subnet layer doing the shaping
on behalf of the application, but unfortunately, i do not know TSN well enough
to know whether TSN actually models it that way. It would IMHO make sense though ;-)

> My feeling is that the shaper does not belong to the current DetNet sub layers either. It should sit above right below the application to control its output, and at the relays.

If we put bounded latency into DetNet (as opposed to the subnet layer), then i would
also claim that on the DetNet hosts it sits in the DetNet forwarding layer.

Cheers
    Toerless

> Does that make sense to you?
> 
> Pascal
> 
> > Le 3 août 2022 à 04:47, Toerless Eckert <[e-mail]> a écrit :
> > 
> > Thanks for the interest Zongpeng,
> > 
> > Given how the TC-TCQF solution is now within scope of DetNet charter, i think this
> > is also a good time to also get more input/review from the MPLS WG, hence Cc'ing it
> > (the chair where already suggesting to engage with th MPLS WG on this in the past).
> > 
> > For background: The draft currently covers what i think is the most easy deployable option to
> > enable tagged-cyclic-queuing-and-forwarding (TCQF) with the MPLS forwarding plane -
> > without changes on the wire, by reusing the existing MPLS header field TC.
> > 
> > If we choose to adopt this work in DetNet it would be good work to document not
> > only this most simple TC encoding, but also any other encoding that do not require
> > on-the-wire-changes, but that may be necessary when this most simple method is
> > considered to be not sufficient for some MPLS networks.
> > 
> > TCQF encoding that would encode the cycle in a new heder field (change on the wire)
> > should IMHO be work reserved for another draft. Primarily because i think we can
> > much faster finish specifying and deploying the mechanism with the options that do
> > not require changes on the wire - and collect experience with it (this is true for
> > MPLS as well as IP/IPv6, where we can use DSCP).
> > 
> > The draft therefore proposed allocation of MPLS TC values for use with TC-TCQF is
> > described in section 3.3 of the draft TC-TCQF draft. We would need 3 or 4 TC values.
> > 
> > Here is a bit more detail:
> > 
> > RFC3270 defines how to use the TC field
> > (actually, it calls it EXP, the field was later renamed to TC in RFC5462)
> > 
> > What our TCQF draft proposes is to propose to use the so-called 
> > "TC- Inferred-PSC LSP (E-LSP) behavior". This is described in section 1.2 of
> > RFC3270.
> > 
> > This is IMHO the most widely deployed method for using DiffServ with MPLS
> > and also the most simple to deploy, because it can get away without additional
> > control plane / labels. What this effectively means is that the network operator
> > configures in a DiffServ style 
> > 
> > When a deployment has already used more than 4/5 TC and therefore
> > does not have 3 or 4 TC free, then (i think!) the operator could allocate additional
> > labels space where the TC values are free. Depending on how MPLS experts read
> > RFC3270, this might require resorting to calling those LSPs SIDs and call that
> > encoding then an SR-MPLS mechanism.
> > 
> > We could also look into allocating 3 or 4 additional L-LSP, but that looks like
> > the most complicated option to me.
> > 
> > IMHO, a first RFC does not have to be complete with all possible encoding
> > options. I'd rather see an RFC finished that can be deployed, and when that
> > raises interest in the industry, but the vendors recognize some customers who
> > already used up all TC, then this would be good justification to do a -bis of
> > the RFC with the more complicated encodings.
> > 
> > Wrt. ECN: For TCQF, we do not need ECN: There CANNOT be any TCQF/DetNet traffic
> > with bounded latency that would need ECN markings. That would simply be a failure
> > of the bounded latency service. The non-TCQF TC values may indicate ECN
> > for non-TCQF traffic, but to the best of my knowledge ECN with TC is practically
> > not deployed.
> > 
> > Hope this help, please comment!
> > 
> > Cheers
> >    Toerless
> > 
> >> On Tue, Aug 02, 2022 at 09:14:24AM +0800, [e-mail] wrote:
> >> Hi, Toerless   
> >> 
> >>    I am Zongpeng Du from China Mobile.
> >> 
> >>    We are interested in the draft. However, we have a question about the method to convey the tag in the TOS of an MPLS label.
> >> 
> >>    MPLS label: 32bits
> >> 
> >>    00-19     20-21                                                 23                                    24-31
> >>    label       TC: Traffic Class(QoS and ECN)        S: Bottom-of-Stack          TTL: Time-to-live
> >> 
> >> As shown in the Figure, the three bits for TC have been defined as the format of "QoS and ECN". 
> >>    IMO, unless the IETF agrees to disuse it, we can not use the bits that have been used.
> >>    Do I have any misunderstanding here?
> >> 
> >>   Or, the label is special defined, such as an S-Label, so that we can define new use of the TC field ? 
> >> 
> >> Best Regards
> >> Zongpeng Du
> >> 
> >> 
> >> 
> >> [e-mail] & [e-mail]
> >> 
> >> From: Toerless Eckert
> >> Date: 2022-07-12 03:20
> >> To: detnet
> >> CC: draft-eckert-detnet-mpls-tc-tcqf
> >> Subject: [Detnet] DetNet: draft-eckert-detnet-mpls-tc-tcqf-03 request for feedback
> >> Dear DetNet WG
> >> 
> >> I just posted rev 3 of https://datatracker.ietf.org/doc/draft-eckert-detnet-mpls-tc-tcqf/
> >> 
> >> Diff over previous version 2:
> >>  http://www.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-eckert-detnet-mpls-tc-tcqf-02.txt&url2=https://www.ietf.org/archive/id/draft-eckert-detnet-mpls-tc-tcqf-03.txt
> >> 
> >> This version adds new text about the per-flow ingres enqueueing into the
> >> cycles, informational text about high-speed HW implementation considerations
> >> and a pointer to a research paper also describing such HW validation.
> >> 
> >> I think this makes the proposed work complete, and as authors, we would
> >> like to ask the WG for adoption - and the participants for feedback.
> >> 
> >>  Btw: The authors are also happy to discuss any restructuring, for example
> >>  Eshan told me it might be better to separaate the genreic mechanism from
> >>  the MPLS encoding (separate drafts). 
> >> 
> >> Quick summary, if you have not kept track:
> >> 
> >>  TCQF stands for Tagged Cyclic Queuing and Forwarding, and is a proposal
> >>  how to adopt the IEEE TSN "Cyclic Queuing and Forwarding" Queuing for
> >>  'native' use in DetNet, specifically with MPLS forwarding plane.
> >> 
> >>  CQF is a great queuing mechanism for DetNet because it does not only offer
> >>  bounded latency, but also tight-bounded jitter, important for all
> >>  industrial "synchronous" applications. It also is most easily scalable
> >>  in HW and operations for metropolitan or larger size WAN DetNet deployments
> >>  because it does not have per-hop state on every router.
> >> 
> >>  By tagging packets with the cycle number, TCQF overcomes also the issues
> >>  that keeps CQF limited to small-scale (few Km) Ethernet: it can support
> >>  large link delays and link-delay variation, and it reduces relatively
> >>  the required clock accuracy, therefore making it feasible to use this
> >>  on 100, 400 Gbs or faster networks.
> >> 
> >>  There is an expired problem description draft i wrote some time ago,
> >>  if you need more background: https://datatracker.ietf.org/doc/draft-eckert-detnet-bounded-latency-problems/
> >> 
> >> Cheers
> >>    Toerless
> >> 
> >> _______________________________________________
> >> detnet mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/detnet
> > 
> > -- 
> > ---
> > [e-mail]
> > 
> > _______________________________________________
> > detnet mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/detnet

-- 
---
[e-mail]