Re: [spring] Different MSDs for different traffic types on the same headend.
Nat Kao <lekao@pyxisworks.org> Wed, 18 December 2019 06:20 UTC
Return-Path: <lekao@pyxisworks.org>
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 31D0D1208B2 for <spring@ietfa.amsl.com>; Tue, 17 Dec 2019 22:20:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=pyxisworks-org.20150623.gappssmtp.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 53hyDWJ7CZgV for <spring@ietfa.amsl.com>; Tue, 17 Dec 2019 22:20:48 -0800 (PST)
Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 B58A112006B for <spring@ietf.org>; Tue, 17 Dec 2019 22:20:48 -0800 (PST)
Received: by mail-ot1-x332.google.com with SMTP id p8so1039203oth.10 for <spring@ietf.org>; Tue, 17 Dec 2019 22:20:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pyxisworks-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PtqvuCv+VJg3iLyt6LQV0vHlVeubFXfX7U+na8YnuBM=; b=zlNKpTIkb+JV0g5Vuyse4RMIXa+IYoEewnRCTWe22svvRfvB9nXhvAMSWtYSkbsL9Q iDzy1Oqp2mIS+lArBhWy81UxSJA3FmIvucupROCxtOn2NbUXXbqPZ9LPTqsXOofDYE1o cnaJl4+md+12uO7/WGRukJAE1JoONlfDzoUOU8UUTkA4Ryew8l6k9Fa/Qjpw+V8ai83U BOgJUZGPc0WXCkvf16zZA1qOgX+EZoy1WLzuh2YljKv9OfOIrvq8f5SWaZaHeJg0WVdC twvJFIA/ZnlAiRhVZJ62IeAszuEvGUZKQ8pZGyeeZV/hev0lpYaVIcpb15wd4MjdjO6v glbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PtqvuCv+VJg3iLyt6LQV0vHlVeubFXfX7U+na8YnuBM=; b=atRYzcrVNZc3ge9PX4mZWvTkMaTC/u8f/zgjZP1TI7/H0ePAjb5CJi50JYR69UbHr5 3OeWiB0+gpqQTTF6NXkTv+efvpFdic4QNvMpp1Zi0hXQYxvKsQLjK2gErSdtGru1XpSd 2IQgOm0nTd/Mo22FhgrenlLe5VODUue/Ltpspm8J4TKDHgW2dGEm5zoZBvSPBnBrlUdb D3NZjcZC7ANMr11oJ/OdVCA18rMexnfD+vFZ6wbUA9+MCsyPLVJ3ZGqadxrhQtEPr+nA fymmaGZSCn9Ml6TgU676ckrHmvLmZ/xRtVhtgy0SGoM3MZ+cYg7K9WUC48eEzQFYp/Ut BUww==
X-Gm-Message-State: APjAAAXnJ0WnSiCmb1LNo8wUmEUUldBnnMSygREIshVuhD011UoQDF2m nMrYkdIxej0tzZXOwAqGaFRNlJ2jQSXnjqYfBctoGw==
X-Google-Smtp-Source: APXvYqwYIpJR84gwKPwTgQXyCox4t/tqvBL7y14EyT4aStVlN2so0qqFBoxp0hJRqartjA2uobEujDxazCtWW3BDmJ8=
X-Received: by 2002:a9d:7410:: with SMTP id n16mr903166otk.23.1576650047984; Tue, 17 Dec 2019 22:20:47 -0800 (PST)
MIME-Version: 1.0
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> <CAN3QBSf8e7H7337_E9odFRbz--whH4w+D0NVozsefVSsD75nNg@mail.gmail.com> <MWHPR11MB1600FC5024F4CB780597079CC1500@MWHPR11MB1600.namprd11.prod.outlook.com> <fa412e53-8f14-4dc8-bbaf-bd677ca04be3@Spark>
In-Reply-To: <fa412e53-8f14-4dc8-bbaf-bd677ca04be3@Spark>
From: Nat Kao <lekao@pyxisworks.org>
Date: Wed, 18 Dec 2019 14:20:35 +0800
Message-ID: <CAN3QBSfdmn113M_vo9P05iwvd2u7YN6_+4L+xSoGBRoVxGxkhw@mail.gmail.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Cc: Robert Raszuk <robert@raszuk.net>, SPRING WG <spring@ietf.org>, Nat Kao <lekao@pyxisworks.org>
Content-Type: multipart/alternative; boundary="0000000000000baac20599f472d7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/8d2YG2OHNsjgrP_Td8__OvWTZ-0>
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 06:20:53 -0000
Hi, Jeff & Ketan. For better discussion, let's assume these first: "TP-MSD" denotes the maximum transport label depth for traffic without service labels. "SRV-TP-MSD" denotes the maximum transport label depth for traffic with 1+ service label(s). Here's one of the use cases: A customized best-effort TE process: 1. Decide which route R (incl. VPN routes) to diverge from its shortest-path. 2. Compute SID-list S for R that satisfies the (TE or whatever) constraints. 3a. If R is a plain IPv4/IPv6 route, we consult TP-MSD. If length(S) <= headend's TP-MSD: Inject an SR-TE policy candidate path P with color X by BGP. Inject a new route R' with color X and larger localpref value. else: This path is not feasible, consider another route. 3b. If R is a service route, we consult SRV-TP-MSD. If length(S) <= headend's SRV-TP-MSD: Inject an SR-TE policy candidate path P with color X by BGP. Inject a new route R' with color X and larger localpref value. else: This path is not feasible, consider another route. 4. Repeat 1 to 3 until the main objectives are met.(best-effort approach, some might fail) Notes: a) Clearly, BMI-MSD >= TP-MSD >= SRV-TP-MSD b) TP-MSD & SRV-TP-MSD can be signaled by the same methods as BMI-MSD. c) If a change on headend that modifies transport label depths(ex: recirculation), TP-MSD & SRV-TP-MSD shall reflect that change accordingly. d) If a change on headend that modifies transport label depths of certain LCs, TP-MSD & SRV-TP-MSD of those links shall reflect that change, too. Hope this helps. Regards, Nat On Wed, Dec 18, 2019 at 8:44 AM Jeff Tantsura <jefftant.ietf@gmail.com> wrote: > Hi Nat, > > Please bring your use case to the wg, MSD has specifically been designed > to address new types with a very little effort. > > Cheers, > Jeff > On Dec 17, 2019, 4:21 AM -0800, Ketan Talaulikar (ketant) < > ketant@cisco.com>, wrote: > > Hi Nat, > > > > The MSD framework enables us to define more/new MSD types. If there is a > real use-case and requirement (as you express) and the necessary MSD > type(s) can be formally defined then perhaps the WG can evaluate it. > > > > Thanks, > > Ketan > > > > *From:* spring <spring-bounces@ietf.org> *On Behalf Of* Nat Kao > *Sent:* 17 December 2019 17:16 > *To:* Robert Raszuk <robert@raszuk.net> > *Cc:* SPRING WG <spring@ietf.org>; Nat Kao <lekao@pyxisworks.org> > *Subject:* Re: [spring] Different MSDs for different traffic types on the > same headend. > > > > Hello, Robert. > > Surely the current BMI-MSD definition is sufficient for platforms without > artificial boundaries. > > In this ideal case, maximum labels available for SR-TE policy can be > inferred from BMI-MSD and VPN routes. > > > However we have 3 different artificial boundaries across 3 different > platforms now. > > Hardcoding these boundaries might not scale well. (Especially different OS > versions may behave differently.) > > A standard mechanism to discover this boundary would greatly help > constructing SR-TE policy candidate paths. > > > > Regards, > > Nat. > > > > > > On Tue, Dec 17, 2019 at 5:58 PM Robert Raszuk <robert@raszuk.net> 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 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>, > 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 > <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>, 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 > >
- [spring] Different MSDs for different traffic typ… Nat Kao
- Re: [spring] Different MSDs for different traffic… Jeff Tantsura
- Re: [spring] Different MSDs for different traffic… Nat Kao
- Re: [spring] Different MSDs for different traffic… Gyan Mishra
- Re: [spring] Different MSDs for different traffic… Gyan Mishra
- Re: [spring] Different MSDs for different traffic… Jeff Tantsura
- Re: [spring] Different MSDs for different traffic… Gyan Mishra
- Re: [spring] Different MSDs for different traffic… Nat Kao
- Re: [spring] Different MSDs for different traffic… Robert Raszuk
- Re: [spring] Different MSDs for different traffic… Nat Kao
- Re: [spring] Different MSDs for different traffic… Ketan Talaulikar (ketant)
- Re: [spring] Different MSDs for different traffic… Gyan Mishra
- Re: [spring] Different MSDs for different traffic… Jeff Tantsura
- Re: [spring] Different MSDs for different traffic… Jeff Tantsura
- Re: [spring] Different MSDs for different traffic… Jeff Tantsura
- Re: [spring] Different MSDs for different traffic… Nat Kao
- Re: [spring] Different MSDs for different traffic… Gyan Mishra
- Re: [spring] Different MSDs for different traffic… Jeff Tantsura
- Re: [spring] Different MSDs for different traffic… Gyan Mishra
- Re: [spring] Different MSDs for different traffic… Nat Kao