Subject: [Detnet-dp-dt] BIER input to the draft..

From: Jouni Korhonen <[email-masked]>
Date: Wed, 10 Feb 2016 10:15:19 -0800

Greg,

Do you have an estimate for providing the first stab of the BIER text? 
I'd like to see something said about it.

- Jouni

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 15 Feb 2016 21:19:42 +0000

Hi Jouni, et. al,

attached is the proposal to DetNet in BIER. Your questions, comments appreciated. We can discuss it in more details this Wednesday.

                Regards,

                                Greg

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]]
Sent: Wednesday, February 10, 2016 10:15 AM
To: Gregory Mirsky; [email-masked]
Cc: Pascal Thubert (pthubert)
Subject: BIER input to the draft..

Greg,

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 15 Feb 2016 21:37:36 -0800

Thanks Greg,

I'll have a look at this with great interest. we'll have a chat on this 
coming Wednesday.

- Jouni

2/15/2016, 1:19 PM, Gregory Mirsky kirjoitti:
>
> Hi Jouni, et. al,
>
> attached is the proposal to DetNet in BIER. Your questions, comments 
> appreciated. We can discuss it in more details this Wednesday.
>
>                 Regards,
>
>                                 Greg
>

---

From: János Farkas <[email-masked]>
Date: Tue, 16 Feb 2016 19:02:05 +0100

Hi,

I've added some more text to the IPv6 section. Maybe that is not the 
right place for all, let's discuss that tomorrow.

I've also copied BIER to the xml. Fig. 2. did not go through completely. 
I understand that the loss is not tolerable in DetNet, but that's what 
it is for the moment.

I also have some comments, questions to some part of the document. I'm 
afraid I cannot assemble them in a written from today, maybe tomorrow; 
and we also have the call.

Regards,
Janos

On 2/16/2016 6:37 AM, Jouni Korhonen wrote:
> Thanks Greg,
>
> I'll have a look at this with great interest. we'll have a chat on 
> this coming Wednesday.
>
> - Jouni
>
> _______________________________________________
> Detnet-dp-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 16 Feb 2016 12:09:15 -0800

Janos,

Thanks for the upper layer considerations and initiating the BIER part. 
I took the upper layer template to IPv4 as well - maybe that would 
actually belong under evaluations and not as a separate section. Let's see.

- Jouni

2/16/2016, 10:02 AM, János Farkas kirjoitti:
> I've also copied BIER to the xml. Fig. 2. did not go through 
> completely. I understand that the loss is not tolerable in DetNet, but 
> that's what it is for the moment.
>

---

From: "Zhuangyan (Yan)" <[email-masked]>
Date: Wed, 17 Feb 2016 10:08:56 +0000

Hi,

I also had some initial text for the GRE section. Please see attached for further discussion.

Talk to you later.

Best Regards,

Yan

-----邮件原件-----
发件人: Detnet-dp-dt [mailto:[email-masked]] 代表 János Farkas
发送时间: 2016年2月17日 2:02
收件人: [email-masked]
主题: Re: [Detnet-dp-dt] BIER input to the draft..

Hi,

I've added some more text to the IPv6 section. Maybe that is not the right place for all, let's discuss that tomorrow.

I've also copied BIER to the xml. Fig. 2. did not go through completely. 
I understand that the loss is not tolerable in DetNet, but that's what it is for the moment.

I also have some comments, questions to some part of the document. I'm afraid I cannot assemble them in a written from today, maybe tomorrow; and we also have the call.

Regards,
Janos

---

From: János Farkas <[email-masked]>
Date: Wed, 17 Feb 2016 15:37:56 +0100

You're welcome.

I have some questions comments to the draft:

1. Introduction
“Deterministic networking (DetNet) [I-D.finn-detnet-problem-statement] 
provides …” Should we refer to the DetNet WD Charter?

I’m afraid the aspect for distinguishing two types of packet loss has 
not been captured. In my recollection, what we discussed last time is 
that we distinguish them because of the different networking tools 
applied to them. It is only just one type of packet loss seen by the 
service at the level of the service. What about replacing
“The deterministic networking Quality of Service (QoS) is expressed as 
1) the minimum and maximum end-to-end latency from sender (talker) to 
receiver (listener), 2) probability of loss of a packet as a result of 
congestion, 3) probability of loss of a packet in the event of the 
failure of a relay system or link.”
with
“Deterministic networking addresses
1) the minimum and maximum end-to-end latency from sender (talker) to 
receiver (listener),
2) probability of loss of a packet as a result of congestion,
3) probability of loss of a packet in the event of the failure of a 
relay system or link
with various networking tools in order to meet the Quality of Service 
(QoS) requirements.”

2.4. #4 Explicit routes
SDN is still missing.
Add “or an SDN approach” to “The explicit route can be seen as a form of 
source routing or a pre-reserved path e.g., using some network 
management procedure.”

2.8. #8 Class and quality of service capabilities
Replace IEEE 803.1p with IEEE 802.1Q. IEEE 802.1p has been deprecated, 
it is not possible to get it from 
http://standards.ieee.org/about/get/802/802.1.html.

3.1.2. Analysis and Discussion (on IPv6):
Explicit routes
I’ve added: “Alternatively, an SDN or a management based approach can be 
applied for explicit routes.”

Packet replication and deletion
“the replicated packets are likely to be sourced from a different IPv6 
address than the original packets” I think having different IP addresses 
is problematic, may introduce unwanted consequences, complexity. I’d 
avoid that. I’d delete this text.

“Another concern regarding packet replication is how to enforce 
replicated packets to take different route while the final destination 
still remains the same.” I agree that this needs to be solved.

“With IPv6 and using layer-3 mechanisms this cannot be done without form 
of source routing encoded into the packet, for example, in form of 
source routing extension headers.” I think it is not true. There can be 
other solutions to explicit routing, e.g. SDN. Overall, the subject of 
explicit routes is addressed in the sub-section right before this one.
Let me just brainstorm a little bit on how we are documenting our 
analysis. We have identified features ~ criteria in Section 2, e.g. #2 
Stream identification, #3 Packet sequencing, #4 Explicit routes, #5 
Packet replication and deletion. We are also looking at how to provide 
seamless redundancy (let me use this name for now). I think #2, #3, #4, 
and #5 are needed for providing seamless redundancy, hence they are 
related. Therefore, it is easy to talk about another feature as well 
when describing one particular feature out of these ones. I guess, it 
would be the best to talk about only the given feature in its 
sub-section. I think #2, #3, and #4 are quite straightforward. My 
interpretation of #5 is that it is only about the functionality 
providing the replication and the functionality providing the 
elimination. If I’m right and it is not yet clear from the draft, we 
should try to make it clearer. Correspondingly we could try to stick to 
#5 in the Packet replication and deletion sub-section as much as 
possible, which is very difficult because it is related to the others 
due to seamless redundancy. I mean to have the concerns related to a 
feature written in the corresponding sub-section and refer to that from 
the other one.

Operations and management
It would be great to add some reference(s).

Technical maturity
I’m afraid that the number of documents is not a good meter. I’d delete 
this sentence.

3.2. Native IPv4 transport
3.2.1. Solution description
“However, IPv6 was designed around the fact that extension headers are 
an integral part of the protocol and operation from the beginning, 
although the practise may some times prove differently 
[I-D.ietf-v6ops-ipv6-ehs-in-real-world].” I agree. Maybe we should have 
it in the IPv6 section.

3.2.2. Analysis and Discussion
Encapsulation and overhead
typo: IPv6 -> IPv4

3.5. PseudoWires
As the first paragraph says: PWs are "over a packet switched network 
(PSN) using IP or MPLS transport". Maybe I’ve misread it, but it seems 
to me that Section 3.5 focuses on PW over MPLS at the moment. Are we 
equally considering PW over IP? I think we should. If we go for it, then 
we probably should make it clear somehow which aspect of PW is relevant 
for MPLS and which one is for IP if they are not the same.

Regards,
Janos

On 2/16/2016 9:09 PM, Jouni Korhonen wrote:
> Janos,
>
> Thanks for the upper layer considerations and initiating the BIER 
> part. I took the upper layer template to IPv4 as well - maybe that 
> would actually belong under evaluations and not as a separate section. 
> Let's see.
>
> - Jouni
>
>> completely. I understand that the loss is not tolerable in DetNet, 
>> but that's what it is for the moment.
>>
>> I also have some comments, questions to some part of the document. 
>> I'm afraid I cannot assemble them in a written from today, maybe 
>> tomorrow; and we also have the call.
>>
>> Regards,
>> Janos
>>
>>
>>>> attached is the proposal to DetNet in BIER. Your questions, 
>>>> comments appreciated. We can discuss it in more details this 
>>>> Wednesday.
>>>>
>>>>                 Regards,
>>>>
>>>>                                 Greg
>>>>

---

From: Olivier Marce <[email-masked]>
Date: Wed, 17 Feb 2016 16:28:05 +0100

Hi everybody,

I'm still confused by  "the minimum and maximum end-to-end latency" 
expression, especially as we stated just before "with [...]known
    upper bound maximum latency" and just after that "Only the 
worst-case values for   the mentioned parameters are concerned.", so the 
maximum only.

DetNet deals with maximum (and even fixed) latency, not minimum, IMHO.

Later :

"   There are three techniques to achieve the QoS required by
    deterministic networks:"

do we mean that we need the three techniques altogether ? Or only one or 
a combination of them ? Is is to say that there 3 known/considered 
techniques ?

In "2.7. #7 Time synchronization"
If the solution could benefit from a sense of time for sure, it is not 
required to have an extension header for time into the packet.
Time synchronisation does not forcedly time stamping.

My 2 cents (only, at this stage)

-- 
Olivier Marcé
Nokia Bell Labs France

---

From: János Farkas <[email-masked]>
Date: Wed, 17 Feb 2016 16:39:08 +0100

Hi Olivier,

On 2/17/2016 4:28 PM, Olivier Marce wrote:
> worst-case values for   the mentioned parameters are concerned.", so 
> the maximum only.
>

I agree that worst case delay, i.e. max delay is very important.

In some cases the variation of the delay can be important too. The 
variation can be interpreted as the interval between the minimum and the 
maximum. In any case, the definition of variation relies on another 
metric. For instance, RFC 5481 uses the minimum as reference:
       "Packet Delay Variation, PDV, where a single reference is chosen
        from the stream based on specific criteria.  The most common
        criterion for the reference is the packet with the minimum delay
        in the sample. "

Regards,
Janos

> do we mean that we need the three techniques altogether ? Or only one 
> or a combination of them ? Is is to say that there 3 known/considered 
> techniques ?
>
>

---

From: Olivier Marce <[email-masked]>
Date: Wed, 17 Feb 2016 16:48:17 +0100

Hi Janos
Agreed. I would suggest to change to :
  1)   the maximum end-to-end latency from sender (talker) to
    receiver (listener), 2) the maximum PDV from sender (talker) to
receiver (listener)

This is the same than min/max but focuses on PDV value rather than min 
by itself.

-- 
Olivier Marcé
Nokia Bell Labs France

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 17 Feb 2016 07:51:14 -0800

Hi Janos,

See my comments inline.

> provides …” Should we refer to the DetNet WD Charter?
I would not refer to a charter.. charter is ever moving target and the 
problem statement once published is more stable as a reference.
> service at the level of the service. What about replacing
The current text has loss because of congestion and loss because of 
failure in the system/link. So I think both are covered? What you 
propose is link a 4th bullet that I cannot, afair, find in the problem 
statement/architecture documents.

> Add “or an SDN approach” to “The explicit route can be seen as a form 
> of source routing or a pre-reserved path e.g., using some network 
> management procedure.”
I am hesitant adding "SDN" here.. but agreed adding "using some network 
management procedure."
> http://standards.ieee.org/about/get/802/802.1.html.
Ok. I used .1p because then people typically know immediately what we 
refer to. Ok to change the reference, though.
> I’ve added: “Alternatively, an SDN or a management based approach can 
> be applied for explicit routes.”
Please, avoid that SDN word. Rather use similar type of expression what 
you had earlier using network management tools.
> address than the original packets” I think having different IP 
> addresses is problematic, may introduce unwanted consequences, 
> complexity. I’d avoid that. I’d delete this text.
Well, this is what is supposed to happen if an intermediate router 
duplicates a packet unless you promote spoofing, which I do not want 
this document to say. What I want to capture is issues that layer-3 
(IPv4 or IPv6) may face. I rather keep the text in.
> “With IPv6 and using layer-3 mechanisms this cannot be done without 
> form of source routing encoded into the packet, for example, in form 
> of source routing extension headers.” I think it is not true. There 
> can be other solutions to explicit routing, e.g. SDN. Overall, the 
> subject of explicit routes is addressed in the sub-section right 
> before this one.
If I have full control of the layer-2 links and can program the paths 
sure. But that is not a layer-3 and IPv6 issue. Naively looking at just 
layer-3 this is the problem you face. I want to first capture the issues 
at the layer we are working and _then_ look into other solutions that we 
can use to go around them.

