Skip to main content

Minutes IETF103: detnet
minutes-103-detnet-00

Meeting Minutes Deterministic Networking (detnet) WG
Date and time 2018-11-08 06:50
Title Minutes IETF103: detnet
State Active
Other versions plain text
Last updated 2018-11-15

minutes-103-detnet-00
IETF 103 (Bangkok) DetNet WG Session Notes
NOTE TAKERS ADD YOUR NAMES HERE (not required):
Ethan Grossman
>  THURSDAY, November 8, 2018
>  1350-1550  Afternoon Session I
>  Location:    Chitlada 3
>
> Slides:    https://datatracker.ietf.org/meeting/103/session/detnet
> Etherpad:    http://etherpad.tools.ietf.org/p/notes-ietf-103-detnet?useMonospaceFont=true
> Meetecho:    http://www.meetecho.com/ietf103/detnet/
> Audio stream:    http://ietf103streaming.dnsalias.net/ietf/ietf1036.m3u
> Jabber:    xmpp:detnet@jabber.ietf.org?join
>
> Available post session:
> Recording:    https://www.ietf.org/audio/ietf103/
> YouTube:    https://www.youtube.com/user/ietf/playlists
>
> Slot Start     Duration    Information
> 0    13:50    10    Title:    Intro, WG Status, Draft Status
>                     Presenter:    Chairs
>                     Draft:    N/A

> 1    14:00    20    Title:    DetNet IP Data Plane Encapsulation, DetNet MPLS
Data Plane Encapsulation >                     Presenter:    Balázs Varga
>                    
Draft:    https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-mpls-01
>                    
Draft:    https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-ip-01 Balazs
Varga: IPv6 flow label use, any comments? Stewart Bryant: Within a
domain you can trust the flow label, given that you have control of all routers
in domain because what they do with the flow label is a configurable option on
the router. So we can use the flow label as a shortcut as long as the routers
on the path are obeying our rules for its use and aren't using the flow label
for something else, and given that we can ensure no stray packets will get in
that will mimic the behavior we want. Stewart to provide text on this. Lou
Berger: Want to see text on this in the management considerations section.
Stewart Bryant: I will provide text on this. David Black: That was also raised
as last call issue on Arch draft - need to protect edges of the domain both to
protect against traffic that doesn't look right from getting in and from some
misconfiguration letting non-elastic traffic out. What do the chairs want to do
about that? Lou Berger: a key caveat in that comment is that it applies to
non-elastic traffic. DetNet not at xport layer, so we are not specifying what
behaviors are at the transport layer. So that comment about elasticity
applies to transport layer not DetNet layer. David Black: My concern is that
the DetNet QOS chunk of a router sends traffic, and if you consider that
traffic by itself, not considering the transport, meaning if you fill all the
slots, it is inelastic, so we need to protect the rest of the world against
DetNet we have to assume we have inelastic traffic. Stewart Bryant: Important
point is that in IP we take a relatively relaxed approach to ingress edge
protection, compared to MPLS where you only get into the network then do what
the label says to do. It is harder in IP due to more edges and exposed attack
surfaces. We need to up our game in IP to build an IP deterministic network.
Lou Berger: Comments on Arch doc are implying that DetNet is a tunneling
technology, but it isn't, it's an IP transport network, thus it is operating
below the normal Transport protocols and doesn't impact those transport
protocols. All it does is impact the congestion experience or traffic treatment
received by those transport protocols. So circuit breaker behavior belongs in a
tunnel, not in an IP transport network. The transport protocol is still
expected to do the right thing, and if it has been modified to do something
different than our normal congestion control behavior, then it needs circuit
breaker behavior, not DetNet. I will put this on the list for discussion.
Stewart Bryant: With a transport network in general, things come in and are put
into the encapsulation that the transport network has and they don't get to do
their own thing, they only get to do what the transport network allows them to
do. This is not a normal IP design. Normally once you get an IP packet in the
network you do whatever the [output?] address says. Lou Berger: Right but we
don't impose transport behavior because we are running on a transport network
down here and the comments being made do that, so I think there is some
confusion on the part of the people making those comments - DetNet is not a
tunnelling technology it is a transport technology. David Black: I will read
your response and figure out what to do about it because I don't know that
circuit breakers are needed here, but it seems like a good idea that any DetNet
traffic trying to escape from the DetNet should be bit-bucketed at the edge of
the network. Lou Berger: We do that in IP networks, so if you have an
uncongested IP network connected to a congested IP network the flows from that
uncongested network will be "let loose" on that congested network. That's all
we're doing with DetNet, we're assuring that for that traffic, it doesn't
percieve that congestion. David Black: Let's take this to email.
--------------
David Black: Regarding 5-tuple vs 6-tuple. I will read the draft and write
some carefully crafted text because what is described here is what the
implementation has to do however flow identification may cause some people to
make incorrect inferences about flow. The upshot is that a flow is defined by a
5-tuple, but DetNet node has to identify a flow with a 6-tuple to pick off
traffic that gets DetNet treatment, but that doesn't constitute the completely
generality of a 6-tuple. Lou Berger: When you write that text, base it on the
forthcoming revised version of the draft. Also note that there is text in there
that says DetNet flow identification impacts next hop selection, but you are
saying we should do selection based on 5-tuple and treatment based on the
6-tuple. This is the crux of the comment and is an accurate observation and a
failing in the current text. David: This is also the same rational that we
should not mix DetNet and non-DetNet DSCPs on the same 5-tuple.
-------------
 > 2    14:20    10    Title:    DetNet Flow Information Model
>                     Presenter:    János Farkas
>                    
Draft:    https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-02
Brim from Huawei: Is it valuable to put the duration of a flow in the flow
parameters? Janos: Yes, that is a discussion item for today, what are the
group's opinions? Need to decide whether to include this parameter. Lou
Berger: We are getting into parameters that impact the control plane and the
scheduling of resources outside the data plane. We have packet scheduling but
this isn't packet scheduling this is scheduling of when a service will show up
and when it will go away. Similarly with bidirectional service we're getting
into something at the control plane level to coordinate traffic in both
directions. In terms of the data plane forwarding when you get to the HW you
must provision both paths in each direction separately so it is more of a
control plane concept.  If have bidirectional service it has implications
mapping from layer 3 to layer 2. John Messenger: It could be a control plane
parameter, setup and teardown...  or it could be considered to be with
ordering, and if you look at the LSR reference model there are places where it
might make sense to represent that kind of information too, at service
establishment and ordering level. But if it was realtime in terms of short
lived flows then it might be more appropriate to put it in the control plane.
Pascal Thubert: Maybe need indication of when path is set up so can send data
over it? UNI could signal that it is up. Janos: We have parameters along this
line in the document for the flow, in line with what we have for TSN, for
example about whether redundant paths were successfullyset up or not.

