Re: [Detnet-dp-dt] high level questions on detnet dataplane

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

Hi Jouni,

On Wed, 2017-02-22 at 07:26 -0800, jouni.nospam wrote:
> Hi,
> 
> > On Feb 22, 2017, at 3:17 AM, Carlos Jesús Bernardos Cano <cjbc@it.u
> > c3m.es> wrote:
> > 
> > Hi Loa,
> > 
> > On Wed, 2017-02-22 at 18:32 +0800, Loa Andersson wrote:
> > > Folks,
> > > 
> > > two questions, the first because I've be taling it for granted,
> > > the 
> > > second brought up bu two indenpendent people I talked about
> > > DetNet
> > > with.
> > > 
> > > - is a design criteria that the existing MPLS control plane
> > > protocols
> > >    shall be able to use with the DetNet dataplane?
> > > 
> > > - I've heard the opinion (from two different directions) that
> > > doing
> > >    replication/elimination other than at the egress/ingress will
> > > make
> > > the
> > >    solution to complicated. Do we have a good motiation why we
> > > need
> > > it?
> > 
> > I also have this question in mind. I've checked draft-ietf-detnet-
> > dp-
> > alt-00 and found this:
> > 
> > "
> > 4.5.  #5 Flow duplication and merging
> > 
> > [...]
> > 
> >    The solution alternative has to provide means for end systems,
> > relay
> >    and edge nodes to be able to duplicate packets into duplicate
> > flows,
> >    and later merge the flows into one for duplicate
> > elimination.  The
> >    duplication and merging may take place at multiple points in the
> >    network in order to ensure that one (or more) equipment failure
> >    event(s) still leave at least one path intact for a
> > deterministic
> >    networking flow.  The goal is again to enable hitless 1+1
> > protection
> >    in a way that no packet gets lost or there is no ramp up time
> > when
> >    either one of the paths fails for one reason or another.
> > "
> > 
> > Not completely clear to me why we need to allow duplication and
> > merging
> > at multiple points. 
> 
> One reason is to be equally good as the IEEE 802.1 counter part.
> 
> > I have also another question: are we considering somehow the
> > requirements that some detnet applications (e.g., crosshauling)
> > might
> > require bidirectional flows to be symmetric?
> 
> There are already mechanisms that you can use to create bidirectional
> tunnels at the transport network level. How the control plane comes 

OK. So, I guess we should document in the draft for example
considerations when using MPLS to keep in mind to ensure that paths are
symmetrical (if the detnet app needs that), right?

Thanks,

Carlos

> up with a DetNet flow pinning in a way that it only has bidirectional
> flows has not been worked on yet - it is a separate work.  The data
> plane will/must allow that, though.

> 
> - JOuni
> 
> 
> > 
> > Thanks,
> > 
> > Carlos
> > 
> > > 
> > > /Loa
> 
>