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

From: Lou Berger <[email-masked]>
Date: Tue, 20 Jun 2017 22:25:04 -0400

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...

---

From: Balázs Varga A <[email-masked]>
Date: Mon, 26 Jun 2017 15:00:10 +0000

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 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.

> 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?

Cheers

Bala'zs

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: 2017. június 21. 4:25
To: [email-masked]
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:

                General edits:

                       document

                    Add some comments

I also came up with following specific questions/comments, which are also captured in comments in the file:

WRT the title:

    WRT L-Label

  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

  In section 5.3.2

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

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/detnet-dp-dt

---

From: Lou Berger <[email-masked]>
Date: Mon, 26 Jun 2017 11:54:35 -0400

> Relay nodes, what results in no difference regarding the DetNet
It's my understanding that there is major difference in PREF support in
this case.

> independent of domain borders and
It would be good to describe how this works in the v6 case
> valid for IPv6. Should we make that

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

> 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:
>
> added as a contributor (or author) but I didn't do this as there was
> no contributor section...
>
>  
>
> [email-masked] <mailto:[email-masked]>
>

---

From: Balázs Varga A <[email-masked]>
Date: Tue, 27 Jun 2017 11:44:54 +0000

Hi Lou,

- Bidirectional: proposed change is fine with me.

- 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).

Have I missed something? Do You mean different control plane requirements?

Cheers
Bala'zs

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: 2017. június 26. 17:55
To: Balázs Varga A <[email-masked]>; [email-masked]
Subject: Re: [Detnet-dp-dt] changes to document pushed & some questions...

> Relay nodes, what results in no difference regarding the DetNet 
It's my understanding that there is major difference in PREF support in this case.

> valid for IPv6. Should we make that

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

[email-masked]

---

From: Lou Berger <[email-masked]>
Date: Tue, 27 Jun 2017 13:39:21 -0400

> - Bidirectional: proposed change is fine with me.
okay, I'll make this and the s-label change

> 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

---

From: Lou Berger <[email-masked]>
Date: Tue, 27 Jun 2017 17:35:39 -0400

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

---

From: "Jouni" <[email-masked]>
Date: Wed, 28 Jun 2017 01:44:53 +0300

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

> Sent: Wednesday, June 28, 2017 00:36 AM
> I just added a few word into to section 6 to highlight that it applies to
> v6 and mpls:
> 
> 
> >> 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.
> >
> associated concepts/terminology and then say how.  How about changing the
> last paragraph to:
> >>
> >>
> >>> 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
> >>> 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...
> >>>
> >>>
> >>>

---

From: Lou Berger <[email-masked]>
Date: Tue, 27 Jun 2017 18:59:48 -0400

Yes. I'm done done. Sorry...

On June 27, 2017 6:45:37 PM "Jouni" <[email-masked]> wrote:

> 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
>

---

From: "Jouni" <[email-masked]>
Date: Wed, 28 Jun 2017 02:43:47 +0300

Done my small thingies.

Lou, add yourelf as a editor.

- Jouni

> From: Lou Berger [mailto:[email-masked]]
> Sent: Wednesday, June 28, 2017 02:00 AM
> To: Jouni <[email-masked]>; 'Balázs Varga A'
> <[email-masked]>; [email-masked]
> > 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
> >> >> 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).
> >> >>>> 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, ...
> >> >>>
> >> >>    that there is no stated requirement for bidirectional DetNet
> >> >> flows
> >> to
> >> >>> 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:
> >> >>>
> >> >>> I also came up with following specific questions/comments, which
> >> >>> are also captured in comments in the file:
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> WRT the title:
> >> >>>
> >> >>>
> >> >>>
> >> >>>   <!-- LB: unclear what the following means.  Perhaps restate or
> drop.
> >> >>> -->
> >> >>>
> >> >>>     <!-- possibly reference new interworking considerations
> >> >>> section
> >> >>> -->
> >> >>>
> >> >>>
> >> >>>
> >> >>>   In section 5.3.2
> >> >>>
> >> >>> 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...
> >> >>>
> >> >>>
> >> >>>

---

From: "Jouni" <[email-masked]>
Date: Wed, 28 Jun 2017 02:47:26 +0300

Meant as a co-author ;)

> From: Jouni [mailto:[email-masked]]
> Sent: Wednesday, June 28, 2017 02:44 AM
> To: 'Lou Berger' <[email-masked]>; 'Balázs Varga A'
> Subject: RE: [Detnet-dp-dt] changes to document pushed & some questions...
> 
> Done my small thingies.
> 
> > > and dropped my stuff in a favor of yours ;) I'll still want to
> > > revisit Section
> > >>    This section applies equally to DetNet flows transported via
> > >> IPv6
> > and
> > >> >> 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
> > >> >>> (1) End System type <> PSN type (TSN + IPv6, TSN + PWoMPLS,
> > >> >>> IPv6
> > >> >>> + PWoMPLS, MPLS-capable + IPv6)
> > >> >>>
> > >> >>> This chapter is very much MPLS focused, however the findings
> > >> >>> are also valid for IPv6. Should we make that
> > >> >>>
> > >> >>> more clear?
> > >> >>>
> > >> 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
> > >> >>    be supported using same IPv6 Flow Label or MPLS Labels in
> > >> >> each
> > >> direction.
> > >> >>>                     Add placeholder for IP native service
> > >> >>> figure
> > >> >>> (4)
> > >> >>>
> > >> >>> I also came up with following specific questions/comments,
> > >> >>> which are also captured in comments in the file:
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>> WRT the title:
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>> should be added as a contributor (or author) but I didn't do
> > >> >>> this as there was no contributor section...
> > >> >>>
> > >> >>>
> > >> >>>

---

From: Lou Berger <[email-masked]>
Date: Tue, 27 Jun 2017 22:29:10 -0400

Done - also changed to STD track vs informational.  I don't have any
more planned comments to discuss or changes to make.

Lou

---

From: Loa Andersson <[email-masked]>
Date: Wed, 28 Jun 2017 10:45:58 +0200

Folks,

I reviewed and think we should post the new draft (cut-off is only a
few days out).

Jouni,

Will you do this?

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Jouni" <[email-masked]>
Date: Thu, 29 Jun 2017 09:45:03 +0300

Yeah. I'll post this.

> From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Loa
> Andersson
> Sent: Wednesday, June 28, 2017 11:46 AM
> To: [email-masked]
> I reviewed and think we should post the new draft (cut-off is only a few
> days out).
> 
> Jouni,
> 
> Will you do this?
> 
> /Loa
> 
> >>>>> 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
> >>>>>>     <!-- LB: I think there needs to be more text on how PREF
> >>>>>> works
> >>> with
> >>>>>>          IPv6 flows. -->
> >>>>>>
> >>>>>> Lou
> >>>>>>
> >>>>>>> I didn't get this from reading the document the first time.
> >>>>>>> I'll reread and suggest clarifications if needed.
> >>>>>>>
> >>>>>>>>> Figure 2 and Figure 3 are the representation of these two
> >>>>>>>>> major variants. So do we really need Figure 4?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I think this needs further discussion. The intention is to
> >>>>>>>>> make PREF independent of domain borders and
> >>>>>>>>>
> >>>>>>>>> domain encapsulations.
> >>>>>>>>>
> >>>>>>>>>     <!-- LB: doesn't the above (sec 5.2.2.) imply the PREF
> >>>>>>>>> with
> >>>>>>>>> IPv6 is
> >>>>>>>>>