Re: [Detnet-dp-dt] quick notes from 1/31/17 call

Loa Andersson <loa@pi.nu> Mon, 06 February 2017 04:13 UTC

Return-Path: <loa@pi.nu>
X-Original-To: detnet-dp-dt@ietfa.amsl.com
Delivered-To: detnet-dp-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E565129B2F for <detnet-dp-dt@ietfa.amsl.com>; Sun, 5 Feb 2017 20:13:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
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 g3jvhh9l16lT for <detnet-dp-dt@ietfa.amsl.com>; Sun, 5 Feb 2017 20:13:10 -0800 (PST)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E61129B25 for <detnet-dp-dt@ietf.org>; Sun, 5 Feb 2017 20:13:09 -0800 (PST)
Received: from [192.168.1.11] (unknown [112.204.177.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id DE7711801556; Mon, 6 Feb 2017 05:13:05 +0100 (CET)
To: Jouni Korhonen <jouni.korhonen@broadcom.com>, cjbc@it.uc3m.es
References: <FB18B1D7-90CA-4D6F-BA43-F6D33AAA7DC0@broadcom.com> <1486295764.2956.1.camel@it.uc3m.es> <F264702E-940C-4B87-BA48-C555A4A65DE1@broadcom.com>
From: Loa Andersson <loa@pi.nu>
Message-ID: <8a7d4c8e-bc79-e0a5-189c-dde3002d18f2@pi.nu>
Date: Mon, 6 Feb 2017 12:13:01 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <F264702E-940C-4B87-BA48-C555A4A65DE1@broadcom.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet-dp-dt/BTFQlUeEfldpzIPAQ2fOwGaUuPA>
Cc: detnet-dp-dt@ietf.org
Subject: Re: [Detnet-dp-dt] quick notes from 1/31/17 call
X-BeenThere: detnet-dp-dt@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: DetNet WG Data Plane Design Team <detnet-dp-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet-dp-dt>, <mailto:detnet-dp-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet-dp-dt/>
List-Post: <mailto:detnet-dp-dt@ietf.org>
List-Help: <mailto:detnet-dp-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet-dp-dt>, <mailto:detnet-dp-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Feb 2017 04:13:12 -0000

Jouni and Carlos,

Please see inline

On 2017-02-06 11:29, Jouni Korhonen wrote:
>
> Carlos,
>
>
>> On 05 Feb 2017, at 03:56, Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> wrote:
>>
>> Hi Jouni, all,
>>
>> Thanks for the minutes and apologies for not joining this time.
>>
>> I have a couple of questions:
>>
>> 1. For the transport, we have so far assumed MPLS and IP PSNs (focusing
>> the discussion mainly on MPLS until this week). Are we restricted to
>> only these two? I think in some use cases other transports such as
>> MPLS-TP can be relevant as well. Will we explore this too/make the
>> solution open enough to support other transports?

The relationship between the MPLS transport profile and MPLS is that 
MPLS-TP is a true subset of MPLS, i.e. anything new that was defined for
MPLS-TP is also applicable for MPLS. On the other hand MPLS-TP 
explicitly excluded a couple of things that is part of MPLS. The two
most important things that were excluded was that
(1) you can not assume the presence of IP or IP routing in MPLS-TP
(2) PHP is always disabled

The DetNet charter says:

The Deterministic Networking (DetNet) Working Group focuses on
deterministic data paths that operate over Layer 2 bridged and Layer 3
routed segments, ...

Since MPLS-TP is neither "Layer 2 bridged" or "Layer 3 routed". to me
it looks like MPLS-TP is excluded.

/Loa


>
> Most of the DetNet DP “sauce” is on the PW layer. We already assured that the PSN can be either a LSP or IP. Since MPLS-TP includes PWE is see no reason why “MPLS-based” PSN could not also be implemented using MPLS-TP.
>
>> 2. How are organizing to work on the first draft text? I'm available to
>> contribute text.
>
> I’ll get the first round up soon. Then we can divide the job into sections that everybody (volunteering) is responsible for.
>
> - Jouni
>
>
>
>>
>> Thanks!
>>
>> Carlos
>>
>> On Wed, 2017-02-01 at 18:02 -0800, Jouni Korhonen wrote:
>>> Present: Jouni, Loa, Norm, Balazs, Janos, Tal and David.
>>>
>>> See the attached slideset that was used as the basis during the call.
>>> The MPLS-based PWE encaps has matured, except for: 1) fine grained
>>> CoS (i.e., 802.1 has discussed finer granularity of CoS basically to
>>> a flow level. The flow identification mechanism in .1CB, .1Qci et al
>>> allows this), and 2) PW CW SN width. We have discussed using 28 bits
>>> but that might cause issues when interworking with systems that only
>>> understand 16 bits (HSR and PRP as an examples).
>>> The CoS part and whether TC bits are copied between layers is still
>>> to be discussed further.
>>> IP PSN seems OK. The questions on the slides were discussed:
>>> - PW labels are still good to have. It makes the stack/implementation
>>> more streamlined between MPLS and IP PSNs. Also PW labels make PW
>>> switching way easier e.g., in a case of replication/elimination.
>>> - In a case of IP PSN each PW will have their own “tunnel” between T-
>>> /S-PEs. That means e.g., a PW between A and B will have different
>>> src/dst addresses than a PW between B and D. This makes pinned down
>>> paths easier to realize using IP PSN.
>>>
>>> Norm asks for the cases where DetNet interworks with e.g. 802.1TSN.
>>> Would there be a way to regenerate MAC addresses if those are not
>>> transported over DetNet (this is for the case where the L2 is just so
>>> bug that interconnect does not make sense). Discussion.. Jouni
>>> commented that it is not in current document’s scope. Could be worked
>>> in parallel once the encaps for DetNet DP mature a bit.
>>>
>>> Loa comments that EXP bits in an MPLS labels should use TC instead
>>> (Traffic Class), see RFC5462.
>>>
>>> Jouni commented that we now start to have enough material to produce
>>> a draft of a draft. Expect the first version next week.
>>>
>>> Quick discussion on 1588 PTP in DetNet. 1588 packets should not be
>>> replicated. Actually using DetNet encapsulation for them is not
>>> really a good idea. Tal will educate us more on that next time.
>>>
>>> Action points:
>>> Tal will produce a slideset regarding his thoughts/concerns on 1588
>>> transport in DetNet.
>>>
>>> Next call: 2/7/17 10PM PDT
>>>
>>>
>>> --
>>> Jouni Korhonen, Broadcom Ltd.
>>> M: +1-408-391-7160
>>>
>>> _______________________________________________
>>> Detnet-dp-dt mailing list
>>> Detnet-dp-dt@ietf.org
>>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>
> _______________________________________________
> Detnet-dp-dt mailing list
> Detnet-dp-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>

-- 


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64