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

[Jiangyuanlong <[e-mail]>]

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:[e-mail]] On Behalf Of
> Jouni Korhonen
> Sent: Monday, February 06, 2017 2:31 PM
> To: Loa Andersson
> Cc: CARLOS JESUS BERNARDOS CANO; [e-mail]
> Subject: Re: [Detnet-dp-dt] quick notes from 1/31/17 call
> 
> >>>
> >>> 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
> >>
> >> 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 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:
> >>>
> >>> 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.
> >>
> >> 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
> 
> Exactly. And this should be just fine for the DP.
> 
> > 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
> 
> 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.
> 
> > So my conclusion is that we can use TP for transport, as long as there
> > are no impact on the DetNet encapsulation.
> >
> > Makes sense?
> 
> Yes.
> 
> - Jouni
> 
> >
> > /Loa
> >
> >>
> >> - Jouni
> >>
> >>
> >>>
> >>> /Loa
> >>>
> >>>
> >>>>
> >>>> 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
> >>>>>
> >>>>> On Wed, 2017-02-01 at 18:02 -0800, Jouni Korhonen wrote:
> >>>>>> 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: [phone]
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Detnet-dp-dt mailing list
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
> >>>>
> >>>> _______________________________________________
> >>>> Detnet-dp-dt mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
> >>>>
> >>>
> >>> --
> >>>
> >>>
> >>> Loa Andersson                        email:
> [e-mail]
> >>> Senior MPLS Expert                          [e-mail]
> >>> Huawei Technologies (consultant)     phone: [phone]
> >>
> >> _______________________________________________
> >> Detnet-dp-dt mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
> >>
> >
> > --
> >
> >
> > Loa Andersson                        email: [e-mail]
> > Senior MPLS Expert                          [e-mail]
> > Huawei Technologies (consultant)     phone: [phone]
> 
> _______________________________________________
> Detnet-dp-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt