Re: [Detnet-dp-dt] detnet LSPs and PWs
Jouni Korhonen <jouni.korhonen@broadcom.com> Wed, 15 February 2017 05:58 UTC
Return-Path: <jouni.korhonen@broadcom.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 D1830129A08
for <detnet-dp-dt@ietfa.amsl.com>; Tue, 14 Feb 2017 21:58:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,
DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001]
autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key)
header.d=broadcom.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 dKJbTyWEnTcR for <detnet-dp-dt@ietfa.amsl.com>;
Tue, 14 Feb 2017 21:58:33 -0800 (PST)
Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com
[IPv6:2607:f8b0:400e:c05::230])
(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 199531296C3
for <detnet-dp-dt@ietf.org>; Tue, 14 Feb 2017 21:58:33 -0800 (PST)
Received: by mail-pg0-x230.google.com with SMTP id 16so2025483pgg.2
for <detnet-dp-dt@ietf.org>; Tue, 14 Feb 2017 21:58:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=ioCirFykFmLbRQCRqBucjSWlcql0rqIPmx+wdPM+wBA=;
b=abHmPAh8QXzEXL0PwYueuNHRwHJpd5FcYM/GF9iyZtC3+SqhSaulQmwtCV3IfXflDl
ItdThUiCN1gqhhOMkOAQFnTPge/E4ZAVWgzeMmfzoYjCpY/I6CZ1q4rTgXPYJ+y5ln6I
qhYF/D2VAvCo0UEKKsbHvyg6+n3/ZixaHHpRQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=ioCirFykFmLbRQCRqBucjSWlcql0rqIPmx+wdPM+wBA=;
b=Sl1sBtEk141jQmth6cnwVV0mVutBPHcKik+/JGGqVp6KFlQCAY/aYow76vLMECHPS+
qqPKp1QeY+STRMGMEXC9f+FpvjWLnW0+LZyz7vdDfX0gP8nFl6OOrrQoYGWEM9hjTTyd
Jno8hTQHOBSxJYyN9hbKy91ZjaTopjyhereHc5lWeOthA7/Six4G1aly02ynz2FQTvtB
Fcuvi1A5FBTC/PS2VcYIBnoeitBk8txkYuGeVlZcu4qjkDq0Y9AFKY63cLVu05LOJ4XR
cCvYNhfnjh7y35wL5HZE+tFJRhtUWuntQPVHiEWLoX74C1sGG4HYxpcv9i3g/f/pehGB
UVfw==
X-Gm-Message-State: AMke39nuogKrve8z9db7Fp2ETU2lj4X3EsqQRNeh2PTmp3+LLnR5siD1Y5EtJcpQhia4PHeL
X-Received: by 10.99.39.70 with SMTP id n67mr36303627pgn.203.1487138312228;
Tue, 14 Feb 2017 21:58:32 -0800 (PST)
Received: from [10.0.0.5] (c-24-5-144-221.hsd1.ca.comcast.net. [24.5.144.221])
by smtp.gmail.com with ESMTPSA id
e7sm4617426pgp.2.2017.02.14.21.58.31
(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Tue, 14 Feb 2017 21:58:31 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Jouni Korhonen <jouni.korhonen@broadcom.com>
In-Reply-To: <633aa9a7-da64-8276-a69f-11361b8e1da0@pi.nu>
Date: Tue, 14 Feb 2017 21:58:29 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <01CA7B06-1AF0-4095-8D83-FD81A6BDA623@broadcom.com>
References: <017eafad-3d74-c8f7-19cb-00027dabea9a@pi.nu>
<CAA=duU36fqem8M3W3CuFadwvcoHVx-sV2qR+TD3BKZuKcVtXvQ@mail.gmail.com>
<bda3c5f9-0795-177a-49ef-8e831b7f05ed@gmail.com>
<9e2a402c-d905-52c8-d354-c49c3664c3b7@pi.nu>
<43128998-28F4-4373-B2EA-86BF596E9250@broadcom.com>
<633aa9a7-da64-8276-a69f-11361b8e1da0@pi.nu>
To: Loa Andersson <loa@pi.nu>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet-dp-dt/KbzY2GsH6XvgEpAtU4zWwTFpDN4>
Cc: Stewart Bryant <stewart.bryant@gmail.com>,
"Andrew G. Malis" <agmalis@gmail.com>, 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: Wed, 15 Feb 2017 05:58:36 -0000
Hi Loa, > On 14 Feb 2017, at 21:50, Loa Andersson <loa@pi.nu> wrote: > > Jouni, > > inline pl.ease > > > On 2017-02-15 13:00, Jouni Korhonen wrote: >> Loa, >> >>> On 14 Feb 2017, at 20:45, Loa Andersson <loa@pi.nu> wrote: >>> >>> Folks, >>> >>> Actually I think (except for the nomenclature, which I think we should >>> adopt) of what Stewart says is there in the new slides. >>> >>> There are a few "if" that I don't agree to a design (maybe it may be >>> possible to collapse the design), e.g. assuming one single domain. >>> >>> I think there are some design decision that need to be there. >>> >>> - replication and elimination of packets at places/nodes that the >>> operator can control, i.e. not every node should do it >> >> It was never assumed every node would do it - or even ever S-PE on path. > > True, but we have spelled it out, and if this is a data plane decision, how do you prevent a node capable of doing it to do it? By configuration. It is not an automatic function, but a purposely made decision. >>> - with an "S-detnet-PE" in the path (for replication/elimination) we >>> need three levels of labels. The implication is that if we don't do >>> replication/elimination other than at the T-detnet-PWs then we only >>> need two layers. >> >> Could you elaborate more.. > > which part? the egress "T-detnet-PE" will know by the label where the > packet came from > T-label says it came from the immediate neighbor > L-label says it came from its S-detnet-PE neighbor > d-pw label says it came from the T-detnet-PE peer ok. gotcha. > > >> >>> - what we called "d-pw" is not a new pw, but a pw from the PWE3/PALS >>> inventory >> >> Ok. >> >>> Now that last bullet is a problem, the sequence number is 16 bits in >>> PWE3/PALS and we know that is to small. Maybe we have to define a detnet >>> PW after all. A PW that carries sequence number + another PW. >> >> Erm why? One can define a new control word. The merge + replication + elimination alone done on PW instance is big enough change to add other tweaks there, like bigger seqnums. >> > I think we need to discuss this, I'm not sure we can change the control > word in an existing PW, or if we want to do that it will have > implications outside detnet. Now I do not follow which “existing PW” in this context. Do you mean that you would terminate a PW with DetNet flavor to a T/S-PE that has no idea of DetNet? I doubt that would work. > >>> I've been thinking hard about the equivalence relationship, but is still not sure it will work in the generic case, equivalence >>> relationship tells node D that it should treat L1 from B and L2 from C >>> the same, which is fine, but it does still not tell us that the packet >>> came from A originally. >>> >>> BTW - I think we need some type of sign-off from Stewart/Andy before we >>> commit to hard. >>> >>> Also the problem of comparing sequence numbers arriving over >>> different physical interface seems to be a eal problem. >> >> I do not see this as an issue if separate port are attached to e.g., same switch soc. How separate physical ports end up to the same PW instance is an implementation issue. There are non-trivial issues if the separate physical ports are in different blades or say in different switch socs. >> > So you are saying, it is sometimes a problem, sometimes not? One can always come up with a node architecture that woudl have issues here at high or moderate speeds. That should not prevent us defining a solution that can perform just fine at multi-tera speeds. - Jouni > > /Loa >> - Jouni >> >>> >>> /Loa >>> >>> On 2017-02-13 18:55, Stewart Bryant wrote: >>>> 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> >>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> _______________________________________________ >>> 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
- [Detnet-dp-dt] detnet LSPs and PWs Loa Andersson
- Re: [Detnet-dp-dt] detnet LSPs and PWs Jouni Korhonen
- Re: [Detnet-dp-dt] detnet LSPs and PWs Andrew G. Malis
- Re: [Detnet-dp-dt] detnet LSPs and PWs Stewart Bryant
- Re: [Detnet-dp-dt] detnet LSPs and PWs Andrew G. Malis
- Re: [Detnet-dp-dt] detnet LSPs and PWs Stewart Bryant
- Re: [Detnet-dp-dt] detnet LSPs and PWs Stewart Bryant
- Re: [Detnet-dp-dt] detnet LSPs and PWs Andrew G. Malis
- Re: [Detnet-dp-dt] detnet LSPs and PWs Stewart Bryant
- Re: [Detnet-dp-dt] detnet LSPs and PWs Jouni Korhonen
- Re: [Detnet-dp-dt] detnet LSPs and PWs Loa Andersson
- Re: [Detnet-dp-dt] detnet LSPs and PWs Loa Andersson
- Re: [Detnet-dp-dt] detnet LSPs and PWs Jouni Korhonen
- Re: [Detnet-dp-dt] detnet LSPs and PWs Norman Finn
- Re: [Detnet-dp-dt] detnet LSPs and PWs Loa Andersson
- Re: [Detnet-dp-dt] detnet LSPs and PWs Jouni Korhonen
- Re: [Detnet-dp-dt] detnet LSPs and PWs Stewart Bryant
- Re: [Detnet-dp-dt] detnet LSPs and PWs Stewart Bryant
- Re: [Detnet-dp-dt] detnet LSPs and PWs Stewart Bryant
- Re: [Detnet-dp-dt] detnet LSPs and PWs Stewart Bryant
- Re: [Detnet-dp-dt] detnet LSPs and PWs Jouni Korhonen
- Re: [Detnet-dp-dt] detnet LSPs and PWs Jouni Korhonen
- Re: [Detnet-dp-dt] detnet LSPs and PWs Andrew G. Malis
- Re: [Detnet-dp-dt] detnet LSPs and PWs Loa Andersson
- Re: [Detnet-dp-dt] detnet LSPs and PWs Andrew G. Malis
- Re: [Detnet-dp-dt] detnet LSPs and PWs Loa Andersson
- Re: [Detnet-dp-dt] detnet LSPs and PWs Andrew G. Malis
- Re: [Detnet-dp-dt] detnet LSPs and PWs Loa Andersson
- Re: [Detnet-dp-dt] detnet LSPs and PWs Stewart Bryant
- Re: [Detnet-dp-dt] detnet LSPs and PWs Andrew G. Malis