Minutes IETF105: detnet
minutes-105-detnet-04

DRAFT NOTES

NOTE TAKERS:
    Ethan Grossman
    János Farkas
    Andy Mali

> DetNet Agenda IETF105 (Montreal)
> Version: Jul 11, 2019
> Wednesday, July 24, 2019 (EDT)
> 13:30-15:30 Wednesday Afternoon session I
> 15:50-16:50 Wednesday Afternoon session II
> Centre Ville
> Slides:    https://datatracker.ietf.org/meeting/105/session/detnet
> Etherpad:    http://etherpad.ietf.org/p/notes-ietf-105-detnet
> Meetecho:    http://www.meetecho.com/ietf105/detnet/
> Audio stream:    http://mp3.conf.meetecho.com/ietf/ietf1051.m3u
> Jabber:    xmpp:detnet@jabber.ietf.org?join
> Available post session:
> Recording:    https://www.ietf.org/audio/ietf105/
> YouTube:    https://www.youtube.com/user/ietf/playlists
> Presentation        Start Time    Duration    Information    Session I
> 0         13:30    15    Title:    Intro, WG Status, Draft Status
> Presenter:    Chairs

> 1         13:45    30    Title:    DetNet Data Plane drafts (IP and MPLS)
> Presenter:    Don Fedyk (onsite) for Balázs Varga (remote)
> Draft:   
https://tools.ietf.org/html/draft-ietf-detnet-data-plane-framework-01 > Draft: 
  https://tools.ietf.org/html/draft-ietf-detnet-ip-01 > Draft:   
https://tools.ietf.org/html/draft-ietf-detnet-mpls-01 > Draft:   
https://tools.ietf.org/html/draft-ietf-detnet-mpls-over-udp-ip-01 > Draft:   
https://tools.ietf.org/html/draft-ietf-detnet-ip-over-mpls-01 > Draft:   
https://tools.ietf.org/html/draft-ietf-detnet-mpls-over-tsn-00 > Draft:   
https://tools.ietf.org/html/draft-ietf-detnet-ip-over-tsn-00 > Draft:   
https://tools.ietf.org/html/draft-ietf-detnet-tsn-vpn-over-mpls-00

Lou Berger: We have an unusual situation in which the chairs are contributing
to these drafts - so Ethan as Secretary will be Document Shepherd for these
drafts.

David Black: (IP, slide 4)
Flow ID is by 6 tuple, but the 5 tuple for the stream still has to be unique
for all streams over the network.

Lou Berger: Yes, obvious, so?

David Black: 5 tuple is Src, Dst Addr, Protocol, ports. 6 tuple adds DSCP.
Diffserv architecture says use DSCP to mark flow, not to subdivide flow into
subflows. Implies for IP draft it is ok to use 6 tuple to identify, but 5 tuple
must be unique since building on diffserv which says 5 tuple must be unique.

Lou Berger: Need to capture in your proposed text the implication of this
uniqueness.

David Black: 2 implications: Easy one: there are few places in diffserv where
you can mark a flow with more than one dscp. The decision to ID a flow by
6tuple says that DetNet can’t do that, no big deal, that’s a design decision
DetNet is entitled to make.

Lou Berger: We plan to change the flow ID to be a list rather than a mask. If
it’s a list, it can allow that.

David Black: Not when there is text in the IP draft that says a 6-tuple
uniquely identifies a flow full stop.

Lou Berger: It is a 6 tuple including masks and other things.

David Black: In that case we have some interesting text to write there.

David Black: The other item: A DetNet flow is also expected to be identified as
a flow using 5 tuple by others e.g. IP and DiffServ. So you need to use this as
an ID outside of DetNet. So it can’t be the case that a flow with this 5-tuple
with an EF DSCP vs a CS1 DSCP are different flows. You would have to change the
port or something to identify them.

Lou Berger: Are you looking at this as an app flow or a network flow?

David Black: Network, specifically DiffServ architecture.

Lou Berger: What is the implication of that data? What does it mean to be a
different flow? For example for an app flow, for a voice stream vs a video
stream, and we are combining them, and the only diff is DSCP, that is fairly
forbidden, understood. But from a network standpoint, if the stream is going to
get different traffic treatment then it is a different flow, that’s what
DiffServ does, gives different traffic treatment.

