Subject: Re: [Detnet-dp-dt] BIER: TE or not TE? (was BIER packet duplication question)

From: Gregory Mirsky <[email-masked]>
Date: Sun, 6 Mar 2016 04:24:59 +0000

Dear All,
there's one question I've missed to bring to the discussion last Wednesday, my comment to section 2.6 Operations and management. Perhaps we should follow RFC 6291<https://tools.ietf.org/html/rfc6291> Guidelines for the Use of the "OAM" Acronym in the IETF. But Management not been defined and its interpretation is ambiguous. Can we use one of acronyms explained in the RFC? If the section, as I think, refers to Operations, Administration and Maintenance (OAM) then sections 2.7 and 2.9 on synchronization and traceability could well be requirements to OAM rather than DetNet data plane. As example of formulated OAM Requirements I can refer to the draft from BIER WG, OAM Requirements for BIER Layer<https://tools.ietf.org/html/draft-ietf-bier-oam-requirements-00>.

Appreciate your comments, shared history of section 2.6.

                Regards,
                                Greg

From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: Friday, February 26, 2016 10:21 PM
To: Lou Berger; Pascal Thubert (pthubert)
Cc: [email-masked]
Subject: Re: [Detnet-dp-dt] BIER: TE or not TE? (was BIER packet duplication question)

Hi Lou and the team,

your wish is my command.

Attached is the copy with my notes and edits (except for BIER/BIER-TE section). I think that I've two questions I need to clarify:

*         can time synchronization requirement be fulfilled by comprehensive delay measurement, active and/or passive, that characterizes a DetNet flow;

*         can packet traceroute, as well, be fulfilled by active OAM traceroute that is guaranteed to fate share with, be in-band with a DetNet flow.

Regards,

        Greg

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: Thursday, February 25, 2016 3:02 PM
To: Gregory Mirsky; Pascal Thubert (pthubert)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Detnet-dp-dt] BIER: TE or not TE? (was BIER packet duplication question)

On 2/25/2016 5:38 PM, Gregory Mirsky wrote:

> I've started reading the draft with a pencil but probably wait with

> sending my notes for another day or two

Gregg,

    It would be really good to get your comments/input on the other sections to the same level of "energy" as bier -- particularly  in some other areas where you have some good experience - e.g., in MPLS and MPLS TE....

Lou

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 6 Mar 2016 17:54:45 -0800

Greg,

Comments inline:

> On 05 Mar 2016, at 20:24, Gregory Mirsky <[email-masked]> wrote:
> 
> Dear All,
> there’s one question I’ve missed to bring to the discussion last Wednesday, my comment to section 2.6 Operations and management. Perhaps we should follow RFC 6291 Guidelines for the Use of the "OAM" Acronym in the IETF. But Management not been defined and its

Referencing RFC6291 would be good and aligning to its terminology.

> interpretation is ambiguous. Can we use one of acronyms explained in the RFC? If the section, as I think, refers to Operations, Administration and Maintenance (OAM) then sections 2.7 and 2.9 on synchronization and traceability could well be requirements to OAM rather than DetNet data plane. As example of formulated OAM Requirements I can refer to the draft from BIER WG, OAM Requirements for BIER Layer.

The are time sync stuff on two layers. The Det & Net text by Janos puts it (finally) nicely to the draft. Traceability could definitely be part of the O&M requirement, timing is not in all cases.

- Jouni

> Attached is the copy with my notes and edits (except for BIER/BIER-TE section). I think that I’ve two questions I need to clarify:
> ·         can time synchronization requirement be fulfilled by comprehensive delay measurement, active and/or passive, that characterizes a DetNet flow;
> ·         can packet traceroute, as well, be fulfilled by active OAM traceroute that is guaranteed to fate share with, be in-band with a DetNet flow.
>  
> Regards,
>         Greg
>  
> > I’ve started reading the draft with a pencil but probably wait with
> _______________________________________________
> Detnet-dp-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 7 Mar 2016 02:09:49 +0000

Hi Jouni,
I think that clock synchronization is not part of what being currently placed in Section 3 into Net layer. I prefer to look into layering and identify server, i.e. transport, and client, i.e. service. And all technologies we've listed, in my opinion, are at server layer, though provide some of functionalities required by DetNet. Clock synchronization can be provided by IEEE 1588 or SyncE. If each DetNet packet must be time-stamped, then we should list this as requirement. If intention to use time-stamp to occasionally measure latency and jitter, then, in my view, that in fact could be requirement towards OAM to support Delay measurement, as part of active and/or passive performance measurement.

	Regards,
		Greg

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Sunday, March 06, 2016 5:55 PM
To: Gregory Mirsky
Cc: Lou Berger <lberger@labn. net>; Pascal Thubert; [email-masked]
Subject: Re: [Detnet-dp-dt] BIER: TE or not TE? (was BIER packet duplication question)

Greg,

