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

[Loa Andersson <[e-mail]>]

Yuanlong,

I still not sure about this, it looks very much like the element 
functional blocks that ITU-T SG15 used to do, but that IETF never
done. IETF leave this mostly up the different implementations.

Having said that, I realize that for an implementor this is important,
but just now I don't see how to fold it on to an IETF standard.

/Loa

On 2017-02-23 15:58, Jiangyuanlong wrote:
> 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]