Re: [Detnet] L2/L3 model?

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 18 November 2014 06: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 9ABD61AD357 for <detnet@ietfa.amsl.com>; Mon, 17 Nov 2014 22:51:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.095
X-Spam-Level:
X-Spam-Status: No, score=-15.095 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, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, 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 bFKyELNQnSqT for <detnet@ietfa.amsl.com>; Mon, 17 Nov 2014 22:51:55 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2272F1AD2C0 for <detnet@ietf.org>; Mon, 17 Nov 2014 22:51:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7425; q=dns/txt; s=iport; t=1416293515; x=1417503115; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JbZAutvx4iHiN/L9bTJNeTcVN4hw78Ki8QUKnnY429Y=; b=OFwEdxCyT830Iu70zpl5cUD7+w4LTErEqpw7NJCPkqEboD7ogBkcocS8 jQkzcv5I2jU/2nx6nUQS8PRffHWdPtXPxNl1kPyLV/YHgLvIAuFFM1EXy ukC4GxItyI5VBrjcFb8dxFNBQuFRYLJ11M6rCcOiH+TkVB7iy1NCNHqIR g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAOXralStJA2I/2dsb2JhbABbgw5VWQTMBgqGdFUCgRAWAQEBAQF9hAIBAQEEAQEBNy0HCwwEAgEIEQQBAQEKFAkHJwsUCQgCBA4FCBOIJg3TIwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEkFcxBwaDJ4EeBZJPjTqRPYQJg3ttgUiBAwEBAQ
X-IronPort-AV: E=Sophos;i="5.07,408,1413244800"; d="scan'208";a="373069925"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-6.cisco.com with ESMTP; 18 Nov 2014 06:51:54 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sAI6ps2s026827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Nov 2014 06:51:54 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.182]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Tue, 18 Nov 2014 00:51:53 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Philippe Klein <philippe@broadcom.com>
Thread-Topic: [Detnet] L2/L3 model?
Thread-Index: AQHQApHsRZu9bb8U10+BJkPq2LnckZxlLNtYgACObICAACsSQIAAA1+wgABrCQD//5udcA==
Date: Tue, 18 Nov 2014 06:51:52 +0000
Deferred-Delivery: Tue, 18 Nov 2014 06:51:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD848A68900@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>
In-Reply-To: <113D6FCE-84EC-4A91-BCCD-E9965DBEBD4C@broadcom.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.83.189]
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/fdPNUla3TpZ4sxTGG4YHxdVP0Dg
Cc: Erik Nordmark <nordmark@acm.org>, "detnet@ietf.org" <detnet@ietf.org>, "Anca Zamfir (ancaz)" <ancaz@cisco.com>
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 06:51:58 -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


> -----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