> seamless redundancy (let me use this name for now). I think #2, #3, 
> #4, and #5 are needed for providing seamless redundancy, hence they 
> are related. Therefore, it is easy to talk about another feature as 
> well when describing one particular feature out of these ones. I 
> guess, it would be the best to talk about only the given feature in 
> its sub-section. I think #2, #3, and #4 are quite straightforward. My 
> should try to make it clearer. Correspondingly we could try to stick 
> to #5 in the Packet replication and deletion sub-section as much as 
> feature written in the corresponding sub-section and refer to that 
> from the other one.
Ok. I am open for proposals ;)
> I’m afraid that the number of documents is not a good meter. I’d 
> delete this sentence.
Ok.
> [I-D.ietf-v6ops-ipv6-ehs-in-real-world].” I agree. Maybe we should 
> have it in the IPv6 section.
Ok.
> Encapsulation and overhead
Ok.
> equally considering PW over IP? I think we should. If we go for it, 
> then we probably should make it clear somehow which aspect of PW is 
> relevant for MPLS and which one is for IP if they are not the same.
I have most text/emphasis around PWs over MPLS. At the end I though to 
point to IPv4 and IPv6 analysis in most part on explicit routers, 
replication etc how to do IP PSN. Most of the solutions would be the 
same and PW would then mostly be the encapsulation.

- Jouni
>> would actually belong under evaluations and not as a separate 
>> section. Let's see.
>>
>> - Jouni
>>

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 17 Feb 2016 08:15:43 -0800

Thanks! I'll put these in shortly.

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 17 Feb 2016 10:01:40 -0800

2/17/2016, 7:39 AM, János Farkas kirjoitti:
> variation can be interpreted as the interval between the minimum and 
> the maximum. In any case, the definition of variation relies on 
> another metric. For instance, RFC 5481 uses the minimum as reference:

The minimum quote originates from the text used in both detnet problem 
statement and architecture documents.

- Jouni

---

From: János Farkas <[email-masked]>
Date: Thu, 18 Feb 2016 09:31:23 +0100

Hi Jouni,

See some comments in-line.

Thanks,
Janos

On 2/17/2016 4:51 PM, Jouni Korhonen wrote:
>> “Deterministic networking (DetNet) 
>> [I-D.finn-detnet-problem-statement] provides …” Should we refer to 
>> the DetNet WD Charter?

<JF>
I'm not proposing any new bullet. I just want to make the text clear.
When it comes to the experience of a service, then there is only one
type of loss, the service cannot distinguish.
</JF>

>
>> “The deterministic networking Quality of Service (QoS) is expressed 
>> as 1) the minimum and maximum end-to-end latency from sender (talker) 
>> to receiver (listener), 2) probability of loss of a packet as a 
>> result of congestion, 3) probability of loss of a packet in the event 
>> of the failure of a relay system or link.”
>> with
> I am hesitant adding "SDN" here.. but agreed adding "using some 
> network management procedure."

<JF>
What is the problem with SDN?
It is already there in many places.
I'm happy with a different name to it.
One can for instance have PCE and use PCEP.
</JF>

>> Replace IEEE 803.1p with IEEE 802.1Q. IEEE 802.1p has been 
>> deprecated, it is not possible to get it from 
> Please, avoid that SDN word. Rather use similar type of expression 
> what you had earlier using network management tools.
>>
>> “the replicated packets are likely to be sourced from a different 
>> IPv6 address than the original packets” I think having different IP 

<JF>
I'm not promoting spoofing at all.
I'd suggest to use cleaner approaches.
I'd be happy to see your update.
</JF>

>> replicated packets to take different route while the final 
>> destination still remains the same.” I agree that this needs to be 
>> solved.
>>
> sure. But that is not a layer-3 and IPv6 issue. Naively looking at 
> just layer-3 this is the problem you face. I want to first capture the 
> issues at the layer we are working and _then_ look into other 
> solutions that we can use to go around them.
>
>> analysis. We have identified features ~ criteria in Section 2, e.g. 
>> #2 Stream identification, #3 Packet sequencing, #4 Explicit routes, 
>> #5 Packet replication and deletion. We are also looking at how to 
>> provide seamless redundancy (let me use this name for now). I think 
>> #2, #3, #4, and #5 are needed for providing seamless redundancy, 
>> hence they are related. Therefore, it is easy to talk about another 
>> feature as well when describing one particular feature out of these 
>> ones. I guess, it would be the best to talk about only the given 
>> feature in its sub-section. I think #2, #3, and #4 are quite 
>> straightforward. My interpretation of #5 is that it is only about the 
>> functionality providing the replication and the functionality 
>> providing the elimination. If I’m right and it is not yet clear from 
>> the draft, we should try to make it clearer. Correspondingly we could 
>> try to stick to #5 in the Packet replication and deletion sub-section 
>> as much as possible, which is very difficult because it is related to 
>> the others due to seamless redundancy. I mean to have the concerns 
>> related to a feature written in the corresponding sub-section and 
>> refer to that from the other one.
>> “However, IPv6 was designed around the fact that extension headers 
>> are an integral part of the protocol and operation from the 
>> beginning, although the practise may some times prove differently 
>> (PSN) using IP or MPLS transport". Maybe I’ve misread it, but it 
>> seems to me that Section 3.5 focuses on PW over MPLS at the moment. 
>> Are we equally considering PW over IP? I think we should. If we go 
>> for it, then we probably should make it clear somehow which aspect of 
>> PW is relevant for MPLS and which one is for IP if they are not the 
>> same.
>>>> I've added some more text to the IPv6 section. Maybe that is not 
>>>> the right place for all, let's discuss that tomorrow.
>>>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 18 Feb 2016 09:13:04 +0000

About the SDN point:

As long as we present concepts SDN is fine. When we go into defining which components and protocols then we need to decide if the PCE is the component of the SDN architecture that we will use. And then finally PCEP is the current protocol that PCE WG has produced but its applicability and the gaps have to be analyzed.

This takes us to the scope of this document. If it is purely the forwarding plane then we could keep the interaction with the controller at an abstract level.

Cheers

Pascal

Le 18 févr. 2016 à 09:31, János Farkas <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Jouni,

Thanks,
Janos

See my comments inline.

1. Introduction
“Deterministic networking (DetNet) [I-D.finn-detnet-problem-statement] provides …” Should we refer to the DetNet WD Charter?
I would not refer to a charter.. charter is ever moving target and the problem statement once published is more stable as a reference.

I’m afraid the aspect for distinguishing two types of packet loss has not been captured. In my recollection, what we discussed last time is that we distinguish them because of the different networking tools applied to them. It is only just one type of packet loss seen by the service at the level of the service. What about replacing
The current text has loss because of congestion and loss because of failure in the system/link. So I think both are covered? What you propose is link a 4th bullet that I cannot, afair, find in the problem statement/architecture documents.

<JF>

“The deterministic networking Quality of Service (QoS) is expressed as 1) the minimum and maximum end-to-end latency from sender (talker) to receiver (listener), 2) probability of loss of a packet as a result of congestion, 3) probability of loss of a packet in the event of the failure of a relay system or link.”
with
“Deterministic networking addresses
1) the minimum and maximum end-to-end latency from sender (talker) to receiver (listener),
2) probability of loss of a packet as a result of congestion,
3) probability of loss of a packet in the event of the failure of a relay system or link
with various networking tools in order to meet the Quality of Service (QoS) requirements.”

2.4. #4 Explicit routes
SDN is still missing.
Add “or an SDN approach” to “The explicit route can be seen as a form of source routing or a pre-reserved path e.g., using some network management procedure.”
I am hesitant adding "SDN" here.. but agreed adding "using some network management procedure."

<JF>

