Re: [Detnet-dp-dt] changes to document pushed & some questions...

[Lou Berger <[e-mail]>]

On 6/27/2017 7:44 AM, Balázs Varga A wrote:
> Hi Lou,
>
> - Bidirectional: proposed change is fine with me.
okay, I'll make this and the s-label change

> - PREF and IPv6: It is not clear for me why the PREF support is considered to be different.
> From data plane perspective the PREF related chapters are formulated to be encapsulation 
> independent. The only difference is that in case of IPv6 the flow-ID does not change during 
> the transport ("src-IPv6 + Flow-label" remains unchanged), whereas it may change in case of 
> MPLS (PW-label value may change on a PREF node). But the rest is the same from data plane 
> function perspective (i.e., eliminate duplicates based on seq-num; do replication).
I didn't get this from reading the document the first time.  I'll reread
and suggest clarifications if needed.

> Have I missed something? Do You mean different control plane requirements?
No, I was thinking data plane.

Thanks,
Lou
> Cheers
> Bala'zs
>
> -----Original Message-----
> From: Detnet-dp-dt [mailto:[e-mail]] On Behalf Of Lou Berger
> Sent: 2017. június 26. 17:55
> To: Balázs Varga A <[e-mail]>; [e-mail]
> Subject: Re: [Detnet-dp-dt] changes to document pushed & some questions...
>
>
>
> On 6/26/2017 11:00 AM, Balázs Varga A wrote:
>> Hi,
>>
>>  
>>
>> I have reviewed all the changes. I am fine with almost all of them 
>> with the remarks below:
>>
>>  
>>
>> Figure4: In my view it should be the same figure as Figure 3, as 
>> DetNet End Systems are connected.
>>
>> In this case the End Systems generate IPv6 packets with included 
>> seq-num and are connected to
>>
>> Relay nodes, what results in no difference regarding the DetNet 
>> functionalities.
>>
> It's my understanding that there is major difference in PREF support in this case.
>
>> It would be a more interesting figure where IPv6 DetNet End Systems 
>> are connected
>>
>> to an MPLS based DetNet domain, but it is similar from DetNet function 
>> perspective to Figure 2.
>>
>> Let's list the possible combinations:
>>
>> - We have three End System types: (1) TSN, (2) IPv6 and (3) 
>> MPLS-capable
>>
>> - We have two PSN encapsulations: (1) IPv6 and (2) PWoMPLS
>>
>> There are six possible combinations, however they result in 2 major 
>> variants from DetNet functions
>>
>> perspective:
>>
>> (1) End System type <> PSN type (TSN + IPv6, TSN + PWoMPLS, IPv6 + 
>> PWoMPLS, MPLS-capable + IPv6)
>>
>> Edge node needed to ensure PSN specific encapsulation
>>
>> (2) End System type = PSN type  (IPv6 + IPv6, MPLS-capable + PWoMPLS)
>>
>> No need for Edge node as the encapsulation does not change.
>>
>> (Note: I think we should treat "MPLS-capable + IPv6" as an invalid 
>> combination ... )
>>
>> Figure 2 and Figure 3 are the representation of these two major 
>> variants. So do we really need Figure 4?
>>
>>  
>>
>>> 522       DetNet composite flow, perhaps even when both LSPs appear
>> on the
>>
>> 522       DetNet compound flow, perhaps even when both LSPs appear on the
>>
>>  
>>
>>> doesn't the above (sec 5.2.2.) imply the PREF with IPv6 is always
>> end-to-end, ...
>>
>> I think this needs further discussion. The intention is to make PREF 
>> independent of domain borders and
>>
>> domain encapsulations.
>>
> It would be good to describe how this works in the v6 case
>>  
>>
>>> 1033 7.4.  Bidirectional traffic
>> This chapter is very much MPLS focused, however the findings are also 
>> valid for IPv6. Should we make that
>>
>> more clear?
>>
> My objective in the first paragraph was to introduce the co-routed and associated concepts/terminology and then say how.  How about changing the last paragraph to:
>
>
>    While the IPv6 and MPLS data planes must support bidirectional DetNet flows, there
>    are no special bidirectional features with respect to the data plane
>    other than need for the two directions take the same paths.  Note,
>    that there is no stated requirement for bidirectional DetNet flows to
>    be supported using same IPv6 Flow Label or MPLS Labels in each direction.
>    Control mechanisms will need to support such bidirectional flows for both IPv6 and MPLS, but
>    such mechanisms are out of scope of this document.
>
> Lou
>
>>  
>>
>> Cheers
>>
>> Bala'zs
>>
>>  
>>
>>  
>>
>> -----Original Message-----
>> From: Detnet-dp-dt [mailto:[e-mail]] On Behalf Of 
>> Lou Berger
>> Sent: 2017. június 21. 4:25
>> To: [e-mail]
>> Subject: [Detnet-dp-dt] changes to document pushed & some questions...
>>
>>  
>>
>> All,
>>
>>  
>>
>> I made a bunch of changes based on going though the document.  Most of 
>> the comments I discussed.  I put non-discussed ones in their own 
>> commits so it would be easier to eliminate them.  Changes are as follows:
>>
>>     commit f79188034b23c80dab2985dc359176e93855376e
>>
>>                 Update txt to match change set
>>
>>     commit 01a1798e4645518bb61acf42444b17466c3b56c1
>>
>>                 Make capitalization of section headings consistent.
>>
>>                 Not saying I agree with what's there, but now it's 
>> consistent.
>>
>>     commit 27103f9af301d1a270ca7d6c9bd59a358dc9d1b0
>>
>>                 Revise CoS and QoS sections
>>
>>     commit c98c0efda04c714db22a1cea6eefb77f04d10c4b
>>
>>                 General edits:
>>
>>                     Fix some capitalization and minor nits
>>
>>                     Add intro paragraph and pointer to arch doc, and 
>> basic scope of
>>
>>                        document
>>
>>                     Add not on why not using PW over IP
>>
>>                     Add placeholder for IP native service figure (4)
>>
>>                     Start clarification on congestion protection and 
>> latency control
>>
>>                     Add some comments
>>
>>     commit 5355f195f205d944d21d8242738fab0a6a8363ba
>>
>>                 Cleanup L-label and T-label language
>>
>>     commit 78e937b1a25f07618b4b221140fc7fcfc2a43d02
>>
>>        Move Time Sync into it's own section (new 8)
>>
>>     commit 42bcb46dde2384cb4e3f76406780137086904bae
>>
>>        Use arch defined terms DetNet compound flow and DetNet member 
>> flow
>>
>>  
>>
>>  
>>
>> I also came up with following specific questions/comments, which are 
>> also captured in comments in the file:
>>
>>  
>>
>>  
>>
>> WRT the title:
>>
>>  
>>
>>     <!-- LB: doesn't "Encapsulation" better fit the scope of the 
>> current
>>
>>          document than "Solution"? -->
>>
>>     <title abbrev="DetNet Data Plane Solution">
>>
>>  
>>
>>     WRT L-Label
>>
>>     <!-- LB: why is this called L-Label, I think it'll be confused 
>> with
>>
>>          the current DiffServ L-LSPs, perhaps a using "(S)vc" would be
>>
>>          better and is aligned with Figure 12 of RFC5921  -->
>>
>>  
>>
>>   <!-- LB: unclear what the following means.  Perhaps restate or drop. 
>> -->
>>
>>   However, transit nodes may have limited capabilities to recognize 
>> DetNet
>>
>>   specific fields (e.g., in case of MPLS the PW label). Therefore, 
>> identifying each
>>
>>   individual DetNet flow on a transit node may not be achieved in some 
>> network
>>
>>   scenarios.
>>
>>  
>>
>>   in Section 5.2.1
>>
>>     <!-- possibly reference new interworking considerations section 
>> -->
>>
>>  
>>
>>   In section 5.3.2
>>
>>     <!-- LB: doesn't the above (sec 5.2.2.) imply the PREF with IPv6 
>> is
>>
>>          always end-to-end, or are you PREF domains with replication 
>> of
>>
>>          incoming packets and scoped domain elimination? I think this
>>
>>          should be explicitly discussed either way -->
>>
>>  
>>
>> I ran out of steam at the end, but this is enough -- I think...
>>
>>  
>>
>> Thanks,
>>
>> Lou
>>
>>  
>>
>> PS given that I now have contributed text to the document, I should be 
>> added as a contributor (or author) but I didn't do this as there was 
>> no contributor section...
>>
>>  
>>
>> _______________________________________________
>>
>> 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
>