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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 3 Mar 2016 11:54:47 +0000

As agreed yesterday at the call I made a pass on this:

J> I've added: "Alternatively, an SDN or a management based approach can be  applied for explicit routes."

P> OK, then. I have added more text. Segment Routing is not an alternative but an implementation of the SDN data plane. I added:

   Explicit routes (W)

      The general assumption is that a Software-Defined Networking (SDN)
      [RFC7426] based approach is applied to compute, establish and
      manage the explicit routes, leveraging Traffic Engineering (TE)
      extensions to routing protocols [RFC5305] [I-D.ietf-idr-ls-
      distribution] and evolutions to the Path Computation Element (PCE)
      Architecture [RFC5440], though a number of issues remain to be
      solved [RFC7399].

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

P> But the source address is also a way to trace the replication point. We may decide to encapsulate IP in IP for instance and that would work. The major point is that we do not want to lose the original source, so I also disagree with that text as it is and agree to remove it.
I think this section should focus on replication and elimination per its title. I made updates

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

P> Added stuff:

      Another concern regarding packet replication is how to enforce
      replicated packets to take different route while the final
      destination still remains the same.  With strict source routing,
      all the intermediate hops are listed and paths can be guaranteed
      to be non-overlapping.  Loose source routing only signals some of
      the intermediate hops and it takes additional knowledge to ensure
      that there is no single point of failure.

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

P> SDN still need a signaling in the data plane and with IPv6 that would be SR. Do I miss something?

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

P> I made a Pass, if you could review the reorg?

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

P> Unsure which? BFD?

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

P> I added the below instead:

      The Cisco 6Lab site [sixlab] provides information on IPv6
      deployment per country, indicating figures for prefixes, transit
      AS, content and users.  Per this site, many countries, including
      Canada, Brazil, the USA, Germany, France, Japan, Portugal, Sweden,
      Finland, Norway, Greece, and Ecuador, achieve a deployment ratio
      above 30 percent, and the overall adoption reported by Google
      Statistics [googleipv6] is now above 10 percent.

Cheers,

Pascal

From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of János Farkas
Sent: jeudi 18 février 2016 09:31
To: Jouni Korhonen <[email-masked]>; [email-masked]
Subject: Re: [Detnet-dp-dt] BIER input to the draft..

Hi Jouni,

See some comments in-line.

Thanks,
Janos

On 2/17/2016 4:51 PM, Jouni Korhonen wrote:
Hi Janos,

See my comments inline.

2/17/2016, 6:37 AM, János Farkas kirjoitti:

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

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>
I'm not promoting spoofing at all.
I'd suggest to use cleaner approaches.
I'd be happy to see your update.
</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 ;)

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.
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.2.2. Analysis and Discussion
Encapsulation and overhead
typo: IPv6 -> IPv4
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

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

2/16/2016, 10:02 AM, János Farkas kirjoitti:

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

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

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

Do you have an estimate for providing the first stab of the BIER text?

I'd like to see something said about it.

- 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