Re: [Detnet] L2/L3 model?

Frank,

I was absent from email for quite a while.  My apologies.

The reason for the MPLS label:

To ensure 0 congestion loss, you have to identify to which specific flow a
packet belongs, so you can assign it to the proper set of resources
(buffers, bandwidth).  In many networks, you can do this with deep packet
inspection, e.g. Looking at the UDP port numbers. In those networks, MPLS
is not needed.

In other networks, you need to export the Flow Identifier to the outside
of the packet in order to assign resources.  There are several reasons you
would need to do this, e.g.: a) Mixed critical data and normal data
requires the critical data be encrypted for sefety, and the encryption
obscures the inner addresses; b) Really simple chips can’t look too far
inside the packets; c) the Flow ID is buried in a transport protocol
unknown to the the forwarding chips; d) you want to aggregate multiple
flows into a single flow in order to scale up to handle a large number of
flows.

In these cases, MPLS would be useful.  This is why the original AVB
specifications said that each L2 critical flow must use its own unique
{VLAN ID, multicast MAC destination address} pair — so that the bridges
can easily identify a specific flow.  There are many choices of
encapsulation besides MPLS of course.

— Norm

-----Original Message-----
From: "Xialiang   (Frank)" <frank.xialiang@huawei.com>
Date: Wednesday, November 26, 2014 at 18:45 PM
To: Norman Finn <nfinn@cisco.com>
Cc: "detnet@ietf.org" <detnet@ietf.org>
Subject: RE: [Detnet] L2/L3 model?

>Hi Norm,
>Interesting viewpoint. Please see my comments inline:
>
>B.R.
>Frank
>
>> -----Original Message-----
>> From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Norman Finn
>> (nfinn)
>> Sent: Wednesday, November 19, 2014 8:16 AM
>> To: Erik Nordmark; detnet@ietf.org
>> Subject: Re: [Detnet] L2/L3 model?
>> 
>> 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.	
>[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
>> 
>> -----Original Message-----
>> From: Erik Nordmark <nordmark@acm.org>
>> Date: Monday, November 17, 2014 at 10:11 AM
>> To: "detnet@ietf.org" <detnet@ietf.org>
>> Subject: [Detnet] L2/L3 model?
>> 
>> >
>> >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
>> >
>> >_______________________________________________
>> >detnet mailing list
>> >detnet@ietf.org
>> >https://www.ietf.org/mailman/listinfo/detnet
>> 
>> _______________________________________________
>> detnet mailing list
>> detnet@ietf.org
>> https://www.ietf.org/mailman/listinfo/detnet