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

[Lou Berger <[e-mail]>]

On 3/8/2017 7:35 AM, Loa Andersson wrote:
> 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.
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

>
> /Loa
>
> On 2017-03-08 13:46, Balázs Varga A wrote:
>> 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:[e-mail]]
>> Sent: Tuesday, March 07, 2017 8:21 PM
>> To: Balázs Varga A <[e-mail]>
>> Cc: [e-mail]
>> 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:
>>> Hi,
>>> Section 4.1 added on the GitHub.
>>> Cheers
>>> Bala'zs
>>>
>>>
>>> -----Original Message-----
>>> From: Jouni Korhonen [mailto:[e-mail]]
>>> Sent: Monday, March 06, 2017 7:23 PM
>>> To: Balázs Varga A <[e-mail]>om>; Loa Andersson
>>> <[e-mail]>
>>> Cc: [e-mail]; [e-mail]
>>> 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:[e-mail]] On Behalf
>>>> Of Loa Andersson
>>>> Sent: Monday, March 06, 2017 3:07 AM
>>>> To: Jouni Korhonen <[e-mail]>
>>>> Cc: [e-mail]; [e-mail]
>>>> 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
>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>>>>>> --
>>>>>> Loa Andersson                        email: [e-mail]
>>>> <mailto:[e-mail]>
>>>>
>>>>>> Senior MPLS Expert                          [e-mail] <mailto:[e-mail]>
>>>>>> Huawei Technologies (consultant)     phone: [phone]
>>>>> _______________________________________________
>>>>> Detnet-dp-dt mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Loa Andersson                        email: [e-mail]
>>>> <mailto:[e-mail]>
>>>>
>>>> Senior MPLS Expert                          [e-mail] <mailto:[e-mail]>
>>>>
>>>> Huawei Technologies (consultant)     phone: [phone]
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> Detnet-dp-dt mailing list
>>>>
>>>> [e-mail] <mailto:[e-mail]>
>>>>
>>>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>>>>
>> _______________________________________________
>> Detnet-dp-dt mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>>