Re: [Detnet] L2/L3 model?

Philippe Klein <philippe@broadcom.com> Tue, 18 November 2014 17:16 UTC

Return-Path: <philippe@broadcom.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022B51A1B14 for <detnet@ietfa.amsl.com>; Tue, 18 Nov 2014 09:16:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.794
X-Spam-Level:
X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EyAdUVToNk8 for <detnet@ietfa.amsl.com>; Tue, 18 Nov 2014 09:15:58 -0800 (PST)
Received: from mail-gw1-out.broadcom.com (mail-gw1-out.broadcom.com [216.31.210.62]) by ietfa.amsl.com (Postfix) with ESMTP id E79781A19FF for <detnet@ietf.org>; Tue, 18 Nov 2014 09:15:57 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.07,410,1413270000"; d="scan'208";a="51179842"
Received: from irvexchcas07.broadcom.com (HELO IRVEXCHCAS07.corp.ad.broadcom.com) ([10.9.208.55]) by mail-gw1-out.broadcom.com with ESMTP; 18 Nov 2014 10:53:00 -0800
Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS07.corp.ad.broadcom.com (10.9.208.55) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 18 Nov 2014 09:15:41 -0800
Received: from SJEXCHMB06.corp.ad.broadcom.com ([fe80::65ea:1de7:41c4:e948]) by SJEXCHCAS04.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Tue, 18 Nov 2014 09:15:31 -0800
From: Philippe Klein <philippe@broadcom.com>
To: "Anca Zamfir (ancaz)" <ancaz@cisco.com>
Thread-Topic: [Detnet] L2/L3 model?
Thread-Index: AQHQApHsARBLnH7SD0eX20wvya89SJxlLNtYgACObICAACsSQIAAjEWA//99jvuAAIkQAIAAqqEA//99grA=
Date: Tue, 18 Nov 2014 17:15:31 +0000
Message-ID: <68DCE24B-1FAF-4885-8770-504BBE64A6D6@broadcom.com>
References: <E045AECD98228444A58C61C200AE1BD848A68900@xmb-rcd-x01.cisco.com>, <D09134BE.C8F10%ancaz@cisco.com>
In-Reply-To: <D09134BE.C8F10%ancaz@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/detnet/QgRWw4ynVvmWHPKM3JLKY9CjGpc
Cc: Erik Nordmark <nordmark@acm.org>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "detnet@ietf.org" <detnet@ietf.org>
Subject: Re: [Detnet] L2/L3 model?
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussions on Deterministic Networking, characterized by 1\) resource reservation; 2\) 0 congestion loss and guaranteed latency; 3\) over L2-only and mixed L2 and L3 networks; and 5\) 1+1 replication/deletion." <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Nov 2014 17:16:02 -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)" <ancaz@cisco.com> wrote:
> 
> 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)" <pthubert@cisco.com>
> 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.
>> 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
>> 
>> 
>>> -----Original Message-----
>>> From: Philippe Klein [mailto:philippe@broadcom.com]
>>> Sent: mardi 18 novembre 2014 07:41
>>> To: Pascal Thubert (pthubert)
>>> Cc: Anca Zamfir (ancaz); Erik Nordmark; detnet@ietf.org
>>> 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
>>> 
>>>> On Nov 18, 2014, at 8:28, "Pascal Thubert (pthubert)"
>>> <pthubert@cisco.com>
>>> wrote:
>>>> 
>>>> 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
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Philippe
>>>>> Klein
>>>>> Sent: mardi 18 novembre 2014 07:15
>>>>> To: Anca Zamfir (ancaz); Erik Nordmark
>>>>> Cc: detnet@ietf.org
>>>>> Subject: Re: [Detnet] L2/L3 model?
>>>>> 
>>>>> 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:ancaz@cisco.com]
>>>>> Sent: Monday, November 17, 2014 9:32 PM
>>>>> To: Philippe Klein; Erik Nordmark
>>>>> Cc: detnet@ietf.org
>>>>> 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" <philippe@broadcom.com> 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.
>>>>>> 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" <nordmark@acm.org>
>>> 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.
>>>>>>> 
>>>>>>> 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
>>>>> 
>>>>> _______________________________________________
>>>>> detnet mailing list
>>>>> detnet@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/detnet
>