Re: [Detnet] L2/L3 model?

["Norman Finn (nfinn)" <[e-mail]>]

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