David Black: Yes but we try not to subdivide by tuples.

Lou Berger: It would be good to capture what restrictions there are on the
network equipment based on that  statement - I think we’re OK with the
statement as it impacts applications, won’t be misinterpreted. But about
network equipment, what would it have to do differently? David Black: Let's
take this offline.

Stewart Bryant: I am curious how a 5-tuple doesn't uniquely id a flow,
excluding NATs? They are a unique description of the flow.

David Black: We are in violent agreement.

Lou Berger: Agreed, but I’m confused.

David Black: But there is text in the draft that isn’t as precise on this point
as it ought to be. So let’s see how that text gets updated and then work from
there.

Janos Farkas: Yes let's see the new text and work from that.

Norm Finn: I assume it’s OK in a flow with a 5 tuple with diff't DSCPs if the
packets get out of order? David Black: That depends on the DSCP. It is true
unless otherwise specified, and there’s an important “otherwise specified”
called AF.

Norm Finn: In the drafts the intention of the flow ID is to route the flows to
different queues, to get the diff't QoS we want. To determine which queue a
packet goes into, the DSCP is an important distinction.

David Black: Correct and hence when the DSCP is picking off the Q, and you
don’t want reordering within a flow, don't use DSCPs in that flow to pick up
different queues and cause reordering, that’s the punchline.

Lou Berger: If that is the text you are putting in, people will agree.

Stewart Bryant: When you actually want diff't DSCPs for same UDP port since
going to same service on same application.

Lou Berger: Generally we don’t worry about app flows here, that is above us. We
are providing tools.

Stewart Bryant: Need some clarification there, I’m trying to figure out why you
would do it?

David Black: Best to point you at WebRTC which is doing a lot of muxing of a
lot of stuff. In general, if it hurts, don't do that, but we need precise words
to say that.

Stewart Bryant: I’m confused, I would like to see an example.

Lou Berger: It is part of the current Internet Architecture, which allows this
case. The WG has not suggested disallowing this case before. If we plan to do
that we would have to reach concensus and be really sure.

Stewart Bryant: It would be useful to have an example of a case where you’d
want to do this.

Lou Berger: Read about DiffServ, it talks a lot about this.

David Black: The simple case is that DiffServ defines a piece of functionality
that DetNet isn’t interested in, AF, assured forwarding. Inside an AF class,
AF3, they have 3 DSCPs in order of drop precedence. DetNet won't drop packets,
so can't use the ones that allow dropping.

Stewart Bryant: We need something in the text for this.

David Black: I have signed up for that.

David Black: Next topic, I am confused about the purpose of the Mgmt and
Control Information? I’m trying to figure out what to do about the v4 “type of
service” and v6 “traffic class” fields. So what I’d like to understand is, what
is the info on this slide used for?

Don Fedyk: These are the possible fields you can choose to ID traffic, but it
doesn't have to have to be all of them at once.

David Black: What do you mean by identify?

Lou Berger: Traffic classification.

David Black: OK for traffic classification the type of service and v6 traffic
class fields then need to be split because the ECN field is in there, and the
ECN field must not be used to identify traffic. That’s the easy one; and then
the DCSP is the other 6 bits in those two fields, and it can be used to
identify and classify traffic, that’s fine.

Lou Berger: We need some clarifying text for that, we already agreed to fix
that; we should have broken it out already in the doc.

David Black: Need to rewrite to split type of service and traffic class fields
out into DSCP and ECN fields and get rid of the bitmask. I need to write an
email to clarify what has to change and why, now that I understand this is to
be used for traffic classification. That to me means these are the fields you
can use in a filter to carve out the very small chunk of traffic that is to go
through the DetNet forwarding plane in the node. DB to provide this text.

> 2         14:15    20    Title:    DetNet Flow Information draft
> Presenter:    Balázs Varga (remote) or János Farkas (onsite)
> Draft:   
https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-04

Xuesong Geng: What is the relationship between the parameters in the green box,
the dynamic flow format vs the blue box, the DetNet service delivery type?

Janos Farkas: In the green box there is the DetNet payload type, that is
related to the service delivery type. When you look at the DetNet service it
can be like a layer 2 service that is provided by DetNet service for a layer 2
Ethernet DetNet flow, or layer 2 app flow.

Xuesong Geng: I can understand the payload type is different, but the flow
format and delivery type should be the same?

Janos Farkas: The flow format reflects whether it is an MPLS or IP data plane.
The same packet network may provide both data planes in some form, so it is
good to know which it is. That’s the idea.

Xuesong Geng: So we conclude that they can be different.
Janos Farkas: Yes.

Lou Berger: What is next to get to last call?

Janos Farkas: This was contributed work, so we need feedback, a thorough review.

Lou Berger: Did you capture everything that happened in all the other data
plane documents?

Janos Farkas: We did our best, but this is a first try from our side, and
self-review is tough.

Lou Berger: We need the WG to review it, now is the time. But we need to review
what was done in the other documents before last-calling this one. Would it be
good to last-call it at the same time as the data plane documents, or not?

Janos Farkas: Not sure.

Lou Berger: The tradeoff is that it would require a lot of reading by the WG,
but the benefit is that it would be readable as a complete set, to get the full
picture

Lou Berger: Right now don’t have a strong opinion.We can think about it.

Andy Malis comment via Jabber: If this document is normatively referenced by
the data plane drafts, they should go at the same time

> 3         14:35    15    Title:    DetNet Configuration YANG Model
> Presenter:    Xuesong Geng
> Draft:    https://tools.ietf.org/html/draft-ietf-detnet-yang-03

David Black: I’ve sent to the list 2 changes to IP data plane draft to take out
DSCP bitmap and ECN from use in flow ID.

Xuesong Geng: Once the data plane draft is fixed, the YANG model can follow.

Lou Berger: David, thanks for this contribution. There is a github for this WG,
so any one can suggest specific changes and do a pull request.

Xuesong Geng: Maybe it is not clear the relation between traditional DiffServ
and DetNet services? Maybe we should have some explicit documentation of this,
to make it easier to understand how best to use the DSCP value in DetNet?

Xuesong Geng: Structure of YANG is now stable, so other parts can be added.
Please review and comment. May need weekly discussion on YANG, as is done with
data plane.

Lou Berger: Per author's tempo, we can make sure the WG’s webex is available to
you for enabling keeping pace with this work.

Lou Berger: To get to last call, need other docs to be complete, then need to
align to them. New structure is now in place?

Xuesong Geng: Yes but subnetwork is not in the draft yet.

Lou Berger: We have to have a framework that allows augmentation for specific
technologies in the future. As long as we have that type of framework that
allows augmentation for subnetworks and for app flow side then we can run
ahead, and we can always add TSN as their own documents as an augmentation to
the base model.

Xuesong Geng: Yes, but also need to add aggregation case?

Lou Berger: Yes, aggregation is part of core IP, MPLS docs, should be covered.

Xuesong Geng: Could be last called with other docs?

Lou Berger: Should follow, best to wait until just after data plane are done,
so won't have to apply last call changes to this draft also.

Lou Berger: Maybe by November IETF if we are halfway done it would be good.

> 4         14:50    20    Title:    DetNet Bounded Latency
> Presenter:    Norm Finn
> Draft:    https://tools.ietf.org/html/draft-finn-detnet-bounded-latency-04
> If published   
https://tools.ietf.org/html/draft-ietf-detnet-bounded-latency-00

Lou Berger: We ran a poll on adoption, so the draft has just been adopted,
please resubmit as detnet draft 00 version.

> 5         15:10    10    Title:    DetNet Bounded Latency Requirements
> Presenter:    Liang Geng
> Draft:   
https://tools.ietf.org/html/draft-geng-detnet-requirements-bounded-latency-03

Janos Farkas: You said want to set requirements w/o specifying solutions, but
it sounds like you have chosen CQF as a solution? For example we just heard
about asynchronous traffic shaping which doesn't have these type of problems.
The other assumption you are making in the previous slide is that the TSN
domains are time synchronized, but that is not a must.

Liang Geng: I am not choosing a solution, the intent is just to provide these
as alternatives. Have not assumed these, but could be guidance.

Janos Farkas: There are other solutions that could work, as we have heard.

Janos Farkas: For smart factory usually not long haul link?

Liang Geng: But we have heard requirements from some large factories that have
central control at several hundred km away, but perhaps that is unique to a
given market.

Norm Finn:  Maybe something for TSN people to think about, when working on
bounded latency draft, the pater noster scheme which might be more useful in
meeting this particular document’s requirements. We need to think about how to
do that, e.g. with a draft, or in TSN?

