Re: [spring] Different MSDs for different traffic types on the same headend.

Jeff Tantsura <jefftant.ietf@gmail.com> Wed, 18 December 2019 00:42 UTC

Return-Path: <jefftant.ietf@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A9112000F for <spring@ietfa.amsl.com>; Tue, 17 Dec 2019 16:42:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 pYY-fKa1UeRN for <spring@ietfa.amsl.com>; Tue, 17 Dec 2019 16:42:40 -0800 (PST)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 2EC44120033 for <spring@ietf.org>; Tue, 17 Dec 2019 16:42:36 -0800 (PST)
Received: by mail-pl1-x635.google.com with SMTP id p9so156210plk.9 for <spring@ietf.org>; Tue, 17 Dec 2019 16:42:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=hVYt5tFOrNVzfaVGFCfGf9mYehJKAJ69tpDfEqn8aEQ=; b=bTsQ7qr1CTGs/EinzuZv4njOoHSBUJB/05KaRuxNHYCMaLqDRhD1xxQRICRRceX08q pQZIayc6ldAG7DNZNT7GTB2DximGhhJITHYTK4znXeJjPYNumsKzwcu/4Zd7s5w0ef5T GaDNu7rZ9Z3YVbvnvmIMzj7t1UcvzNP+JdkzHE2iy79GretdHuhyreZYfNz4YnlqJhWY SqHWoCW8nikhPpIzZaweBYwGNQlmexOfpFmJE9xbPZAy3gzH+EZcvUz8QIqFkXrkfGZ8 P7zhv86C6Bag5Xx51mMrDKBsKOQGoIZufvmgYG5Dsly1wTBgMLbAlmYChX6SE9bpyBn/ GROg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=hVYt5tFOrNVzfaVGFCfGf9mYehJKAJ69tpDfEqn8aEQ=; b=m1FQUhwZ6ZCRu+1DbcTKvEA3DKRvINiDlkgXBuBMYN9TKLSlFgMt8xmAPga6zxIslq Bfkqcve/SpaRU6c4CIGHyiVWKf1XAbqsOI2NiPkN/DTy9nTuQ65VIdoNMDLxOL4wwYWM eyWBQI+7VIQZoC6kdgdHsGA41LF840A5g9UE912ftox93BgHhM5X2dknzUqS/9BATW1p 3p4cu2v2r57jsgi45LUnr1IZnDpMA5ovPJkLnpwN71qIvsLWMOe0JSVNg2vb8UoojG2u EH8jff5w9qFPh1aNxJcL2okYokHyAjWnUCdBUiFAdR7xqCacAkX5TAOOTI5btjxg/FdS wLWA==
X-Gm-Message-State: APjAAAXqKyQklDyxZ8vtQX2x/ihW1M5ww3Arv143/x5EaAYMEUPdjWo3 zaDDhmvXOoYC8aaZLtKsm9ATOoDG
X-Google-Smtp-Source: APXvYqyJNLNKR2q39fDxGKWwpPI10MUHkf8otU/zhlsmvWBkxsYRxLn3BeN7qz9lOyljBLesEYMgZw==
X-Received: by 2002:a17:90a:23ee:: with SMTP id g101mr226275pje.14.1576629755426; Tue, 17 Dec 2019 16:42:35 -0800 (PST)
Received: from [10.1.253.22] ([216.221.150.18]) by smtp.gmail.com with ESMTPSA id w5sm186616pgb.78.2019.12.17.16.42.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Dec 2019 16:42:34 -0800 (PST)
Date: Tue, 17 Dec 2019 16:42:28 -0800
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: Nat Kao <lekao@pyxisworks.org>, Robert Raszuk <robert@raszuk.net>
Cc: SPRING WG <spring@ietf.org>
Message-ID: <ff911cc4-d2af-49af-bf5c-e9cf651b05f3@Spark>
In-Reply-To: <CAOj+MMFZnhYgOShZDFuBAwvhaUPGppo+JTF1k_1+MWKh08NGQg@mail.gmail.com>
References: <CAN3QBScGjeL=yDSW3AOXZrVTGA-czbY2qDrOMQ=gDxAd4d=nYQ@mail.gmail.com> <38b14bf5-b6d9-4d46-ad1d-d26d3376df51@Spark> <CAN3QBSf2Kpu3Pd_FYmA7BCHJ=uWu9DnEEaYdQwGDDs26NmbJQg@mail.gmail.com> <CABNhwV1-yRcK18JsJbAr3e+Hm-35WdmUFZ0mkzwLj5iBD9zWxw@mail.gmail.com> <c8967bfb-5a8e-447d-8e28-314820764f13@Spark> <CAN3QBScyJ5QgmKU8_h62pLF=FQ8y40C3sSRB1TWfKBQfdb1Mkw@mail.gmail.com> <CAN3QBSdFVCBQVPVc2Ax0i2EgMrGqzSCj7YpsUUE2m3HiM9AcyA@mail.gmail.com> <CAOj+MMFZnhYgOShZDFuBAwvhaUPGppo+JTF1k_1+MWKh08NGQg@mail.gmail.com>
X-Readdle-Message-ID: ff911cc4-d2af-49af-bf5c-e9cf651b05f3@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5df975f9_5992a02e_872b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/Ff-PXonieyoOYKFxeDLJ6CZHbiY>
Subject: Re: [spring] Different MSDs for different traffic types on the same headend.
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Dec 2019 00:42:46 -0000

Robert,

While you are correct wrt single ASIC platforms, on a line-card based platforms (at least ones I’m familiar with and that includes merchant silicon)  in some case service labels were imposed on egress LC while transport on ingress, in any case, they are imposed at different stages in the pipeline. When you program HW there are clear differences and trade-offs associated.
On many NPU’s, there’s a way to recirculate packets inside ASIC/NPU to provide additional manipulations, usually comes with performance penalty, perfect use case for an additional MSD type (Cisco is doing exactly that on Jericho+ to increase MSD).
In general - as long as a device can provide any additional information that could be used by computation logic to compute the most optimized path, it is a good thing.

Cheers,
Jeff
On Dec 17, 2019, 1:59 AM -0800, Robert Raszuk <robert@raszuk.net>et>, wrote:
> Hi Nat,
>
> I am having a bit of difficulty understanding reasoning and the way you are separating transport from service labels.
>
> The processing label limit usually comes from data plane capabilities of the platform namely LFIB or hardware below.
>
> Such layer is function agnostic and it does not matter what role the label serves.
>
> Label lookup results in pointer to a adj. rewrite on the outbound side. It really does not matter if the adjacent peer is your P router, segment endpoint or CE.
>
> Of course there are number of processing exceptions - for example concept of aggregate VPN label, additional header modifications etc ...
>
> Likely some platforms put such artificial boundary between transport and service hence your request. But if so IMHO this is more of an issue with specific platform or its marketing message then IETF :).
>
> Many thx,
> R.
>
>
>
>
>
>
>
> > On Tue, Dec 17, 2019 at 6:06 AM Nat Kao <lekao@pyxisworks.org> wrote:
> > > Hi, Jeff.
> > >
> > > Consider a headend that can perform 1 of the following 2 modes(but not both):
> > > 1) Plain IPv4: 6 transport labels + 0 service label => traffic can be steered into a 6-label SR-TE policy.
> > > 2) Any type of VPN: 3 transport labels + 1~3 service labels => traffic cannot be steered into a 6-label SR-TE policy.
> > >
> > > a) As defined in RFC8491, the BMI-MSD is 6 for this headend. Do we have a standardized way to signal the transport label depth in mode 2?
> > >    Maybe in a different MSD type?
> > > b) Since plain IPv4 and VPN routes can be steered into the same SR-TE policy, do we have a standardized headend behavior in this situation?
> > >    (Should I open a new thread to discuss this? It seems not quite MSD-relative.)
> > >
> > > Thanks...
> > > Nat
> > >
> > >
> > > > On Tue, Dec 17, 2019 at 11:14 AM Nat Kao <lekao@pyxisworks.org> wrote:
> > > > > Hi, Jeff.
> > > > >
> > > > > Consider a headend that can perform 1 of the following 2 modes(but not both):
> > > > > 1) Plain IPv4: 6 transport labels + 0 service label => traffic can be steered into a 6-label SR-TE policy..
> > > > > 2) Any type of VPN: 3 transport labels + 1~3 service labels => traffic cannot be steered into a 6-label SR-TE policy.
> > > > >
> > > > > a) As defined in RFC8491, the BMI-MSD is 6 for this headend. Do we have a standardized way to signal the transport label depth in mode 2?
> > > > >    Maybe in a different MSD type?
> > > > > b) Since plain IPv4 and VPN routes can be steered into the same SR-TE policy, do we have a standardized headend behavior in this situation?
> > > > >    (Should I open a new thread to discuss this? It seems not quite MSD-relative.)
> > > > >
> > > > > Thanks.
> > > > > Nat.
> > > > >
> > > > >
> > > > > > On Tue, Dec 17, 2019 at 7:19 AM Jeff Tantsura <jefftant.ietf@gmail.com> wrote:
> > > > > > > Gyan,
> > > > > > >
> > > > > > > MSD is only relevant for a device that either imposes the label stack (head-end) or manipulates it (BSID anchor). There are some other constrains when it comes to entropy labels and ERLD, please read the respective drafts.
> > > > > > > In general, SID stack would grow when TE is in use (any time you need to use additional SID to deviate from SPT), another case is when additional SID’s are used for services on the nodes, other than the tail-end.
> > > > > > > That’s why we've designed MSD to be very flexible to accommodate all the different use cases, it is upto computational logic to decide how to deal with different constrains (MSD types)
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Jeff
> > > > > > >
> > > > > > > P.S. you might want to see the NANOG MSD presentation I did some time ago.
> > > > > > > https://pc.nanog.org/static/published/meetings/NANOG71/1424/20171004_Tantsura_The_Critical_Role_v1.pdf
> > > > > > > On Dec 14, 2019, 11:59 PM -0800, Gyan Mishra <hayabusagsm@gmail.com>om>, wrote:
> > > > > > > > Jeff
> > > > > > > >
> > > > > > > > With SR-MPLS with SR-TR let’s say if you use cSPF snd don’t have an ERO strict explicit path defined or is a loose path, then the for the cSPF would the transport labels be 1.  For loose would also be 1 also.  If the path were explicit defined to egress PE and was 7 hops from ingress to egress then transport would be 6.  And if L3 vpn service sid was signaled that would be 1 vpn label.
> > > > > > > >
> > > > > > > > Let me know if I have that right.
> > > > > > > >
> > > > > > > > In Nats scenario for IPv6 he has 3 vpnv6 labels.
> > > > > > > >
> > > > > > > > Why is that?
> > > > > > > >
> > > > > > > > With both SR-MPLS and SRv6 the L3 vpn AFI/SAFI MBGP services overlay single label sits on top off SR as if does today with MPLS so why 3 vpn labels.
> > > > > > > >
> > > > > > > > So with this draft with BGP-LS and BMI-MSD you can flood into the IGP the SID depth so all the nodes along the SR-TE path don’t go over the maximum which would result in an error.
> > > > > > > >
> > > > > > > > If you set your MTU high enough in the core like 9216, does that overcome the SID depth issues with SR-TE?
> > > > > > > >
> > > > > > > > Warm regards,
> > > > > > > >
> > > > > > > > Gyan
> > > > > > > >
> > > > > > > > > On Sat, Dec 14, 2019 at 2:43 AM Nat Kao <lekao@pyxisworks.org> wrote:
> > > > > > > > > > Hi, Jeff.
> > > > > > > > > >
> > > > > > > > > > Thanks for the BMI-MSD reference. If I understand correctly:
> > > > > > > > > >
> > > > > > > > > > BMI-MSD = Transport Label Depth + Service Label Depth
> > > > > > > > > > Only former can be utilized by SR-TE policies.
> > > > > > > > > >
> > > > > > > > > > Currently do we have any method to determine the composition of BMI?
> > > > > > > > > > We need to know the transport label depth when doing service route per-destination steering.
> > > > > > > > > >
> > > > > > > > > > This problem arises when trying to steer a plain IPv4 route and a VPN service route into the same SR-TE policy that exceeds the transport label depth of the service route. I'm trying to figure out the standard behavior in this case since the headend we use currently produces some interesting results.
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > > Nat.
> > > > > > > > > >
> > > > > > > > > > > On Sat, Dec 14, 2019 at 2:42 AM Jeff Tantsura <jefftant.ietf@gmail.com> wrote:
> > > > > > > > > > > > Hi Nat,
> > > > > > > > > > > >
> > > > > > > > > > > > Please read https://tools.ietf.org/html/rfc8491#section-5
> > > > > > > > > > > > Currently defined MSD types are:
> > > > > > > > > > > > 1: BMI
> > > > > > > > > > > > 2: ERLD
> > > > > > > > > > > >
> > > > > > > > > > > > Specifically to BMI:
> > > > > > > > > > > > Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS labels that can be imposed, including all service/transport/special labels.
> > > > > > > > > > > > The answer to your question is 6
> > > > > > > > > > > >
> > > > > > > > > > > > Cheers,
> > > > > > > > > > > > Jeff
> > > > > > > > > > > > On Dec 13, 2019, 3:42 AM -0800, Nat Kao <lekao@pyxisworks.org>rg>, wrote:
> > > > > > > > > > > > > Hello, SPRING WG.
> > > > > > > > > > > > >
> > > > > > > > > > > > > How do we deal with an SR-TE policy headend with different MSDs for different types of traffic?
> > > > > > > > > > > > > For example, a headend H can impose:
> > > > > > > > > > > > > 6 transport labels for plain IPv4 packets;
> > > > > > > > > > > > > 5 transport labels + 1 IPv6 ExpNull label for plain IPv6 packets;
> > > > > > > > > > > > > 3 transport labels + 3 VPN  labels for VPN packets.
> > > > > > > > > > > > >
> > > > > > > > > > > > > a) For a plain IPv4 route R4 and a VPN route Rv both steered into the SR-TE policy P1 with SID list <S1, S2, S3, S4, S5>, what will H perform in this situation?
> > > > > > > > > > > > > b) What is the MSD of H? 6, 5 or 3?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks,
> > > > > > > > > > > > > Nat.
> > > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > > spring mailing list
> > > > > > > > > > > > > spring@ietf.org
> > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/spring
> > > > > > > > > > _______________________________________________
> > > > > > > > > > spring mailing list
> > > > > > > > > > spring@ietf.org
> > > > > > > > > > https://www.ietf.org/mailman/listinfo/spring
> > > > > > > > --
> > > > > > > > Gyan S. Mishra
> > > > > > > > IT Network Engineering & Technology
> > > > > > > > Verizon Communications Inc. (VZ)
> > > > > > > > 13101 Columbia Pike FDC1 3rd Floor
> > > > > > > > Silver Spring, MD 20904
> > > > > > > > United States
> > > > > > > > Phone: 301 502-1347
> > > > > > > > Email: gyan.s.mishra@verizon.com
> > > > > > > > www.linkedin.com/in/networking-technologies-consultant
> > > > > > > >
> > > _______________________________________________
> > > spring mailing list
> > > spring@ietf.org
> > > https://www.ietf.org/mailman/listinfo/spring
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring