Re: [Detnet-dp-dt] quick notes from 1/24/17 call

[Lou Berger <[e-mail]>]

Hi Loa,

    I'm not sure if this came on the call or not. 


On 1/25/2017 10:53 PM, Loa Andersson wrote:
> Jouni,
>
> On 2017-01-26 05:56, Jouni Korhonen wrote:
>> Folks,
>>
>> Regarding the CoS point below. We should look at and follow what RFC3270 defines. I recon pipe and uniform models combined with both E-LSPs and L-LSPs is already out there and probably is enough for CoS purposes.
>>
> For QoS this is probably right.
Note Jouni said CoS -- and I agree the statement if that's what you meant.

> I'm a bit concerned on how we do bandwidth management.
>
> It looks like building the LSP virtual network, with assigned bw. Then 
> we fill the LSPs with pw's/d-pw's that has a certain be (lesser than
> the transport LSP). When the transport LSP is fully booked, we can
> either increase the bandwidth of the transport LSP or add a new fresh
> LSP.

This is certainly a possibility as layering is always a good scaling
tool.  Another option for a PW to be mapped to single LSP with bandwidth
allocation - for fine grained QoS control.

> Maybe we just should point out the possibilities and leave the rest to
> the operators?

I think it's fine for this DT to layout the dataplane (i.e., hardware)
options and identify what needs to be addressed by the
control/management/provisioning planes.  Doing less means we aren't
fulfilling our WG charter...

Thanks,
Lou

> /Loa
>
>
>
>> - Jouni
>>
>>
>> --
>> Jouni Korhonen, Broadcom Ltd.
>> M: [phone]
>>
>>> On Jan 25, 2017, at 8:44 AM, Jouni Korhonen <[e-mail]> wrote:
>>>
>>> Folks,
>>>
>>> We had a +1h call last night. Participants: Jouni, Carlos, Loa, Norm, Yuanlong, Janos and Tal.
>>>
>>> For the discussion refer to Loa’s slides sent to the DT list on 1/13/17.
>>>
>>> We seemed to have reached consensus on PWs and three label approach i.e., transport label + PW label + “detnet PW” label (d-pw in slides and this one is associated with the seqnum). The “detnet PW” label is end to end between detnet flow end points and unique within the detnet domain. This arrangement will cause 16 octet overhead (3x label + cw):
>>>
>>> +-----------------+
>>> | Transport Label | --> per each LSR; top of stack
>>> +-----------------+
>>> | PW Label        | --> per each PW (between T-PEs and/or S-PEs)
>>> +-----------------+
>>> | Detnet PW Label | --> between DetNet end points
>>> +-----------------+
>>> | CW - 28 bit sn  | --> associated with DetNet PW label
>>> +-----------------+
>>> | Payload         | --> whatever we transport
>>> +-----------------+
>>>
>>> Multiplexing: one transport label may transport PW labels, and one PW label may transport multiple “detnet PW” labels.
>>>
>>> The (virtual) network topology (LSP paths) can be programmed at the PW level. This means any detnet flow can use those without having to setup path individually for each “detnet PW”. As a consequence adding new detnet flows to system is enable i.e., when the duplicate detection and elimination function sees a new “detnet PW” label, it can instantiate new function to deal with duplicate detection and elimination - dynamically.
>>>
>>> We started the discussion on class of service and how that could be arranged in a label stack. The CoS could use the EXP bits on the transport label. However, it needs to be checked whether/how different CoS could be “propagated” through the label stack e.g., in a case where “detnet PW” labels/flows have different CoS needs. Need to check whether this is sufficient as a way forward.
>>>
>>> Need some more thinking:
>>> * CoS (see above)
>>> * Any need for timestamps (we did not discuss this, but see IETF97 presentation about RTP headers)?
>>>
>>> Next call:
>>> Tue 1/31/2017 the usual time.
>>>
>>>
>>> --
>>> Jouni Korhonen, Broadcom Ltd.
>>> M: [phone]
>>>
>> _______________________________________________
>> Detnet-dp-dt mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>>