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

[Loa Andersson <[e-mail]>]

Jouni,


On 2017-02-19 15:11, Jouni Korhonen wrote:
> Loa,
>
>> On 18 Feb 2017, at 23:04, Loa Andersson <[e-mail]> wrote:
>>
>> Jouni,
>>
>>
>>
>> On 2017-02-19 14:49, Jouni Korhonen wrote:
>>>
>>> Additional thoughts from my side.
>>>
>>>> On 17 Feb 2017, at 10:50, Jouni Korhonen <[e-mail]> 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.
>>>
>>> Assuming that after replication each outgoing PWs would have also different d-pw label makes the solution less hardware friendly. That would mean yet another mapping table and effectively doubling the label space needed for each PW.
>>>
>>> With a single outgoing d-pw one could be effectively reusing (to most part) 1+1 redundancy if the existing implementation already has one.
>>>
>> What is the scope of "single" here? Do you mean that packet being replicated will have the same d-pw label? I thought that was necessary
>
> As in the slidesset the detnet/administrative domain. All x-PE devices would use the same d-pw. What I am saying above is that if we were using different d-pw labels stuff gets complicated even when replicating.
>
I don't follow - let us say we have one Ethernet and one TDM PW crossing
the domain, id e use the same d-pw label, how do we know which one we
do Ethernet NSP and which one we do TDM NSP on??

/Loa
> - JOuni
>
>> otherwise we can identify duplicates.
>>
>> If you mean that each node only uses one d-pw, I don't think that can
>> work.
>>
>> /Loa
>>>> 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.
>>>
>>>
>>> - Jouni
>>>
>>>>
>>>>
>>>> Thoughts? Comments? Flames?
>>>>
>>>> - Jouni
>>>>
>>>>
>>>> <detnet-frer-jik_v3.pptx>
>>>> --
>>>> 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]
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]