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

Nat Kao <lekao@pyxisworks.org> Tue, 17 December 2019 11:46 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 BFCC6120180 for <spring@ietfa.amsl.com>; Tue, 17 Dec 2019 03:46:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=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 4ByRLnI85yQT for <spring@ietfa.amsl.com>; Tue, 17 Dec 2019 03:45:57 -0800 (PST)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 B7CFD12016E for <spring@ietf.org>; Tue, 17 Dec 2019 03:45:57 -0800 (PST)
Received: by mail-ot1-x334.google.com with SMTP id c22so2163638otj.13 for <spring@ietf.org>; Tue, 17 Dec 2019 03:45:57 -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=JQH3nkTVOw9CSyOe1N8JYrIYdl3zX1o54PUdxSxxURU=; b=dJqQemfGbgca+CQCTaGFd5Qi3t8Ub5wJlGkOS7tTREveoINJAr+/U3BPT0sq+cYaId HzT6/IcovkBRw1qZ05n/x1/YXpTDgs0EQ0zfrNRbhLT9JXerNykzBySkEMWlCvshAR5d Q3eJ98CMy9Li6ZAjisqVQ8t/Piduw+JJjrUKKOkQPTke9vPaVy6TJkdFRc7asRSIw654 TtsK/joQfi2TxP84lR2ETvBA/h2y9ZLAkO5FRgXKtjstCfeaNvs9eaKWc0QQNGf4bA3R +31M/JoB6UPPv32890EuRjOM28cTvAcpUgjkcjnu6l87vK1uN0bjg0/GVgRNE6omQKEI L1SQ==
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=JQH3nkTVOw9CSyOe1N8JYrIYdl3zX1o54PUdxSxxURU=; b=EtLkULnfuEfhRDl47g9Pf0TJyfSdGCn5LGGLyPDRJbT/tegkblhQUc/pMBgVdWDUAZ KsSTIrXTkxWh9ywlVx/nNp4EVddCc6D8jE89Lan8wIbUVmCRaPT8KKhGVVnCauDPWJSa yBbIruWu/XR56LqSSS5DCWe6EPS8dpZCAgR/54joRZNopbByZcpJ3vhl3dJXhkf7e2pm bOtSFVqmhEIAaSMWTCi+wj+vd3sfptkTzzcBEV6tHpX62eHC8fZayrJm6oosa725RaKb l5FyDd2twgJMByBlkoj4ZC0c2lVsA66CS5k314KlRC8fHrUL3Q80gBfwr9PRv6mY9GYY f0vA==
X-Gm-Message-State: APjAAAUOlnkjsxuINh78eUFiNzmaGwYimL8Mmg4Bwui8+SLlkify5X3X NhO6Ucn1kgr1o3Z1W/wjs5WpKowi9zV9DCToeDQkJA==
X-Google-Smtp-Source: APXvYqxfYheXib0BYZc3ovAT+bFlKIiVhSO0ayg1Tq1FBQjs8uBylp5kCjsyJgDWhHMc3LYgdaBwEU84gHb7UuLCyWo=
X-Received: by 2002:a9d:149:: with SMTP id 67mr2803723otu.217.1576583157036; Tue, 17 Dec 2019 03:45:57 -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>
In-Reply-To: <CAOj+MMFZnhYgOShZDFuBAwvhaUPGppo+JTF1k_1+MWKh08NGQg@mail.gmail.com>
From: Nat Kao <lekao@pyxisworks.org>
Date: Tue, 17 Dec 2019 19:45:44 +0800
Message-ID: <CAN3QBSf8e7H7337_E9odFRbz--whH4w+D0NVozsefVSsD75nNg@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: SPRING WG <spring@ietf.org>, Nat Kao <lekao@pyxisworks.org>
Content-Type: multipart/alternative; boundary="00000000000008cb7c0599e4df5b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/V6jAEPBU3BJHikSgR2AL6lXBlAc>
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: Tue, 17 Dec 2019 11:46:02 -0000

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>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
>>>>> <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
>>
>