> 3    14:30    10    Title:    DetNet Configuration YANG Model
>                     Presenter:    Xuesong Geng
>                    
Draft:    https://tools.ietf.org/html/draft-ietf-detnet-yang-00 Lou Berger: A
minor point: you called out that an individual draft you referenced is really
about a DiffServ model and not really about QOS in general, maybe it is worth
pointing this out to them. To help them do the right thing. Xuesong Geng: I'm
not sure since there is no definition for whether DetNet queues belong to
DiffServ. Lou Berger: but there's no definition of DetNet as QOS, only DetNet
as DetNet. Xuesong: This structure works for both DiffServ and ... Lou Berger:
I wasn't commenting on your draft, I'm distinguishing between IETF draft work
and individual draft work. Greg Mirsky: You said YANG model for IP is
much simpler than for MPLS data plane? Xuesong: That is because all of the
parameters are needed for IP data plane solution are already defined in a
struct but now we have to split them out for IP and MPLS. Greg Mirsky:
But you can't say that DetNet over IP data plane is simpler than over MPLS data
plane. Xuesong: Yes, because IP dataplane design is still under construction,
the YANG model will have to be updated based on work of data plane. So we will
keep connected with the others of the IP data plane design team. Greg Mirsky: I
agree with that. Mach Chen: Simpler is based on the assumption that the current
YANG model including IP and MPLS tunnels has already been included in current
MPLS based flow configuration so it is easier to defend IP encapsulation model.
Xuesong Geng: Agree. Cristina Qiang: We just discussed in info model draft, if
time based detnet service is going to support in the information model draft we
also need to add some time related parameters. Xuesong Geng: Time related
params should be considered in transport queues YANG models. Cristina Qiang:
No, no. Lou Berger: That decision sits in flow info doc. If that gets it then
this one will get it. This doc mirrors what we do in the other doc, then this
one will follow. Xuesong: Agree. Janos: Why is it difficult to use the YANG
model defined by 802.1? Xuesong Geng: Look at the first slide... Lou Berger:
Given the time let's postpone this for Sunday meeting. This question is a
preview of what we will discuss then. Janos: We should not duplicate work done
by 802. Lou Berger: We will discuss this at Sunday session. Need to work out
what work we do where, so as not to duplicate work. Lou Berger: Regarding
splitting this into two drafts - they are loosely related, could split to allow
to progress independently, so from chair perspective makes sense. How many care
about this? Reasonable number. Who supports doing a split: Almost the same.
Objections to split? None. Lou Berger: OK please split the draft. They will
both be WG documents. Please propose some names and we'll go ahead with it.

> 4    14:40    15    Title:    DetNet QoS Policy and Yang
>                     Presenter:    Quan Xiong
>                    
Draft:    https://tools.ietf.org/html/draft-xiong-detnet-qos-policy-00
>                    
Draft:    https://tools.ietf.org/html/draft-xiong-detnet-qos-yang-00 David
Black: thanks for submitting these drafts, they raise
an important architectural issue for WG to resolve. Should one or more PHBs be
defined for DetNet? If so then DetNet traffic will use DetNet DSCPs not
existing ones. Not sure what the right answer it. Lou Berger: DetNet is about
delivering service for individual flows, so what does "DetNet PHB" mean in this
context? Norman Finn: Question: Regarding specific DSCP values: you often need
more than one class of DetNet service, e.g. hi, med, lo speed requirements, so
need 2 or 3 DSCPs. OTOH you often want to be able to give individual flows
different kinds of service. If using cyclical queueing and forwarding (CQF) you
don't have to identify the flow at all, you just use the DSCP or layer 2
priority to assign it. But in severalofthese cases, particularly if we are
defining DSCP values then we must defend network against any frame using our
DSCP values because it will screw up what we're doing if we have extraneous
traffic. This implies a defense method which is not as important if you are
looking at individual flows and validating them. If you are checking flow ID
before giving it DetNet service then it isn't a problem to re-use DSCPs.The
other part I don't understand is what a PHB is or what that means so I'd ask
for others to explain that. Lou Berger: Let's keep this document around
and discuss this further on list.  Some new things to think about, but not yet
sure what to do about it. Lou Berger: Who wants to hear more about this:
Reasonable number. OK, we're in sync. David Black: Thank you for raising this.
The high level answer to Norm's question might be to define a sufficiently
fuzzy PHB but no I don't yet know how to do that.

