Subject: [Detnet] L2/L3 model?

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Nov 2014 10:11:03 -0800

After the BoF I realized there was one thing we didn't talk about which 
is what combined L2 and L3 topologies that folks have in mind.
It is true that from a packet forwarding perspective both L2 and L3 have 
queues and clocks, but the interaction with the control plane and the 
approach might be different for different forms of combinations.

First of all we have 6TISCH which is an L3-only network.

But in combined L2/L3 networks we could have at least
  - interconnecting L2 islands using L3
  - arbitrary topologies with mixtures of L2 and L3 forwarding devices

A suggestion (at the mike during the BoF) was to consider pseudo-wires. 
That might make sense when interconnecting L2 islands.
But with arbitrary topologies one could end with with a path that as a 
mixture of bridges and routers e.g.

      Sender - B1 - B2 - R1 - B3 - B4 - B5 - R2 - R3 - Listener

Are there use cases that result in such topologies/paths?

Would one need one controller which is aware of both the L2 and L3 
devices and can pick paths (with resources) that include both?
(Typically we separate the layers thus we might have a PCE which sees 
the L3 topology but not the L2 devices in between the routers.)

I think it would be good to explore the combined L2/L3 use cases and 
models in more detail.

    Erik

---

From: Philippe Klein <[email-masked]>
Date: Mon, 17 Nov 2014 19:02:14 +0000

Erik,
In my humble view, the L3 must only indicate the L3 router path over of the L2 island with its path attributes  and let the L2 protocol select the constrained path.
Essentially the inner L2 topology could be ignored by the L3.

/Philippe
Broadcom

Sent from my iPhone

> On Nov 17, 2014, at 20:11, "Erik Nordmark" <[email-masked]> wrote:
> 
> 
> After the BoF I realized there was one thing we didn't talk about which is what combined L2 and L3 topologies that folks have in mind.
> It is true that from a packet forwarding perspective both L2 and L3 have queues and clocks, but the interaction with the control plane and the approach might be different for different forms of combinations.
> 
> A suggestion (at the mike during the BoF) was to consider pseudo-wires. That might make sense when interconnecting L2 islands.
> But with arbitrary topologies one could end with with a path that as a mixture of bridges and routers e.g.
> 
> Would one need one controller which is aware of both the L2 and L3 devices and can pick paths (with resources) that include both?
> (Typically we separate the layers thus we might have a PCE which sees the L3 topology but not the L2 devices in between the routers.)
> 
> I think it would be good to explore the combined L2/L3 use cases and models in more detail.
> 
>   Erik
> 
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

---

From: Pat Thaler <[email-masked]>
Date: Mon, 17 Nov 2014 19:23:00 +0000

Hi Erik,

One of the L2/L3 use cases is in industrial networks. 

