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

From: Jouni Korhonen <[email-masked]>
Date: Wed, 1 Feb 2017 18:02:52 -0800

Present: Jouni, Loa, Norm, Balazs, Janos, Tal and David.

See the attached slideset that was used as the basis during the call.
The MPLS-based PWE encaps has matured, except for: 1) fine grained CoS (i.e., 802.1 has discussed finer granularity of CoS basically to a flow level. The flow identification mechanism in .1CB, .1Qci et al allows this), and 2) PW CW SN width. We have discussed using 28 bits but that might cause issues when interworking with systems that only understand 16 bits (HSR and PRP as an examples). 
The CoS part and whether TC bits are copied between layers is still to be discussed further.
IP PSN seems OK. The questions on the slides were discussed:
- PW labels are still good to have. It makes the stack/implementation more streamlined between MPLS and IP PSNs. Also PW labels make PW switching way easier e.g., in a case of replication/elimination.
- In a case of IP PSN each PW will have their own “tunnel” between T-/S-PEs. That means e.g., a PW between A and B will have different src/dst addresses than a PW between B and D. This makes pinned down paths easier to realize using IP PSN.

Norm asks for the cases where DetNet interworks with e.g. 802.1TSN. Would there be a way to regenerate MAC addresses if those are not transported over DetNet (this is for the case where the L2 is just so bug that interconnect does not make sense). Discussion.. Jouni commented that it is not in current document’s scope. Could be worked in parallel once the encaps for DetNet DP mature a bit.

Loa comments that EXP bits in an MPLS labels should use TC instead (Traffic Class), see RFC5462.

Jouni commented that we now start to have enough material to produce a draft of a draft. Expect the first version next week.

Quick discussion on 1588 PTP in DetNet. 1588 packets should not be replicated. Actually using DetNet encapsulation for them is not really a good idea. Tal will educate us more on that next time.

Action points:
Tal will produce a slideset regarding his thoughts/concerns on 1588 transport in DetNet.

Next call: 2/7/17 10PM PDT

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

---

From: Lou Berger <[email-masked]>
Date: Thu, 02 Feb 2017 07:43:09 -0500

Jouni/DT

Sounds like good progress - I have some questions /comments:

1 mpls labels - svc vs transport vs hop-by-hop

I see that the mpls label is identified as a transport label that changes 
hop by hop.  While this is certainly a likely and perhaps initial use case, 
I think there are others that should be allowed for in the DetNet dp 
definition.  Perhaps just show it as a mpls label stack at the high level 
(this is what we ended up doing in the TP doc)?

I think other likely scenarios include 0|1 mpls domain service label 
followed by n (>1) domain transport labels. Where the n covers (or allows 
for) the hop by hop case, protection cases and even SR/spring label stacks.

Does this make any sense?

2 qos

Documenting the progress on cos is certainly critical - and I don't want to 
detract from that. That said:

Was there any discussion on per DetNet flow resource management /  
allocation, i.e. qos?  What's your plane here?

I suspect all already know my opinion, i.e., that the WG needs to cover 
both cases equally and in the same detnet data plane definition - At least 
from the DT perspective.

Thanks,
Lou

On 2/1/2017 9:02 PM, Jouni Korhonen wrote:

See the attached slideset that was used as the basis during the call.
The MPLS-based PWE encaps has matured, except for: 1) fine grained CoS 
(i.e., 802.1 has discussed finer granularity of CoS basically to a flow 
level. The flow identification mechanism in .1CB, .1Qci et al allows this), 
and 2) PW CW SN width. We have discussed using 28 bits but that might cause 
issues when interworking with systems that only understand 16 bits (HSR and 
PRP as an examples).
The CoS part and whether TC bits are copied between layers is still to be 
discussed further.
IP PSN seems OK. The questions on the slides were discussed:
- PW labels are still good to have. It makes the stack/implementation more 
streamlined between MPLS and IP PSNs. Also PW labels make PW switching way 
easier e.g., in a case of replication/elimination.
- In a case of IP PSN each PW will have their own “tunnel” between 
T-/S-PEs. That means e.g., a PW between A and B will have different src/dst 
addresses than a PW between B and D. This makes pinned down paths easier to 
realize using IP PSN.