> 5    14:55    10    Title:    OAM for DetNet
>                     Presenter:    Greg Mirsky
>                    
Draft:    https://tools.ietf.org/html/draft-mirsky-detnet-oam-00 Stewart
Bryant: Concerned about fate sharing - you fate share OAM with end to end
service, but you don't fate share over the particular path that any given
packet was taking - so there's a dilemma? Greg Mirsky: If the network doesn't
use payload for determining behavior of the packet then there will be a
sharing. For example if they have ECMP and use payload to do hashing, selecting
path, then yes .. Stewart Bryant: But that won't happen because of the control
word. Greg Mirsky: But if they use entropy label, then OAM would use the same
label and there would be fate sharing. Lou Berger: We are over time, take this
to the list. Stewart Bryant: Or a work session call. Lou Berger: If warranted
to have an OAM interim or call, we are open to it. Lou Berger: Do you see
impact of OAM on the base dataplane documents? Greg Mirsky: No, OAM can
be a stand-alone document, not part of base document. Janos Farkas: Do you see
any changes required to base dataplane documents to support OAM? Greg
Mirsky: No, there is no redefinition for base protocol, we just define an
informational field that we can use in DetNet ACH format that can be used to do
PREF. Stewart Bryant: Without that conversation I am not so certain. There
might need to be characteristics we need to measure that we can't
measure... particularly as not allpackets go on same path depending on arrival
times and competing traffic. Pascal Thubert: There is work that started here
which is now in BIER that changes the headers to provide exactly what Stewart
is mentioning, which is the capability to explore out of the replicated and
eliminated paths which one actually worked. And to control when you have this
capability whether you actually replicate over all of the ports, all the
possibilities. This work impacts this separation. If we have this interim I am
happy to explain how this works. But you can't say now that OAM won't affect
the signalling because it depends on which proposal we use. Stewart Bryant: You
might have to turn off elimination to make this work properly. Lou Berger: How
many feel it is important for us to work on OAM: How many have read
draft? Slightly less. How many want to adopt as the foundation for WG activity
on OAM: An OK number, not great. Wait until it matures?  (No result recorded).
Don't want to adopt? Only one. Chairs will discuss and see where to go next.

> 6    15:05    10    Title:    DetNet Packet Loss and Delay Performance
Measurement >                     Presenter:    Mach Chen >                    
Draft:    https://tools.ietf.org/html/draft-chen-detnet-loss-delay-00

Greg Mirsky:  According to RFC7799 this is a hybrid method. Looks like
alternate marking method RFC8381 doesn't have to use 2 bits. With compressed
alternate marking method quality delay and loss measurements can be done with
one bit flag. Mach Chen: Actually here it is not necessary to use that
alternative marking solution. Because DetNet encapsulation already introduced
the DetNet control word which contains a sequence number and that can be used
to correlate the information. Don't need to use other means to mark and
separate packets into separate blocks, we have enough information already to do
that. Lou Berger: Let him finish his presentation and see what he is proposing.
Stewart Bryant: An issue: Using the sequence  number works
if you have a continuous expected rate of ingress packets, but if you have
packets that you want DetNet treatment for, but you can't be sure when the next
one is going to arrive, i.e. it may miss elements out, then you can't do it
with the sequence number because you have to set the expected sequence number
but you may not have any packets coming or you may get too many. You may be
able to steal a bit like you are suggesting here to do it, but using the
sequence number for alternate marking won't work unless you can be sure you
have a constant flow of packets.

Al Morten: 1. What Greg said. 2. What a long sequence number you have. Consider
packet reordering. Lou Berger: Cutting the line. good discussion for the list.

