Re: [Detnet] L2/L3 model?

[Philippe Klein <[e-mail]>]

I do not have any issue with the L3 able to access the L2 parameters of the unified database but i still strongly believe in rightness of a clear separation of L3 and L2 model in which L2 offer L2 path establishment services to L3. (We will detail the rational in a contribution we planned as we move ahead with this effort. 
The scalability  could be addressed in my humble view in a hierarchical way similar to the autonomous and inter-autonomous model of the bridging protocols...

My two cents
/Ph

Sent from my iPhone

> On Nov 27, 2014, at 3:20, "Peter Jones (petejone)" <[e-mail]> wrote:
> 
> 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