Re: [Detnet-dp-dt] one question on S-DetNet-PEs

[Loa Andersson <[e-mail]>]

Bala'zs,

Oh, sure understood - it is just that when we invented the P and
PE terminology it was not for nodes, but for functions. A PE were the
group of functions needed in a node that interfaced customers. A
P was the functions that were need by a node that was passing traffic
inside a provider network,

The caveat was that PE an P functions, at least in the network that
did run at that time, were often found on the same node, consider this.


           +-----+                     +-----+
+--+      |     |                     |     |     +--+
|CE|------|  A  |---------------------|  B  |-----|CE|
+--+      |     |                     |     |     +--+
           +-----+                     +-----+
              |                           |
              |         +------+          |
              |         |      |          |
              +---------|  C   |----------+
                        |      |
                        +------+
                            |
                            |
                          +---+
                          |CE |
                          +---+

If one view A, B and C as node are they P or PE nodes?

/Loa

On 2017-03-09 18:31, Balázs Varga A wrote:
> Hi,
>
> Correct. My comment was an additional argument for the tunnels.
> There are two scenarios mandating tunnels:
> 1, regular P nodes
> 2, DA-S-PE nodes acting as P node for some PWs
>
> Cheers
> Bala'zs
>
> -----Original Message-----
> From: Loa Andersson [mailto:[e-mail]]
> Sent: Thursday, March 09, 2017 11:11 AM
> To: Balázs Varga A <[e-mail]>om>; [e-mail]; [e-mail]
> Subject: Re: [Detnet-dp-dt] one question on S-DetNet-PEs
>
> Balázs,
>
> inline please.
>
> On 2017-03-09 17:02, Balázs Varga A wrote:
>> Hi,
>>
>> Generally agree, just two additional notes/comments:
>> - Mandatory tunnels:
>> They are needed anyway for regular P nodes. The DetNet role of
>> intermediate "P" nodes is limited to ensure congestion protection.
>> However P nodes can usually recognize only LSP labels and cannot
>> consider the whole label stack for flow recognition.  Therefore if
>> DetNet flows would not use tunnels P nodes may not distinguish them
>> from regular (non-DetNet) flows and cannot achieve congestion protection.
>
> While I agree to this, and it is another nail in the coffin of thw "we don't need", you are changing the scenario I draw. The point I tried to make was that DA-S-PE capable nodes in some scenarios might serve in a P role in some scenarios - the operators choice.
>
> /Loa
>
>
>>
>> - DA-S-PE needs also PW and FRER specific configuration:
>> As clarification to the step when "DetNet-PW-label is allocated by the
>> DA-S-PE for the DA-T-PE". You wrote:
>>    > the DetNet-PW-label is allocated by the DA-S-PE for the DA-T-PE, and
>>    >  as the LSP is set up an instruction is entered into the LFIB whether
>>    >  the DA-S-PE should do FRER or not.
>> I think we need more than a simple instruction "to do FRER or not".
>> The egress replication on the DA-S-PE (towards the next DA-S-PE(s) or
>> the terminating
>> DA-T-PE) may be DetNet-flow specific (how many member flows should be
>> created, which tunnel should be used by the egress member flows, etc.).
>>
>> I think we do not have signaling for that DetNet-flow and FRER specific configuration.
>> Do we intend to configure them in advance via management?
>>
>> Cheers
>> Bala'zs
>>
>> -----Original Message-----
>> From: Detnet-dp-dt [mailto:[e-mail]] On Behalf Of
>> Loa Andersson
>> Sent: Thursday, March 09, 2017 2:31 AM
>> To: [e-mail]; [e-mail]
>> Subject: Re: [Detnet-dp-dt] one question on S-DetNet-PEs
>>
>> Jouni, et.al.,
>>
>> On 2017-03-09 04:18, Jouni Korhonen wrote:
>>> Good guestion.
>>>
>>> I guess, if you want a specific node to be a S-DetNet-PE for some
>>> overlay and P for other, you could "tunnel" through it in P case.
>>
>> Yes - I think that is necessary. There is a bit more too it though.
>>> The
>>> currect draft still has text for "overlay labels" (i.e., L-labels)
>>> and I think those would work nicely for this case as you say below.
>>
>> OK - leave that in! There is a terminology issue here, the way we are doing things now, the L-label is the PSN tunnel in the PW architecture.
>>
>> The caveat is that PSN tunnel needsto be mandatory, unless you want to have a very complicated configuration for when a node is P for one overlay but DA-S-PE for another.
>>
>> Let me see if I got right
>>
>> - the PSN-tunnel (PHP'ed at the P node adjacent to the DA-S-PE) takes
>>    the DetNet PW to the DA-S-PE.
>>
>> - the DetNet-PW-label is allocated by the DA-S-PE for the DA-T-PE, and
>>    as the LSP is set up an instruction is entered into the LFIB whether
>>    the DA-S-PE should do FRER or not.
>>
>> - DA-T-PE establish a PSN-tunnel through which the DetNet PW is
>>    tunneled.
>>
>> - in the case of using a signaling protocol (since this is PWs I guess
>>    it by default is LDP) to establish the PW, no other node than the
>>    DA-S-PE, and the egress (DA-T-PE) sees the request for FRER.
>>
>> - for signaling the L-Label/PSN tunnel, RSVP-TE could be used, which
>>    means that the L-Label/PSN-tunnel also serves at BW container.
>>
>> Did I get that right?
>>
>> Yes I think it will work.
>>
>> /Loa
>>
>>>
>>> - Jouni
>>>
>>> 3/8/2017, 5:03 AM, Loa Andersson kirjoitti:
>>>>
>>>> Folks,
>>>>
>>>> There might be a simple answer, but I don't see it just now.
>>>>
>>>> Suppose we have a network, where we designate a certain number of
>>>> nodes as S-DetNet-PEs, to build a nice overlay DetNet.
>>>>
>>>> Assume that we also designate another set of nodes as S-DetNet-PEs
>>>> for another overlay DetNet.
>>>>
>>>> Also assume that some nodes that are S-DetNet-PE in one network are
>>>> P's in the other.
>>>>
>>>> If we signal that we have have a detnet-ms-pw going through a P node
>>>> that is capable of doing elimination/replication, how do we stop the
>>>> P-node from doing that?
>>>>
>>>> This was something that the T-Lables did for us.
>>>>
>>>> /Loa
>>
>

-- 


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