Comments inline:

> there’s one question I’ve missed to bring to the discussion last 
> Wednesday, my comment to section 2.6 Operations and management. 
> Perhaps we should follow RFC 6291 Guidelines for the Use of the "OAM" 
> Acronym in the IETF. But Management not been defined and its

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 6 Mar 2016 23:02:29 -0800

Hi,

> On 06 Mar 2016, at 18:09, Gregory Mirsky <[email-masked]> wrote:
> 
> Hi Jouni,
> I think that clock synchronization is not part of what being currently placed in Section 3 into Net layer. I prefer to look into

Probably “time synchronization” is not the proper naming to start with. On the Det layer maybe “awareness of time” would be a better description.

>  layering and identify server, i.e. transport, and client, i.e. service. And all technologies we've listed, in my opinion, are at server layer, though provide some of functionalities required by DetNet. Clock synchronization can be provided by IEEE 1588 or SyncE. If each DetNet packet must be time-stamped, then we should list this as requirement. If intention to use time-stamp to occasionally measure latency and jitter, then, in my view, that in fact could be requirement towards OAM to support Delay measurement, as part of active and/or passive performance measurement.

I am fine with O&M on the Net layer for time I still don’t see how that would be the same for Det layer. The Det layer is more application specific so a generic performance measurement may not suffice. 

- Jouni

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 7 Mar 2016 07:12:19 +0000

Hi Jouni,

my notes tagged GIM>>.

                Regards,

                                Greg

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]]
Sent: Sunday, March 06, 2016 11:02 PM
To: Gregory Mirsky
Cc: [email-masked]
Subject: Re: [Detnet-dp-dt] BIER: TE or not TE? (was BIER packet duplication question)

Hi,

> On 06 Mar 2016, at 18:09, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

> I think that clock synchronization is not part of what being currently

> placed in Section 3 into Net layer. I prefer to look into

GIM>> I think it would help if we can formulate it as requirement. My understanding is that DetNet, in general, puts certain timing constraints on a flow. Hence we may have two requirements:

·         transport paths MUST satisfy delivery time constraint;

·         transport OAM MUST support latency and jitter measurement in order to verify that the path provides required timing constraints.

GIM>> See above.

- Jouni

> Cc: Lou Berger <lberger@labn. net<mailto:lberger@labn.%20net>>; Pascal Thubert;

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

> Subject: Re: [Detnet-dp-dt] BIER: TE or not TE? (was BIER packet

> duplication question)

>> On 05 Mar 2016, at 20:24, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

>> From: Detnet-dp-dt [mailto:[email-masked]] On Behalf

>> Of Gregory Mirsky

>> Subject: Re: [Detnet-dp-dt] BIER: TE or not TE? (was BIER packet

>> duplication question)

>> Subject: Re: [Detnet-dp-dt] BIER: TE or not TE? (was BIER packet

>> duplication question)

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

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 6 Mar 2016 23:42:11 -0800

Hi Greg,

> On 06 Mar 2016, at 23:12, Gregory Mirsky <[email-masked]> wrote:
> 
> Hi Jouni,
> my notes tagged GIM>>.
>  
>                 Regards,
>                                 Greg
>  
> GIM>> I think it would help if we can formulate it as requirement. My understanding is that DetNet, in general, puts certain timing

Having that as a requirement is fine.

> constraints on a flow. Hence we may have two requirements:

The above is good and should be in our document. However, I still wondering whether it fits all cases. For example, if I need to inform my endpoints that a specific sequence number equals to a certain timestamp.. I would most likely do that at the Det layer where I already do my sequencing. Would that be part of the "transport paths MUST satisfy delivery time constraint”?

- Jouni

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 7 Mar 2016 07:45:43 +0000

Hi Jouni,
I believe that measuring latency/jitter on each and every DetNet Packet would not scale. Thus we split it to traffic engineered path provisioning and performance (latency and jitter) measurement.

	Regards,
		Greg

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Sunday, March 06, 2016 11:42 PM
To: Gregory Mirsky
Cc: [email-masked]
Subject: Re: [Detnet-dp-dt] BIER: TE or not TE? (was BIER packet duplication question)

Hi Greg,

> > I think that clock synchronization is not part of what being 
> > currently placed in Section 3 into Net layer. I prefer to look into
>  
> GIM>> I think it would help if we can formulate it as requirement. My 
> GIM>> understanding is that DetNet, in general, puts certain timing

- Jouni

> >>> I’ve started reading the draft with a pencil but probably wait 
> >>> with sending my notes for another day or two
> >> Gregg,

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 6 Mar 2016 23:57:34 -0800

Hi Greg,

No one said that kind of measurement would be on every packet. As long as it is doable will suffice. Actually, I would not even use term “measurement” here, because it does not need to have anything to do with active/passive measurements. More like stating a “fact” or something.

- Jouni

> On 06 Mar 2016, at 23:45, Gregory Mirsky <[email-masked]> wrote:
> 
> Hi Jouni,

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 7 Mar 2016 08:11:05 +0000

Hi Jouni,
then I don't see justification for both sequence number and the timestamp as requirement for DetNet packet at the same time.

	Regards,
		Greg

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Sunday, March 06, 2016 11:58 PM
To: Gregory Mirsky
Cc: [email-masked]
Subject: Re: [Detnet-dp-dt] BIER: TE or not TE? (was BIER packet duplication question)

Hi Greg,

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 7 Mar 2016 00:14:28 -0800

Hi Greg,

No one said this specific example is a requirement. We are still talking about “criteria” and things that can be done and could be useful. 

- Jouni

> On 07 Mar 2016, at 00:11, Gregory Mirsky <[email-masked]> wrote:
> 
> Hi Jouni,

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 7 Mar 2016 08:16:49 +0000

Hi Jouni,
should we summarize our findings as set of requirements towards DetNet data plane?

	Regards,
		Greg

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Monday, March 07, 2016 12:14 AM
To: Gregory Mirsky
Cc: [email-masked]
Subject: Re: [Detnet-dp-dt] BIER: TE or not TE? (was BIER packet duplication question)

Hi Greg,

- Jouni

>>> GIM>> I think it would help if we can formulate it as requirement. 
>>> GIM>> My understanding is that DetNet, in general, puts certain 
>>> GIM>> timing
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 7 Mar 2016 08:17:26 +0000

Hello Greg

It's not so much measures as recovery. It's a current requirement in industrial to traverse non deterministic switches and recover the timeliness at the egress of that segment. 

In that case the time stamp may be done at segment ingress with a predetermined latency for the segment that is more than the normal latency. The time stamp is used at egress to recover jitter.

Regards,

Pascal

> Le 7 mars 2016 à 08:45, Gregory Mirsky <[email-masked]> a écrit :
> 
> Hi Jouni,

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 7 Mar 2016 08:20:02 +0000

Hi Pascal,
thank you for setting the context. So, is it because industrial equipment does not support clock synchronization protocols, e.g. NTP, PTP or SyncE?

	Regards,
		Greg

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: Monday, March 07, 2016 12:17 AM
To: Gregory Mirsky
Cc: Jouni Korhonen; [email-masked]
Subject: Re: [Detnet-dp-dt] BIER: TE or not TE? (was BIER packet duplication question)

Hello Greg

Regards,

Pascal

>> Probably "time synchronization" is not the proper naming to start with. On the Det layer maybe "awareness of time" would be a better description.
> The above is good and should be in our document. However, I still wondering whether it fits all cases. For example, if I need to inform my endpoints that a specific sequence number equals to a certain timestamp.. I would most likely do that at the Det layer where I already do my sequencing. Would that be part of the "transport paths MUST satisfy delivery time constraint"?
> 
> - Jouni
> 
> 
>> 
>> I am fine with O&M on the Net layer for time I still don't see how that would be the same for Det layer. The Det layer is more application specific so a generic performance measurement may not suffice.
>> GIM>> See above.
>> 
>> - Jouni
>> 
>> 
>>> 
>>>            Regards,
>>>                            Greg
>>> 
>>>> there's one question I've missed to bring to the discussion last 
>>>>> I've started reading the draft with a pencil but probably wait

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 7 Mar 2016 00:25:21 -0800

Jitter removal is a good example e.g., using a “presentation time". And this is independent of whether network has clock synchronization protocols or not. Obviously the nodes interested in that timestamp must have a sense of time.

- Jouni

> On 07 Mar 2016, at 00:20, Gregory Mirsky <[email-masked]> wrote:
> 
> Hi Pascal,

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 7 Mar 2016 16:16:51 +0000

Hi Jouni,

we're considering one-way latency and jitter and for the former to be useful clocks must be well-synchronized. For the latter clock synchronization is not required. Hence are my questions:

·         how well-synchronized clocks in a DetNet domain required to be;

·         is one-way latency required metrics.

Regards,

        Greg

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]]
Sent: Monday, March 07, 2016 12:25 AM
To: Gregory Mirsky
Cc: Pascal Thubert; [email-masked]
Subject: Re: [Detnet-dp-dt] BIER: TE or not TE? (was BIER packet duplication question)

Jitter removal is a good example e.g., using a "presentation time". And this is independent of whether network has clock synchronization protocols or not. Obviously the nodes interested in that timestamp must have a sense of time.

- Jouni

> On 07 Mar 2016, at 00:20, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

> Cc: Jouni Korhonen; [email-masked]<mailto:[email-masked]>

>> Le 7 mars 2016 à 08:45, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> a écrit :

>>> On 06 Mar 2016, at 23:12, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

>>>>> From: Detnet-dp-dt [mailto:[email-masked]] On

>>>>> Behalf Of Gregory Mirsky