In a typical industrial use case, there would be: 
Dedicated control networks (i.e. the network for machine or a group of machines with an L2 network connecting the controllers, sensors and actuators connected to
A supervisory control network (a L2 network or mixed L2 and L3 depending on the size of the plant)  by L3 forwarding devices connected to
An Enterprise network (e.g. a data center - probably multiple L3 subnets with L2 forwarding within the subnets)

The tightest timing requirements would be in the dedicated control networks, but time synchronization and some scheduled traffic would extend up the to the supervisory control network and perhaps the Enterprise network.

You might look at slides 11 and 12 of this IEEE 802 tutorial for a couple of figures relevant to this use case. 
http://www.ieee802.org/802_tutorials/2013-07/Winkel_00_0713_DMLT_SG_Tutorial_v04.pdf

The type of path in the arbitrary use case would fit here. 

If one has an L3 PCE that sees the L3 topology, it would need an accurate view of the L2 cost (i.e. latency) of the L3 hops to choose a good path and an interface to something in L2 (perhaps the L2 PCE) to create a reservation for scheduled traffic through the L2 forwarders for an L3 hop.

Regards,
Pat

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Erik Nordmark
Sent: Monday, November 17, 2014 10:11 AM
To: [email-masked]
Subject: [Detnet] L2/L3 model?

    Erik

---

From: "Anca Zamfir (ancaz)" <[email-masked]>
Date: Mon, 17 Nov 2014 19:31:59 +0000

Hi Philippe,
My understanding is that QoS (delay, jitter, b/w, etc) must be guaranteed
for the end-to-end path, whether the path spans L3 only, L2 only or a
mixture. One solution would be for PCE to get the L2 and L3 island
topologies (yes, make PCE work at L2 with SPB + extensions which is new)
and create a single heterogeneous view of the network. Once the path is
computed, PCE can determine how the different segments (could be TE LSPs
in L3 or multicast groups for L2) should be created. I think PW-s (if
used) would be carried inside these segments and it would be good to only
expose the label at the termination point (listener or the node that
eliminates the duplicates). This is to avoid having to do stitching.
There are other possibilities to explore, with some (like where L2 and L3
islands independently establish these paths) I am struggling with the
end-to-end guarantee.

thanks
-ana

On 11/17/14 8:02 PM, "Philippe Klein" <[email-masked]> wrote:

>Erik,
>In my humble view, the L3 must only indicate the L3 router path over of
>the L2 island with its path attributes  and let the L2 protocol select
>the constrained path.
>> It is true that from a packet forwarding perspective both L2 and L3
>>have queues and clocks, but the interaction with the control plane and
>>the approach might be different for different forms of combinations.
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 17 Nov 2014 20:21:00 +0000

Dear all,

I'd think that the whole idea is that the physical resources of all machines can ultimately be abstracted in terms of line rate, time, buffers and queues regardless of whether the forwarding decision happens at L2 or L3.

It would make sense to compute a path based on such terms, wouldn't it?

For Erik's initial question, there may be a need for end-to-end detnet for a 6TiSCH network federated by a backbone, not that the latency of gigE would affect anything but to avoid congestion loss in large deployments.

Cheers,

Pascal

> Le 17 nov. 2014 à 13:32, Anca Zamfir (ancaz) <[email-masked]> a écrit :
> 
> Hi Philippe,

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 17 Nov 2014 23:19:39 +0000

You mean an L3 router who needs an L2 circuit would ask for an L2 path computation element possibly in the same node to provide a service for setting up the L2 circuit between two L3 nodes?

- Jouni

> From: detnet [mailto:[email-masked]] On Behalf Of Philippe Klein
> Sent: Monday, November 17, 2014 9:02 PM
> To: Erik Nordmark
> Cc: [email-masked]
> Subject: Re: [Detnet] L2/L3 model?
> 
> Erik,
> In my humble view, the L3 must only indicate the L3 router path over of the L2
> island with its path attributes  and let the L2 protocol select the constrained
> path.
> > After the BoF I realized there was one thing we didn't talk about which is what
> combined L2 and L3 topologies that folks have in mind.
> queues and clocks, but the interaction with the control plane and the approach
> might be different for different forms of combinations.
> >
> > A suggestion (at the mike during the BoF) was to consider pseudo-wires. That
> might make sense when interconnecting L2 islands.
> > Would one need one controller which is aware of both the L2 and L3 devices
> and can pick paths (with resources) that include both?
> > (Typically we separate the layers thus we might have a PCE which sees the L3
> topology but not the L2 devices in between the routers.)
> >

---

From: Philippe Klein <[email-masked]>
Date: Tue, 18 Nov 2014 05:45:59 +0000

Yes,  
This is what I mean. Thank you Jouni for the clarification.
My point is that the L3 topology DB does not need to know all the details of the L2 topology DB but should only ask the L2 to compute an L2 path based on the L3 circuit constrains. 

/Philippe

-----Original Message-----
From: Jouni Korhonen h
Sent: Tuesday, November 18, 2014 1:20 AM
To: Philippe Klein; Erik Nordmark
Cc: [email-masked]
Subject: RE: [Detnet] L2/L3 model?

- Jouni

> In my humble view, the L3 must only indicate the L3 router path over 
> of the L2 island with its path attributes  and let the L2 protocol 
> select the constrained path.
> > have
> > But with arbitrary topologies one could end with with a path that as 
> > a mixture
> of bridges and routers e.g.
> >
> > devices
> > models
> in more detail.

---

From: Philippe Klein <[email-masked]>
Date: Tue, 18 Nov 2014 06:14:41 +0000

Ana,
Thank you for your question. 
In my humble view I am not sure we must create a single heterogeneous view of the network. It seems to me that we must keep both topology separated and  let the L3 ask the L2 to create a path with the given QoS (delay, jitter, bw...AND REDUNDACY if needed) constrains.

/Philippe

-----Original Message-----
From: Anca Zamfir (ancaz) [mailto:[email-masked]] 
Sent: Monday, November 17, 2014 9:32 PM
To: Philippe Klein; Erik Nordmark
Cc: [email-masked]
Subject: Re: [Detnet] L2/L3 model?

Hi Philippe,
My understanding is that QoS (delay, jitter, b/w, etc) must be guaranteed for the end-to-end path, whether the path spans L3 only, L2 only or a mixture. One solution would be for PCE to get the L2 and L3 island topologies (yes, make PCE work at L2 with SPB + extensions which is new) and create a single heterogeneous view of the network. Once the path is computed, PCE can determine how the different segments (could be TE LSPs in L3 or multicast groups for L2) should be created. I think PW-s (if
used) would be carried inside these segments and it would be good to only expose the label at the termination point (listener or the node that eliminates the duplicates). This is to avoid having to do stitching.
There are other possibilities to explore, with some (like where L2 and L3 islands independently establish these paths) I am struggling with the end-to-end guarantee.

thanks
-ana

On 11/17/14 8:02 PM, "Philippe Klein" <[email-masked]> wrote:

>> After the BoF I realized there was one thing we didn't talk about 
>>which is what combined L2 and L3 topologies that folks have in mind.
>>a mixture of bridges and routers e.g.
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 18 Nov 2014 06:28:11 +0000

I do not think so Philippe.

I do not see the PCE talking only to L3 devices and let the L3 devices set up a path through a UNI interface. The PCE needs to know the capabilities and topology of all the hops, so as to guarantee an optimized path.
Whether a hop is L2 or L3 is actually a secondary artifact from that perspective; and in practice, I expect that the L3 TSN switching will often be L2.5,  MPLS or TSCH.
>From the detnet and the 6TiSHC meetings, I gathered that:
- the IETF is forming a TEAS WG that would define a Yang data model for topologies. We could probably extend that.
- we could extend PCEP to configure and maintain the paths and related state info if we use the model whereby the PCE talks individually to the intermediate nodes
- OTOH, if we decide to set up the path hop-by-hop using a source-route indication computed by the PCE, then CCAMP may become useful, to be monitorind for new work just being started.

Cheers,

Pascal

> Sent: mardi 18 novembre 2014 07:15
> To: Anca Zamfir (ancaz); Erik Nordmark
> Cc: [email-masked]
> In my humble view I am not sure we must create a single heterogeneous view of
> the network. It seems to me that we must keep both topology separated and  let
> the L3 ask the L2 to create a path with the given QoS (delay, jitter, bw...AND
> REDUNDACY if needed) constrains.
> 
> /Philippe
> 
> 
> My understanding is that QoS (delay, jitter, b/w, etc) must be guaranteed for the
> end-to-end path, whether the path spans L3 only, L2 only or a mixture. One
> solution would be for PCE to get the L2 and L3 island topologies (yes, make PCE
> work at L2 with SPB + extensions which is new) and create a single
> heterogeneous view of the network. Once the path is computed, PCE can
> determine how the different segments (could be TE LSPs in L3 or multicast
> groups for L2) should be created. I think PW-s (if
> expose the label at the termination point (listener or the node that eliminates
> the duplicates). This is to avoid having to do stitching.
> There are other possibilities to explore, with some (like where L2 and L3 islands
> independently establish these paths) I am struggling with the end-to-end
> guarantee.
> 
> thanks
> -ana
>

---

From: Philippe Klein <[email-masked]>
Date: Tue, 18 Nov 2014 06:41:18 +0000

In my view the PCE will be both a L3 and L2 PCE but L3 will get services from L2 to establish a path based on the circuit constraints. They could be many L2 parameters that do not need to be exposed to L3 and and in my view this L2/L3 interface is the key but against this is my humble view and we are at the start of this discussion with wise open minds.
Trying to blend the L2/L3 in a single path computation might be very difficult. Having said that the L3 and L2 topology DB could be unified

Sent from my iPhone

> On Nov 18, 2014, at 8:28, "Pascal Thubert (pthubert)" <[email-masked]> wrote:
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 18 Nov 2014 06:51:52 +0000

Hello Philippe:

Certainly L3 uses L2 which uses L1 etc... What I hardly see is a PCE going (PCEP, say) to the L3 nodes and then the L3 nodes using some UNI interface to reserve a multihop path over a L2 island, even via L2 services.
I agree that the blend will be difficult; I'll note that there are already distributed approaches whereby specialized PCEs are responsible for dotted lines. This approach could eventually be leveraged in our case.

These are rough thoughts at the moment but I'd imagine that some physical resources are, well, just physical, not L2 or L3. 
The description and reservation of the physical resources c/should be independent of the forwarding operation.

What is L2 or L3 is a mapping of a particular frame or packet onto such resources. There is a potential for physical descriptors, and then L2 and or L3 descriptors. The key would be the unified tagging that relates them all.

Cheers,

Pascal

> From: Philippe Klein [mailto:[email-masked]]
> Sent: mardi 18 novembre 2014 07:41
> To: Pascal Thubert (pthubert)
> Cc: Anca Zamfir (ancaz); Erik Nordmark; [email-masked]
> In my view the PCE will be both a L3 and L2 PCE but L3 will get services from L2
> to establish a path based on the circuit constraints. They could be many L2
> parameters that do not need to be exposed to L3 and and in my view this L2/L3
> interface is the key but against this is my humble view and we are at the start of
> this discussion with wise open minds.
> Trying to blend the L2/L3 in a single path computation might be very difficult.
> Having said that the L3 and L2 topology DB could be unified
> 
> Sent from my iPhone
> 
> > I do not see the PCE talking only to L3 devices and let the L3 devices set up a
> path through a UNI interface. The PCE needs to know the capabilities and
> topology of all the hops, so as to guarantee an optimized path.
> > Whether a hop is L2 or L3 is actually a secondary artifact from that
> perspective; and in practice, I expect that the L3 TSN switching will often be
> L2.5,  MPLS or TSCH.
> > - the IETF is forming a TEAS WG that would define a Yang data model for
> topologies. We could probably extend that.
> > - we could extend PCEP to configure and maintain the paths and related
> > state info if we use the model whereby the PCE talks individually to
> > the intermediate nodes
> > - OTOH, if we decide to set up the path hop-by-hop using a source-route
> indication computed by the PCE, then CCAMP may become useful, to be
> monitorind for new work just being started.
> >
> > Cheers,
> >
> > Pascal
> >
> >
> >> In my humble view I am not sure we must create a single heterogeneous
> >> view of the network. It seems to me that we must keep both topology
> >> separated and  let the L3 ask the L2 to create a path with the given
> >> QoS (delay, jitter, bw...AND REDUNDACY if needed) constrains.
> >>
> >> /Philippe
> >>
> >>
> >> My understanding is that QoS (delay, jitter, b/w, etc) must be
> >> guaranteed for the end-to-end path, whether the path spans L3 only,
> >> L2 only or a mixture. One solution would be for PCE to get the L2 and
> >> L3 island topologies (yes, make PCE work at L2 with SPB + extensions
> >> which is new) and create a single heterogeneous view of the network.
> >> Once the path is computed, PCE can determine how the different
> >> segments (could be TE LSPs in L3 or multicast groups for L2) should
> >> be created. I think PW-s (if
> >> used) would be carried inside these segments and it would be good to
> >> only expose the label at the termination point (listener or the node
> >> that eliminates the duplicates). This is to avoid having to do stitching.
> >> There are other possibilities to explore, with some (like where L2
> >> and L3 islands independently establish these paths) I am struggling
> >> with the end-to-end guarantee.
> >>
> >> thanks
> >> -ana
> >>
> >>>> have queues and clocks, but the interaction with the control plane
> >>>> and the approach might be different for different forms of combinations.
> >>>>
> >>>> (Typically we separate the layers thus we might have a PCE which
> >>>> sees the L3 topology but not the L2 devices in between the
> >>>> routers.)
> >>>>

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Tue, 18 Nov 2014 15:32:20 +0000

Hello Pascal/ Anca/ Phillipe,
  Would it be fair to assume that the UNI path setup involving the first and last hop switch(es)/ router(s) and the end-hosts can be decoupled from the way NNI tunnels/ paths are setup. In other words, can the state regarding the various flows be restricted to the first-hop devices only? This could simplify the problem in my understanding. Please share your thoughts.
Thanks
Prasad

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, November 18, 2014 12:22 PM
To: Philippe Klein
Cc: Erik Nordmark; [email-masked]; Anca Zamfir (ancaz)
Subject: Re: [Detnet] L2/L3 model?

Hello Philippe:

Cheers,

Pascal

> In my view the PCE will be both a L3 and L2 PCE but L3 will get 
> services from L2 to establish a path based on the circuit constraints. 
> They could be many L2 parameters that do not need to be exposed to L3 
> and and in my view this L2/L3 interface is the key but against this is 
> my humble view and we are at the start of this discussion with wise open minds.
> > On Nov 18, 2014, at 8:28, "Pascal Thubert (pthubert)" 
> > <[email-masked]>
> wrote:
> >
> path through a UNI interface. The PCE needs to know the capabilities 
> and topology of all the hops, so as to guarantee an optimized path.
> perspective; and in practice, I expect that the L3 TSN switching will 
> often be L2.5,  MPLS or TSCH.
> > - we could extend PCEP to configure and maintain the paths and 
> > related state info if we use the model whereby the PCE talks 
> > individually to the intermediate nodes
> >> In my humble view I am not sure we must create a single 
> >> heterogeneous view of the network. It seems to me that we must keep 
> >> both topology separated and  let the L3 ask the L2 to create a path 
> >> with the given QoS (delay, jitter, bw...AND REDUNDACY if needed) constrains.
> >>
> >> /Philippe
> >>
> >>
> >> L3 island topologies (yes, make PCE work at L2 with SPB + 
> >> extensions which is new) and create a single heterogeneous view of the network.
> >> used) would be carried inside these segments and it would be good 
> >> to only expose the label at the termination point (listener or the 
> >> node that eliminates the duplicates). This is to avoid having to do stitching.
> >>> In my humble view, the L3 must only indicate the L3 router path 
> >>> over of the L2 island with its path attributes  and let the L2 
> >>> protocol select the constrained path.
> >>>> It is true that from a packet forwarding perspective both L2 and 
> >>>> L3 have queues and clocks, but the interaction with the control 
> >>>> plane and the approach might be different for different forms of combinations.
> >>>>
> >>>> Would one need one controller which is aware of both the L2 and 
> >>>> L3 devices and can pick paths (with resources) that include both?

---

From: "Anca Zamfir (ancaz)" <[email-masked]>
Date: Tue, 18 Nov 2014 17:02:34 +0000

Hi Philippe, Pascal,
The L2 and L3 islands could be separated and the path computation be
distributed across multiple PCEs, ala BRPC for multi-area TE (RFC5441).
But in a single domain this is not really needed, a single PCE could in
fact maintain the different island topologies and "connect" them for a
full view (imagine the PCE virtually talking to itself instead of multiple
PCEs talking to each other). IMO is not that difficult and not
fundamentally different. And it saves the overhead of the PCE-to-PCE
communication and more straightforward since there is no need for the
backward-recursive approach as the full topology is known. I agree that
abstracting the L2 vs L3 node and links when doing the end-to-end path
computation should be looked at. The actual device/ interface types become
relevant after, at the forwarding setup time.

thanks,
-anca

On 11/18/14 7:51 AM, "Pascal Thubert (pthubert)" <[email-masked]>
wrote:

>Hello Philippe:
>
>Certainly L3 uses L2 which uses L1 etc... What I hardly see is a PCE
>going (PCEP, say) to the L3 nodes and then the L3 nodes using some UNI
>interface to reserve a multihop path over a L2 island, even via L2
>services.
>I agree that the blend will be difficult; I'll note that there are
>already distributed approaches whereby specialized PCEs are responsible
>for dotted lines. This approach could eventually be leveraged in our case.
>
>These are rough thoughts at the moment but I'd imagine that some physical
>resources are, well, just physical, not L2 or L3.
>What is L2 or L3 is a mapping of a particular frame or packet onto such
>resources. There is a potential for physical descriptors, and then L2 and
>or L3 descriptors. The key would be the unified tagging that relates them
>all.
>
>Cheers,
>
>Pascal
>
>
>>services from L2

---

From: Philippe Klein <[email-masked]>
Date: Tue, 18 Nov 2014 17:15:31 +0000

I hope I am not of the mark with my responses but IMO we want to keep  the computation of the L2 paths of L2 islands separated from the L3 routing ones. Not every L2 bridge needs a L2 CPE. We are looking for a model where a L2 CPE could control distributed CPs (bridges with FiB only that do not compute the path).

Sent from my iPhone

> On Nov 18, 2014, at 19:02, "Anca Zamfir (ancaz)" <[email-masked]> wrote:
> 
> Hi Philippe, Pascal,

---

From: "Anca Zamfir (ancaz)" <[email-masked]>
Date: Tue, 18 Nov 2014 17:27:05 +0000

Hi Prasad,
My understanding below with [AZ].

On 11/18/14 4:32 PM, "Vengada Prasad Govindan (venggovi)"
<[email-masked]> wrote:

>  Would it be fair to assume that the UNI path setup involving the first
>and last hop switch(es)/ router(s) and the end-hosts can be decoupled
>from the way NNI tunnels/ paths are setup.

[AZ] It is not clear to me at this point if UNI signaling from the
endpoint will trigger the setup or is done by the User/App ->
Controller/PCE ->..
If that would be the case, yes..but ..

>In other words, can the state regarding the various flows be restricted
>to the first-hop devices only?

[AZ] .. what you say here is different than above (although it doesn't
contradict it). There will be per flow states on other hops. In fact,
unless some aggregation method is in place, all hops on path will maintain
per flow/stream state. But UNI (if there is one) should not care.
Whether some sort of aggregation is required and possible for the current
problem scope (wrt to time schedulers) I don't know.

thanks,
-anca

> This could simplify the problem in my understanding. Please share your
>thoughts.
>Thanks
>Prasad
>

---

From: "Shitanshu Shah (svshah)" <[email-masked]>
Date: Tue, 18 Nov 2014 20:58:49 +0000

> per flow/stream state.

##svshah, and why aggregate state not possible? Controller has enough view
of capacity required. Plus all the deterministic end-points can be trusted
with respect to traffic they are sending is in compliance with reservation
asked or alternatively can be conditioned at the first hop. Thus networks
should be able to work without per-flow state in such cases unless there
are other requirements.

Regards,
Shitanshu

> But UNI (if there is one) should not care.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Nov 2014 15:32:21 -0800

> The type of path in the arbitrary use case would fit here.

If the enterprise network and supervisory control network are both 
bridged LANs, then there might be a multi-hop L3 topology with L2 hops 
in between. However, the supervisory control network to the control 
networks might be a single L3 hop, in which case the topology would be a 
lot simpler.
> If one has an L3 PCE that sees the L3 topology, it would need an accurate view of the L2 cost (i.e. latency) of the L3 hops to choose a good path and an interface to something in L2 (perhaps the L2…
To do a good job of allocating resources, I think the L3 PCE would also 
need to have an accurate (but abstract) view of what L2 resources are 
available between different attachment points to that L2 network. I 
think there are cases where a separate L3 and L2 PCE would do suboptimal 
allocation and at high load might need backtracking (L3 PCE might think 
L2 has resources between A and B, but when asking the L2 PCE it might 
turn out that the actual L2 topology doesn't have those resources.)

I don't know if there is a way one can have an architecture which can 
support different degrees of accuracy, and start working on the design 
of the simple cases (and later add support for more L2 visibility and 
optimality across L3+L2.)

Regards,
    Erik

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Wed, 19 Nov 2014 00:15:36 +0000

Catching up on my email.

I agree most definitely that we want to explore arbitrary combinations of
L2/L3, with paths including any combination of routers and bridges.

Without going too deep into MPLS/Pseudo-wire topics, let me point out that
what the bridges need is a pair {VLAN, multicast destination MAC address}
that uniquely identifies the flow to which the Ethernet frame belongs (at
least among the packets seen by that bridge).  The bridges don’t care
whether MPLS is present in the frame or not.  So, if the routers can apply
a {VLAN, MAC address} to the packet that will be handled by a bridge, then
the routers can switch on the MPLS labels and the bridges on the Ethernet
stuff.

Note that MPLS labels can go end-to-end, or as close to the ends as you
want them to go, as is normal for MPLS; you don’t need to get rid of MPLS
when going through the bridges.

How close this gets to the Talker and Listener is another matter, and we
can talk about that in another message.

— Norm

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Wed, 19 Nov 2014 00:15:39 +0000

That would be nice to keep L2 and L3 separate, Philippe, and in some
topologies that will be possible.  But, in general, I don’t think so.

Any number of routers can connect to an L2 cloud, and in order to get
spatial diversity for the paths and avoid single points of failure, the
path computation will have to look at the physical topology, including
both bridges and routers.

I think that the the solution needs to work for absolutely any L2/L3
topology, and I think that requires that the application that is laying
out the paths be aware of the complete physical topology.  Interestingly,
in the data center, there can be multiple virtual L2/L3 topologies for
different customers all overlaid on the same physical topology.  To a
first approximation (your implementation may more or less interesting than
mine), the physical topology is all that matters.  The days when you could
easily label a box as a “router”, “bridge”, or “host” are long gone.

— Norm

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Fri, 21 Nov 2014 21:30:33 +0000

Philippe,

After speaking with you on the weekly TSN call, I think we’re mostly in
sync, now.  Testing that thought ...

  - Neither you nor I (and, I hope, no one else) is asking routers to know
their adjacent L2 networks’ topologies, or for bridges to know their
attached L3 topologies.

  - For a central controller to meet the L2/L3 problem posed in the
current problem statement draft, it would need to know both the logical
(L2/L3) topology (topologies) and the physical topology of the networks
over which it is creating paths and assigning resources.

  - Scaling this up to a network larger than a single controller can
practically serve, or across authority boundaries, is a non-trivial
problem.  We’ll have to decide whether and/or when to tackle it.

— Norm

-----Original Message-----
From: Philippe Klein <[email-masked]>
Date: Monday, November 17, 2014 at 22:41 PM
To: Pascal Thubert <[email-masked]>
Cc: Erik Nordmark <[email-masked]>, "[email-masked]" <[email-masked]>,
"Anca Zamfir (ancaz)" <[email-masked]>
Subject: Re: [Detnet] L2/L3 model?

>In my view the PCE will be both a L3 and L2 PCE but L3 will get services
>from L2 to establish a path based on the circuit constraints. They could
>be many L2 parameters that do not need to be exposed to L3 and and in my
>view this L2/L3 interface is the key but against this is my humble view
>and we are at the start of this discussion with wise open minds.
>Trying to blend the L2/L3 in a single path computation might be very
>difficult. Having said that the L3 and L2 topology DB could be unified
>
>Sent from my iPhone
>
>><[email-masked]> wrote:
>> 
>> I do not see the PCE talking only to L3 devices and let the L3 devices
>>set up a path through a UNI interface. The PCE needs to know the
>>capabilities and topology of all the hops, so as to guarantee an
>>optimized path.
>>state info if we use the model whereby the PCE talks individually to the
>>intermediate nodes
>>>view of
>>>guaranteed for the
>>>only
>>>eliminates
>>>>of
>>>>>and

---

From: Philippe Klein <[email-masked]>
Date: Sun, 23 Nov 2014 07:41:33 +0000

Thank you Norm. We are in synch and I apologize if my mail was not clear enough
/Ph

-----Original Message-----
From: Norman Finn (nfinn) [mailto:[email-masked]] 
Sent: Friday, November 21, 2014 11:31 PM
To: Philippe Klein
Cc: [email-masked]
Subject: Re: [Detnet] L2/L3 model?

Philippe,

After speaking with you on the weekly TSN call, I think we’re mostly in sync, now.  Testing that thought ...

  - Neither you nor I (and, I hope, no one else) is asking routers to know their adjacent L2 networks’ topologies, or for bridges to know their attached L3 topologies.

  - For a central controller to meet the L2/L3 problem posed in the current problem statement draft, it would need to know both the logical
(L2/L3) topology (topologies) and the physical topology of the networks over which it is creating paths and assigning resources.

  - Scaling this up to a network larger than a single controller can practically serve, or across authority boundaries, is a non-trivial problem.  We’ll have to decide whether and/or when to tackle it.

— Norm

-----Original Message-----
From: Philippe Klein <[email-masked]>
Date: Monday, November 17, 2014 at 22:41 PM
To: Pascal Thubert <[email-masked]>
Cc: Erik Nordmark <[email-masked]>, "[email-masked]" <[email-masked]>, "Anca Zamfir (ancaz)" <[email-masked]>
Subject: Re: [Detnet] L2/L3 model?

>> I do not see the PCE talking only to L3 devices and let the L3 
>>devices set up a path through a UNI interface. The PCE needs to know 
>>the capabilities and topology of all the hops, so as to guarantee an 
>>optimized path.
>> - the IETF is forming a TEAS WG that would define a Yang data model 
>>for topologies. We could probably extend that.
>> - OTOH, if we decide to set up the path hop-by-hop using a 
>>source-route indication computed by the PCE, then CCAMP may become 
>>useful, to be monitorind for new work just being started.
>> 
>> Cheers,
>> 
>> Pascal
>> 
>> 
>>>L2 only or a mixture.
>>>One
>>> solution would be for PCE to get the L2 and L3 island topologies 
>>>(yes, make PCE  work at L2 with SPB + extensions which is new) and 
>>>create a single  heterogeneous view of the network. Once the path is 
>>>computed, PCE can  determine how the different segments (could be TE 
>>>LSPs in L3 or multicast  groups for L2) should be created. I think 
>>>PW-s (if
>>>L3 islands
>>> independently establish these paths) I am struggling with the 
>>>end-to-end  guarantee.
>>> 
>>> thanks
>>> -ana
>>>

---

From: "Peter Jones (petejone)" <[email-masked]>
Date: Thu, 27 Nov 2014 01:20:53 +0000

I think that Norm's summary is concise and clear.

The internal structure of the "central controller to meet the L2/L3 problem" (unified database/computation, separated L3 and N instances of L2 database/computation) is less important right now than understanding what it needs to get done.

The scale question ("Scaling this up to a network larger than a single controller can practically serve, or across authority boundaries, is a non-trivial problem.  We’ll have to decide whether and/or when to tackle it.") I agree is challenging, but I don’t see any way of avoiding it long term. I think getting a good handle on the (somewhat simpler) case of a single controller is where to start, but I feel an "NNI" (controller to controller, AS to AS, etc)  signaling and data interface coming in the future.

Regards
Peter

_______________________________________________ 
Peter Jones             Cisco Systems 
Principal Engineer      3600 Cisco Way 
ENG Switching Software  San Jose, CA, 95134 USA 
Tel: +1 408 525 6952    Fax: +1 408 527 4698 
Email:                  petejone at cisco.com 
Twitter:                @petergjones
_______________________________________________ 

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Philippe Klein
Sent: Saturday, November 22, 2014 11:42 PM
To: Norman Finn (nfinn)
Cc: [email-masked]
Subject: Re: [Detnet] L2/L3 model?

Thank you Norm. We are in synch and I apologize if my mail was not clear enough /Ph

-----Original Message-----
From: Norman Finn (nfinn) [mailto:[email-masked]]
Sent: Friday, November 21, 2014 11:31 PM
To: Philippe Klein
Cc: [email-masked]
Subject: Re: [Detnet] L2/L3 model?

Philippe,

— Norm

---

From: Philippe Klein <[email-masked]>
Date: Thu, 27 Nov 2014 01:49:29 +0000

I do not have any issue with the L3 able to access the L2 parameters of the unified database but i still strongly believe in rightness of a clear separation of L3 and L2 model in which L2 offer L2 path establishment services to L3. (We will detail the rational in a contribution we planned as we move ahead with this effort. 
The scalability  could be addressed in my humble view in a hierarchical way similar to the autonomous and inter-autonomous model of the bridging protocols...

My two cents
/Ph

Sent from my iPhone

> On Nov 27, 2014, at 3:20, "Peter Jones (petejone)" <[email-masked]> wrote:
>

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 27 Nov 2014 02:45:12 +0000

Hi Norm,
Interesting viewpoint. Please see my comments inline:

B.R.
Frank

> From: detnet [mailto:[email-masked]] On Behalf Of Norman Finn
> (nfinn)
> Sent: Wednesday, November 19, 2014 8:16 AM
> To: Erik Nordmark; [email-masked]
> whether MPLS is present in the frame or not.  So, if the routers can apply a
> {VLAN, MAC address} to the packet that will be handled by a bridge, then the
> routers can switch on the MPLS labels and the bridges on the Ethernet stuff.	
[Frank] : I agree above analysis from aspect of data plane handling. But IMO the key points of hybrid L2/L3 network for DetNet is about resource allocation and path computation in control plane. And I think we already achieve a rough sync in the thread. 

> 
> Note that MPLS labels can go end-to-end, or as close to the ends as you want
> them to go, as is normal for MPLS; you don’t need to get rid of MPLS when
> going through the bridges.
[Frank] : I have no idea about the reason of using of MPLS label. Can you clarify me?

> 
> How close this gets to the Talker and Listener is another matter, and we can
> talk about that in another message.
> 
> — Norm
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 27 Nov 2014 08:51:39 +0000

Hello Peter:

I think that the BoF agreed on the mainlines to stay away from:
- fully distributed, INTSERV-like flows. So for this round at least we'll work with a PCE. Multiple collaborating PCE was evoked. I'm not sure if we had a firm position whether we consider the PCE-to-PCE interaction in the first round vs. have an abstract object that we call PCE and consider its external interfaces. Presentations indicated the latter, though.
- X-admin, so for the first round we'll stay within one administrative boundary. 

There was a strong push in those directions and I'd read that as a rough consensus - though I'm not judge here.

Cheers,

Pascal

> From: detnet [mailto:[email-masked]] On Behalf Of Peter Jones
> (petejone)
> Sent: jeudi 27 novembre 2014 02:21
> To: Philippe Klein; Norman Finn (nfinn)
> Cc: [email-masked]
> The internal structure of the "central controller to meet the L2/L3 problem"
> (unified database/computation, separated L3 and N instances of L2
> database/computation) is less important right now than understanding what it
> needs to get done.
> 
> The scale question ("Scaling this up to a network larger than a single controller
> can practically serve, or across authority boundaries, is a non-trivial problem.
> We’ll have to decide whether and/or when to tackle it.") I agree is challenging,
> but I don’t see any way of avoiding it long term. I think getting a good handle on
> the (somewhat simpler) case of a single controller is where to start, but I feel an
> "NNI" (controller to controller, AS to AS, etc)  signaling and data interface
> coming in the future.
> 
> Regards
> Peter
> 
>   - Neither you nor I (and, I hope, no one else) is asking routers to know their
> adjacent L2 networks’ topologies, or for bridges to know their attached L3
> topologies.
> 
>   - For a central controller to meet the L2/L3 problem posed in the current
> problem statement draft, it would need to know both the logical
> (L2/L3) topology (topologies) and the physical topology of the networks over
> which it is creating paths and assigning resources.
> 
>   - Scaling this up to a network larger than a single controller can practically
> serve, or across authority boundaries, is a non-trivial problem.  We’ll have to
> decide whether and/or when to tackle it.
> 
> — Norm
> 
> Cc: Erik Nordmark <[email-masked]>, "[email-masked]"
> <[email-masked]>, "Anca Zamfir (ancaz)" <[email-masked]>