Subject: [Detnet-dp-dt] Providing unique Flow-ID

From: Balázs Varga A <[email-masked]>
Date: Tue, 21 Feb 2017 17:05:42 +0000

Hi,

question to be answered:
- how to ensure that detnet flows can be unique recognized during transport?

Labels used by DetNet flows so far in our discussions:
- d-pw: DetNet flow specific
- l-label: FRER specific label to identify replica (member) flows
- t-label: transport label (FEC of T-PE or S-PE nodes)
Note: Text below assumes an l-label present, what may not be always the case.

Before discussing uniqueness/allocation/usage of these labels let's list the scenarios
requiring flow identification during transport. They can be separated in two groups:
1, DetNet function related scenarios:
- congestion protection: usage of allocated resources (queuing, policing, shaping).
- explicit routes: select/apply the flow specific path.
- service protection: recognize compound / member flows for replication an
elimination.

2, OAM function related scenarios:
- troubleshooting (e.g., identify misbehaving flows, etc.)
- recognize flow(s) for analytics (e.g, increase counters, etc.)
- correlate events with flows (e.g., volume above threshold, etc.)
- others ...

We can distinguish 3 node types:
- T-PE: d-pw starts/terminates here
- S-PE: place of detnet specific function (e.g., FRER)
- P: intermediate node (transport only functions)

T-PE and S-PE nodes are fully aware of both the DetNet service and transport layers.
In case of PHP, they receive only "d-pw + l-label", so the x-PE node should recognize
the DetNet flow based on these labels. DetNet specific functions are driven by the
"d-pw label" and "l-label" pair. The "d-pw"+"l-label" pairs have to be locally unique
on the x-PE.

The problematic points are the intermediate "P" nodes. Their detnet role is limited to
ensure congestion protection from the above listed DetNet functions. Additionally OAM
functions are also nice to have at each hop (as usual).

We have two options for P nodes:
- Option-A, P node can recognize only "t-label" and cannot consider the whole label
stack for flow recognition. This is the scenario, where we have pre-established
tunnels over the network, where the DetNet flows are mapped to appropriate tunnels to
be transported over the network. This can be treated as a form of aggregation as many
DetNet flows may use the same tunnel. Of course with this aggregation we lost per flow
identification, that is the price for scalability.
- Option-B, P-nodes can consider the whole label stack and they can identify each
individual flow. That represents additional requirement on P nodes, which may not be
acceptable in some network scenarios.

So, what labels should be unique and how should we allocate labels?
- d-pw: allocated by egress PE node. Label value is unique on that particular PE node.
Other PE nodes may allocate the same label value for a different detnet flow.
- l-label: allocated by the S-PE node. Label value is unique on that particular S-PE
node.
- t-label: allocated by P node. Refer to the tunnel endpoint node (FEC) and the
tunnel-ID. Value locally unique on the P node.

Such an allocation scheme ensure that all nodes in the network are able to identify
uniquely the DetNet flows (or aggregate flows) and support the above listed
functions:
- T-PE (egress): DetNet flow(s) identified based on the "d-pw" value.
- S-PE: DetNet flow(s) identified based on the "l-label" value
- P-node (option-A): aggregated DetNet flow(s) identified based on the "t-label"
- P-node (option-B): DetNet flow(s) identified based on the "l-label + t-label" (no
need to look for the "d-pw" label, unless "l-label" is not present)

Note, that as shown above globally unique "d-pw" labels are optional!

Good night and see You tomorrow early morning
Bala'zs

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 21 Feb 2017 13:34:17 -0800

Hi,

I have few comments inline.

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

> On Feb 21, 2017, at 9:05 AM, Balázs Varga A <[email-masked]> wrote:
> 
> Hi,
>  
> question to be answered:

To my understanding the l-labels “connect” x-PE nodes i.e. create the desired overlay topology over all LSRs/PEs. L-labels also identify which packets will receive FRER processing and which not i.e., whether a specific PW gets terminated in an x-PE or whether x-PE just acts as a transit.

> "d-pw label" and "l-label" pair. The "d-pw"+"l-label" pairs have to be locally unique