Norm asks for the cases where DetNet interworks with e.g. 802.1TSN. Would 
there be a way to regenerate MAC addresses if those are not transported 
over DetNet (this is for the case where the L2 is just so bug that 
interconnect does not make sense). Discussion.. Jouni commented that it is 
not in current document’s scope. Could be worked in parallel once the 
encaps for DetNet DP mature a bit.

Loa comments that EXP bits in an MPLS labels should use TC instead (Traffic 
Class), see RFC5462.

Jouni commented that we now start to have enough material to produce a 
draft of a draft. Expect the first version next week.

Quick discussion on 1588 PTP in DetNet. 1588 packets should not be 
replicated. Actually using DetNet encapsulation for them is not really a 
good idea. Tal will educate us more on that next time.

Action points:
Tal will produce a slideset regarding his thoughts/concerns on 1588 
transport in DetNet.

_______________________________________________
Detnet-dp-dt mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet-dp-dt

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 2 Feb 2017 12:18:00 -0800

Lou,

> On Feb 2, 2017, at 4:43 AM, Lou Berger <[email-masked]> wrote:
> 
> Jouni/DT
> 
> I see that the mpls label is identified as a transport label that changes hop by hop.  While this is certainly a likely and perhaps initial use case, I think there are others that should be allowed for in the DetNet dp definition.  Perhaps just show it as a mpls label stack at the high level (this is what we ended up doing in the TP doc)?

I think we are in sync here. The current layout is an example with the most simplest label stack. I would not be surprised there are multiple labels below the PW label, not just one. Notation of n*4 or similar (LSE) for the lowest label would probably be better?

> I think other likely scenarios include 0|1 mpls domain service label followed by n (>1) domain transport labels. Where the n covers (or allows for) the hop by hop case, protection cases and even SR/spring label stacks.
> 
> Documenting the progress on cos is certainly critical - and I don't want to detract from that. That said:
> 
> Was there any discussion on per DetNet flow resource management /  allocation, i.e. qos?  What’s your plane here?

Discussion yes, decisions no. Plan is rather vague atm. The resource management/allocation needs more input (I welcome it from anyone participating who has a good vision of it). One thing came regarding per detnet flow treatment. If we need to identify and treat every detnet flow individually at the transport level, we soon run out of identifier space without looking higher in the label stack.

> I suspect all already know my opinion, i.e., that the WG needs to cover both cases equally and in the same detnet data plane definition - At least from the DT perspective.

Understood.

- Jouni

---

From: Lou Berger <[email-masked]>
Date: Fri, 03 Feb 2017 12:59:56 -0500

Jouni,

On February 2, 2017 3:18:30 PM Jouni Korhonen <[email-masked]> 
wrote:

> I think we are in sync here. The current layout is an example with the most 
> simplest label stack. I would not be surprised there are multiple labels 
> below the PW label, not just one.

Great.  This wasn't clear from the slide.

> Notation of n*4 or similar (LSE) for the lowest label would probably be better?
>

How about just using/allowing for a standard LS?

>> allocation, i.e. qos?  What’s your plane here?
>
> Discussion yes, decisions no. Plan is rather vague atm. The resource 
> management/allocation needs more input (I welcome it from anyone 
> participating who has a good vision of it).

Well the DP dt doesn't need to solve all of detnet:-) just state your 
assumptions that there will be "some" mechanism (control plane management 
plane or otherwise) that will provide any data path setup/allocation 
needed.  It of course would be helpful to identify what dp related 
parameters are supported/required/assumed.

> One thing came regarding per detnet flow treatment. If we need to identify 
> and treat every detnet flow individually at the transport level, we soon 
> run out of identifier space without looking higher in the label stack.
>

Or lower.  Layered qos is a fairly familiar concept in te/transport nets.

-- scaling qos is always interesting.

>> both cases equally and in the same detnet data plane definition - At least 

Thank you!

Lou

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sun, 05 Feb 2017 12:56:04 +0100

Hi Jouni, all,

Thanks for the minutes and apologies for not joining this time.

I have a couple of questions:

1. For the transport, we have so far assumed MPLS and IP PSNs (focusing
the discussion mainly on MPLS until this week). Are we restricted to
only these two? I think in some use cases other transports such as
MPLS-TP can be relevant as well. Will we explore this too/make the
solution open enough to support other transports?

2. How are organizing to work on the first draft text? I'm available to
contribute text.

Thanks!

Carlos

