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

[Lou Berger <[e-mail]>]

I just added a few word into to section 6 to highlight that it applies
to v6 and mpls:


   This section applies equally to DetNet flows transported via IPv6 and
   MPLS.  While flow identification and some header related processing
   will differ between the two, the considerations covered in this
   section are common to both.

feel free to check in what ever changes you want to this. 

Also I added the following comment:

    <!-- LB: I think there needs to be more text on how PREF works with
         IPv6 flows. -->

Lou

On 6/27/2017 1:39 PM, Lou Berger wrote:
>
> 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
>>
> _______________________________________________
> Detnet-dp-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt