Re: [Detnet-dp-dt] detnet LSPs and PWs

Stewart Bryant <stewart.bryant@gmail.com> Mon, 13 February 2017 10:56 UTC

Return-Path: <stewart.bryant@gmail.com>
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 0E0F9127076 for <detnet-dp-dt@ietfa.amsl.com>; Mon, 13 Feb 2017 02:56:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 6wNwGBdvHOPA for <detnet-dp-dt@ietfa.amsl.com>; Mon, 13 Feb 2017 02:56:00 -0800 (PST)
Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 621D31293DF for <detnet-dp-dt@ietf.org>; Mon, 13 Feb 2017 02:56:00 -0800 (PST)
Received: by mail-wm0-x241.google.com with SMTP id u63so18708889wmu.2 for <detnet-dp-dt@ietf.org>; Mon, 13 Feb 2017 02:56:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to; bh=TTpf8pKzcWulIvrax1Auh0ihD3ArRsXIueIHC4Q4M9k=; b=SCzlgwiWn0SIV1w6Sl2yCw47DdVyacYE6g9wOIoG4Ja0F+nbWMd4GfUyxRkQv1iGAB 3dpyZZGMj82BAvLGNaVGg3yBi79ZQtIs0BGOzD16Mg2NkjEE9muZ9QXipEx0KVMMAIlb Aw90lISFIZkrW8Hpc1SegZHTbVrs15FbPX84AFz7vgVymAcZb4ErCgUNvXLIvOiroNvr Jky3ktZx1fWZ8ewLXdTOYeA3VWqFODvY6vjZRliVHpAASpjpdKEleSgxcF753FtpdpnG JRwn7KMbdBZ87JwNsF1/2bUAjLmsPdkYClZmKIH2iryqPhHz2RXojuJnO4hLsO7L51d7 hCVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to; bh=TTpf8pKzcWulIvrax1Auh0ihD3ArRsXIueIHC4Q4M9k=; b=IRRlW1KelHH8N4g7+4JQ/qfL1ZADCtGx0R3FVJ5wrJITD8a+aWNtpJDD5lOr4iWzaj dkrsIasV8RAkJ1nXwxLNevv8MRlirWxDZrMFPy9zyeELlJyRbKwhUXuqU48EFk1Mg9v/ 3tbu014ewHPKrJU+b6ujRvTO9IDcw0HPIlDj04IIh1NPQEDRLxg1rr85FY1ANVBMmbEq NBFBqvun98OvUlSxsQQB6sFk2lvE+v75Fg6F0yZ/P3Jb3/gLC3ieIQfWEpnBAKG7CjbQ DJJgDIUQybbHtlMsNBMNO1FfvRtMirgnLMmx0J1W6578Osml5g5CQfqy0j7sCRiSmSWO bPhQ==
X-Gm-Message-State: AMke39kqWMLhtig8qcEh7FxdZx2K42abJqI5RsRzCd8ksFFDxwNX/TZwUh1PqHxgHM83zA==
X-Received: by 10.28.64.213 with SMTP id n204mr19350560wma.12.1486983358786; Mon, 13 Feb 2017 02:55:58 -0800 (PST)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id o70sm4838095wmi.26.2017.02.13.02.55.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Feb 2017 02:55:58 -0800 (PST)
To: "Andrew G. Malis" <agmalis@gmail.com>, Loa Andersson <loa@pi.nu>
References: <017eafad-3d74-c8f7-19cb-00027dabea9a@pi.nu> <CAA=duU36fqem8M3W3CuFadwvcoHVx-sV2qR+TD3BKZuKcVtXvQ@mail.gmail.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <bda3c5f9-0795-177a-49ef-8e831b7f05ed@gmail.com>
Date: Mon, 13 Feb 2017 10:55:55 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <CAA=duU36fqem8M3W3CuFadwvcoHVx-sV2qR+TD3BKZuKcVtXvQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------50D02D92FBDD1F59DC782479"
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet-dp-dt/W6nQ9ki9QlxSET6mPXqCpzbDh3M>
Cc: detnet-dp-dt@ietf.org
Subject: Re: [Detnet-dp-dt] detnet LSPs and PWs
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, 13 Feb 2017 10:56:03 -0000

Hi,

I was given some background information on your thoughts on detnet-PW, 
and pass on my thoughts in response.

I think NSP issue  is a red herring. NSP can be NULL.

An S-PE does no NSP, although in any case I suspect that you may need 
some processing function at the detnet-S-PE - see below.

The underlying DETNET PW is an SS-PW in the diagram I was shown, in that 
the PW label is the same end to end, although of course it need not be, 
you could have an equivalence label set and run pure MS-PW. Indeed when 
you have multiple administrations you would like them to be different 
for administrative purposes (that is why we designed MS-PW like that).

So if you create an equivalence relationship in the egress-PE, i.e. two 
entries in the global label table pointing to the same duplicate 
suppressor (sequencer), then you could use regular MS-PW for this.

If the S-PEs are in the same administrative domain in both ingress and 
egress, you can also use a single label value on egress and on egress 
since you can give them the same label mappings, i.e. they have 
identical swap instructions programmed into the L-FIB.

We don't have NSP at the S-PE's in the current PW architecture, in the 
data-plane it is essentially a simple MPLS LSR, swapping PW labels and 
forwarding the packet on a new LSP. What you will almost certainly want 
to do is to have the ability to replicate at nodes at the S-PEs, and 
that is new functionality.

An approach I would look at is as follows:

Create a new detnet-T-PE. On ingress this adds the sequence number, 
replicates and adds the PW label, which as I said above MAY be next hop 
detnet-S-PE dependent. Then it delivers the copies to the detnet-S-PEs 
over the LSPs. Now if you have an ECMP path between the detnet-T-PE and 
a detnet-S-PE, or you have SR or RSVP-TE available you can also deliver 
multiple copies to the detnet-S-PE and take advantage of the variability 
of transit time in the MPLS underlay.

Now you create a new detnet-S-PE that operates as follows. On it's 
ingress side it looks for the first packet at a given sequence number on 
this PW (or PW set) and suppresses all future packets on that sequence 
number on that PW or PW-set. It then replicates the packet if required, 
swaps the PW label (note that it may also use multiple outgoing labels) 
and send the packet over the egress LSP set.

At the egress T-PE it looks at the sequence number on this PW (or 
PW-set), trims all duplicates, applies any required egress processing 
and send the packet on it's way.

In summary on ingress a detnet-T-PE replicates to multiple S-PEs using 
the PW label the detnet-S-PE expects and potentially sends the packet 
over multiple paths to the detnet-S-PEs. At egress a detnet-T-PE looks 
at the sequence numbers across the detnet-PW set and selects the first 
of the sequence number suppressing all others, and sends the underlying 
packet on its way. A detnet-S-PE is a back to back detnet-egress-T-PE 
and a detnet-ingress-T-PE with a PW label swap in the middle and no 
other PW processing.

Now for the elephant in the corner of all of the schemes I have seen. If 
you have multiple paths to an X-PE, packets will likely arrive on 
different line cards. Sequence number co-ordination amongst different 
line cards, and at high speed even amongst different ports on the same 
line card is a hard problem. Indeed depending on the pipeline design on 
the line card, ANY sequence number processing can be hard. You could 
mitigate this (at the cost of availability) by requiring a common 
ingress port at any detnet X-PE. This would normally require an RSVP-TE 
or SR underlay.

- Stewart



On 13/02/2017 04:11, Andrew G. Malis wrote:
> Loa et al,
>
> To be clear, there’s currently no definition of PWs encapsulated in 
> PWs, and while it might be conceptually possible, such as an Ethernet 
> PW carried within a SONET/SDH PW, I couldn’t imagine a use case for 
> doing it as it’s very inefficient, and I asked Loa if he had one. And 
> if you were to do so, each PW in the hierarchy would need NSP 
> functionality and real or emulated CE access circuits at the 
> endpoints. Also, thinking about it some more, you couldn’t have both 
> PWs in the same label stack, since a PW emulates a physical circuit. 
> So there would need to be a separate label stack (and MPLS LSP) inside 
> the emulated circuit for the outer PW. By definition, PW labels 
> terminate a label stack.
>
> As I haven’t been following Detnet at all, I don’t have the context 
> for what you’re trying to accomplish. That said, I’ll take a look at 
> the slides and let you know if I have any comments.
>
> Cheers,
> Andy
>
>
> On Sun, Feb 12, 2017 at 8:31 PM, Loa Andersson <loa@pi.nu 
> <mailto:loa@pi.nu>> wrote:
>
>     Folks,
>
>     The mail from Yuanlong mmade me go back and check the PW
>     architecture and consult with Andy Malis and Stewart Bryant. So I
>     have one more thing
>     that we should discuss on "Tuesday".
>
>     What Yaunlong said was: "IMHO, multiple layers of PW is a break from
>     the PWE3 architecture, and all DP/CP/MP things will become more
>     complicated."
>
>     It is correct that multi-layer pw's is problematic, though Andy said
>     that "if you have a good use case, you can do it".
>
>     The problem is that there is a native service processing (NSP) at
>     the end of the PW. Multi-layer PWs will only do NSP at one level.
>     I think
>     we should replace the MS-PW with an LSP. I've added one slide (9) and
>     change slide 8,9 and 11 in the earlier package. The other slides arere
>     for reference
>
>     I want Andy and Stewart to have a chance to review this prior to that
>     we commit too hard to it. Copied them.
>
>
>     /Loa
>     -- 
>
>
>     Loa Andersson                        email: loa@mail01.huawei.com
>     <mailto:loa@mail01.huawei.com>
>     Senior MPLS Expert loa@pi.nu <mailto:loa@pi.nu>
>     Huawei Technologies (consultant)     phone: +46 739 81 21 64
>     <tel:%2B46%20739%2081%2021%2064>
>
>