Loa Anderson: I like this, it looks close to WG adoption, if the draft is as
clear as the presentation is. The use of Must and Should, are those intended as
MUST and SHOULD in IETF sense?

Liang Geng: Good comment, it is written that way, but not really intended to be
that formal, needs to be looked at more carefully by the authors.

Loa Anderson: If not, need to change accordingly.

Loa Anderson: Question about the numbers, but here in 7.1 and 7.2. Link node
changes are topology changes, so rather the same thing, need to adapt language
to this. Regarding link definitions of  “intercontinental” vs “intercontental
long” link? Are these different? Some words like "long, big" which are not
defined. Should put effort into defining what they actually are.

Liang Geng: Agree, need to take more care of language here. Really just long
haul, need to re-word to describe.

Ethan Grossman: This seems rather like the Use Cases draft, in that it looks at
making sure that the capabilities of DetNet meet the real world requirements.
Some of the items mentioned are already mentioned in the Common Themes of the
Use Cases draft, so they are already part of what we are doing here. Also in
the Use Cases draft we avoided the MUSTs and SHOULDs and word “Requirements”
since we are trying to guide the work but not define what has to be done. So
I’m trying to understand if we adopt this draft, what is the relation of this
draft to the Use Cases draft? Have you thought about that?

Liang Geng: I understand your concern, but the Use Cases draft is about the
service or application point of view about what the application requires the
network to be in terms of functionality and performance. This requirement is
actually technical requirements for performance, so I don’t see them as
overlapping, but I might need to re-read that draft to understand these
concerns.

Janos Farkas:  Actually the Use Cases draft sets forth a good set of technical
requirements, but this could have been a chapter in the Use Cases draft, but it
is late now since that is already an RFC.

Liang Geng: Different people mean different things by requirements or use
cases, like in 3GPP requirements can stand for use cases, but this requirements
document does not talk about use cases like video or audio or things like that.
It is really about how we think the network should function and perform. And
given that the Use Cases draft has already been published…

Janos Farkas: One of the requirements in the Use Cases draft is about how many
packets can be lost, it is very specific, but it doesn’t need to have its own
draft.

Norm Finn: Have you made a clear distinction between synchronizing time in the
parts of the network and having the same frequency in the various parts of the
network? I know there are service provider networks that provide frequency lock
without time sync, for example CQF can be made to work with frequency sync
without needing time sync.

Liang Geng: Yes, we consider time sync or time variance versus clock frequency
variance to be two different requirements (need to change title of slide to
time and clock variance)

Norm Finn: So asynchronous clocks, does that mean there are also different freq
domains? Liang Geng: Yes.

Norm Finn: So within the domain it is not a problem to have frequency lock?

Liang Geng: It needs to be within a tolerance.

Norm Finn: Everything is within a tolerance, there’s no such thing as perfect

Liang Geng: For 5G backhaul, I don’t recall exact number but it is smaller than
the previous two examples, and that’s the tolerance we need to obey for clocks
asynchronization.

Stewart Bryant: I recall the numbers being 1.2usec or you can’t work at all,
and there are lots of numbers between 350ns down to 150ns to get the optimum
use, and so I imagine that those kinds of timing numbers are going to be
commodities in the network because every transmitter is going to need it.

Mach Chen: In the numbers Stewart mentioned we need to differentiate between
front and backhaul clock sync requirements?

Liang Geng: I don't recall exact numbers for 5G but I can check that:

Janos Farkas: As noted on the list, I’m not sure if time sync requirements
should be DetNet requirements? We let implementers choose their time sync
solution. Time sync solution is part of implementation. Good set of
requirements, maybe study more about time sync.

Lou Berger: Need to wrap up, how many think this is a topic that the WG should
be working on to refine and document?
     Product of IETF are documents – should we be working on documenting this?
     Result: Reasonable number. How many not: nobody, that’s pretty clear. How
     many have read the doc? Less than before, but a reasonable number. Is this
     a good starting place for our work in this area?
         Somewhat fewer, so there’s some weakness here.
     Maybe go through some draft updates, discuss more on the list? Maybe if we
     want we can discuss further in the second session today.

