Subject: [Detnet-dp-dt] quick notes from 1/24/17 call

From: Jouni Korhonen <[email-masked]>
Date: Wed, 25 Jan 2017 08:44:30 -0800

Folks,

We had a +1h call last night. Participants: Jouni, Carlos, Loa, Norm, Yuanlong, Janos and Tal.

For the discussion refer to Loa’s slides sent to the DT list on 1/13/17.

We seemed to have reached consensus on PWs and three label approach i.e., transport label + PW label + “detnet PW” label (d-pw in slides and this one is associated with the seqnum). The “detnet PW” label is end to end between detnet flow end points and unique within the detnet domain. This arrangement will cause 16 octet overhead (3x label + cw):

+-----------------+
| Transport Label | --> per each LSR; top of stack
+-----------------+
| PW Label        | --> per each PW (between T-PEs and/or S-PEs)
+-----------------+
| Detnet PW Label | --> between DetNet end points
+-----------------+
| CW - 28 bit sn  | --> associated with DetNet PW label 
+-----------------+
| Payload         | --> whatever we transport
+-----------------+

Multiplexing: one transport label may transport PW labels, and one PW label may transport multiple “detnet PW” labels.

The (virtual) network topology (LSP paths) can be programmed at the PW level. This means any detnet flow can use those without having to setup path individually for each “detnet PW”. As a consequence adding new detnet flows to system is enable i.e., when the duplicate detection and elimination function sees a new “detnet PW” label, it can instantiate new function to deal with duplicate detection and elimination - dynamically. 

We started the discussion on class of service and how that could be arranged in a label stack. The CoS could use the EXP bits on the transport label. However, it needs to be checked whether/how different CoS could be “propagated” through the label stack e.g., in a case where “detnet PW” labels/flows have different CoS needs. Need to check whether this is sufficient as a way forward.

Need some more thinking:
 * CoS (see above)
 * Any need for timestamps (we did not discuss this, but see IETF97 presentation about RTP headers)?

Next call:
 Tue 1/31/2017 the usual time.

--
Jouni Korhonen, Broadcom Ltd.
M: +1-408-391-7160

---

From: Lou Berger <[email-masked]>
Date: Wed, 25 Jan 2017 15:44:07 -0500

Jouni/Team,

    Sounds like good progress. A couple of questions:

- I see you thinking about CoS,  That's good.  Have you thought about
how QoS (flow specific resource allocation) is tagged/managed?

- Have you had any discussions yet about DetNet without MPLS, i.e.,
DetNet flows over IP? If so, what are you thinking?

Thanks,

Lou

PS I will make it to one of these calls at some point...

On 1/25/2017 11:44 AM, Jouni Korhonen wrote:
> _______________________________________________
> Detnet-dp-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 25 Jan 2017 12:47:07 -0800

> On Jan 25, 2017, at 12:44 PM, Lou Berger <[email-masked]> wrote:
> 
> Jouni/Team,
> 

Not yet. One possibility would be associating this to the “detnet PW” label, but haven’t really looked into that yet.

> DetNet flows over IP? If so, what are you thinking?

Nothing yet. We have been very MPLS biased.

- JOuni

---

From: Lou Berger <[email-masked]>
Date: Wed, 25 Jan 2017 16:48:21 -0500

Mapping a PW down to an mpls service label (before the transport label)
would fit with existing architecture, and I bet hardware.  You could
even use SR underneath. 

> Nothing yet. We have been very MPLS biased.

That's fine.  One concern I have is if detnet specific functions rely on
a CW or detnet label, that it can't be made to work with IP while the
converse wouldn't be true.  Of course there's the alternative that IP
hosts would implement basically PW transport  over IP. 

The real point here is a gentle reminder that DetNet service over IP is
in scope for the DT...

Thanks for the quick reply!

Lou

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 25 Jan 2017 13:56:27 -0800

Folks,

Regarding the CoS point below. We should look at and follow what RFC3270 defines. I recon pipe and uniform models combined with both E-LSPs and L-LSPs is already out there and probably is enough for CoS purposes.

- Jouni

> On Jan 25, 2017, at 8:44 AM, Jouni Korhonen <[email-masked]> wrote:
> 
> Folks,
>

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 25 Jan 2017 14:01:18 -0800

Lou,

> On Jan 25, 2017, at 1:48 PM, Lou Berger <[email-masked]> wrote:
> 
> 
> 

That’s what I have had in mind i.e., DetNet over IP is actually just a PW with IP PSN. I cannot speak for others, though.

> The real point here is a gentle reminder that DetNet service over IP is

Sure. We’ll keep this also in pipe.

- Jouni

---

From: Lou Berger <[email-masked]>
Date: Wed, 25 Jan 2017 17:12:01 -0500

Thank Jouni!

---

From: Loa Andersson <[email-masked]>
Date: Thu, 26 Jan 2017 11:53:26 +0800

Jouni,

> Regarding the CoS point below. We should look at and follow what RFC3270 defines. I recon pipe and uniform models combined with both E-LSPs and L-LSPs is already out there and probably is enough fo…

For QoS this is probably right.

I'm a bit concerned on how we do bandwidth management.

It looks like building the LSP virtual network, with assigned bw. Then 
we fill the LSPs with pw's/d-pw's that has a certain be (lesser than
the transport LSP). When the transport LSP is fully booked, we can
either increase the bandwidth of the transport LSP or add a new fresh
LSP.

Maybe we just should point out the possibilities and leave the rest to
the operators?

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Lou Berger <[email-masked]>
Date: Tue, 31 Jan 2017 17:00:31 -0500

Hi Loa,

    I'm not sure if this came on the call or not. 

> For QoS this is probably right.
Note Jouni said CoS -- and I agree the statement if that's what you meant.

> either increase the bandwidth of the transport LSP or add a new fresh

This is certainly a possibility as layering is always a good scaling
tool.  Another option for a PW to be mapped to single LSP with bandwidth
allocation - for fine grained QoS control.

> Maybe we just should point out the possibilities and leave the rest to

I think it's fine for this DT to layout the dataplane (i.e., hardware)
options and identify what needs to be addressed by the
control/management/provisioning planes.  Doing less means we aren't
fulfilling our WG charter...

Thanks,
Lou