Re: [Detnet] L2/L3 model?

["Pascal Thubert (pthubert)" <[e-mail]>]

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:[e-mail]] On Behalf Of Peter Jones
> (petejone)
> Sent: jeudi 27 novembre 2014 02:21
> To: Philippe Klein; Norman Finn (nfinn)
> Cc: [e-mail]
> 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: [phone]    Fax: [phone]
> Email:                  petejone at cisco.com
> Twitter:                @petergjones
> _______________________________________________
> 
> 
> -----Original Message-----
> From: detnet [mailto:[e-mail]] On Behalf Of Philippe Klein
> Sent: Saturday, November 22, 2014 11:42 PM
> To: Norman Finn (nfinn)
> Cc: [e-mail]
> 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:[e-mail]]
> Sent: Friday, November 21, 2014 11:31 PM
> To: Philippe Klein
> Cc: [e-mail]
> 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 <[e-mail]>
> Date: Monday, November 17, 2014 at 22:41 PM
> To: Pascal Thubert <[e-mail]>
> Cc: Erik Nordmark <[e-mail]>, "[e-mail]"
> <[e-mail]>, "Anca Zamfir (ancaz)" <[e-mail]>
> 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)"
> >><[e-mail]> 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:[e-mail]] On Behalf Of Philippe
> >>>Klein
> >>> Sent: mardi 18 novembre 2014 07:15
> >>> To: Anca Zamfir (ancaz); Erik Nordmark
> >>> Cc: [e-mail]
> >>> 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:[e-mail]]
> >>> Sent: Monday, November 17, 2014 9:32 PM
> >>> To: Philippe Klein; Erik Nordmark
> >>> Cc: [e-mail]
> >>> 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" <[e-mail]> 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" <[e-mail]>
> 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
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/detnet
> >>>>
> >>>> _______________________________________________
> >>>> detnet mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/detnet
> >>>
> >>> _______________________________________________
> >>> detnet mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/detnet
> >
> >_______________________________________________
> >detnet mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/detnet
> 
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet