Subject: [Detnet-dp-dt] Section 4.1 added (DP solution requirements)

From: Balázs Varga A <[email-masked]>
Date: Tue, 7 Mar 2017 18:23:27 +0000

Hi,
Section 4.1 added on the GitHub.
Cheers
Bala'zs

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Monday, March 06, 2017 7:23 PM
To: Balázs Varga A <[email-masked]>; Loa Andersson <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Detnet-dp-dt] about identity labels.. was Re: new versions of my slides

Balazs,

Your proposed Section 4.x would definitely be good to have. I am not too much for Section 4.y since I do not see it would not be needed in the final document, except for the definitions that should go to Section 2.

Regarding the two choices we have now I just add prologue text and describe (graphically both). The logic of the "identity label/tag" is mostly the same independent of the location in the stack. The processing is of course different.

- Jouni

3/6/2017, 9:49 AM, Balázs Varga A kirjoitti:
> Hi Jouni,
>
>
>
> just for clarification: Do we intend to list all options in the draft ???
>
> They all have pros and cons ...
>
>
>
> Anyway I think we need a structure like below in the draft for example
>
> in section 4. Is it inline with your intention? Shall I prepare some 
> text
>
> around this items for the call on Wednesday?
>
>
>
> *4.x DP solution requirements*
>
> List of prerequisites for a proper solution on an x-PE:
>
> 1, to distinguish PWs going through (operation label-swap) and PWs 
> need DetNet serving (e.g., FRER)
>
> 2, to handle PW-label collisions (without major implementation
> difficulties)
>
> 3, to work with both centralized control and distributed control 
> (signaling)
>
>
>
> *4.y DP solution toolset*
>
> Description of the toolset discussed so far:
>
> A, L-label: additional label between t-label and PW-label
>
> B, different PW-labels per segment: similar to the MS-PW label 
> allocation mechanism
>
> C, e2e PW label: no change of the PW-label (same PW-label value 
> between T-PE nodes)
>
> D, d-id label: additional label used as T-PE identification
>
> E, Flow-ID outside of the label stack
>
>
>
> Cheers
>
> Bala'zs
>
>
>
> -----Original Message-----
> From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of 
> Loa Andersson
> Sent: Monday, March 06, 2017 3:07 AM
> To: Jouni Korhonen <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Detnet-dp-dt] about identity labels.. was Re: new 
> versions of my slides
>
>
>
> Jouni,
>
>
>
> On 2017-03-06 07:36, Jouni Korhonen wrote:
>
>>
>
> <snip>
>
>>>
>
>>> - global as the special purpose labels, seems unlikely
>
>>> - global as unique with in the domain, though we know there is a
>
>>> scaling  problem
>
>>> - global for one sender, not that different from d-id, other that 
>>> the
>
>>> placment in the stack
>
>>>
>
>>> ???
>
>>
>
>> In my small mind I reasoned it to be unique within one domain. Since
> the identity would now be 32 bits (there is no need to restrict it to 
> 20 bits since it is part of the _encapsulation_header_ not the label 
> stack), the scaling concern is more relaxed. Assuming each node in the 
> domain would like to be able to name 4k unique detnet flows of their 
> own then the domain could host 1M such detnet nodes.. not too bad for 
> one domain.
>
>
>
> My earlier calculations estimated that we would have about the number 
> of PWs between any pair of T-DetNet-PEs would be about 400 and the 
> number T-DetNet-PEs about 1000.
>
>
>
> 32 bits is  4 000 millions, so there is ample number of flow id's even 
> if we would have to configure a range on each T-DetNet-PE.
>
>
>
> So you look at the flow-id and then compare the CW/Seq #, right?
>
>
>
> Now, range configuration is a kludge, can we find a way to avoid it, 
> maybe d-pw + node-id would work, all this would have to happen in the 
> context of the (outgoing) d-pw anyway, right?
>
>
>
> /Loa
>
>
>
>>
>
>> - Jouni
>
>>
>
>>
>
>>
>
>>
>
>>>
>
>>> /Loa
>
>>>>
>
>>>> Carlos
>
>>>>
>
>>>>> - Jouni
>
>>>>>
>
>>>>
>
>>>> _______________________________________________
>
>>>> Detnet-dp-dt mailing list
>
>>>> [email-masked] <mailto:[email-masked]>
>
>>>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>
>>>>
>
>>>
>
>>> --
>
>>>
>
>>>
>
>>> Loa Andersson                        email: [email-masked]
> <mailto:[email-masked]>
>
>>> Senior MPLS Expert                          [email-masked] <mailto:[email-masked]>
>
>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>
>>
>
>> _______________________________________________
>
>> Detnet-dp-dt mailing list
>
>> [email-masked] <mailto:[email-masked]>
>
>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>
>>
>
>
>
> --
>
>
>
>
>
> Loa Andersson                        email: [email-masked]
> <mailto:[email-masked]>
>
> Senior MPLS Expert                          [email-masked] <mailto:[email-masked]>
>
> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>
>
>
> _______________________________________________
>
> Detnet-dp-dt mailing list
>
> [email-masked] <mailto:[email-masked]>
>
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 7 Mar 2017 11:21:10 -0800

Thanks Balazs,

I am not quite sure about the local-id text:
"Local-ID MUST be unambiguously bounded to the Flow-ID encoded in the 
DetNet packet."

By default each router has their unique router id with the autonomous 
system that you need e.g., with routing protocols.

If the flow-id is unique within the detnet domain I am not sure what 
mapping the above is talking about. Do you mean that a set of flow-ids 
would belong to a router (identified by a local-id)?

- Jouni

---

From: Balázs Varga A <[email-masked]>
Date: Wed, 8 Mar 2017 05:46:14 +0000

Hi Jouni,

OK, I think my text may not be clear enough. Local-ID is not meant as a router id.
" Each node (T-PE, S-PE and P) use a local-ID of the detnet-(compound)-flow in order to accomplish its role during transport."
Local-ID refers to an ID used by a node to identify internally a DetNet-flow. Maybe "local-Flow-ID" would express it better.
Such a "local-Flow-ID" value may or may not differ from the "Flow-ID" value encoded in the DetNet packet. If it is different
we fallback to what You have called "virtual-label". 

I hope that clarifies your concerns.

Cheers
Bala'zs

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Tuesday, March 07, 2017 8:21 PM
To: Balázs Varga A <[email-masked]>
Cc: [email-masked]
Subject: Re: [Detnet-dp-dt] Section 4.1 added (DP solution requirements)

Thanks Balazs,

I am not quite sure about the local-id text:
"Local-ID MUST be unambiguously bounded to the Flow-ID encoded in the DetNet packet."

By default each router has their unique router id with the autonomous system that you need e.g., with routing protocols.

If the flow-id is unique within the detnet domain I am not sure what mapping the above is talking about. Do you mean that a set of flow-ids would belong to a router (identified by a local-id)?

- Jouni

3/7/2017, 10:23 AM, Balázs Varga A kirjoitti:
>> From: Detnet-dp-dt [mailto:[email-masked]] On Behalf 
>> Of Loa Andersson
>> stack), the scaling concern is more relaxed. Assuming each node in 
>> the domain would like to be able to name 4k unique detnet flows of 
>> their own then the domain could host 1M such detnet nodes.. not too 
>> bad for one domain.
>>
>>
>>
>> 32 bits is  4 000 millions, so there is ample number of flow id's 
>> even if we would have to configure a range on each T-DetNet-PE.
>>
>>
>>

---

From: Loa Andersson <[email-masked]>
Date: Wed, 8 Mar 2017 20:35:34 +0800

Folks,

One terminology question, I don't really have any opinion on what we
call things, but I'm definitely for that we only have one name for one
thing.

Today we use T-PE and S-PE, but also T-DetNet-PE and S-DetNet-PE, can we 
converge. My slight preference would be  T-DetNet-PE and S-DetNet-PE,
to differentiate it from "normal" S-PE and T-PE.

/Loa

On 2017-03-08 13:46, Balázs Varga A wrote:
> [email-masked]

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Lou Berger <[email-masked]>
Date: Wed, 8 Mar 2017 08:56:25 -0500

> to differentiate it from "normal" S-PE and T-PE.
The architecture defines this as:

   DetNet intermediate node
           A DetNet relay node or transit node.

And some good examples are in the DP Alternatives draft

  TSN              Edge          Transit        Relay        DetNet
  End System       Node            Node         Node         End System

  +---------+    +.........+                                 +---------+
  |  Appl.  |<---:Svc Proxy:-- End to End Service ---------->|  Appl.  |
  +---------+    +---------+                   +---------+   +---------+
  |   TSN   |    |TSN| |Svc|<-- DetNet flow ---: Service :-->| Service |
  +---------+    +---+ +---+    +---------+    +---------+   +---------+
  |Transport|    |Trp| |Trp|    |Transport|    |Trp| |Trp|   |Transport|
  +-------.-+    +-.-+ +-.-+    +--.----.-+    +-.-+ +-.-+   +---.-----+
          :  Link  :    /  ,-----.  \   :  Link  :    /  ,-----.  \
          +........+    +-[  Sub  ]-+   +........+    +-[  Sub  ]-+
                          [Network]                     [Network]
                           `-----'                       `-----'

                 Figure 1: A Simple DetNet Enabled Network

          DetNet                                           DetNet
          Service         Transit          Transit        Service
   DetNet   |          |<-Tunnel->|     |<-Tunnel->|         |    DetNet
   End      |          V     1    V     V     2    V         |    End
   System   |    +-----+          +-----+          +-----+   |    System
   +---+    |    |S-PE1|==========|S-PE2|==========|S-PE3|   |    +---+
   |  X....DFa.....X_.......DF1.......X_....DF3........X.....DFa...X  |
   |CE1|=========|  \  |          |  /  |          |  /  |========|CE2|
   |   |    |    |   \......DF2.....X_......DF4....../   |   |    |   |
   +---+         |     |==========|     |==========|     |        +---+
       ^         +-----+          +-----+          +-----+        ^
       |        Relay Node       Relay Node       Relay Node      |
       |                                                          |
       |<------------- End to End DetNet Service ---------------->|

                          Figure 5: Native DetNet

So I think what you are asking for is a shorthand for a 'S-PE that is a
DetNet (aware) Relay Node' , right?
How about one or more of the following:
    - DetNet S-PE
    - DA-S-PE (DA=DetNet Aware)
    - DC-S-PE (DA=DetNet Capable)
    - DR-S-PE (DR=DetNet Relay)
    - DRN-S-PE (DRN=DetNet Relay Node)

Lou

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 8 Mar 2017 11:47:50 -0800

Hi Balazs,

Thanks. Clear now.

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 8 Mar 2017 11:51:53 -0800

> to differentiate it from "normal" S-PE and T-PE.

Agree.

- Jouni

>> " Each node (T-PE, S-PE and P) use a local-ID of the
>> detnet-(compound)-flow in order to accomplish its role during transport."
>> Local-ID refers to an ID used by a node to identify internally a
>> DetNet-flow. Maybe "local-Flow-ID" would express it better.
>> Such a "local-Flow-ID" value may or may not differ from the "Flow-ID"
>> value encoded in the DetNet packet. If it is different
>>> Your proposed Section 4.x would definitely be good to have. I am not
>>> too much for Section 4.y since I do not see it would not be needed in
>>> the final document, except for the definitions that should go to
>>> Section 2.
>>>
>>> Regarding the two choices we have now I just add prologue text and
>>> describe (graphically both). The logic of the "identity label/tag" is
>>> mostly the same independent of the location in the stack. The
>>> processing is of course different.
>>>
>>> - Jouni
>>>
>>>>>> <mailto:[email-masked]>
>>>> <mailto:[email-masked]>

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 8 Mar 2017 12:18:56 -0800

WFM.

---

From: Lou Berger <[email-masked]>
Date: Wed, 8 Mar 2017 15:20:30 -0500

Which option do you prefer?

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 8 Mar 2017 12:42:24 -0800

Hi,

DA-S-PE (like.. das PE ;)

- Jouni

---

From: Lou Berger <[email-masked]>
Date: Wed, 8 Mar 2017 15:45:08 -0500

> DA-S-PE (like.. das PE ;)
funny - I like it!

---

From: Loa Andersson <[email-masked]>
Date: Thu, 9 Mar 2017 09:08:27 +0800

Folks,

Yes I like it too :D !

Does this mean we have a DA-T-PE also?

/Loa

--

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 9 Mar 2017 01:57:47 +0000

And  DA-T-PE, DetNet Aware T-PE;)

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Thursday, March 09, 2017 4:42 AM
To: Lou Berger; Loa Andersson; [email-masked]
Subject: Re: [Detnet-dp-dt] Section 4.1 added (DP solution requirements)

Hi,

- Jouni

3/8/2017, 12:20 PM, Lou Berger kirjoitti:
>>>> One terminology question, I don't really have any opinion on what 
>>>> we call things, but I'm definitely for that we only have one name 
>>>> for one thing.
>>>>
>>>> Today we use T-PE and S-PE, but also T-DetNet-PE and S-DetNet-PE, 
>>>> can we converge. My slight preference would be  T-DetNet-PE and 
>>>> S-DetNet-PE, to differentiate it from "normal" S-PE and T-PE.
>>> So I think what you are asking for is a shorthand for a 'S-PE that 
>>> is a DetNet (aware) Relay Node' , right?
>>>>> Such a "local-Flow-ID" value may or may not differ from the 
>>>>> "Flow-ID" value encoded in the DetNet packet. If it is different we fallback to what You have called "virtual-label".
>>>>>
>>>>>>> in section 4. Is it inline with your intention? Shall I prepare 
>>>>>>> some text
>>>>>>>
>>>>>>> 1, to distinguish PWs going through (operation label-swap) and 
>>>>>>> PWs need DetNet serving (e.g., FRER)
>>>>>>>
>>>>>>> From: Detnet-dp-dt [mailto:[email-masked]] On 
>>>>>>> Behalf Of Loa Andersson
>>>>>>>>> - global as unique with in the domain, though we know there is 
>>>>>>>>> a scaling  problem
>>>>>>>>> - global for one sender, not that different from d-id, other 
>>>>>>>>> that the placment in the stack ???
>>>>>>> 20 bits since it is part of the _encapsulation_header_ not the 
>>>>>>> label stack), the scaling concern is more relaxed. Assuming each 
>>>>>>> node in the domain would like to be able to name 4k unique 
>>>>>>> detnet flows of their own then the domain could host 1M such 
>>>>>>> detnet nodes.. not too bad for one domain.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> My earlier calculations estimated that we would have about the 
>>>>>>> number of PWs between any pair of T-DetNet-PEs would be about 
>>>>>>> 400 and the number T-DetNet-PEs about 1000.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 32 bits is  4 000 millions, so there is ample number of flow 
>>>>>>> id's even if we would have to configure a range on each T-DetNet-PE.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Now, range configuration is a kludge, can we find a way to avoid 
>>>>>>> it, maybe d-pw + node-id would work, all this would have to 
>>>>>>> happen in the context of the (outgoing) d-pw anyway, right?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> /Loa
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> - Jouni
>>>>>>>>> /Loa
>>>>>>>>>> Carlos
>>>>>>>>>>> - Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 9 Mar 2017 06:48:40 -0800

okay.. se we got the “das PE” and from local hood the “dat PE” ;-)

- JOuni

> On 08 Mar 2017, at 17:57, Jiangyuanlong <[email-masked]> wrote:
>