I have an issue what “pair” means here. L-labels should only have simple rules and actions like
pop, label swap, etc:

In the context of DetNet and L-labels, popping it would expose the d-pw label to the system, which would then do PW (+FRER) thing based on the top d-pw label. Label swap for L-label would allow making desired x-PW nodes to behave as transit nodes in the DetNet context.

Combining L-label into DetNet specific processing is IMHO a bad decision. Even if the hardware could be able to look up multiple labels in parallel, the next hop and action decisions would still be per label, not as a single result. Keeping this in mind, the system would also work as such when L-labels are not present i.e., the x-PE just receives a packet with d-pw label or T-label+d-pw label.. the assumption here is that the configuration at this point is such there is no ambiguity..

> - l-label: allocated by the S-PE node. Label value is unique on that particular S-PE

How would the L-label assignment work in our A,B,C,D x-PE example? B would do downstream assignment to A and upstream assignment to D?

> - S-PE: DetNet flow(s) identified based on the “l-label" value

How do you do the flow to seqnum pairing? It does not make sense to map multiple L-labels to a single seqnum counter & duplicate elimination function. A solution like this would need us to introduce kind of master and slave label relationships, or virtual labels that L-labels point at.

> need to look for the “d-pw" label, unless “l-label” is not present)
>  
> Note, that as shown above globally unique “d-pw" labels are optional!

I realize that detnet domain wide global d-pw labels are a pain in a neck. It would, for example, required each ingress T-detnet-PE to have their own d-pw label ranges they assign labels to detnet flows (assuming upstream label assignment). However, I still think global d-pw labels are cleaner from the forwarding point of view.

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

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 22 Feb 2017 03:28:13 +0100

Hi,

A couple of small comments/questions inline below.

On Tue, 2017-02-21 at 13:34 -0800, Jouni Korhonen wrote:
> To my understanding the l-labels “connect” x-PE nodes i.e. create the
> desired overlay topology over all LSRs/PEs. L-labels also identify
> which packets will receive FRER processing and which not i.e.,
> whether a specific PW gets terminated in an x-PE or whether x-PE just
> acts as a transit.
> 
> In the context of DetNet and L-labels, popping it would expose the d-
> pw label to the system, which would then do PW (+FRER) thing based on
> the top d-pw label. Label swap for L-label would allow making desired
> x-PW nodes to behave as transit nodes in the DetNet context.
> 
> Combining L-label into DetNet specific processing is IMHO a bad
> decision. Even if the hardware could be able to look up multiple
> labels in parallel, the next hop and action decisions would still be
> per label, not as a single result. Keeping this in mind, the system
> would also work as such when L-labels are not present i.e., the x-PE
> just receives a packet with d-pw label or T-label+d-pw label.. the
> assumption here is that the configuration at this point is such there
> is no ambiguity..

I share Jouni's view on this. One clarifying question (for Jouni): you
mean here the action decision would still be per __d-pw__ label, right?

> > acceptable in some network scenarios.

Wouldn't this (Option-B) make P nodes "DetNet service aware"?

> How would the L-label assignment work in our A,B,C,D x-PE example? B
> would do downstream assignment to A and upstream assignment to D?
> 
> How do you do the flow to seqnum pairing? It does not make sense to
> map multiple L-labels to a single seqnum counter & duplicate
> elimination function. A solution like this would need us to introduce
> kind of master and slave label relationships, or virtual labels that
> L-labels point at.
> 
> I realize that detnet domain wide global d-pw labels are a pain in a
> neck. It would, for example, required each ingress T-detnet-PE to
> have their own d-pw label ranges they assign labels to detnet flows
> (assuming upstream label assignment). However, I still think global
> d-pw labels are cleaner from the forwarding point of view.

I agree.

Carlos

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 21 Feb 2017 18:58:04 -0800

Carlos,

Many pops here..

> mean here the action decision would still be per __d-pw__ label, right?

Yes.. if I understood you question correctly.

- JOuni

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 22 Feb 2017 03:27:07 +0000

Hi,

What is I-label and what is L-label? Are they in the same label stack as the d-pw label? It will help us to be aligned to the same picture;)
In the past, we have PW label and LSP label (maybe multiple LSP labels in hierarchy) for a service. 

Thanks,
Yuanlong
-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Wednesday, February 22, 2017 5:34 AM
To: Balázs Varga A
Cc: [email-masked]
Subject: Re: [Detnet-dp-dt] Providing unique Flow-ID

Hi,

> Before discussing uniqueness/allocation/usage of these labels let's 
> list the scenarios requiring flow identification during transport. They can be separated in two groups:
> - service protection: recognize compound / member flows for 
> replication an elimination.
>  
> In case of PHP, they receive only "d-pw + l-label", so the x-PE node 
> should recognize the DetNet flow based on these labels. DetNet 
> specific functions are driven by the "d-pw label" and "l-label" pair. 
> The "d-pw"+"l-label" pairs have to be locally unique on the x-PE.

I have an issue what “pair” means here. L-labels should only have simple rules and actions like pop, label swap, etc:

> The problematic points are the intermediate "P" nodes. Their detnet 
> role is limited to ensure congestion protection from the above listed 
> DetNet functions. Additionally OAM functions are also nice to have at each hop (as usual).
>  
> - Option-A, P node can recognize only "t-label" and cannot consider 
> the whole label stack for flow recognition. This is the scenario, 
> where we have pre-established tunnels over the network, where the 
> DetNet flows are mapped to appropriate tunnels to be transported over 
> the network. This can be treated as a form of aggregation as many 
> DetNet flows may use the same tunnel. Of course with this aggregation we lost per flow identification, that is the price for scalability.
> - Option-B, P-nodes can consider the whole label stack and they can 
> identify each individual flow. That represents additional requirement 
> on P nodes, which may not be acceptable in some network scenarios.
>  
> - l-label: allocated by the S-PE node. Label value is unique on that 
> particular S-PE node.

> - t-label: allocated by P node. Refer to the tunnel endpoint node 
> (FEC) and the tunnel-ID. Value locally unique on the P node.
>  
> Such an allocation scheme ensure that all nodes in the network are 
> able to identify uniquely the DetNet flows (or aggregate flows) and 
> support the above listed
> functions:

> - P-node (option-B): DetNet flow(s) identified based on the "l-label + 
> t-label" (no need to look for the “d-pw" label, unless “l-label” is 
> not present)
>  

>  
> Good night and see You tomorrow early morning Bala'zs
>

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 21 Feb 2017 19:30:11 -0800

Hi,

We refer to the naming found in slides we used & shared in past two or so calls.

- Jouni

> On Feb 21, 2017, at 7:27 PM, Jiangyuanlong <[email-masked]> wrote:
> 
> Hi,
>

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 22 Feb 2017 03:50:33 +0000

Is I-label just the DetNet Id label named by Loa? 

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Wednesday, February 22, 2017 11:30 AM
To: Jiangyuanlong
Cc: Balázs Varga A; [email-masked]
Subject: Re: [Detnet-dp-dt] Providing unique Flow-ID

Hi,

- Jouni

> What is I-label and what is L-label? Are they in the same label stack 
> as the d-pw label? It will help us to be aligned to the same picture;) In the past, we have PW label and LSP label (maybe multiple LSP labels in hierarchy) for a service.
> 
> Thanks,
> Yuanlong
>> - P-node (option-B): DetNet flow(s) identified based on the "l-label 
>> + t-label" (no need to look for the “d-pw" label, unless “l-label” is 
>> not present)
>>

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 21 Feb 2017 19:52:45 -0800

I think we only have L-, T-, and d-pw labels.. ‘I’ is probably just lowercase ‘L’?

- JOuni

> On Feb 21, 2017, at 7:50 PM, Jiangyuanlong <[email-masked]> wrote:
>

---

From: Loa Andersson <[email-masked]>
Date: Wed, 22 Feb 2017 13:53:35 +0800

Yuanlong,

Since this is on the table I think we should review the naming.

For labels we currently have

T-lable (Tunnel Label), i.e. the outermost label that is PHP'ed
by the pen-ultimate node before reaching one of the x-PEs.

L-label (or L-level-label, since it can be a stack in its own right,
the lavle that takes you between the x-PE's and conserving what node
the packet came from.

d-pw label, the label that is preserved end to end

d-id (DetNet node ID), label that is used to disambiguate between flows
when the control plane has allocated the same d-pw label beween two
different pair of ingress and egress T-detnet-PE

Apart from that we have  some other terms (which I btw think should
be changed)

T-detnet-PE, the ingress and egress nodes for a detnet flow.
- A node that is ingress relative to a flow does replication.
- A node that is egress relative to a flow does elimination.

S-detnet-PE, the node on the wire that does both replication and
elimnination.

/Loa

-- 

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

---

From: Balázs Varga A <[email-masked]>
Date: Wed, 22 Feb 2017 05:56:46 +0000

Hi,

> To my understanding the l-labels “connect” x-PE nodes i.e. create the desired overlay topology over all LSRs/PEs. 
> L-labels also identify which packets will receive FRER processing and which not i.e., whether a specific PW gets 
> terminated in an x-PE or whether x-PE just acts as a transit.

Why do we need l-label to connect x-PE nodes? t-lables do that for free.
I agree that the next label after the t-label will tell x-PE what to do.
Terminate the PW or just act as transit.

See You soon
Bala'zs

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Tuesday, February 21, 2017 10:34 PM
To: Balázs Varga A <[email-masked]>
Cc: [email-masked]
Subject: Re: [Detnet-dp-dt] Providing unique Flow-ID

Hi,

---

From: Loa Andersson <[email-masked]>
Date: Wed, 22 Feb 2017 14:06:09 +0800

Bala'zs,

The tunnel might carry more the just one PW, and in the general case it 
might come from more than one node.

/Loa

--

---

From: Loa Andersson <[email-masked]>
Date: Wed, 22 Feb 2017 18:32:21 +0800

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?

/Loa
--

---

From: Lou Berger <[email-masked]>
Date: Wed, 22 Feb 2017 06:08:56 -0500

Loa,

>    shall be able to use with the DetNet dataplane?

This is more a wg question than DT one, and we're not there yet.  I'd say 
the intent *at this point* is that they should be allowed for, and any work 
done by the DT that would impact / limit will need to be documented and 
discussed.

Lou

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 22 Feb 2017 12:17:23 +0100

Hi Loa,

>    solution to complicated. Do we have a good motiation why we need

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. 

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?

Thanks,

Carlos

---

From: "jouni.nospam" <[email-masked]>
Date: Wed, 22 Feb 2017 07:26:14 -0800

Hi,

> On Feb 22, 2017, at 3:17 AM, Carlos Jesús Bernardos Cano <[email-masked]> wrote:
> 
> Hi Loa,
> 

One reason is to be equally good as the IEEE 802.1 counter part.

> 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 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

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 22 Feb 2017 16:45:03 +0100

Hi Jouni,

On Wed, 2017-02-22 at 07:26 -0800, jouni.nospam wrote:
> > > second brought up bu two indenpendent people I talked about
> > > DetNet
> > > with.
> > > 
> > >    replication/elimination other than at the egress/ingress will
> > > make
> > > the
> > >    solution to complicated. Do we have a good motiation why we
> > > need
> > > it?
> > 
> 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.

---

From: "jouni.nospam" <[email-masked]>
Date: Wed, 22 Feb 2017 07:49:24 -0800

Hi,

> On Feb 22, 2017, at 2:32 AM, Loa Andersson <[email-masked]> 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.
> 

My understanding is “as much as possible” but not restricted by it if something is missing at this point.

> - I’ve heard the opinion (from two different directions) that doing

Who are? Because, I have not heard complaints myself other than those we have discussed in the DT..

>  replication/elimination other than at the egress/ingress will make the

This I definitely agree, but still want to solve it.

>  solution to complicated. Do we have a good motiation why we need it?

Too complicated meaning:
1) it changes too many things architecturally/conceptually, or
2) the current sw would need a facelift, or
3) the current hw would need a facelift

Replication/elimination was one of the criterias we set up when we started working on data plane alternatives. That originates from the “service protection”, and in a case of protection we wanted to match what 802.1CB is capable of at the L2.

- Jouni

---

From: "jouni.nospam" <[email-masked]>
Date: Wed, 22 Feb 2017 07:51:55 -0800

Hi Carlos,

[snip]

> On Feb 22, 2017, at 7:45 AM, Carlos Jesús Bernardos Cano <[email-masked]> wrote:
> Hi Jouni,

Sure. I welcome contributions for the needed text.

- Jouni

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 22 Feb 2017 17:00:53 +0100

Hi Jouni,

On Wed, 2017-02-22 at 07:51 -0800, jouni.nospam wrote:
> > > > On Feb 22, 2017, at 3:17 AM, Carlos Jesús Bernardos Cano <cjbc@
> > > > it.u
> > > > c3m.es> wrote:
> > > > 
> > > > Hi Loa,
> > > > 

OK. I'll provide some text there.

Carlos

---

From: Norman Finn <[email-masked]>
Date: Wed, 22 Feb 2017 16:29:34 +0000

Also, they define the overlay topology over which the pseudowires are created.

I think.

-- Norm
________________________________________
From: Detnet-dp-dt [[email-masked]] on behalf of Loa Andersson [[email-masked]]
Sent: Tuesday, February 21, 2017 10:06 PM
To: [email-masked]
Subject: Re: [Detnet-dp-dt] Providing unique Flow-ID

Bala'zs,

/Loa

--

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 22 Feb 2017 08:54:55 -0800

Thanks Loa for listing these and specifically pointing out that L-label level can be a stack itself. I was myself assuming that the T-label-level could be a label stack as well. 

I would exclude d-id for now because we really have not had any discussion around it yet. I, for example, am not sure whether it is actually present on wire or not.

- Jouni

> On Feb 21, 2017, at 9:53 PM, Loa Andersson <[email-masked]> wrote:
> 
> Yuanlong,
>

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 23 Feb 2017 01:45:47 +0000

Totally agreed. To understand the requirements, a slide on the IEEE 802.1 web site may help us further:
http://www.ieee802.org/1/files/public/docs2013/cb-nfinn-packet-loss-ratio-10-13-v03.pdf

Thanks,
Yuanlong
-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of jouni.nospam
Sent: Wednesday, February 22, 2017 11:49 PM
To: Loa Andersson
Cc: DetNet Chairs; [email-masked]
Subject: Re: [Detnet-dp-dt] high level questions on detnet dataplane

Hi,

Too complicated meaning:

- Jouni

---

From: Loa Andersson <[email-masked]>
Date: Mon, 27 Feb 2017 16:01:29 +0800

Jouni,

Sorry for late response.

The terminology around T-Labels and L-labels are a bit ambivalent.

Basically T-Labels and L-Labels are labels in the same label stack, only
that the T-label is on the top of the stack. Normally T-labels are just
for transportation, i.e. no BW allocated.

/Loa

--

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 27 Feb 2017 09:00:42 +0000

Hi Loa,
How about just using a single T-Label? We can use it to stand for an LSP or whatever LSP hierarchy.
It can be bandwidth reserved, or PHP enabled.
B.R.,
Yuanlong

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Monday, February 27, 2017 4:01 PM
To: [email-masked]
Subject: Re: [Detnet-dp-dt] Providing unique Flow-ID

Jouni,

Sorry for late response.

Basically T-Labels and L-Labels are labels in the same label stack, only that the T-label is on the top of the stack. Normally T-labels are just for transportation, i.e. no BW allocated.

/Loa

