Re: [Detnet] L2/L3 model?
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 27 November 2014 08:51 UTC
Return-Path: <pthubert@cisco.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 916A61A6FB7 for <detnet@ietfa.amsl.com>; Thu, 27 Nov 2014 00:51:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 ra4PhpjrIZHF for <detnet@ietfa.amsl.com>; Thu, 27 Nov 2014 00:51:42 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFDD11A6FE5 for <detnet@ietf.org>; Thu, 27 Nov 2014 00:51:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14734; q=dns/txt; s=iport; t=1417078302; x=1418287902; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Hmqg0fJVY+UxJiv+21QpN3hPaIn8uFD8BaGKZ05CxO4=; b=cgf9cOBxi1k3l9VE22Jn4cR4wr6S9RnvN+usgAGFhYh5zeUQo/Ni6q0o VY7YKOSp8LMWEBzn92YiZp4e0AzNUwzSsGDtCD1TAuPjZGU3U4f2eyMpA nzN9aO8HJ9s794bWnA32Y1vqvbzLizxbPXtRvdhe77G8qJe7GI1BoZXu8 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhsIAEbldlStJV2P/2dsb2JhbAAZAT4DgwZRXMU5gh4KhXhVAhxuFgEBAQEBfYQCAQEBBAEBASARMwcLDAQCAQYCEQMBAQEBAgIGHQMCAgIlCxQBCAgCBAENBQgTiCUNnhRZnHaWOAEBAQEBAQEBAQEBAQEBAQEBAQEBAReBLo5rEQEfFgsQBwYLgmc2gR8FkmWEZ4hqP4ZTikuECoN8b4EPOYECAQEB
X-IronPort-AV: E=Sophos;i="5.07,468,1413244800"; d="scan'208";a="100512373"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-1.cisco.com with ESMTP; 27 Nov 2014 08:51:40 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sAR8peVB029694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Nov 2014 08:51:40 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.182]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Thu, 27 Nov 2014 02:51:40 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "Peter Jones (petejone)" <petejone@cisco.com>, Philippe Klein <philippe@broadcom.com>, "Norman Finn (nfinn)" <nfinn@cisco.com>
Thread-Topic: [Detnet] L2/L3 model?
Thread-Index: AQHQApHsRZu9bb8U10+BJkPq2LnckZxlkXAAgAAIUICAALORgIAAA8aAgAADqgCABa9zgIACPQuAgAV4evCAAH2eAA==
Date: Thu, 27 Nov 2014 08:51:39 +0000
Deferred-Delivery: Thu, 27 Nov 2014 08:51:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD848A7D185@xmb-rcd-x01.cisco.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> <E3164327BB56B14B9162ABA2F0078A5B20CCF312@SJEXCHMB06.corp.ad.broadcom.com> <16D433D8140F0E47885CD19E308EBB342C9632DF@xmb-rcd-x11.cisco.com>
In-Reply-To: <16D433D8140F0E47885CD19E308EBB342C9632DF@xmb-rcd-x11.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.49.80.23]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/detnet/33WU7nsuvib3phMJcCWjkqKHcGE
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: Thu, 27 Nov 2014 08:51:44 -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 > -----Original Message----- > From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Peter Jones > (petejone) > Sent: jeudi 27 novembre 2014 02:21 > To: Philippe Klein; Norman Finn (nfinn) > Cc: detnet@ietf.org > Subject: Re: [Detnet] L2/L3 model? > > 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:detnet-bounces@ietf.org] On Behalf Of Philippe Klein > Sent: Saturday, November 22, 2014 11:42 PM > To: Norman Finn (nfinn) > Cc: detnet@ietf.org > 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: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 > > _______________________________________________ > 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] L2/L3 model? Erik Nordmark
- Re: [Detnet] L2/L3 model? Philippe Klein
- Re: [Detnet] L2/L3 model? Pat Thaler
- Re: [Detnet] L2/L3 model? Anca Zamfir (ancaz)
- Re: [Detnet] L2/L3 model? Pascal Thubert (pthubert)
- Re: [Detnet] L2/L3 model? Jouni Korhonen
- Re: [Detnet] L2/L3 model? Philippe Klein
- Re: [Detnet] L2/L3 model? Philippe Klein
- Re: [Detnet] L2/L3 model? Pascal Thubert (pthubert)
- Re: [Detnet] L2/L3 model? Philippe Klein
- Re: [Detnet] L2/L3 model? Pascal Thubert (pthubert)
- Re: [Detnet] L2/L3 model? Vengada Prasad Govindan (venggovi)
- Re: [Detnet] L2/L3 model? Anca Zamfir (ancaz)
- Re: [Detnet] L2/L3 model? Philippe Klein
- Re: [Detnet] L2/L3 model? Anca Zamfir (ancaz)
- Re: [Detnet] L2/L3 model? Shitanshu Shah (svshah)
- Re: [Detnet] L2/L3 model? Erik Nordmark
- Re: [Detnet] L2/L3 model? Norman Finn (nfinn)
- Re: [Detnet] L2/L3 model? Norman Finn (nfinn)
- Re: [Detnet] L2/L3 model? Norman Finn (nfinn)
- Re: [Detnet] L2/L3 model? Philippe Klein
- Re: [Detnet] L2/L3 model? Peter Jones (petejone)
- Re: [Detnet] L2/L3 model? Philippe Klein
- Re: [Detnet] L2/L3 model? Xialiang (Frank)
- Re: [Detnet] L2/L3 model? Pascal Thubert (pthubert)
- Re: [Detnet] L2/L3 model? Norman Finn (nfinn)