Subject: [Detnet-dp-dt] a quick look at the replication/discarding case for detnet flows

From: Loa Andersson <[email-masked]>
Date: Sat, 14 Jan 2017 12:28:31 +0800

Folks,

I took a quick look at the replication / discarding case we talked about 
at the meeting this week.

Please remember that so far this is not a proposal, just a demonstration
that there is at least one way of doing it.

What is there can bee revised, improved, changed or discarded if we
find something better. Take a look a send comments.

/loa

Warning: I have a grave case of dyslexia, so any odd or inventive
spelling is pure accident.
-- 

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

---

From: Jiangyuanlong <[email-masked]>
Date: Sat, 14 Jan 2017 11:45:58 +0000

Loa,

Thank a lot for the slides, a very good start!
Maybe we just need one layer of PW label, while redefine the MS-PW paradigm to support DetNet data plane.
The T-PEs as defined in the PWE3 can encapsulate/de-capsulate the DetNet frames, and generate the sequence number.
The S-PEs usually can swap the PW label or terminate the PW completely; we can extend their operations to support replication and filtering based on the sequence number.
LSP FECs can work as in the traditional MPLS, but if any new DetNet mechanism is needed in P nodes in the future, we can also add new FECs quite conveniently.

Thanks,
Yuanlong

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Saturday, January 14, 2017 12:29 PM
To: [email-masked]
Subject: [Detnet-dp-dt] a quick look at the replication/discarding case for detnet flows

Folks,

I took a quick look at the replication / discarding case we talked about at the meeting this week.

Please remember that so far this is not a proposal, just a demonstration that there is at least one way of doing it.

What is there can bee revised, improved, changed or discarded if we find something better. Take a look a send comments.

/loa

Warning: I have a grave case of dyslexia, so any odd or inventive spelling is pure accident.
--

---

From: Loa Andersson <[email-masked]>
Date: Sun, 15 Jan 2017 12:09:19 +0800

Yuanlong,

> Thank a lot for the slides, a very good start!

Tnx!

> Maybe we just need one layer of PW label,

Currently I dob't see how this would work, can you explain plz?

> while redefine the MS-PW paradigm to support DetNet data plane.

This a very tricky approach, we would need to "tweak" the paradigm
in a backwards compatibel way.
I tend to think that if we add replication and discarding at merege
point this is a big enough "tweak".

> The T-PEs as defined in the PWE3 can encapsulate/de-capsulate the DetNet frames,

yes - the PW paradigm allows you to add whatever encapsulation we need.

  and generate the sequence number.

Yes the function is there to guarantee that packets are not re-ordred.

> The S-PEs usually can swap the PW label or terminate the PW completely;

wouldn't terminating the PW make the S-PE into a T-PE, isn't at the
core of the definition of S-PE and T-PE?

  we can extend their operations to support replication and filtering 
based on the sequence number.

I - think yes, that cam be done, but I don't see that filtering on the 
sequence number is enough, some context (e.g. label) is needed, right?

> LSP FECs can work as in the traditional MPLS,

yes they will, but I thought that the consensus in the meeting were that
we don't want non-detnet traffic sharing the transport of detnet, right?

but if any new DetNet mechanism is needed in P nodes in the future, we
can also add new FECs quite conveniently.

Yes it can be done, but I think we need from the start to avoid piggy-
backing of non-detnet traffic.

/Loa

--

---

From: Jiangyuanlong <[email-masked]>
Date: Mon, 16 Jan 2017 13:02:46 +0000

Loa, please see my comments inline.
I also have a question on the availability requirements of the DetNet, do we need to prevent any single point of failure in the whole MPLS network?

Thanks
Yuanlong

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Sunday, January 15, 2017 12:09 PM
To: Jiangyuanlong; [email-masked]
Subject: Re: [Detnet-dp-dt] a quick look at the replication/discarding case for detnet flows

Yuanlong,

Tnx!

Currently I dob't see how this would work, can you explain plz?
[YJ] I will prepare a slide to explain the details. It may take a couple of days.

> while redefine the MS-PW paradigm to support DetNet data plane.

This a very tricky approach, we would need to "tweak" the paradigm in a backwards compatibel way.
I tend to think that if we add replication and discarding at merege point this is a big enough "tweak".
[YJ] yes, we need to introduce a new data plane mechanism to support this function.