On 2017-02-23 00:54, Jouni Korhonen wrote:
>> T-lable (Tunnel Label), i.e. the outermost label that is PHP'ed by 
>> the pen-ultimate node before reaching one of the x-PEs.
>>
>> d-id (DetNet node ID), label that is used to disambiguate between 
>> flows when the control plane has allocated the same d-pw label beween 
>> two different pair of ingress and egress T-detnet-PE
>>
>>>> What is I-label and what is L-label? Are they in the same label 
>>>> stack as the d-pw label? It will help us to be aligned to the same picture;) In the past, we have PW label and LSP label (maybe multiple LSP labels in hierarchy) for a service.
>>>>
>>>> Thanks,
>>>> Yuanlong
>>>>> Before discussing uniqueness/allocation/usage of these labels 
>>>>> let's list the scenarios requiring flow identification during transport. They can be separated in two groups:
>>>>> In case of PHP, they receive only "d-pw + l-label", so the x-PE 
>>>>> node should recognize the DetNet flow based on these labels. 
>>>>> DetNet specific functions are driven by the "d-pw label" and "l-label" pair.
>>>>> The problematic points are the intermediate "P" nodes. Their 
>>>>> detnet role is limited to ensure congestion protection from the 
>>>>> above listed DetNet functions. Additionally OAM functions are also nice to have at each hop (as usual).
>>>>>
>>>>> - Option-A, P node can recognize only "t-label" and cannot 
>>>>> consider the whole label stack for flow recognition. This is the 
>>>>> scenario, where we have pre-established tunnels over the network, 
>>>>> where the DetNet flows are mapped to appropriate tunnels to be 
>>>>> transported over the network. This can be treated as a form of 
>>>>> aggregation as many DetNet flows may use the same tunnel. Of course with this aggregation we lost per flow identification, that is the price for scalability.
>>>>> - Option-B, P-nodes can consider the whole label stack and they 
>>>>> can identify each individual flow. That represents additional 
>>>>> requirement on P nodes, which may not be acceptable in some network scenarios.
>>>>>
>>>>> - l-label: allocated by the S-PE node. Label value is unique on 
>>>>> that particular S-PE node.
>>>>
>>>>> able to identify uniquely the DetNet flows (or aggregate flows) 
>>>>> and support the above listed
>>>>> functions:
>>>>> + t-label" (no need to look for the “d-pw" label, unless “l-label” 
>>>>> + is
>>>>> not present)
>>>>>

--

---

From: Loa Andersson <[email-masked]>
Date: Mon, 27 Feb 2017 19:08:23 +0800

Yuanlong,

> It can be bandwidth reserved, or PHP enabled.

Exactly what do you gain by first saying 1 single label, and then saying
that it can stands for hierarchy?

What I think we need to show is that each node has the information
needed to take the right decision in all cases.

One case is intresting to look at, and where I hav not made up my mind.
With a label stack T/d-pw/d-id might work. You need to use the T-label
as the BW container. And the d-pw label need to carry information 
whether it is "swapped only" or "eliminated/replicated", but the gain is 
very small and if routing is changing there is no guarantee that all PWs 
actually pass throug the correct nodes if there is more links in
the mesh than we show in the pictures.

/Loa

--

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 27 Feb 2017 12:04:50 +0000

Loa, 

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Monday, February 27, 2017 7:08 PM
To: Jiangyuanlong; [email-masked]
Subject: Re: [Detnet-dp-dt] Providing unique Flow-ID

Yuanlong,

> It can be bandwidth reserved, or PHP enabled.

Exactly what do you gain by first saying 1 single label, and then saying that it can stands for hierarchy?
[YJ] Sorry that I was totally influenced by the PW and MS-PW architecture (RFC 3985 and RFC 5659), where the LSP is called PSN tunnel.
[YJ] But my point is, all the approaches in discussion will have a PSN tunnel between T-PE and S-PE, there is no difference in this respect.

What I think we need to show is that each node has the information needed to take the right decision in all cases.

One case is intresting to look at, and where I hav not made up my mind.
With a label stack T/d-pw/d-id might work. You need to use the T-label as the BW container. And the d-pw label need to carry information whether it is "swapped only" or "eliminated/replicated", but the gain is very small and if routing is changing there is no guarantee that all PWs actually pass throug the correct nodes if there is more links in the mesh than we show in the pictures.
[YJ] Dynamic paths will have great impact on the sequence number, static paths make more sense if any FRER operation is needed. 
Cheers,
Yuanlong

/Loa

>>> flows when the control plane has allocated the same d-pw label 
>>> beween two different pair of ingress and egress T-detnet-PE
>>>
>>>>>> Such an allocation scheme ensure that all nodes in the network 
>>>>>> are able to identify uniquely the DetNet flows (or aggregate 
>>>>>> flows) and support the above listed
>>>>>> functions:

--