Subject: [Detnet] L2 vs L3 ...

From: Robert Raszuk <[email-masked]>
Date: Mon, 20 Jul 2015 14:53:22 +0200

Hi,

So listening to today's BOF I have one unclarity between L2 vs L3 debate
here ..

If I am switching based on MPLS label being programmed by controller or
being installed by distributed mpls-tp L3 control plane is my network
element L2 or L3 ?

Yes I know it is L2.5 :) but none of the slides neither charter pointers
mentioned that layer augmentation today.

And frankly at least to me the presented problem space could quite well fit
to mpls based forwarding with good L3 control planes steering it properly.

I support forming a WG for it.

Best,
R.

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Tue, 21 Jul 2015 17:37:56 +0000

Thanks for your support!

What’s required at whatever level the packets operate is that it be easy to distinguish one stream from another, so that streams can get special QoS handling.  (There are both per-stream and per-class methods for achieving zero congestion loss.)  MPLS seems a good candidate for this job, but we’re very open to other suggestions.

— Norm

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 20, 2015 at 14:53 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Detnet] L2 vs L3 ...

Hi,

So listening to today's BOF I have one unclarity between L2 vs L3 debate here ..

If I am switching based on MPLS label being programmed by controller or being installed by distributed mpls-tp L3 control plane is my network element L2 or L3 ?

Yes I know it is L2.5 :) but none of the slides neither charter pointers mentioned that layer augmentation today.

And frankly at least to me the presented problem space could quite well fit to mpls based forwarding with good L3 control planes steering it properly.

Best,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 21 Jul 2015 22:01:53 +0200

Hi Norman,

Ok many thx for your reply.

As you very well know per flow bw reservations has been tried in the past
with vanilla RSVP and turned out to have a bit of scalability issues.

How about a vast different approach - strict admission control ?

Note that we are operating in controlled network hence it is quite feasible
to control what get's into the network from central controller POV. While I
am a distributed guy I must say that I am yet to see a distributed protocol
which will be able to accomplish bandwith guarantees.

In any case I think my question is answered :)

Best,
Robert.

On Tue, Jul 21, 2015 at 7:37 PM, Norman Finn (nfinn) <[email-masked]>
wrote:

>  Thanks for your support!
>
>  What’s required at whatever level the packets operate is that it be easy
> to distinguish one stream from another, so that streams can get special QoS
> handling.  (There are both per-stream and per-class methods for achieving
> zero congestion loss.)  MPLS seems a good candidate for this job, but we’re
> very open to other suggestions.
>
>  — Norm
>
>   From: Robert Raszuk <[email-masked]>
> To: "[email-masked]" <[email-masked]>
>  And frankly at least to me the presented problem space could quite well
> fit to mpls based forwarding with good L3 control planes steering it
> properly.
>

---

From: Lou Berger <[email-masked]>
Date: Wed, 22 Jul 2015 00:00:54 +0200

Hi Robert,
    Sorry for being a little slow to respond ;-)  You said:
>
> And frankly at least to me the presented problem space could quite
> well fit to mpls based forwarding with good L3 control planes steering
> it properly.
>
My response wording is a little different than norms, but I do not think
inconsistent with it:
This seems like a reasonable solution starting point and it certainly
was part of what was intended when these existing technologies were
mentioned during the BoF. That said,  it will be for the WG to decide on
the specific solution approach. 
 
> I support forming a WG for it.

Great, thanks for your endorsement!

Lou

On 7/21/2015 10:01 PM, Robert Raszuk wrote:
> As you very well know per flow bw reservations has been tried in the
> past with vanilla RSVP and turned out to have a bit of scalability
> issues. 
>
> Note that we are operating in controlled network hence it is quite
> feasible to control what get's into the network from central
> controller POV. While I am a distributed guy I must say that I am yet
> to see a distributed protocol which will be able to accomplish
> bandwith guarantees. 
>
> On Tue, Jul 21, 2015 at 7:37 PM, Norman Finn (nfinn) <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Thanks for your support!
>
>     What’s required at whatever level the packets operate is that it
>     be easy to distinguish one stream from another, so that streams
>     can get special QoS handling.  (There are both per-stream and
>     per-class methods for achieving zero congestion loss.)  MPLS seems
>     a good candidate for this job, but we’re very open to other
>     suggestions.
>
>     — Norm
>
>     From: Robert Raszuk <[email-masked] <mailto:[email-masked]>>
>     To: "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>         If I am switching based on MPLS label being programmed by
>         controller or being installed by distributed mpls-tp L3
>         control plane is my network element L2 or L3 ? 
>
>         Yes I know it is L2.5 :) but none of the slides neither
>         charter pointers mentioned that layer augmentation today.
>
>         And frankly at least to me the presented problem space could
>         quite well fit to mpls based forwarding with good L3 control
>         planes steering it properly.
>
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

---

From: "Shitanshu Shah (svshah)" <[email-masked]>
Date: Wed, 22 Jul 2015 06:53:36 +0000

Well, RSVP or not, if source of the traffic can’t be trusted, some sort of enforcing mechanism is required to control what gets into the network.

Scalability is definitely an important aspect of consideration.. I am not necessarily suggesting RSVP protocol itself has scalability issues (well how it is leveraged in the solution/deployments can I think may have one).

Regardless RSVP or not scalability I am highlighting is - would data-plane require per flow classification based 5-tuple or with deep packet inspection? Would it mandate every packets, including “non-deterministic” class of traffic, on the wire subject to such classification?

This sort of issues are not new and has been explored and addressed. first few lines of abstract from RFC2475,

"

This document defines an architecture for implementing scalable
   service differentiation in the Internet.  This architecture achieves
   scalability by aggregating traffic classification state which is
   conveyed by means of IP-layer packet marking using the DS field
   [DSFIELD]

“

At that point of a time scalability might have been realized in the Internet. I wonder if such scalability now would be applicable to some of the use-cases described in the detnet session.

Nonetheless, enforcing control of what gets into the network can be done only at the first hop. Rest of the network can work with specific service on aggregation of such traffic?

Caveat though is that aggregation for such traffic is possible only if every deterministic flow, in a given deployed network, has exact same requirement of deterministic service. Why not though? Would a specific network serve two different types of deterministic applications that requires different determinism? And if it does than infact is it practically possible? I guess not.
I agree with you that such applications are operating in controlled network and thus value of aggregation is quite possible.

On a side note though to WG – requirements for detnet should also cover a point if a deterministic network would have mix of application traffic (weather from same type of application or different types of applications), requiring different determinism from the elements of the same network? I hope not :) point is important to highlight, or have it on a record, that may have influence on the solution outcome.

Regards,
Shitanshu

From: detnet <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 21, 2015 at 10:01 PM
To: "Norman Finn (nfinn)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Detnet] L2 vs L3 ...

Hi Norman,

As you very well know per flow bw reservations has been tried in the past with vanilla RSVP and turned out to have a bit of scalability issues.

Note that we are operating in controlled network hence it is quite feasible to control what get's into the network from central controller POV. While I am a distributed guy I must say that I am yet to see a distributed protocol which will be able to accomplish bandwith guarantees.

Best,
Robert.

On Tue, Jul 21, 2015 at 7:37 PM, Norman Finn (nfinn) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for your support!

— Norm

Hi,

Best,
R.

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Thu, 23 Jul 2015 08:01:09 +0000

Robert,

First, Lou’s answer is perfectly aligned with my opinion — MPLS is one candidate, but WG will decide.

People have tried lots of ways to avoid resource reservation.  Strict admission control at the edges, prioritization, and over provisioning is one main way things are done, today, for real-time applications.  The problem is that this works only for toy networks; the worst-cast collisions of streams somewhere in the middle of the network blow away any reasonable buffer space allocations at critical data rates that are much too low to be useful.  Furthermore, the point at which packet loss becomes unacceptable is very difficult to determine, and depends on the details of the critical flows.  The result is that the only way to be SURE that your application will work is to perform extensive testing.  This is how people are getting along, today, but it is THE major obstacle to shifting the applications to IP and Ethernet.  (Also, I prefer a centrally-controlled model, not a distributed one, for most applications.)

Yes, resource reservation is expensive, ESPECIALLY when it is applied to paths that automatically follow changes in the topology; the burst of control traffic required to re-establish reservations after a link-up or link-down event is particularly annoying.  (To me, it’s a non-starter, but others really are getting useful work from such systems.)  My very personal opinion is that there are two primary usage scenarios for DetNet, both of which avoid that issue:

  1. Networks that have very fast re-route without micro loops, such as rings, or some of the more advanced stuff done by IETF.  Reservations are made along both primary and alternate paths, so that a failed-over stream has a ready-made reservation waiting for it, and there is no additional reservation control traffic.  One must be careful not to oversubscribe, of course.

  2. Reservations made over pinned-down paths (that don’t automatically follow topology changes), with the reservation and the path created at the same time, to save control traffic.  Typically, one has more than one path active at the same time for the same flow (perhaps a multicast), serializes all packets, and discards duplicates at or near the destination(s).  Changes or repairs due to network changes are made by a central authority that can balance reduced reliability (running on one leg for a while) against control bandwidth, planned maintenance, policy, etc.

Of course, the possibilities for combinations, additions of other ideas, etc. are legion!!!  But those two poles, I think, offer a good place to start thinking about the issues.

— Norm

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 21, 2015 at 22:01 PM
To: Norman Finn <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Detnet] L2 vs L3 ...

Hi Norman,

Best,
Robert.

— Norm

Hi,

Best,
R.

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 23 Jul 2015 09:11:06 +0000

Hi Shitanshu,

From: detnet [mailto:[email-masked]] On Behalf Of Shitanshu Shah (svshah)
Sent: Tuesday, July 21, 2015 11:54 PM
To: Robert Raszuk; Norman Finn (nfinn)
Cc: [email-masked]
Subject: Re: [Detnet] L2 vs L3 ...

[JiK:] [snip]

On a side note though to WG - requirements for detnet should also cover a point if a deterministic network would have mix of application traffic (weather from same type of application or different types of applications), requiring different determinism from the elements of the same network? I hope not :) point is important to highlight, or have it on a record, that may have influence on the solution outcome.
[JiK:] Yes, this mixture of application traffic is in scope at least to a level that we have to acknowledge it. There are mechanisms coming from both IEEE802.3 & .1 that are helpful to realize mixing different types of traffic in the same network, basically one being deterministic express traffic and others being best effort pre-emptible traffic.

- Jouni

Regards,
Shitanshu

Hi Norman,

Best,
Robert.

What's required at whatever level the packets operate is that it be easy to distinguish one stream from another, so that streams can get special QoS handling.  (There are both per-stream and per-class methods for achieving zero congestion loss.)  MPLS seems a good candidate for this job, but we're very open to other suggestions.

- Norm

Hi,

Best,
R.

---

From: "Shitanshu Shah (svshah)" <[email-masked]>
Date: Thu, 23 Jul 2015 09:57:55 +0000

Jouni,

Did you mean to say “best effort pre-emptible traffic” as best effort traffic or class of traffic that does not require deterministic service from the network?

Just to clarify what the point below is about having multiple deterministic applications/flows in the same network with different deterministic parameters. For examples 1) do we expect, in the same network, one application/flow looking for worst case latency of 500 us and other looking for worst case latency of 300 us?, 2) do we expect, in the same network, one application/flow looking for determinism in terms of worst latency bound, while other looking for worst latency + strict jitter?
Did you mean this is a required use-case?

Type of co-existence of multiple deterministic service traffic in a network is different from a network having only one type of deterministic service + best-effort traffic.

Regards,
Shitanshu

From: Jouni Korhonen <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 23, 2015 at 11:11 AM
To: svshah <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>, "Norman Finn (nfinn)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Detnet] L2 vs L3 ...

Hi Shitanshu,

Cc: [email-masked]<mailto:[email-masked]>

[JiK:] [snip]

- Jouni

Regards,
Shitanshu

Hi Norman,

Best,
Robert.

— Norm

Hi,

Best,
R.

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Thu, 23 Jul 2015 13:00:14 +0000

Can’t speak for Jouni, but definitely, different DetNet streams will have different requirements.

— Norm

From: "Shitanshu Shah (svshah)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 23, 2015 at 11:57 AM
To: Jouni Korhonen <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>, Norman Finn <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Detnet] L2 vs L3 ...

Jouni,

Regards,
Shitanshu

Hi Shitanshu,

[JiK:] [snip]

- Jouni

Regards,
Shitanshu

Hi Norman,

Best,
Robert.

— Norm

Hi,

Best,
R.