> 6         15:20    10    Title:    DetNet SRv6 Data Plane Encapsulation
> Presenter:    Xuesong Geng
> Draft:    https://tools.ietf.org/html/draft-geng-detnet-dp-sol-srv6-01

Janos Farkas: What are you looking for here? We discussed SR as a tool to
establish explicit routes, but we have chosen to specify an IP data plane
solution without any new fields for DetNet. Reading this it is like a new data
plane for DetNet that would require new fields, so is this a new data place
specfic to SRv6?

Xuesong Geng: Yes, this is a new story for SRv6, not native IP.

Stewart Bryant: Clearly it is a new data plane but it has properties we don't
have in existing ones so we should look at it seriously. And there is a lot
going on in network programming e.g. SPRING. Don't know which of those would be
the right one to pick.

Xuesong Geng: This will also be presented tomorrow in 6MAN WG to show to more
SRv6 people to get feedback from them. But we think it is necessary for DetNet
to see that SRv6 can implement DetNet.

Stewart Bryant: Agree, should have PREOF in the IP domain, and maybe people
will want an SRv6 solution as well.

Lou Berger: A lot of flux in SPRING at this time, in SRv6, should be aware of
this. Is DetNet on SRv6 something we want to take on as a new data plane, i.e.
expand our solution set to SRv6? How many people in the room are interested?
Result: Some few hands. Should not be working on it? Result: none. Reasonable
information.

Pascal Thubert: There are two things, to layout path, then the dynamics of how
many packets are going through the path, e.g. tuninq queues. I can see how SRv6
can be used to serialize a complex path, but I see less how we can signal
everything we need to signal from the packet, like the rate, which must be
maintained in the hops. So there has to be a balance between what can go in
packet vs in the hop. In the extreme we have BIER, where the bits indicate the
segment, but nothing about realtime. Everything is laid out, all state is in
the hop, so we just decide to use it or not. In this case could signal the
existing things, or signal some more, but you will still need hop state.

Xuesong Geng: Understand concerns, have read BIER draft, interesting option for
PREF. Similar to multicast case, if we use BIER it is a natural idea. But
different story between BIER and SRv6. In BIER don't need status, but doesn't
mean an SRv6 solution isn't valuable, it is just another way. If it works, it
would be good.

Stewart Bryant: We do need a full blown IP solution that can be deployed in
regular IP networks, but whether they will be running SRv6 I don’t know, since
that is more of a service provider domain. So even if we do this, still need
existing IP sol'n. Needs to be aligned with IP network slicing, but industry is
not quite clear there, some push for SRv6, but some 3GPP are not sold on that
design.

Xuesong Geng: It is just another option to do DetNet, it does not replace
native IP. We are just adding a new draft.

Stewart Bryant: But the current data plane doesn't support PREOF for IP, we
don’t have a full service IP solution, and we need to remember that.

Lou Berger: Have IP over MPLS which would be equivalent. IP over SRv6 would be
equivalent.

Loa Anderson: Agree with Stewart. Lou said I didn't like how the question was
phrased. It is because it is too early; we need to wait and see where SRv6
goes. If SRv6 will be part of a DetNet type of network, then we need to do
something. But if apart, there’s no point can't decide that today.

Xuesong Geng: But SRH is stable now, a standards track RFC.  So SRv6 with SRH
is stable enough.

Mach Chen: BIER can be a candidate for DetNet PREOF...

Lou Berger: Should not talk about BIER now.

Pascal Thubert: I mentioned BIER just to contrast between where state is
maintained, not as suggestion for PREOF for IP.

Lou Berger: We can continue this next session if we have time. Adjourn first
session, return in 15 minutes.

> Adjourn         15:30
>
> 15:50-16:50 Wednesday Afternoon session II
>
> Presentation        Start Time    Duration    Information    Session II
> 0         15:50    5    Title:    Intro to Session II
> Presenter:    Chairs

> 7         15:55    20    Title:    DetNet OAM
> Presenter:    Greg Mirsky
> Draft:    https://tools.ietf.org/html/draft-mirsky-detnet-ip-oam-00
> Draft:    https://tools.ietf.org/html/draft-mirsky-detnet-mpls-oam-00

MPLS OAM draft:

Andy Malis: The draft needs to specify if the sequence number goes through zero
or not, for example 255->0>1 or 255>1. That is currently not specified.

Greg Mirsky: Yes, the sequence number may wrap, but I understand that for PREOF
that is not critical.

Janos Farkas: The data plane docs are very specific about this, so the OAM
draft should follow.

Greg Mirsky: Will review that draft.

Lou Berger: Do people think this document is headed in the right direction? Few
responses
   How many have read? Few.
   How many think we should be working on OAM for MPLS data plane? Reasonable
   number. We can't do much with the low number of people who have read the
   document.

Stewart Bryant: To make progress, maybe we should review at an interim?
Lou Berger: Could have an adoption poll but if it is rejected, don't consider
it dead, i.e. understand it to be a guage of whether it is headed in the right
direction, and can just be redirected. We generally agree need to work on OAM,
question is whether there is support for this specific solution.

IP OAM draft:

Lou Berger: Sounds like a good description of the problem; do you have any
proposed solution?

Greg Mirsky:  That’s what I have. IP OAM has to be mapped with DetNet flow.
Maybe there needs to be some management tools. If there is ECMP in the network,
then it will be more of a problem.

David Black: Ouch, Greg is completely correct.

Janos Farkas: On the co-routing stuff, we have in the flow info model
introducing some parameters trying to make congruent with ID parameters, like
flowID and so on, maybe extend to OAM to ensure it goes along the same flow.

David Black: Example: Suppose that the DetNet forwarding plane is fouled up a
node, but the IP forwarding plane is not. The OAM traffic, traceroute in
particular has to go through the DetNet forwarding plane to tell you where the
broken node is because if you send it through the IP forwarding plane it will
tell you everything is OK.

Lou Berger: You also have to get into the right queues because there’s a whole
queueing behavior property.

David Black: That is part of forwarding plane. In queue-speak if the DetNet
queue is broken in a node and the corresponding queue for the pair of IP
addresses is working, you send traceroute on a different path than the DetNet
queue, then traceroute will fail to find the problem.

Norm Finn: It is not trivial to get OAM to follow IP, understood. And not easy
to get it treated with same QoS (make sure it goes in the same queues etc).

Greg Mirsky: If flow is identified by 6-tuple and that controls which queue it
goes to, I understand, but if we can’t make that happen then we can’t make OAM
do its purpose.

Norm Finn: Must look at OAM and know which flow that OAM is for. There is an
OAM flow per DetNet flow. Also we must allow for bandwidth of OAM in each
DetNet flow. So OAM must be limited in bandwidth and comply with same rules
that apply to the DetNet flow itself.

Norm Finn: Consider that with PRF, can argue that the sequence number allows
the flow to be the OAM – you don’t get all the functions, but you get
connectivity. So if you have two paths, getting one packet on one path but not
the other, then you know something is wrong, not just that the source stopped.
If you have the two paths.

Greg Mirsky: Can use hybrid OAM methods. It is a good compliment but not a
substitute for active OAM where packets are constructed for test purposes.

Greg Mirsky: IP has some properties we need to discuss, e.g. fate sharing.

There are two scenarios for OAM: Tunnelling, and interworking. Can look at
DetNet or MPLS domains as one hop, or interwork as end to end DetNet.

Stewart Bryant: Have never been able to solve congruent paths with IP. Maybe if
use explicit routing? SR, or PPR, RSVP-TE, PCE-based, etc. So there are at
least 5 possible solutions for this. Once one of those is in place for DetNet,
then the OAM will naturally be fate sharing.

Lou Berger: We have been here before with MPLS, discussed companion labels
co-routed with shared resources, but wasn’t adequate since something in label
database might be corrupted, so just because use same resources and paths,
because use different traffic class identifiers then OAM may still not succeed
which is why we ended up with GASH and Gal, we’ve been here before, don’t
forget those lessons. But we can do something like resource sharing and
congruent paths.

Stewart Bryant: Would have to have all the same queueing stuff, DiffServ paths
and so on. .

David Black:It is worse, ICMP is crucial part of IP OAM, it has none of that.

Stewart Bryant: So you have to set explicit path such that the source and dest
pair are the trigger, not a richer set of information in the packet.

David Black: Correct. If you do your DetNet selection based solely on IP
src/addr pair, then you will pick up ECMP, but if you get fancier than that
then things get risky fast.

Lou Berger: Is OAM for IP DetNet something this WG wants to work on?
    Result: reasonable number but less than MPLS case, surprising. MPLS is an
    easier problem.