On Wed, 2017-02-01 at 18:02 -0800, Jouni Korhonen wrote:
> The MPLS-based PWE encaps has matured, except for: 1) fine grained
> CoS (i.e., 802.1 has discussed finer granularity of CoS basically to
> a flow level. The flow identification mechanism in .1CB, .1Qci et al
> allows this), and 2) PW CW SN width. We have discussed using 28 bits
> but that might cause issues when interworking with systems that only
> understand 16 bits (HSR and PRP as an examples). 
> - PW labels are still good to have. It makes the stack/implementation
> more streamlined between MPLS and IP PSNs. Also PW labels make PW
> switching way easier e.g., in a case of replication/elimination.
> - In a case of IP PSN each PW will have their own “tunnel” between T-
> /S-PEs. That means e.g., a PW between A and B will have different
> src/dst addresses than a PW between B and D. This makes pinned down
> paths easier to realize using IP PSN.
> 
> Norm asks for the cases where DetNet interworks with e.g. 802.1TSN.
> Would there be a way to regenerate MAC addresses if those are not
> transported over DetNet (this is for the case where the L2 is just so
> bug that interconnect does not make sense). Discussion.. Jouni
> commented that it is not in current document’s scope. Could be worked
> in parallel once the encaps for DetNet DP mature a bit.
> 
> Jouni commented that we now start to have enough material to produce
> a draft of a draft. Expect the first version next week.
> 
> replicated. Actually using DetNet encapsulation for them is not
> really a good idea. Tal will educate us more on that next time.
> 
> Action points:

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 5 Feb 2017 19:29:40 -0800

Carlos,

> On 05 Feb 2017, at 03:56, Carlos Jesús Bernardos Cano <[email-masked]> wrote:
> 
> Hi Jouni, all,
> 

Most of the DetNet DP “sauce” is on the PW layer. We already assured that the PSN can be either a LSP or IP. Since MPLS-TP includes PWE is see no reason why “MPLS-based” PSN could not also be implemented using MPLS-TP.

> 2. How are organizing to work on the first draft text? I'm available to

I’ll get the first round up soon. Then we can divide the job into sections that everybody (volunteering) is responsible for.

- Jouni

---

From: Loa Andersson <[email-masked]>
Date: Mon, 6 Feb 2017 12:13:01 +0800

Jouni and Carlos,

Please see inline

>> solution open enough to support other transports?

The relationship between the MPLS transport profile and MPLS is that 
MPLS-TP is a true subset of MPLS, i.e. anything new that was defined for
MPLS-TP is also applicable for MPLS. On the other hand MPLS-TP 
explicitly excluded a couple of things that is part of MPLS. The two
most important things that were excluded was that
(1) you can not assume the presence of IP or IP routing in MPLS-TP
(2) PHP is always disabled

The DetNet charter says:

The Deterministic Networking (DetNet) Working Group focuses on
deterministic data paths that operate over Layer 2 bridged and Layer 3
routed segments, ...

Since MPLS-TP is neither "Layer 2 bridged" or "Layer 3 routed". to me
it looks like MPLS-TP is excluded.

/Loa

-- 

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

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 5 Feb 2017 21:12:42 -0800

Loa,

> On 05 Feb 2017, at 20:13, Loa Andersson <[email-masked]> wrote:
> 
> Jouni and Carlos,
> 
> Please see inline
> 
> The relationship between the MPLS transport profile and MPLS is that MPLS-TP is a true subset of MPLS, i.e. anything new that was defined for
> MPLS-TP is also applicable for MPLS. On the other hand MPLS-TP explicitly excluded a couple of things that is part of MPLS. The two

Yes... and? I think you cannot assume the presence of IP in a case detnet either, and PHP can always be turned off my configuration.

> it looks like MPLS-TP is excluded.

I don’t quite get the conclusion here. Maybe I am thinking too simple but for me MPLS-TP in DetNet DP case is just labels.

- Jouni

---

From: Loa Andersson <[email-masked]>
Date: Mon, 6 Feb 2017 13:45:25 +0800

Jouni,

On 2017-02-06 13:12, Jouni Korhonen wrote:
> Yes... and? I think you cannot assume the presence of IP in a case detnet either,

fine, but it only works one way (all ravens are black, but not all black
birds are are ravens). So DetNet is L2 bridged or L3 routed, no
alternatives, right?

  and PHP can always be turned off my configuration.

not in MPLS-TP, there it can only be disabled, not enabled if you need
it (read depth of label stack).

