Re: [Detnet-dp-dt] FRER example.. maybe a way forward? was Re: quick notes from call 2/14/15

[Jiangyuanlong <[e-mail]>]

Hi loa,

Your slides provide a good start point, it also made me think about the "Eliminate first and then replicate" scheme. 
In slide 4 & 5, you said:
"Eliminate duplicates in PW instance (indexed by d-pw).
Replicate d-pw after duplicate elimination towards C and D using L5 and L2."

Assume that we have an S-PE router with a switch fabric inside (given the high throughput in the typical aggregation and metro network, switch fabric is a reasonable piece imbedded in a router).
Assume that Eliminate module and Replicate module are separate modules. 
For a DetNet flow with a 10M bps, let us calculate what is the requirement on the switch fabric.
We have several options to implement Eliminate & Replicate in the S-PE1 (please see the attached slides):
1. "Eliminate first and then replicate", if we put both Eliminate module and Replicate module in some central processing unit near the switch fabric, then 4 times of the DetNet flow (i.e., 40Mbps) need to pass through the switch fabric. When d-pw1 is broken, the traffic from d-pw3 is looped back to S-PE2.
2. "Eliminate first and then replicate", if we put both Eliminate module and Replicate module in the port connecting to the other S-PE, then optimally only 2 times of the DetNet flow (i.e., 20Mbps) need to pass through the switch fabric. When d-pw1 is broken, the traffic from d-pw3 is also looped back to S-PE2.
3. "Replicate first and then Eliminate", we can put Replicate module in the ingress of pw1 and put Eliminate module in the egress to PW2, then 3 times of the DetNet flow (i.e., 30Mbps) need to pass through the switch fabric.
When d-pw1 is broken, no traffic from d-pw3 is looped back to S-PE2.

In summary, "Eliminate & replicate" scheme will influence the bandwidth consumed in the switch fabric and on d-pw3.

Thanks,
Yuanlong

-----Original Message-----
From: Detnet-dp-dt [mailto:[e-mail]] On Behalf Of Loa Andersson
Sent: Sunday, February 19, 2017 3:22 PM
To: Jouni Korhonen
Cc: [e-mail]
Subject: Re: [Detnet-dp-dt] FRER example.. maybe a way forward? was Re: quick notes from call 2/14/15

slides

/Loa

On 2017-02-19 15:17, Jouni Korhonen wrote:
> Loa,
>
>> On 18 Feb 2017, at 21:37, Loa Andersson <[e-mail]> wrote:
>>
>> Jouni,
>>
>> You st me off thinking in another direction. I have a concern that I tried to describe in two slides I've added in front of your. The solution involves adding  DetNet Id label to the stack.
>
> No slides?
>
>> The issues arises when two pair of nodes agree on the same d-pw label 
>> value.
>
> Is this an issue with an _existing_ control plane?
>
>
>>
>> Though I need to re-read draft-ietf-mpls-flow-ident to see if there 
>> is a more efficient way of doing it.
>>
>> I also have a question on what now is slide 5. WHy do we send a packet out over the same interface it came in over?
>
> That was an automatic byproduct of the replication rule as it does not care which interface the packet came in. Also I think the ladder redundancy case needed to have packets going two directions and this type of “echoing” would do that. The content of a packet on A->B->C would be the same as coming from C->B->C.
>
> - Jouni
>
>
>>
>> /Loa
>>
>>
>> On 2017-02-18 02:50, Jouni Korhonen wrote:
>>> Folks,
>>>
>>> See the attached slideset for some thoughts on implementing FRER in S-DetNet-PEs and Norm’s ladder redundancy case. Note, S-DetNet-PEs and T-DetNet-PEs are not off the shelf x-PEs, since they do understand DetNet quirks in addition to existing x-PE functionality.
>>>
>>> The solution still assumes global d-pw space witin an administrative domain due the easier handling of SN counters and bit vectors for elimination on each x-PE. I have rightfully been pointed out that having a common reserved label space among all x-PEs for d-pw (detnet) purposes can be hard to achieve, especially in a multivendor environment (there are similar issues on segment routing as well). This is mostly a management/implementation issue, not a technical hardship IMHO.
>>>
>>> If we were to agree to go towards a solution where each x-PE knows the d-pw space of their peers (at L-label level) the d-pw could be different on each PW for the same e2e detnet flow. The d-pw label would in this case be an x-PE DetNet-label-base + index. The index here would actually identify the e2e detnet flow.
>>>
>>>
>>> Thoughts? Comments? Flames?
>>>
>>> - Jouni
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Jouni Korhonen, Broadcom Ltd.
>>> M: [phone]
>>>
>>>> On Feb 15, 2017, at 11:37 AM, Jouni Korhonen <[e-mail]> wrote:
>>>>
>>>> Present: Jouni, Norm, Loa, Balazs, Janos, Carlos, Yuanlong.
>>>>
>>>> Agenda:
>>>> - Was meant to be about CoS and QoS. However, we ended up discussion all time about proper layering and encapsulation of PW stack.
>>>>
>>>> Discussion:
>>>> - Sequence number. We made a >>decision<< to settle down to 16 
>>>> bits. This is the most “compatible” approach. At high speeds it has 
>>>> been argued 16 bits is not enough. In practical implementations 
>>>> even 16 bits of sequence number won’t be maintained. It is 
>>>> typically a much smaller window of the entire sequence number space 
>>>> (think about numbers.. 1M PWs times the seqnum bit vector etc..)
>>>> - PWs and the label stack. See the latest slides from Loa and specifically the slide 9 (attached). I did add one slide to this deck, the slide 14.
>>>> - T-labels are typically per hop. L-labels are between DetNet aware S/P-PEs and essentially form an overlay over the underlying network. d-pw labels are end to end (at the moment.. to be discussed) between the T-PEs or in general between the DetNet aware end point that understand the detnet data plane.
>>>> - currently all d-pw (detnet PW labels) experience FRER if that functionality is enabled. d-pw labels are tied to sequence numbers (the detnet CW).
>>>> - L-labels seen beneficial allowing the autoconfiguration of FRER i.e., build the overlay over the network and do not care configuring the PWs. This mimics one 802.1CB feature (see .1CB sub-clause 7.11).
>>>> - L-labels also allow simple label swap in a detnet S-PE i.e., no FRER would be applied.
>>>> - This setup seems plausible. There was concerns overloading L-labels with some of the PW decision making in the fast path and thus possibly causing a lookup that needs to be done over two labels (L & d-pw). Essentially it is the L-label that signals whether the FRER gets applied.
>>>> - General consensus towards the PW instance “facing egress ports” in a detnet S-PE would do the elimination.  This discussion needs to be completed. An interesting use case was described by Norm (see slide 14). An example: packet arrives from A towards B (flow X), it always gets replicated towards C, but towards D only if the same packet (from flow Y) has not earlier arrived from C. Whether this works ok with the current S-PE and PW instance doing elimination concepts needs to be verified.
>>>> - Discussion to be completed whether there are cases where L-labels can be left out i.e., only use T-labels and d-pw labels.
>>>> - Balazs said to provide a matrix/table of different permutations for labels & replications & eliminations.
>>>>
>>>> We’ll have a call next Tuesday 2/21/17.
>>>>
>>>>
>>>> --
>>>> Jouni Korhonen, Broadcom Ltd.
>>>> M: [phone]
>>>>
>>>> <detnet-replication-jik.pptx>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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]