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

Loa Andersson <loa@pi.nu> Fri, 17 February 2017 11:54 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 C9FB71299B8 for <detnet-dp-dt@ietfa.amsl.com>; Fri, 17 Feb 2017 03:54:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 fNjIkAaP-RF4 for <detnet-dp-dt@ietfa.amsl.com>; Fri, 17 Feb 2017 03:54:20 -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 04B061299C0 for <detnet-dp-dt@ietf.org>; Fri, 17 Feb 2017 03:54:20 -0800 (PST)
Received: from [192.168.1.11] (unknown [122.52.25.23]) (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 3E0CB18015C7; Fri, 17 Feb 2017 12:54:11 +0100 (CET)
To: "Andrew G. Malis" <agmalis@gmail.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> <CAA=duU0mmr110Xmi_3NSArJoFv3BLUrsvjyhuTZSrwfgedCxEw@mail.gmail.com> <6aaaadf7-6a9e-7e95-a1e0-e479f6116db9@pi.nu> <CAA=duU1mX4-nM5TsUNJFSRP4ZUchwYri-=7peJh59LW5zX5=Sw@mail.gmail.com>
From: Loa Andersson <loa@pi.nu>
Message-ID: <cd02e185-d67f-6480-5143-d9c58f432fe6@pi.nu>
Date: Fri, 17 Feb 2017 19:54:06 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <CAA=duU1mX4-nM5TsUNJFSRP4ZUchwYri-=7peJh59LW5zX5=Sw@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet-dp-dt/ZzPfjjjRmxsRiphaU0aocmNOyLY>
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:54:23 -0000

Andy,

On 2017-02-17 19:29, Andrew G. Malis wrote:
> 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?).

I don't understand that last sentence, if I have a tunnel with enough BW
and good enough QoS, why can't I carry two different types of PWs over
that tunnel?

The NSP is PW not per tunnel, right?

/Loa

>
> Cheers,
> Andy
>
> On Fri, Feb 17, 2017 at 5:37 AM, Loa Andersson <loa@pi.nu
> <mailto: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>
>         <mailto: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>>
>                     <mailto: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>>
>                         <mailto: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>>
>                         <mailto: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>
>         <mailto: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>
>                 <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>
>             <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