> The S-PEs usually can swap the PW label or terminate the PW 

wouldn't terminating the PW make the S-PE into a T-PE, isn't at the core of the definition of S-PE and T-PE?
[YJ] Swapping is normal, and terminating is unnecessary. Though the S-PE may need to look into the PW control word to get the sequence number of the packet.

  we can extend their operations to support replication and filtering based on the sequence number.

I - think yes, that cam be done, but I don't see that filtering on the sequence number is enough, some context (e.g. label) is needed, right?
[YJ] Yes, some lattice PW connectivity such as introduced in draft-ietf-pals-mpls-tp-dual-homing-protection may be needed. These lattice PW can be dynamically established for the DetNet service.

> LSP FECs can work as in the traditional MPLS,

yes they will, but I thought that the consensus in the meeting were that we don't want non-detnet traffic sharing the transport of detnet, right?
[YJ] maybe I got it wrong, but my understanding is: the DetNet PW is exclusively used for DetNet services, though the MPLS network can still carry non-detnet services. Maybe the service providers have more to say on this topic:)

but if any new DetNet mechanism is needed in P nodes in the future, we can also add new FECs quite conveniently.

Yes it can be done, but I think we need from the start to avoid piggy- backing of non-detnet traffic.

/Loa

--

---

From: Norman Finn <[email-masked]>
Date: Tue, 17 Jan 2017 09:41:39 -0500

Thanks for the slides!

Question: You don’t introduce the cross-connect with intermediate packet deletion until slide 9.  Is there any reason you could not add the cross-connect to slide 5, You could have PW5 (B to C) and PW6 (C to B).  B would discard duplicates between PW1 and PW6, outputting the remaining packets on PW2.

I assume that you didn’t put this idea in the slides, because you’re assuming that the two streams have to have the same PW label in order for you to discard duplicates.  I’m assuming that you can direct two PW labels to a single state machine.  Is that necessarily a problem?

— Norm

> On Jan 13, 2017, at 23:28, Loa Andersson <[email-masked]> wrote:
> 
> Folks,
> 
> <detnet-replication.pptx>_______________________________________________
> Detnet-dp-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt

---

From: Balázs Varga A <[email-masked]>
Date: Tue, 17 Jan 2017 15:26:01 +0000

Hi Loa,

Two comments/discussions points for the weekly call:

1, P nodes (recognizing detnet-flows)
P nodes have to recognize detnet-flows in order to use the allocated resources (e.g., QoS) during the 
forwarding of packets belonging to a given detnet-flow. We have two options: 
(i) P nodes recognize "d-pw" label to identify the detnet-flow. This would mean that P nodes have to 
walk through the whole label stack. And I think also that "d-pw" label value must be globally unique 
in the network to make life simple! That can be a scalability issue ...
(ii) We are using different LSP per detnet-flow. This would make identification more simple for P nodes
but raises scalability issues for the LSPs.

2, Distinguishing replica flows (required for OAM purposes)
Let's assume that "node1 and node5" and "node2 and node6" are collapsed. I have created slide13 
based on your slide7 (collapsed nodes denoted as node15 and node26). As a result the upper and 
lower MS-PWs shares the first and second hop link when leaving nodeA. Node15 cannot distinguish
the two replica flows only using the "d-pw" label. We should consider to use different "d-pw" label 
value per "detnet-flow segment". Such a scenario is shown on slide14. Using different "d-pw" labels
may furthermore obsolete the PW-labels ...

Cheers
Bala'zs

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Saturday, January 14, 2017 5:29 AM
To: [email-masked]
Subject: [Detnet-dp-dt] a quick look at the replication/discarding case for detnet flows

Folks,

/loa

---

From: Norman Finn <[email-masked]>
Date: Tue, 17 Jan 2017 11:32:59 -0500

This collapsed scenario (in 2) is the example that drove 802.1 to assume (as the typical case) that the two parts of the duplicated flow have different labels.

— Norm

> On Jan 17, 2017, at 10:26, Balázs Varga A <[email-masked]> wrote:
> 
> Hi Loa,
> 
> <detnet-replication_comVB.pptx>_______________________________________________

---

From: Loa Andersson <[email-masked]>
Date: Wed, 18 Jan 2017 09:55:10 +0800

On 2017-01-17 22:41, Norman Finn wrote:
> Thanks for the slides!
>
> Question: You don’t introduce the cross-connect with intermediate packet deletion until slide 9.  Is there any reason you could not add the cross-connect to slide 5,

No other reason than I wanted to take one step at the time.

  You could have PW5 (B to C) and PW6 (C to B).  B would discard 
duplicates between PW1 and PW6, outputting the remaining packets on PW2.

Sure, but I thought that just one case (PW5 B to C) would be enough, 
replication at B and discarding at C, wouldn't that be the same as
(PW6 C to B replication at C and discarding at B?
>
> I assume that you didn’t put this idea in the slides, because you’re assuming that the two streams have to have the same PW label in order for you to discard duplicates.
Well the PW label (d-pw) will be the same everywhere for a detnet PW 
starting at A.
I’m assuming that you can direct two PW labels to a single state 
machine.  Is that necessarily a problem?

Don't get the question? You can direct as many PW labels as you want 
(within reason) th the same machine. I don't see the problem.

/Loa

--

---

From: Loa Andersson <[email-masked]>
Date: Wed, 18 Jan 2017 12:35:00 +0800

Balazs,

Short responses in-line.

> walk through the whole label stack. And I think also that "d-pw" label value must be globally unique

Depends on what you mean by "globally unique", it is the same end to
end, i.e. between A and B, but not unique in the sense that same the
label value cannot be used be A and Z signifying something totally
different.

> may furthermore obsolete the PW-labels ...

Why does the nodes need to know the detnet label, isn't it enough that 
the QoS requirements are known?

This actually begs the question whether we need the intermediary PW at 
all, we could work with one or two RSVP_TE tunnels and the detnet pw
label.

/Loa
> _______________________________________________

--

---

From: Norman Finn <[email-masked]>
Date: Thu, 19 Jan 2017 11:45:07 -0500

We’re in sync, I think.

— Norm

> On Jan 17, 2017, at 20:55, Loa Andersson <[email-masked]> wrote:
> 
> 
> 
> You could have PW5 (B to C) and PW6 (C to B).  B would discard duplicates between PW1 and PW6, outputting the remaining packets on PW2.
> 
> Sure, but I thought that just one case (PW5 B to C) would be enough, replication at B and discarding at C, wouldn't that be the same as
> Well the PW label (d-pw) will be the same everywhere for a detnet PW starting at A.
> I’m assuming that you can direct two PW labels to a single state machine.  Is that necessarily a problem?
> 
> Don't get the question? You can direct as many PW labels as you want (within reason) th the same machine. I don't see the problem.
> 
> /Loa
>> 
>> — Norm
>> 
> Loa Andersson                        email: [email-masked] <mailto:[email-masked]>
> Senior MPLS Expert                          [email-masked] <mailto:[email-masked]>

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 20 Jan 2017 18:47:20 -0800

Loa,

Thanks for the slides. The slide 9 is exactly what I was after with my e2e PW labels. Now the question: “I don’t know if there is currently enough capabilities in LDP to merge, unless we merge all traffic with the same FEC on the same outgoing outer label.” I cannot claim expertise in LDP to be able to have any kind of educated view here. So if we are not going to be able to merge we would “waste” additional transport label between C->D? Duplicated would have been eliminated, thus there is no bandwidth impact. I do not think that would be an issue. It is no optimal but works.

- Jouni

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

> On Jan 13, 2017, at 8:28 PM, Loa Andersson <[email-masked]> wrote:
> 
> Folks,
>

---

From: Loa Andersson <[email-masked]>
Date: Sat, 21 Jan 2017 13:25:11 +0800

Jouni,

On 2017-01-21 10:47, Jouni Korhonen wrote:
> Loa,
>
> Thanks for the slides. The slide 9 is exactly what I was after with my e2e PW labels. Now the question: “I don’t know if there is currently enough capabilities in LDP to merge, unless we merge all traffic with the same FEC on the same outgoing outer label.” I cannot claim expertise in LDP

If you have the same forwarding class and destination (part of the FEC
defintion) LDP will merge. This mean that all detnet traffic from one 
node will arrive at D on the same (transport) LSP. I think this is fine
since the label for that LDP is php'ed.
  to be able to have any kind of educated view here. So if we are not 
going to be able to merge we would “waste” additional transport label 
between C->D?

Yes but that is a label that will be unique for a link, we are not
running into problems until we start trying to use domaion wide unique
labels.

  Duplicated would have been eliminated, thus there is no bandwidth impact.

Correct!

I do not think that would be an issue. It is no optimal but works.

Well - I guess we could find some minor optimizations, but this wuth
merging and php this is close to optimal.

/Loa

--

---

From: Jouni Korhonen <[email-masked]>
Date: Sat, 21 Jan 2017 08:27:57 -0800

Loa,

Ok. Thanks.  I think we also need to make clear that php is not always
necessarily done.

Jouni

Sent from a smart phone.. Mind the typos..

> On Jan 20, 2017, at 21:25, Loa Andersson <[email-masked]> wrote:
>
> Jouni,
>
>

---

From: Loa Andersson <[email-masked]>
Date: Sun, 22 Jan 2017 13:26:01 +0800

Jouni,

Depends on what you mean by " not always necessarily done", php is done 
by default but can be turned off. I see no reason to turn it of, at
least not if we are concerned for the depth of the label stack.

/Loa

--

---

From: Loa Andersson <[email-masked]>
Date: Sun, 22 Jan 2017 18:13:12 +0800

All,

Rhere is one more MPLS (though it is not a standard, but an
informational independent stream RFC) that could hlp us guarantee
QOS for the MPLS layer that transport the PWs.

Take a look at RFC 7625 (https://datatracker.ietf.org/doc/rfc7625/)

I'm a bit reluctant to propose this, since we would have to take the 
document into the mpls working group and make it a Standards Track RFC.

/Loa

On 2017-01-22 13:26, Loa Andersson wrote:
>>>> Thanks for the slides. The slide 9 is exactly what I was after with
>>>> my e2e PW labels. Now the question: “I don’t know if there is
>>>> currently enough capabilities in LDP to merge, unless we merge all
>>>> traffic with the same FEC on the same outgoing outer label.” I
>>>> cannot claim expertise in LDP
>>>

--

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 22 Jan 2017 17:40:18 -0800

Loa,

It is just that the solution has to work even if php does not take place.

- JOuni

> On Jan 21, 2017, at 9:26 PM, Loa Andersson <[email-masked]> wrote:
> 
> Jouni,
> 
> Depends on what you mean by " not always necessarily done", php is done by default but can be turned off. I see no reason to turn it of, at

---

From: Loa Andersson <[email-masked]>
Date: Mon, 23 Jan 2017 10:12:40 +0800

Jouni,

Sure - it should work just fine, but one more label in the stack that 
has to be popped at the the S-PE and T-PE. I don't know the limits of
labels in the stack that need to be popped, anyone tht have "hard"
information.

/Loa

--

---

From: Loa Andersson <[email-masked]>
Date: Mon, 23 Jan 2017 20:55:36 +0800

Balaazs,

I've been thinking about this, but still not sure I understand the issues.

On 2017-01-17 23:26, Balázs Varga A wrote:
> walk through the whole label stack.

No, I don't think the P nodes needs to look at anything other than
transport label. The required QoS is assigned to the transport label
at setup time, at forwarding only one label needs to looked at.

And I think also that "d-pw" label value must be globally unique

It needs to be unique within the replicas of the replicas and the
the incoming interface of the T-PW.

> in the network to make life simple! That can be a scalability issue ...

It is certainly a scalability issue, and it would have an effect all
traffic in the network and all levels.

> lower MS-PWs shares the first and second hop link when leaving nodeA.

yes, and the issue

  Node15 cannot distinguish
> the two replica flows only using the "d-pw" label.

Is the P-node really supposed do anything about the replicas than
forwarding them?
  We should consider to use different "d-pw" label
> may furthermore obsolete the PW-labels ...

I think I lost you here, if we use díferent labels, how will the nodes 
know they are replicas? And P nodes only look at the transport label.

/Loa

--

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 23 Jan 2017 08:25:26 -0800

> Is the P-node really supposed do anything about the replicas than

Based on my current understanding.. no.

- JOuni