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

[Carlos Jesús Bernardos Cano <[e-mail]>]

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
> > > > 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].c
> > > > om
> > > > 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]
> 
>