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

[Lou Berger <[e-mail]>]

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
>