Re: [Detnet-dp-dt] detnet LSPs and PWs
"Andrew G. Malis" <agmalis@gmail.com> Fri, 17 February 2017 11:30 UTC
Return-Path: <agmalis@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 7F7F7129876
for <detnet-dp-dt@ietfa.amsl.com>; Fri, 17 Feb 2017 03:30:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.385
X-Spam-Level:
X-Spam-Status: No, score=-3.385 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887,
RCVD_IN_SORBS_SPAM=0.5, 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 ELPqz1a58R_t for <detnet-dp-dt@ietfa.amsl.com>;
Fri, 17 Feb 2017 03:30:27 -0800 (PST)
Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com
[209.85.218.44])
(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 3CBC61296DE
for <detnet-dp-dt@ietf.org>; Fri, 17 Feb 2017 03:30:27 -0800 (PST)
Received: by mail-oi0-f44.google.com with SMTP id u143so22711075oif.3
for <detnet-dp-dt@ietf.org>; Fri, 17 Feb 2017 03:30:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=1pJe2jRvfgD7+RwbG8VTLMm9FFzT96gQQ3VRMuDPgVM=;
b=YWHmFvX2TRyj2kwy+P/FwgrFrUaosPNBvt6Y+sKPrWypASli9XGzRoZi7CzUwthMW1
4z9oVcCyuU6jolvsSnYNTvncZ3zegFUHHXqhizRPTCpQ/zQpVeh3baTyZoeODa+bg3u/
JCCxVjATJfZqCTs0P9XDNkZS7qV9Qj5GxPSyKCJTrB6T/j8HHuh3wotTdfysBI8O6yS5
7NjpaPt9laLeiayF0TmSccT4Ym43BZJ6R1Tj6Khc9zu2/2abdvX8f11I3GEah70UughS
tn74mbMvgPeUpbhNiISB8xxv6VyxZskCqwVWvS/vVIcvWFKZYpjmEo0ikg0kXpv0yFyC
7SVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=1pJe2jRvfgD7+RwbG8VTLMm9FFzT96gQQ3VRMuDPgVM=;
b=cIPXVv6cNWrFA3TsMJyUuHF+Aj8EYb7IrkmjQn9pAwRVcCma0fxdmnPAW/k5CEWa3u
gDFf3ROhGptwlnKLDARoG9sm8SRpvMo716g8x+k5m9iFKECw71YCLezVorptWTg4Cne+
/X78lC0YNdOQkCPfaLJli3BrSLMJdj8/KZnNzJs5NM8a95qIkZ3aKE7pfqFO6F7bO2gj
RiKaN51Sibii/bwYNs94snQove/wxJegZFP6TEGKjEgKE1vLwbEAQgARWZ5+NZzmq/3/
NOQvkpPhIGsbBCRBtjvOv3ix0OZK/6Nj9mR6SWQQCaHElx08PZc2Z2Cg+0eeM2QR6fEC
yIdg==
X-Gm-Message-State: AMke39mpEXN/QxgvI5i98l29vd/uIsFXgq+wj6bngtNJuSgtWcCRrQbn0oqL1qbfzQI0dK8g8Ryds4opeSJhMQ==
X-Received: by 10.202.68.10 with SMTP id r10mr4006386oia.181.1487330966453;
Fri, 17 Feb 2017 03:29:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.159.42 with HTTP; Fri, 17 Feb 2017 03:29:06 -0800 (PST)
In-Reply-To: <6aaaadf7-6a9e-7e95-a1e0-e479f6116db9@pi.nu>
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>
<CAA=duU0mmr110Xmi_3NSArJoFv3BLUrsvjyhuTZSrwfgedCxEw@mail.gmail.com>
<6aaaadf7-6a9e-7e95-a1e0-e479f6116db9@pi.nu>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Fri, 17 Feb 2017 06:29:06 -0500
Message-ID: <CAA=duU1mX4-nM5TsUNJFSRP4ZUchwYri-=7peJh59LW5zX5=Sw@mail.gmail.com>
To: Loa Andersson <loa@pi.nu>
Content-Type: multipart/alternative; boundary=001a113d22e2eb48dc0548b8390e
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet-dp-dt/5XwIzAQBVtiNE4XLmX182eyVsD8>
Cc: Stewart Bryant <stewart.bryant@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: Fri, 17 Feb 2017 11:30:30 -0000
Loa, You asked: "Yes - but wouldn't that require that we had a DetNet variant for each of the existing PWs, right?” That depends - what kind of packets does Detnet plan to carry? If it’s only IP, then you need to define a new PW type for Detnet that carries IP packets preceded by a new Detnet-specific control word. It gets more complicated if the goal is to also carry Ethernet frames, or TDM, or FR packets, etc. Then you would need to replicate each of those PW types with the new control word. Also part of a Detnet PW definition would be multiple parallel PW paths to be carried by multiple distinct traffic tunnels, and the NSPs, which on the sending side would replicate packets and on the receiving side to do the duplicate elimination (and reordering?). Cheers, Andy On Fri, Feb 17, 2017 at 5:37 AM, Loa Andersson <loa@pi.nu> wrote: > Andy, > > My background is mostly MPLS, while DetNet is also strongly influenced by > 802. I hope that someone from that side of the house can chime in. > > On 2017-02-16 02:48, Andrew G. Malis wrote: > >> Loa, >> >> As I said earlier, I really don’t have any of the Detnet background, but >> interpolating from what I have seen lately, is the general idea to send >> out multiple replicas of a packet along different ECMP paths, and then >> use the first one to arrive, dropping later duplicates? >> > > In general - yes! Though equal cost is not a strict requirement, but we > will likely look at routing info to find sufficient paths. > >> >> Do you expect that a 16-bit sequence number would wrap around before all >> of the duplicates have arrived? >> > > We discussed that at the last dt-meeting, and Norm put up figures that > convinced the people that early said 16 bits is not enough, that it will > be. > Note that this was not the original > >> purpose of the PW sequence number, we originally expected that all >> packets would take the same route through the network, but there could >> be occasional out of order packets if routing should change, for example >> if there were a node or link outage followed by an MPLS fast reroute of >> the underlying traffic tunnel. The sequence number would be used to >> reorder such out of order packets. The PW generic control word was >> designed to prevent automatic ECMP in routers by making sure that the >> first nibble of the PW payload isn’t a 4 or 6, thus looking like IPv4 or >> IPv6 to an interior router that’s just doing ECMP. >> >> However, there are some cases where ECMP can be used with a PW, see RFC >> 6391 for further details. >> >> There is no requirement that all PWs use the same control word format, >> for example, the TDM PWs have their own control word different from the >> generic one. So if a Detnet PW were to be defined, it could, for >> example, have a sequence number of whatever length is required for the >> application. >> > > Yes - but wouldn't that require that we had a DetNet variant for each > of the existing PWs, right? > >> >> I doubt that you really want "A PW that carries sequence number + >> another PW”, that sounds very inefficient. >> > > Yes - that is my concern too, but cam we force all PWs to carry a > CW with a sequence number? I think we have converged on the MPLS label > stack on top of the PW, but still need to carefully discuss the PW > part. I've included slides that I think reflect where the dt is just > now. Even if I think the dt agrees that "PW in PW" is not efficient, > we still are not sure exactly how to do it. > > The PW in DetNet my carry any of the traffic types for which you have > defined PWs, If we can count on a sequence number to be there, that > would solve most of our problems. > >> >> MPLS traffic tunnels can also deliberately use ECMP, see RFC 6790. >> > > Yes - but is not exactly ECMP we are after, even if it from a high > level can look quite like ECMP. > > /Loa > >> >> Cheers, >> Andy >> >> >> On Tue, Feb 14, 2017 at 11:45 PM, Loa Andersson <loa@pi.nu >> <mailto: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 >> - 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. >> - what we called "d-pw" is not a new pw, but a pw from the PWE3/PALS >> inventory >> >> 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. >> >> 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. >> >> /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> >> <mailto: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> >> <mailto:loa@mail01.huawei.com >> <mailto:loa@mail01.huawei.com>> >> Senior MPLS Expert loa@pi.nu >> <mailto:loa@pi.nu> >> <mailto:loa@pi.nu <mailto:loa@pi.nu>> >> Huawei Technologies (consultant) phone: +46 739 81 >> 21 64 <tel:%2B46%20739%2081%2021%2064> >> <tel:%2B46%20739%2081%2021%2064> >> >> >> >> >> >> _______________________________________________ >> Detnet-dp-dt mailing list >> Detnet-dp-dt@ietf.org <mailto:Detnet-dp-dt@ietf.org> >> https://www.ietf.org/mailman/listinfo/detnet-dp-dt >> <https://www.ietf.org/mailman/listinfo/detnet-dp-dt> >> >> >> -- >> >> >> 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] 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