Re: [Detnet] L2/L3 model?

Philippe Klein <philippe@broadcom.com> Sun, 23 November 2014 07:41 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 E41641A1AF9 for <detnet@ietfa.amsl.com>; Sat, 22 Nov 2014 23:41:59 -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 i6YaW-de1t28 for <detnet@ietfa.amsl.com>; Sat, 22 Nov 2014 23:41:57 -0800 (PST)
Received: from mail-gw2-out.broadcom.com (mail-gw2-out.broadcom.com [216.31.210.63]) by ietfa.amsl.com (Postfix) with ESMTP id 507FD1A1AEA for <detnet@ietf.org>; Sat, 22 Nov 2014 23:41:57 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.07,442,1413270000"; d="scan'208";a="51423292"
Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw2-out.broadcom.com with ESMTP; 23 Nov 2014 00:09:38 -0800
Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.12) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.174.1; Sat, 22 Nov 2014 23:41:56 -0800
Received: from SJEXCHMB06.corp.ad.broadcom.com ([fe80::65ea:1de7:41c4:e948]) by SJEXCHCAS05.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Sat, 22 Nov 2014 23:41:57 -0800
From: Philippe Klein <philippe@broadcom.com>
To: "Norman Finn (nfinn)" <nfinn@cisco.com>
Thread-Topic: [Detnet] L2/L3 model?
Thread-Index: AQHQApHsARBLnH7SD0eX20wvya89SJxlLNtYgACObICAACsSQIAAjEWA//99jvuABjWPgIABtsag
Date: Sun, 23 Nov 2014 07:41:33 +0000
Deferred-Delivery: Sun, 23 Nov 2014 07:42:00 +0000
Message-ID: <E3164327BB56B14B9162ABA2F0078A5B20CCF312@SJEXCHMB06.corp.ad.broadcom.com>
References: <38B7ABF9-00B4-462E-9788-3B40A7BE9460@broadcom.com> <D09007FF.C888F%ancaz@cisco.com> <E3164327BB56B14B9162ABA2F0078A5B20CC98AB@SJEXCHMB06.corp.ad.broadcom.com> <E045AECD98228444A58C61C200AE1BD848A6881D@xmb-rcd-x01.cisco.com> <113D6FCE-84EC-4A91-BCCD-E9965DBEBD4C@broadcom.com> <D094EBF1.3540B%nfinn@cisco.com>
In-Reply-To: <D094EBF1.3540B%nfinn@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.16.203.100]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/detnet/hSc34bZsC7AvJ5LSxIQCm46qdRg
Cc: "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: Sun, 23 Nov 2014 07:42:00 -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:nfinn@cisco.com] 
Sent: Friday, November 21, 2014 11:31 PM
To: Philippe Klein
Cc: detnet@ietf.org
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 <philippe@broadcom.com>
Date: Monday, November 17, 2014 at 22:41 PM
To: Pascal Thubert <pthubert@cisco.com>
Cc: Erik Nordmark <nordmark@acm.org>, "detnet@ietf.org" <detnet@ietf.org>, "Anca Zamfir (ancaz)" <ancaz@cisco.com>
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
>
>_______________________________________________
>detnet mailing list
>detnet@ietf.org
>https://www.ietf.org/mailman/listinfo/detnet