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

["Jouni" <[e-mail]>]

Lou,

Are you now done with your edits? I was working on the same section and dropped my stuff in a favor of yours ;) I'll still want to revisit Section 6 before statingnthe draft is ready for adoption.

- Jouni

> -----Original Message-----
> From: Detnet-dp-dt [mailto:[e-mail]] On Behalf Of Lou
> Berger
> Sent: Wednesday, June 28, 2017 00:36 AM
> To: Balázs Varga A <[e-mail]>om>; [e-mail]
> Subject: Re: [Detnet-dp-dt] changes to document pushed & some questions...
> 
> 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]>om>;
> >> [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
> 
> _______________________________________________
> Detnet-dp-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt