Subject: [Detnet-dp-dt] Any thoughts on VXLAN?

From: Jouni Korhonen <[email-masked]>
Date: Tue, 12 Jan 2016 23:55:46 +0000

Folks,

Another prominent technology that could be usable is VXLAN. Has anyone thought about it in this context?

- Jouni

-- 
Jouni Korhonen, CTO Office, Networking, Broadcom Corporation
O: +1-408-922-8135,  M: +1-408-391-7160

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Wed, 13 Jan 2016 00:37:03 +0000

While I suppose the encapsulation could be repurposed to work, it doesn't have any accompanying concept of reserving bandwidth. It is built around hiding the structure the underlying network from the tenant and ensuring that the traffic of one tenant doesn't leak to another tenant, It isn't built around delivering guarantees of bandwidth or latency.

Pat

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Tuesday, January 12, 2016 3:56 PM
To: [email-masked]
Subject: [Detnet-dp-dt] Any thoughts on VXLAN?

Folks,

- Jouni

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

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 13 Jan 2016 03:59:35 +0000

That actually applies to most approaches we are looking at now... unless explicit a priori reservation for a specific flow has been done.

- Jouni

> From: Pat (Patricia) Thaler
> Sent: Tuesday, January 12, 2016 4:37 PM
> To: Jouni Korhonen; [email-masked]
> Subject: RE: Any thoughts on VXLAN?
> 
> While I suppose the encapsulation could be repurposed to work, it doesn't
> have any accompanying concept of reserving bandwidth. It is built around
> hiding the structure the underlying network from the tenant and ensuring
> that the traffic of one tenant doesn't leak to another tenant, It isn't built
> around delivering guarantees of bandwidth or latency.
> 
> Pat
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 22 Jan 2016 06:59:18 -0500

Sorry about the long latency on my response. I was thinking we could 
discuss this on the call, but the next call is a long way off.

To me the key enabler for DetNet, at the architectural level, will be 
layers control mechanisms. We will need to have parallel control (e.g. 
resource allocation/bookkeeping) and data plane (e.g. traffic/queue 
management) mechanisms that work together. I look at these as layers of 
control loops, with different response times at each layer of control, 
which need to be aligned with the data plane mechanisms that manage traffic 
at that layer.

For example, looking at purely at the IEEE  space, we can have frame 
preemption at the interface, pause / PFC at the link layer, QCN from the 
middle of the net, and SRP or equivalent at the top. In theory, although I 
don't think currently reflected in the standards, these mechanisms could be 
applied at multiple levels when you look at PBB.

>From the  DetNet data plane perspective, I think we have two separable 
problems that need to be solved:

Problem 1: what encapsulation is used for user traffic, i.e., as the 
adaption layer to a DetNet "service" domain

Problem 2: what header information is added/ used to support transport and, 
in particular,  flow identification / traffic classification, across a 
DetNet domain. Given and and service may actually be delivered over 
multiple domains, I think the ability to layer such header information will 
be important from the architectural perspective to enable aggregation of 
controlled flows.

Both problems can  be solved using the same technology or they can be 
solved with different technologies.

>From my perspective, vxLAN is a candidate solution for problem 1, but not 2 
given  its over head size.

I do think it's good to throw out different candidates for each problem and 
see what alternatives are possible, reasonable, most viable...

My 2c is that the full MPLS label tool box provides almost everything we 
need at the data plane. I include all mpls related mechanisms in this 
statement, including SR and PWs - and not that they all need to be used 
just sidered as part of the candidate overall solution.

Thoughts, reactions?

Thanks

Lou

On January 12, 2016 7:37:35 PM "Pat (Patricia) Thaler" 
<[email-masked]> wrote:

> that the traffic of one tenant doesn't leak to another tenant, It isn't 
> built around delivering guarantees of bandwidth or latency.
>
> Pat
>

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 22 Jan 2016 20:59:22 +0000

Generally agree on the assessment. I threw the question because I got asked by folks who I know to know quite a bit of switching. We do have a good preliminary sets of technologies to check already, however, that must not prohibit us having short evaluations like this one we just had when "new candidates" pop up. For me these serve as pre-thought answers for possible questions "why this or that was not considered".

- Jouni

> From: Lou Berger [mailto:[email-masked]]
> Sent: Friday, January 22, 2016 3:59 AM
> To: Pat (Patricia) Thaler; Jouni Korhonen; [email-masked]
> Subject: Re: [Detnet-dp-dt] Any thoughts on VXLAN?
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 22 Jan 2016 17:31:57 -0500

Okay.  Do you have criteria (or a lexicon) with which you'll describe
the different candidates?

Lou

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 28 Jan 2016 00:19:42 +0000

Hi Lou,

I thought to describe each candidate as a set of features and "supporting functions" they have. Basically that means considering at the following (subject to change):
o Encapsulation and overhead 
o Flow/stream identification 
o Support for sequencing (seqnums or timestamps)
o Support for (any) time/synchronization awareness 
o support for pinned down paths (can also be part of the protocol itself)
o support for packet duplication and duplicate elimination
o auxiliary management protocols

- Jouni

> Sent: Friday, January 22, 2016 2:32 PM
> To: Jouni Korhonen; Pat (Patricia) Thaler; [email-masked]
> > Generally agree on the assessment. I threw the question because I got
> asked by folks who I know to know quite a bit of switching. We do have a
> good preliminary sets of technologies to check already, however, that must
> not prohibit us having short evaluations like this one we just had when "new
> candidates" pop up. For me these serve as pre-thought answers for possible
> questions "why this or that was not considered".
> >
> >
> > - Jouni
> >
> >
> >>> From: Detnet-dp-dt [mailto:[email-masked]] On Behalf
> Of
> >>> Jouni Korhonen
> >>> Another prominent technology that could be usable is VXLAN. Has
> anyone
> >>> thought about it in this context?
> >>>
> >>> - Jouni
> >>>
> >>> --

---

From: Lou Berger <[email-masked]>
Date: Wed, 27 Jan 2016 20:08:06 -0500

Thanks Jouni.  A nice list. 

- How does CoS/QoS capabilities and other congestion control mechanisms
(eg.g., ECN/QCN) fit in?
- isn't 'pinned paths' more of control plane issue than encap?

Thanks,
Lou

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 28 Jan 2016 07:08:26 +0000

Hello Jouni:

We could add:

- portability (e.g. works over MPLS and IPv6)
- debugability (capability to identify which copy by which replicator)
- manageability (in particular identify losses)
- Time stamp AND sequence as opposed to OR (the time stamp is useful to recover the timing across non deterministic hops)

Cheers,

Pascal

> From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Lou
> Berger
> Sent: jeudi 28 janvier 2016 02:08
> To: [email-masked]
> Cc: Jouni Korhonen <[email-masked]>
> > I thought to describe each candidate as a set of features and "supporting
> functions" they have. Basically that means considering at the following
> (subject to change):
> > o Support for sequencing (seqnums or timestamps) o Support for (any)
> > time/synchronization awareness o support for pinned down paths (can
> > also be part of the protocol itself) o support for packet duplication
> > and duplicate elimination o auxiliary management protocols
> >
> > - Jouni
> >
> >> asked by folks who I know to know quite a bit of switching. We do
> >> have a good preliminary sets of technologies to check already,
> >> however, that must not prohibit us having short evaluations like this
> >> one we just had when "new candidates" pop up. For me these serve as
> >> pre-thought answers for possible questions "why this or that was not
> considered".
> >>>
> >>> - Jouni
> >>>
> >>>
> >>>> Sorry about the long latency on my response. I was thinking we
> >>>> could discuss this on the call, but the next call is a long way off.
> >>>>
> >>>> To me the key enabler for DetNet, at the architectural level, will
> >>>> be layers control mechanisms. We will need to have parallel control
> (e.g.
> >>>> management) mechanisms that work together. I look at these as
> >>>> layers of control loops, with different response times at each
> >>>> layer of control, which need to be aligned with the data plane
> >>>> mechanisms that manage traffic at that layer.
> >>>>
> >>>> For example, looking at purely at the IEEE  space, we can have
> >>>> frame preemption at the interface, pause / PFC at the link layer,
> >>>> QCN from the middle of the net, and SRP or equivalent at the top.
> >>>> In theory, although I don't think currently reflected in the
> >>>> standards, these mechanisms could
> >> be
> >>>> From the  DetNet data plane perspective, I think we have two
> >>>> separable problems that need to be solved:
> >>>>
> >>>> Problem 1: what encapsulation is used for user traffic, i.e., as
> >>>> the adaption layer to a DetNet "service" domain
> >>>>
> >>>> Problem 2: what header information is added/ used to support
> >>>> transport and, in particular,  flow identification / traffic
> >>>> classification, across a DetNet domain. Given and and service may
> >>>> actually be delivered over multiple domains, I think the ability to
> >>>> layer such header information will be important from the
> >>>> architectural perspective to enable aggregation of controlled
> >>>> flows.
> >>>>
> >>>> Both problems can  be solved using the same technology or they can
> >>>> be solved with different technologies.
> >>>>
> >>>> From my perspective, vxLAN is a candidate solution for problem 1,
> >>>> but not
> >> 2
> >>>> I do think it's good to throw out different candidates for each
> >>>> problem
> >> and
> >>>> My 2c is that the full MPLS label tool box provides almost
> >>>> everything we need at the data plane. I include all mpls related
> >>>> mechanisms in this statement, including SR and PWs - and not that
> >>>> they all need to be used just sidered as part of the candidate overall
> solution.
> >>>>
> >>>> Thoughts, reactions?
> >>>>
> >>>> Thanks
> >>>>
> >>>> Lou
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> that the traffic of one tenant doesn't leak to another tenant, It
> >>>>> isn't built around delivering guarantees of bandwidth or latency.
> >>>>>
> >>>>> Pat
> >>>>>

---

From: Lou Berger <[email-masked]>
Date: Thu, 28 Jan 2016 06:02:39 -0500

Hi Pascal,

Nice additions.  I have some suggested tweaks below:

> - portability (e.g. works over MPLS and IPv6)

How about: support for v4 and v6 user traffic.

> - debugability (capability to identify which copy by which replicator)

Can you elaborate on this?  I'm not sure what function this describes.

> - manageability (in particular identify losses)
Support for loss detection and measurement

> - Time stamp AND sequence as opposed to OR (the time stamp is useful to 
> recover the timing across non deterministic hops)
>

Operation across  non deterministic hops.

Lou

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 28 Jan 2016 12:30:00 +0000

Hello Lou:

I'm happy with your proposed naming.

The point about debugability is that if a certain copy of a packet is found in the middle of the network at the wrong time of the wrong place, then it would be neat to find if that packet is a replication, which node performed that replication (the most recent one, and somehow that replicator is a secondary source of the packet), and what the intent of that replication was (e.. the copy towards successor A or the copy towards successor B).

Maybe tracability is another name for what I'm talking about here?

Cheers,

Pascal

________________________________________
De : Lou Berger <[email-masked]>
Envoyé : jeudi 28 janvier 2016 06:02
À : Pascal Thubert (pthubert); [email-masked]
Cc : Jouni Korhonen
Objet : RE: [Detnet-dp-dt] Any thoughts on VXLAN?

Hi Pascal,

Lou

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 28 Jan 2016 17:41:30 +0000

Lou,

Good to remind about QoS/CoS - forgot to add that originally.

Regarding pinned paths that can be IMHO done in several ways: control plane is one but then some solution approaches folks have shown interest encode _loose_ path into the packet header (SR for example). This is what I intended to capture.

- Jouni

> Sent: Wednesday, January 27, 2016 5:08 PM
> Cc: Jouni Korhonen
> >>>> don't think currently reflected in the standards, these mechanisms
> could
> >> be
> transport
> >>>> and,
> >>>> From my perspective, vxLAN is a candidate solution for problem 1, but
> not
> >> 2

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 28 Jan 2016 17:51:22 +0000

Pascal,

> From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of
> Pascal Thubert (pthubert)
> Sent: Wednesday, January 27, 2016 11:08 PM
> To: Lou Berger; [email-masked]
> Cc: Jouni Korhonen
 
[JiK:] Ok.
> - debugability (capability to identify which copy by which replicator)

[JiK:] Ok. This is a good thing. 

> - manageability (in particular identify losses)
 
[JiK:] Ok.. we could lump that as a part of sequencing.
> recover the timing across non deterministic hops)

[JiK:] Sure. Or rather AND/OR.. as it depends.

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 28 Jan 2016 17:52:52 +0000

I'll update all these criteria into the draft template.

- Jouni

> From: Pascal Thubert (pthubert) [mailto:[email-masked]]
> Sent: Thursday, January 28, 2016 4:30 AM
> Subject: RE: [Detnet-dp-dt] Any thoughts on VXLAN?
> 
> Hello Lou:
> 
> The point about debugability is that if a certain copy of a packet is found in
> the middle of the network at the wrong time of the wrong place, then it
> would be neat to find if that packet is a replication, which node performed
> that replication (the most recent one, and somehow that replicator is a
> secondary source of the packet), and what the intent of that replication was
> (e.. the copy towards successor A or the copy towards successor B).
> 
> Of Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 28 Jan 2016 12:54:21 -0500

> Regarding pinned paths that can be IMHO done in several ways: control plane is one but then some solution approaches folks have shown interest encode _loose_ path into the packet header (SR for exa…
ahh, that's valid and a good addition!

Lou

---

From: János Farkas <[email-masked]>
Date: Fri, 29 Jan 2016 12:36:38 +0100

Hi,

Yes, I agree that we should consider Segment Routing, which involves 
data plane. I also see value in loose hops.

I'd suggest to use "explicit" instead of "pinned down". "Explicit route" 
is a well known term, which already involves loose hop. People may 
wonder why "pinned down" ("nailed down") instead of "explicit", what is 
the difference? Furthermore, the new term may resemble "fully nailed 
down path", which does not allow loose hop. Using "pinned down", we have 
to explain that it includes loose hop. I think it is pretty 
straightforward for "explicit route".

Regards,
Janos

ps: Should we change subject? It is not VxLAN any more, but a good 
discussion on criteria.

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 29 Jan 2016 16:28:08 +0000

Agree with the "explicit route" terminology. 

- Jouni

> János Farkas
> Sent: Friday, January 29, 2016 3:37 AM
> To: [email-masked]; Jouni Korhonen
> Cc: [email-masked]
> >> Regarding pinned paths that can be IMHO done in several ways: control
> plane is one but then some solution approaches folks have shown interest
> encode _loose_ path into the packet header (SR for example). This is what I
> intended to capture.
> have a
> >>>>> not prohibit us having short evaluations like this one we just had
> when
> >>> "new
> layers
> >>> of
> >>>>>>> which need to be aligned with the data plane mechanisms that
> manage
> >>>>>>> traffic
> >>>>>>> at that layer.
> >>>>>>>
> frame
> >>>>>>> preemption at the interface, pause / PFC at the link layer, QCN
> from
> >>> the
> >>>>>>> middle of the net, and SRP or equivalent at the top. In theory,
> although
> >>> I
> >>>>>>> multiple domains, I think the ability to layer such header
> information
> >>> will
> >>>>>>> be important from the architectural perspective to enable
> aggregation
> >>> of
> >>>>>>> controlled flows.
> >>>>>>>
> but
> everything we
> >>>>>>>> While I suppose the encapsulation could be repurposed to work,
> it
> >>>>> doesn't
> isn't