> 7    15:15    15    Title:    DetNet Bounded Latency
>                     Presenter:    Jean-Yves Le Boudec / Norm Finn
>                    
Draft:    https://tools.ietf.org/html/draft-finn-detnet-bounded-latency-01
Norm: Is this going in the right direction? Xuesong Geng: This preso can
answer the question from David about whether DetNet can change the PHB -
this presentation shows that the answer is yes can because the Q'ing
algorithm changes the elements of the PHB, including classifier,
Q'ing, metering, dropper. Perhaps part of them, but this is actually the PHB
for DetNet. Norm Finn: I will study more about this. I suspect DetNet will
involve several PHBs. Janos Farkas: Let us continue this discussion on the
list. Lou Berger: You changed something from where we left off at last
discussion: this is now to be normative not informative? Norm Finn: Yes that is
my suggestion. Lou Berger: As we discussed last time we wouldn't expect to
specify q'ing behavior in this WG - that probably would be defined
elsewhere,and we could discuss which working group. I thought we reached the
conclusion that the group thought it would be good to have this information
here to inform people on possible implementation approaches, versus being
required. If it is normative it is required. What we want to require is that we
per flow give the service that is provisioning for the DetNet service, but we
don't want to specify how it is implemented internally. that's where we were at
the last meeting as I understood it. Norm Finn: What I am looking for here is
not "this is the only way to do it", as much as "these are the requirements for
anything you do to produce the DetNet quality of service". Lou Berger: So you
want to define behavior through a mechanism but other mechanisms are allowed?
Norm Finn: Exactly. Lou Berger: So for us this translates to being
an informative document, and the requirement to deliver the service is what we
specify. That goes into the data plane solution documents. We can point to this
as informational. Norm Finn: Thank you that was my confusion. Stewart Bryant: I
don't understand your point Lou. This could be a standards track doc and is
only required behavior when you are executing the behavior of that document.
The fact that it is standards track doesn't bound DetNet to do it.
Lou Berger: The title and context of this is DetNet Bounded Latency. So it says
that if you want to implement bounded latency you have to do it this one way.
We don't want to limit our vendors to say they have to deliver it this
way. That's not something we typically do. Stewart Bryant: Agree, but that
doesn't mean this has to be an informational document. As a standard it  is
only required behavior when you configure a piece of equipment to behave like
this. Lou Berger: But that is not in our interest to say that if you want to
deliver bounded latency you have to do it this way. Stewart Bryant: That's not
what I'm saying. Norm Finn: The intention is to provide some options, if you do
these then this is how you have to do it, otherwise it won't work. Janos: It
would be cleaner if it were informational. Norm Finn: It is the same info for
MPLS or IP encaps; I would not want to put this in both of those documents.

David Black: Is what you refer to as the network calculus part of the
definition of bounded latency DetNet service? Norm Finn: I don't think it is.
It is information about how you can calculate it, not how you must calculate
it. David Black: So you are saying the calculus is implementation dependent
and that different implementations can meet the service definitions in a way
that requires different calculus to figure out service characteristics
and admission control. (No answer from Norm) Lou Berger: That's the limit on
how much we can discuss this now. How many interested: Most of the room. How
many think is headed in right direction, ignoring whether normative -
reasonable number, maybe half of before. We will discuss normative vs standard
with the authors, come back with a proposal, then probably move toward adoption.

> 8    15:30    10    Title:    Large Scale DetNet
>                     Presenter:    Cristina Qiang
>                    
Draft:    https://tools.ietf.org/html/draft-qiang-detnet-large-scale-detnet-02
David Black: On the IP based solution, a typical way to get more bits is to
insert a UDP shim. (conversation fragments) Lou Berger: We are out of time,
please take this to the list. Lou Berger: There has been no discussion on this
since the last time it was presented. If you want to progress it, have
discussion on the list.

> 9    15:40    10    Title:    SR-Based Bounded Latency
>                     Presenter:    Mach Chen
>                    
Draft:    https://tools.ietf.org/html/draft-chen-detnet-sr-based-bounded-latency-00

Lou Berger: Have to work out where SR-related work goes. Probably SPRING WG but
we can take that as we progress it. Greg Mirsky: Did you do estimate on scale
of this new adjacency SID... Lou Berger: We are out of time. On Sunday we will
try to figure out split of work between us and 802.1. Some of what you are
talking about may amount to work for 802.1 hopefully we will clarify this on
Sunday.

> 10    15:50    5    Title:    SR-Based Bounded Latency
>                     Presenter:    Yuanlong Jiang
>                    
Draft:    https://tools.ietf.org/html/draft-jiang-detnet-ring-02

(Out of time, did not present).
> Adjourn    15:55