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

[Lou Berger <[e-mail]>]

 Jouni,


On February 2, 2017 3:18:30 PM Jouni Korhonen <[e-mail]> 
wrote:

> Lou,
>
>> On Feb 2, 2017, at 4:43 AM, Lou Berger <[e-mail]> wrote:
>>
>> Jouni/DT
>>
>> Sounds like good progress - I have some questions /comments:
>>
>> 1 mpls labels - svc vs transport vs hop-by-hop
>>
>> I see that the mpls label is identified as a transport label that changes 
>> hop by hop.  While this is certainly a likely and perhaps initial use case, 
>> I think there are others that should be allowed for in the DetNet dp 
>> definition.  Perhaps just show it as a mpls label stack at the high level 
>> (this is what we ended up doing in the TP doc)?
>
> I think we are in sync here. The current layout is an example with the most 
> simplest label stack. I would not be surprised there are multiple labels 
> below the PW label, not just one.

Great.  This wasn't clear from the slide.

> Notation of n*4 or similar (LSE) for the lowest label would probably be better?
>

How about just using/allowing for a standard LS?

>
>> I think other likely scenarios include 0|1 mpls domain service label 
>> followed by n (>1) domain transport labels. Where the n covers (or allows 
>> for) the hop by hop case, protection cases and even SR/spring label stacks.
>>
>> Does this make any sense?
>>
>> 2 qos
>>
>> Documenting the progress on cos is certainly critical - and I don't want to 
>> detract from that. That said:
>>
>> Was there any discussion on per DetNet flow resource management /  
>> allocation, i.e. qos?  What’s your plane here?
>
> Discussion yes, decisions no. Plan is rather vague atm. The resource 
> management/allocation needs more input (I welcome it from anyone 
> participating who has a good vision of it).

Well the DP dt doesn't need to solve all of detnet:-) just state your 
assumptions that there will be "some" mechanism (control plane management 
plane or otherwise) that will provide any data path setup/allocation 
needed.  It of course would be helpful to identify what dp related 
parameters are supported/required/assumed.

> One thing came regarding per detnet flow treatment. If we need to identify 
> and treat every detnet flow individually at the transport level, we soon 
> run out of identifier space without looking higher in the label stack.
>

Or lower.  Layered qos is a fairly familiar concept in te/transport nets.

-- scaling qos is always interesting.

>> I suspect all already know my opinion, i.e., that the WG needs to cover 
>> both cases equally and in the same detnet data plane definition - At least 
>> from the DT perspective.
>
> Understood.
>

Thank you!

Lou
> - Jouni
>
>
>>
>> Thanks,
>> Lou
>>
>> On 2/1/2017 9:02 PM, Jouni Korhonen wrote:
>>
>> Present: Jouni, Loa, Norm, Balazs, Janos, Tal and David.
>>
>> See the attached slideset that was used as the basis during the call.
>> The MPLS-based PWE encaps has matured, except for: 1) fine grained CoS 
>> (i.e., 802.1 has discussed finer granularity of CoS basically to a flow 
>> level. The flow identification mechanism in .1CB, .1Qci et al allows this), 
>> and 2) PW CW SN width. We have discussed using 28 bits but that might cause 
>> issues when interworking with systems that only understand 16 bits (HSR and 
>> PRP as an examples).
>> The CoS part and whether TC bits are copied between layers is still to be 
>> discussed further.
>> IP PSN seems OK. The questions on the slides were discussed:
>> - PW labels are still good to have. It makes the stack/implementation more 
>> streamlined between MPLS and IP PSNs. Also PW labels make PW switching way 
>> easier e.g., in a case of replication/elimination.
>> - In a case of IP PSN each PW will have their own “tunnel” between 
>> T-/S-PEs. That means e.g., a PW between A and B will have different src/dst 
>> addresses than a PW between B and D. This makes pinned down paths easier to 
>> realize using IP PSN.
>>
>> Norm asks for the cases where DetNet interworks with e.g. 802.1TSN. Would 
>> there be a way to regenerate MAC addresses if those are not transported 
>> over DetNet (this is for the case where the L2 is just so bug that 
>> interconnect does not make sense). Discussion.. Jouni commented that it is 
>> not in current document’s scope. Could be worked in parallel once the 
>> encaps for DetNet DP mature a bit.
>>
>> Loa comments that EXP bits in an MPLS labels should use TC instead (Traffic 
>> Class), see RFC5462.
>>
>> Jouni commented that we now start to have enough material to produce a 
>> draft of a draft. Expect the first version next week.
>>
>> Quick discussion on 1588 PTP in DetNet. 1588 packets should not be 
>> replicated. Actually using DetNet encapsulation for them is not really a 
>> good idea. Tal will educate us more on that next time.
>>
>> Action points:
>> Tal will produce a slideset regarding his thoughts/concerns on 1588 
>> transport in DetNet.
>>
>> Next call: 2/7/17 10PM PDT
>>
>> --
>> Jouni Korhonen, Broadcom Ltd.
>> M: [phone]
>>
>> _______________________________________________
>> Detnet-dp-dt mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>>
>
>