Stewart Bryant: This is potentially a much broader problem than just DetNet
since we don’t have a first class IP solution that has these properties.

Lou Berger: Our forwarding is different than IP, but we have different' things
available to us, e.g. all of our 6-tuple flows are explicitly controlled, so
can put additional requirements on control plane (which doesn’t answer what we
do in the data plane) but we have different tools.

Stewart Bryant: A more constrained problem, but still one that is not solved by
IETF yet.

Greg Mirsky: What we are monitoring is what we are measuring, we don't know
where it is in the network. We know if is between two points but we don’t know
which nodes these packets are traversing.

Norm Finn: More interested in plain IP OAM than MPLS since harder more fun
problem than MPLS OAM. If someone comes up with a plausible solution I would
like to hear about it.

Lou Berger: Those who are interested, please self-organize, Mirsky to
coordinate activity, maybe get critical mass on it. Maybe could have informal
Webex work meetings, contact chairs to get set up. Or could ask for interim on
this. But first try self-organizing, then see how chairs can help.

> 8         16:15    10    Title:    DetNet Controller Plane Framework Intro
> Presenter:    Xuesong Geng (onsite) for Andy Malis (offsite)
> Draft:   
https://tools.ietf.org/html/draft-malis-detnet-controller-plane-framework-01

Lou Berger: Based on charter, but to be validated by Deborah as AD: We are not
chartered to do control plane solutions; we are chartered to do management and
control plane requirements, i.e. to identify what we need from a control plane.
So part of this draft is in scope, some not. Identifying gaps in control plane
solutions is within charter. If we identify a solution we’ve gone too far, we
should be talking to other WGs about solutions. Discuss which specific
technologies are available, that is safe ground. But proposing solutions is out
of scope.

Stewart Bryant: If we need to do a control plane solution, we don't want to be
stalled on this.

Lou Berger: There are at least 3 groups working on control plane in the routing
area; we should go to them and ask them to fix any gaps in their protocols. If
they have a good reason why not, then we'd have a strong reason to ask IESG to
re-charter DetNet.

Stewart Bryant: We need to get past that soon. We wanted to get data plane
going first, but now it is in good shape, we should be starting early work on
control plane, since it will take time.

Lou Berger: Most of this doc is really helpful. .

Stewart Bryant: We need to clear the structural and administrative obstacles to
working on control plane.

Lou Berger: It is only specification of control plane solutions that is out of
scope.

Stewart Bryant: OK as long as we have a path forward.

Lou Berger: Earlier in TEAS was a proposal for doing TE for IP flows. May end
up with sol'n we can use even before we discuss framework.

Loa Anderson: Given we have a good document, 98% in scope, the problem I see is
that if plan to go to other working groups, will it be the DetNet Chairs who
will take that initiative?

Lou Berger: Once we identify shortcomings, then we can discuss with IESG. If we
have proposals then it will be specific, not generalities.

Andy Malis: We were being conservative in our reading of the charter. Does
include "management and control", what we call the controller plane. So that is
in scope.

Loa Anderson: Concerned that you are pushing it too far out. We should be
proactive now to start discussing within the WG that we need to be involved.

Lou Berger: Need some concrete control plane proposals on the table, in
documents. If anyone has any control plane solutions, please contribute it
somewhere in IETF. Don't hold up on process, get docs submitted.

Eric Gray: We could already start this now, in TEAS, so maybe since that is Lou
talking to Lou it may not be that difficult.

Lou Berger: We have a controller plane framework document here. Should the WG
spend time on architecture and framework discussion on controller plane, given
that it is scope for our charter? Result: Similar number to previous, a smaller
than expected number. Anyone think we should not be? Nobody.

Lou Berger: For this doc please carve out solutions, write them up and discuss
them separately, but continue discussing this document in the WG.

Xuesong Geng: If have alignment on what to do or not to do, it will be clear if
it is in charter.

Lou Berger: Don’t worry about charter. Discuss what is missing, put solutions
in another doc, contribute to appropriate working group. Main thing is to get
it contributed and get discussion going.

Xuesong Geng: Without detailed discussion of specific solutions, what would the
purpose of this draft be? Is that the right direction?

Lou Berger: Here’s what we need from a control plane, here’s what’s missing.
What the options are and where the gaps are. More like a gap analysis, define
what has to be done.

Lou Berger: Notes that AD did not get up and shout at us, this is a good result.

> 9         16:25    10    Title:    Deterministic Networking Application in
Ring Topologies > Presenter:    Liang Geng > Draft:   
https://tools.ietf.org/html/draft-jiang-detnet-ring-04

Janos Farkas: What makes this so specific, given that we have DetNet MPLS data
plane and other ring topology work? Is this an informational document on how to
combine these into a solution?

Liang Geng: This only describes how to handle ring topology in an MPLS data
plane.

Lou Berger: Have you looked at other MPLS ring solutions in the IETF?
Liang Geng: Yes.

Lou Berger: Do they not apply? Can you not build on them?

Liang Geng: Principles are similar, but when you introduce DetNet, you add
PREOF, which are not covered elsewhere.

Lou Berger: We have PREOF at service layer. Have you looked at using existing
MPLS rings soln's at the forwarding layer?

Liang Geng: No, good question.

Loa Anderson: This is RMR for the forwarding layer, then you need to add PREOF
for service layer. We shouldn't specify anything new for the forwarding layer,
should use RMR.

Kireeti Kompella: How do you determine clockwise vs anticlockwise? Every node
has to have the same notion.  How do you get all nodes to agree on which is
which?

Liang Geng: Configure it before hand.

Kireeti Kompella: One advantage of RMR is that it does this by advertising
something then does it automatically. Other thing is in this two ring case,
with "upper node" vs "low node" - how can this be algorithmically done, or you
will have to configure them all. If you have a lot of rings, making sure you
configure them all can be difficult.

Kireeti Kompella: To make scalable, must be algorithmical. Also there can be
chords, e.g. bypass some nodes, e.g. optical bypass. Is that of any interest to
DetNet?

Liang Geng: This is a question for the authors, will take it offline.

Lou Berger: Look at RMR and try to build on it.

Jeong-dong Ryoo: There many ring protection mechanisms including MPLS, RMR. For
those we can't avoid traffic disruption in case of a network failure. With this
DetNet ring, at least we won't lose packets, so that is an advantage of this
document, of DetNet.

Janos Farkas: That PREOF comes with DetNet. This is combination of ring in the
forwarding plane and PREOF in the service sub-layer.  The Ladder topology is
comprised of rings, for which examples are given on the use of replication and
elimination, e.g. as described in IEEE802.1CB.

Jeong-dong Ryoo: How to use ring protection with DetNet? My answer is when you
use this DetNet protection mechanism, you must disable conventional protection
in forwarding sub-layer. I understand the Ladder topology, but this draft
explains how to apply DetNet technology to rings.

Lou Berger: You are saying there is an opportunity for a PREOF-optimized ring
protection using DetNet. But we would like to leverage RMR, so if you can
leverage that please do, or explain why you can’t. Need to include how to make
it scalable.

Jeong-Dong Ryoo: What do you mean by scalable?

Lou Berger: That each ring doesn’t need to have the same number of PREOF
functions as you have end to end, if there’s a way to do that, some shared
protection. If your solution is that every ring is a segment, and you do a ring
for every flow, maybe there is an opportunity to do something better, e.g.
through aggregation.

Jeong-Dong Ryoo: Can't quite catch it now, we can follow up offline. Including
relation to existing rings e.g. RMR.

Kireeti Kompella: Since multicasting on both rings, not really doing
protection, just that if one fails get the packet over the other path. But RMR
has two parts, protection and configuration. need configuration to scale.

Loa Anderson: Need to look at RMR and see if we can use it, or determine if we
can’t. Need autoconfiguration.

Lou Berger: In general we try not to have two solutions for the same problem,
so I’m just trying to follow that standard practice. If there’s an existing
solution we should use it.

Jeong-Dong Ryoo: Regarding autoconfiguration the example is done by any
multicast protocol. Bridge node to each leaf is aware of subscriber, that is
done by any multicast configuration protocol. Then maybe that once subscriber
is attached, then DetNet can get a signal to enable

Liang Geng: Value of draft is how to incorporate service layer in DetNet.

Lou Berger: We look forward to your update, and its relation to RMR. We're out
of time, if there are more comments on earlier topics please bring them to the
list.

> Adjourn         16:53