2.8. #8 Class and quality of service capabilities
Replace IEEE 803.1p with IEEE 802.1Q. IEEE 802.1p has been deprecated, it is not possible to get it from http://standards.ieee.org/about/get/802/802.1.html.
Ok. I used .1p because then people typically know immediately what we refer to. Ok to change the reference, though.

3.1.2. Analysis and Discussion (on IPv6):
Explicit routes
I’ve added: “Alternatively, an SDN or a management based approach can be applied for explicit routes.”
Please, avoid that SDN word. Rather use similar type of expression what you had earlier using network management tools.

Packet replication and deletion
“the replicated packets are likely to be sourced from a different IPv6 address than the original packets” I think having different IP addresses is problematic, may introduce unwanted consequences, complexity. I’d avoid that. I’d delete this text.
Well, this is what is supposed to happen if an intermediate router duplicates a packet unless you promote spoofing, which I do not want this document to say. What I want to capture is issues that layer-3 (IPv4 or IPv6) may face. I rather keep the text in.

<JF>

“Another concern regarding packet replication is how to enforce replicated packets to take different route while the final destination still remains the same.” I agree that this needs to be solved.

“With IPv6 and using layer-3 mechanisms this cannot be done without form of source routing encoded into the packet, for example, in form of source routing extension headers.” I think it is not true. There can be other solutions to explicit routing, e.g. SDN. Overall, the subject of explicit routes is addressed in the sub-section right before this one.
If I have full control of the layer-2 links and can program the paths sure. But that is not a layer-3 and IPv6 issue. Naively looking at just layer-3 this is the problem you face. I want to first capture the issues at the layer we are working and _then_ look into other solutions that we can use to go around them.

Let me just brainstorm a little bit on how we are documenting our analysis. We have identified features ~ criteria in Section 2, e.g. #2 Stream identification, #3 Packet sequencing, #4 Explicit routes, #5 Packet replication and deletion. We are also looking at how to provide seamless redundancy (let me use this name for now). I think #2, #3, #4, and #5 are needed for providing seamless redundancy, hence they are related. Therefore, it is easy to talk about another feature as well when describing one particular feature out of these ones. I guess, it would be the best to talk about only the given feature in its sub-section. I think #2, #3, and #4 are quite straightforward. My interpretation of #5 is that it is only about the functionality providing the replication and the functionality providing the elimination. If I’m right and it is not yet clear from the draft, we should try to make it clearer. Correspondingly we could try to stick to #5 in the Packet replication and deletion sub-section as much as possible, which is very difficult because it is related to the others due to seamless redundancy. I mean to have the concerns related to a feature written in the corresponding sub-section and refer to that from the other one.
Ok. I am open for proposals ;)

Technical maturity
I’m afraid that the number of documents is not a good meter. I’d delete this sentence.
Ok.

3.2. Native IPv4 transport
3.2.1. Solution description
“However, IPv6 was designed around the fact that extension headers are an integral part of the protocol and operation from the beginning, although the practise may some times prove differently [I-D.ietf-v6ops-ipv6-ehs-in-real-world].” I agree. Maybe we should have it in the IPv6 section.
Ok.

3.5. PseudoWires
As the first paragraph says: PWs are "over a packet switched network (PSN) using IP or MPLS transport". Maybe I’ve misread it, but it seems to me that Section 3.5 focuses on PW over MPLS at the moment. Are we equally considering PW over IP? I think we should. If we go for it, then we probably should make it clear somehow which aspect of PW is relevant for MPLS and which one is for IP if they are not the same.
I have most text/emphasis around PWs over MPLS. At the end I though to point to IPv4 and IPv6 analysis in most part on explicit routers, replication etc how to do IP PSN. Most of the solutions would be the same and PW would then mostly be the encapsulation.

- Jouni

Regards,
Janos

Thanks for the upper layer considerations and initiating the BIER part. I took the upper layer template to IPv4 as well - maybe that would actually belong under evaluations and not as a separate section. Let's see.

- Jouni

I've also copied BIER to the xml. Fig. 2. did not go through completely. I understand that the loss is not tolerable in DetNet, but that's what it is for the moment.

Regards,
Janos

I'll have a look at this with great interest. we'll have a chat on this coming Wednesday.

- Jouni

Hi Jouni, et. al,

                Regards,

                                Greg

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]]
Sent: Wednesday, February 10, 2016 10:15 AM
To: Gregory Mirsky; [email-masked]<mailto:[email-masked]>
Cc: Pascal Thubert (pthubert)
Subject: BIER input to the draft..

Greg,

- Jouni

_______________________________________________
Detnet-dp-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet-dp-dt

_______________________________________________
Detnet-dp-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet-dp-dt

_______________________________________________
Detnet-dp-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet-dp-dt

---

From: János Farkas <[email-masked]>
Date: Thu, 18 Feb 2016 10:16:14 +0100

Thank you Pascal.

My main concern is that remaining completely silent on SDN may be not 
the best strategy these days.

Thanks,
Janos

On 2/18/2016 10:13 AM, Pascal Thubert (pthubert) wrote:
> About the SDN point:
>
> As long as we present concepts SDN is fine. When we go into defining 
> which components and protocols then we need to decide if the PCE is 
> the component of the SDN architecture that we will use. And then 
> finally PCEP is the current protocol that PCE WG has produced but its 
> applicability and the gaps have to be analyzed.
>
> This takes us to the scope of this document. If it is purely the 
> forwarding plane then we could keep the interaction with the 
> controller at an abstract level.
>
> Cheers
>
> Pascal
>
> Le 18 févr. 2016 à 09:31, János Farkas <[email-masked] 
> <mailto:[email-masked]>> a écrit :
>
>> Hi Jouni,
>>
>>> I would not refer to a charter.. charter is ever moving target and 
>>> the problem statement once published is more stable as a reference.
>>>>
>>>> I’m afraid the aspect for distinguishing two types of packet loss 
>>>> has not been captured. In my recollection, what we discussed last 
>>>> time is that we distinguish them because of the different 
>>>> networking tools applied to them. It is only just one type of 
>>>> packet loss seen by the service at the level of the service. What 
>>>> about replacing
>>> propose is link a 4th bullet that I cannot, afair, find in the 
>>> problem statement/architecture documents.
>>
>> <JF>
>>>> as 1) the minimum and maximum end-to-end latency from sender 
>>>> (talker) to receiver (listener), 2) probability of loss of a packet 
>>>> as a result of congestion, 3) probability of loss of a packet in 
>>>> the event of the failure of a relay system or link.”
>>>> with
>>>> Add “or an SDN approach” to “The explicit route can be seen as a 
>>>> form of source routing or a pre-reserved path e.g., using some 
>>>> network management procedure.”
>>> Ok. I used .1p because then people typically know immediately what 
>>> we refer to. Ok to change the reference, though.
>>>>
>>>> form of source routing encoded into the packet, for example, in 
>>>> form of source routing extension headers.” I think it is not true. 
>>>> There can be other solutions to explicit routing, e.g. SDN. 
>>>> Overall, the subject of explicit routes is addressed in the 
>>>> sub-section right before this one.
>>> If I have full control of the layer-2 links and can program the 
>>> paths sure. But that is not a layer-3 and IPv6 issue. Naively 
>>> looking at just layer-3 this is the problem you face. I want to 
>>> first capture the issues at the layer we are working and _then_ look 
>>> into other solutions that we can use to go around them.
>>>
>>>> straightforward. My interpretation of #5 is that it is only about 
>>>> the functionality providing the replication and the functionality 
>>>> providing the elimination. If I’m right and it is not yet clear 
>>>> from the draft, we should try to make it clearer. Correspondingly 
>>>> we could try to stick to #5 in the Packet replication and deletion 
>>>> sub-section as much as possible, which is very difficult because it 
>>>> is related to the others due to seamless redundancy. I mean to have 
>>>> the concerns related to a feature written in the corresponding 
>>>> sub-section and refer to that from the other one.
>>>> As the first paragraph says: PWs are "over a packet switched 
>>>> network (PSN) using IP or MPLS transport". Maybe I’ve misread it, 
>>>> but it seems to me that Section 3.5 focuses on PW over MPLS at the 
>>>> moment. Are we equally considering PW over IP? I think we should. 
>>>> If we go for it, then we probably should make it clear somehow 
>>>> which aspect of PW is relevant for MPLS and which one is for IP if 
>>>> they are not the same.
>>> I have most text/emphasis around PWs over MPLS. At the end I though 
>>> to point to IPv4 and IPv6 analysis in most part on explicit routers, 
>>>>>> completely. I understand that the loss is not tolerable in 
>>>>>> DetNet, but that's what it is for the moment.
>>>>>>
>>>>>> I also have some comments, questions to some part of the 
>>>>>> document. I'm afraid I cannot assemble them in a written from 
>>>>>> today, maybe tomorrow; and we also have the call.
>>>>>>
>>>>>> Regards,
>>>>>> Janos
>>>>>>
>>>>>>
>> [email-masked] <mailto:[email-masked]>

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 18 Feb 2016 08:22:20 -0800

Hi Janos,

Inline..

2/18/2016, 12:31 AM, János Farkas kirjoitti:
>>> time is that we distinguish them because of the different networking 
>>> tools applied to them. It is only just one type of packet loss seen 
>>> by the service at the level of the service. What about replacing

So we are back from more explicit loss types to just "packet loss"? I am 
happy to just state plain packet loss and not elaborate any further.

>>> as a result of congestion, 3) probability of loss of a packet in the 
>>> event of the failure of a relay system or link.”
>>> with
I just don't like to term because it can be understood in so many ways. 
The current text says:
"..or a pre-reserved path e.g., using some network management 
procedure." which to me is close enough to what SDN could provide.
> I'd be happy to see your update.
Pascal & Norm also had the good point on packets appearing from 
links/boxes that are not supposed to originating such. There are also 
simple security practises widely used where packets arriving with 
"wrong" source address just get discarded (ingress filtering).

I am going to note down the approach that was used with IP mobility 
using HOA destination option, which eventually allows for sourcing 
packets with topologically correct source address while still retaining 
the original address the packet is supposed to have.

- Jouni

>> just layer-3 this is the problem you face. I want to first capture 
>> the issues at the layer we are working and _then_ look into other 
>>> the draft, we should try to make it clearer. Correspondingly we 
>>> could try to stick to #5 in the Packet replication and deletion 
>>> for it, then we probably should make it clear somehow which aspect 
>>> of PW is relevant for MPLS and which one is for IP if they are not 
>>> the same.

---

From: János Farkas <[email-masked]>
Date: Mon, 22 Feb 2016 14:15:20 +0100

Hi Jouni ,

See in-line.

>>> the problem statement once published is more stable as a reference.
<JF>
OK.
</JF>

> So we are back from more explicit loss types to just "packet loss"? I 
> am happy to just state plain packet loss and not elaborate any further.
<JF>
Maybe that's the best way.
</JF>

> I just don't like to term because it can be understood in so many 
> ways. The current text says:

<JF>
Just to make it clear, I'm not saying anything else but what we have in 
the architecture draft: 
https://tools.ietf.org/html/draft-finn-detnet-architecture-02#section-4. 
It refers to RFC 7426 Software-Defined Networking (SDN): Layers and 
Architecture Terminology. Not only the Management Plane can set-up the 
Data Plane, but the Control Plane as well.

In any case, if that is preferred, we can leave SDN out.
</JF>

> packets with topologically correct source address while still 
> retaining the original address the packet is supposed to have.
>
> - Jouni

Thanks,
Janos

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 22 Feb 2016 11:20:02 -0800

Hi Janos,

2/22/2016, 5:15 AM, János Farkas kirjoitti:
> Hi JouI’m afraid the aspect for distinguishing two types of packet 
> loss has not been captured. In my recollection, what we discussed last 
> tools applied to them. It is only just one type of packet loss seen by 
> the service at the level of the service. What about replacing

Let's start with that and then see what the extended community has to say.
>>>>> “The deterministic networking Quality of Service (QoS) is 
>>>>> expressed as 1) the minimum and maximum end-to-end latency from 
>>>>> sender (talker) to receiver (listener), 2) probability of loss of 
>>>>> a packet as a result of congestion, 3) probability of loss of a 
>>>>> packet in the event of the failure of a relay system or link.”
>>>>> with
> Just to make it clear, I'm not saying anything else but what we have 
> in the architecture draft: 
Okay. I can agree adding the reference as a starting point.

- Jouni