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

[Loa Andersson <[e-mail]>]

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:
> 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
>
> On 2017-01-22 00:27, Jouni Korhonen wrote:
>> 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 <[e-mail]> wrote:
>>>
>>> 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
>>>>
>>>> - Jouni
>>>>
>>>>
>>>> --
>>>> Jouni Korhonen, Broadcom Ltd.
>>>> M: [phone]
>>>>
>>>>> On Jan 13, 2017, at 8:28 PM, Loa Andersson <[e-mail]> wrote:
>>>>>
>>>>> 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: [e-mail]
>>>>> Senior MPLS Expert                          [e-mail]
>>>>> Huawei Technologies (consultant)     phone: [phone]
>>>>> <detnet-replication.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]