> I don’t quite get the conclusion here. Maybe I am thinking too simple but for me MPLS-TP in DetNet DP case is just labels.

just labels, does not make it MPLS-TP, it makes it mpls, which I take to 
mean that you can use an MPLS-TP tunnel (by making i show up in the
routing as a adjacency, but since you can't enable PHP it is at best
risky to have an MPLS-TP tunnel terminating on the same node as the
ms-pw label

So my conclusion is that we can use TP for transport, as long as there
are no impact on the DetNet encapsulation.

Makes sense?

/Loa

--

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 5 Feb 2017 22:30:54 -0800

> it (read depth of label stack).

I was referring to MPLS and its use of PHP, where it can be turned off by configuration. MPLS-TE has it always off as you originally pointed out.

> just labels, does not make it MPLS-TP, it makes it mpls, which I take to mean that you can use an MPLS-TP tunnel (by making i show up 

Exactly. And this should be just fine for the DP. 

> in the

That is a downside that I think we acknowledged earlier, and we need to make sure the document also mentions it. For some hardware lack of PHP is not that much of an issue as long as the label stack depth is reasonable. 

We wouldn’t have LSP merge and ECMP with MPLS-TP either.. On the other hand I find bi-directional LSPs and not losing the origin/source information usable. Also the bias towards manually set up LSPs fits to some centrally controlled use cases nicely.

> are no impact on the DetNet encapsulation.

Yes.

- Jouni

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 6 Feb 2017 12:58:26 +0000

Many thanks for the discussion. I agree with you that MPLS-TP can work just fine as one of the DetNet transport layers.
The php behavior is not critical for DetNet, moreover, bi-directional LSP is also attractive for some use cases of DetNet.

One interesting thing is, MPLS-TP can support 1+1 protection by using a single layer of MPLS label (though this label may be in the LSP or PW layer).
Thus, I wonder whether we can use a single PW layer in the data plane of DetNet. IMHO, multiple layers of PW is a break from the PWE3 architecture, and all DP/CP/MP things will become more complicated.

Cheers,
Yuanlong

> -----Original Message-----
> From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of
> Jouni Korhonen
> Sent: Monday, February 06, 2017 2:31 PM
> To: Loa Andersson
> Cc: CARLOS JESUS BERNARDOS CANO; [email-masked]
> Subject: Re: [Detnet-dp-dt] quick notes from 1/31/17 call
> 
> >>>
> >>> MPLS-TP is a true subset of MPLS, i.e. anything new that was defined
> >>> for MPLS-TP is also applicable for MPLS. On the other hand MPLS-TP
> > fine, but it only works one way (all ravens are black, but not all
> > black birds are are ravens). So DetNet is L2 bridged or L3 routed, no
> > alternatives, right?
> >
> I was referring to MPLS and its use of PHP, where it can be turned off by
> configuration. MPLS-TE has it always off as you originally pointed out.
> 
> >>> The DetNet charter says:
> >>>
> >>> deterministic data paths that operate over Layer 2 bridged and Layer
> >>> 3 routed segments, ...
> >>>
> >>> Since MPLS-TP is neither "Layer 2 bridged" or "Layer 3 routed". to
> >>> me it looks like MPLS-TP is excluded.
> >>
> >> I don’t quite get the conclusion here. Maybe I am thinking too simple but
> for me MPLS-TP in DetNet DP case is just labels.
> >
> > just labels, does not make it MPLS-TP, it makes it mpls, which I take
> > to mean that you can use an MPLS-TP tunnel (by making i show up
> 
> That is a downside that I think we acknowledged earlier, and we need to
> make sure the document also mentions it. For some hardware lack of PHP is
> not that much of an issue as long as the label stack depth is reasonable.
> 
> We wouldn’t have LSP merge and ECMP with MPLS-TP either.. On the other
> hand I find bi-directional LSPs and not losing the origin/source information
> usable. Also the bias towards manually set up LSPs fits to some centrally
> controlled use cases nicely.
> 
> >>>> Most of the DetNet DP “sauce” is on the PW layer. We already assured
> that the PSN can be either a LSP or IP. Since MPLS-TP includes PWE is see no
> reason why “MPLS-based” PSN could not also be implemented using
> MPLS-TP.
> >>>>
> >>>>> 2. How are organizing to work on the first draft text? I'm
> >>>>> available to contribute text.
> >>>>
> >>>> I’ll get the first round up soon. Then we can divide the job into
> sections that everybody (volunteering) is responsible for.
> >>>>
> >>>> - Jouni
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> Carlos
> >>>>>
> >>>>>> The MPLS-based PWE encaps has matured, except for: 1) fine
> >>>>>> grained CoS (i.e., 802.1 has discussed finer granularity of CoS
> >>>>>> basically to a flow level. The flow identification mechanism in
> >>>>>> .1CB, .1Qci et al allows this), and 2) PW CW SN width. We have
> >>>>>> discussed using 28 bits but that might cause issues when
> >>>>>> interworking with systems that only understand 16 bits (HSR and
> PRP as an examples).
> >>>>>> - PW labels are still good to have. It makes the
> >>>>>> stack/implementation more streamlined between MPLS and IP PSNs.
> >>>>>> Also PW labels make PW switching way easier e.g., in a case of
> replication/elimination.
> >>>>>> - In a case of IP PSN each PW will have their own “tunnel”
> >>>>>> between T- /S-PEs. That means e.g., a PW between A and B will
> >>>>>> have different src/dst addresses than a PW between B and D. This
> >>>>>> makes pinned down paths easier to realize using IP PSN.
> >>>>>>
> >>>>>> transported over DetNet (this is for the case where the L2 is
> >>>>>> just so bug that interconnect does not make sense). Discussion..
> >>>>>> Jouni commented that it is not in current document’s scope. Could
> >>>>>> be worked in parallel once the encaps for DetNet DP mature a bit.
> >>>>>>
> >>>>>> Jouni commented that we now start to have enough material to
> >>>>>> produce a draft of a draft. Expect the first version next week.
> >>>>>>
> >>>>>> Quick discussion on 1588 PTP in DetNet. 1588 packets should not
> >>>>>> be replicated. Actually using DetNet encapsulation for them is
> >>>>>> not really a good idea. Tal will educate us more on that next time.
> >>>>>>
> >>>>>> Action points:

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 07 Feb 2017 09:27:45 +0100

Hi Jouni, Loa,

Thanks for the discussion and clarification! I think we are in sync
here.

Carlos

On Sun, 2017-02-05 at 22:30 -0800, Jouni Korhonen wrote:
> > > > 
> > > > The relationship between the MPLS transport profile and MPLS is
> > > > that MPLS-TP is a true subset of MPLS, i.e. anything new that
> > > > was defined for
> > black
> I was referring to MPLS and its use of PHP, where it can be turned
> off by configuration. MPLS-TE has it always off as you originally
> pointed out.
> 
> > > > The DetNet charter says:
> > > > 
> > > I don’t quite get the conclusion here. Maybe I am thinking too
> > > simple but for me MPLS-TP in DetNet DP case is just labels.
> > 
> > just labels, does not make it MPLS-TP, it makes it mpls, which I
> > take to mean that you can use an MPLS-TP tunnel (by making i show
> > up 
> 
> That is a downside that I think we acknowledged earlier, and we need
> to make sure the document also mentions it. For some hardware lack of
> PHP is not that much of an issue as long as the label stack depth is
> reasonable. 
> 
> We wouldn’t have LSP merge and ECMP with MPLS-TP either.. On the
> other hand I find bi-directional LSPs and not losing the
> origin/source information usable. Also the bias towards manually set
> up LSPs fits to some centrally controlled use cases nicely.
> 
> > > > > Most of the DetNet DP “sauce” is on the PW layer. We already
> > > > > assured that the PSN can be either a LSP or IP. Since MPLS-TP 
> > > > > includes PWE is see no reason why “MPLS-based” PSN could not
> > > > > also be implemented using MPLS-TP.
> > > > > 
> > > > > I’ll get the first round up soon. Then we can divide the job
> > > > > into sections that everybody (volunteering) is responsible
> > > > > for.
> > > > > 
> > > > > - Jouni
> > > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > Thanks!
> > > > > > 
> > > > > > Carlos
> > > > > > 
> > > > > > > The CoS part and whether TC bits are copied between
> > > > > > > layers is still
> > > > > > > to be discussed further.
> > > > > > > stack/implementation
> > > > > > > Loa comments that EXP bits in an MPLS labels should use
> > > > > > > TC instead
> > > > > > > (Traffic Class), see RFC5462.
> > > > > > >