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

Gyan Mishra <hayabusagsm@gmail.com> Tue, 17 December 2019 01:25 UTC

Return-Path: <hayabusagsm@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 7DE4912096B for <spring@ietfa.amsl.com>; Mon, 16 Dec 2019 17:25:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.997
X-Spam-Level:
X-Spam-Status: No, score=-0.997 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, FREEMAIL_REPLY=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=no 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 731GoT07Nsa5 for <spring@ietfa.amsl.com>; Mon, 16 Dec 2019 17:25:41 -0800 (PST)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 AA4AB12090A for <spring@ietf.org>; Mon, 16 Dec 2019 17:25:41 -0800 (PST)
Received: by mail-io1-xd31.google.com with SMTP id k24so7525650ioc.4 for <spring@ietf.org>; Mon, 16 Dec 2019 17:25:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oP00QHkL4f46D7iUC3xSM61YZtGjRyKODRGKjFA/euE=; b=o60dEYnVe/+ATc9DDXococuqXpzr2xBQ3BQ905l2PBEls6J6ex2/nCf92KviqJanc3 iEbVfbrKcBtCkmgAPpYHpbeMBx88RfrrlJdIDCdCLz+7UpTI0aaupNJLdGpevfRbQ92U UFb5Oe72mkg1SL6Woyt/sJ1dzJST2YqhDVbPBsT4xqD0rRsLREVXWCes7q/ALzzAHOre /N+R8FZedkABaWkeQGI/zox1axfe7On/NSOUxtEzxZBrhNYoL59LQiTa6sFjX7Xvqkb4 2a4xrrT5R4BBoiSgj7cEAadFLLJJgP2E/y68g/gRtLyiH76aygsxzBIpDe373RxvA9ul k+cA==
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=oP00QHkL4f46D7iUC3xSM61YZtGjRyKODRGKjFA/euE=; b=jCe//NhCNsxVu23hqS3SkQJEQ09ICAblSMd8qNQMFcSCxKod+PgBYgj+bEkXtDLLCO CWSGWVGc+SGpI+CniMY+0WKlFK8OmAn185zR4fiGpxQs/Pbxc09UVWK4Ao3Z+Vlp6R5y v5i77dzWizMjfjrutIlITWYIjqE6aJ8ALsMrCvRW6Z1r8tE9cQOZ6pIcFBgCvIK7eK3i EzpVOSWgSfjUTCngYZj2L+aQleNuPM6hMZxmKuKh0cWDdsbHDTIXhSMGHJURQ8tQnnE6 /mFgngEXlAsRoIMEkYCH4yp7nOE68pnqQnBUr4yyr6uJgHDL1els/C9wkxqbHSPvWRFX bUVQ==
X-Gm-Message-State: APjAAAXS6VLmC0YzLOzqRJFO5H0qk1lofl9Qa/sxYk6oFgGjJg5CeqYZ 8FZC4aEc+O1JwqaxN5c16Es7Y0Hpw5qmcIvgfrU=
X-Google-Smtp-Source: APXvYqxh2SDWDxrbMqGd6o91cAmkNkr29Tcdhmgotu6aFh/WvHQiUNeB4rf8VEnK74E+J9oE0g3yGiko4T1tHT3NBBM=
X-Received: by 2002:a5e:8505:: with SMTP id i5mr1752662ioj.158.1576545940739; Mon, 16 Dec 2019 17:25:40 -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>
In-Reply-To: <c8967bfb-5a8e-447d-8e28-314820764f13@Spark>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 16 Dec 2019 20:25:29 -0500
Message-ID: <CABNhwV0POjT+_i6fcRNb8390mF=kQy76s_A1_=i63L_hw1BTpg@mail.gmail.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: Nat Kao <lekao@pyxisworks.org>, spring@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c51e220599dc341c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/KvwOMXkSSMlaL87bqmbwbBB7WsU>
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 01:25:44 -0000

Thanks Jeff!!

Both SR-MPLS & SRv6 in general I am guessing most deployments have been
centralized controller based model to take advantage of PCEP  and SR-TE
policy as necessary automatically instead of statically defined explicit
paths.

For small deployments I guess you could get away with non controller based
deployments.

The MSD limit does seem low even with proprietary asic 4-10 seems low.

Is the limiting factor with MSD the ASIC merchant or proprietary.

What is the MTU of the packet when you hit 10 hops or 10 adjacencies SIDS?

Also if you are doing tunnel stitching using BSID the MSD limit gets worse.

Sounds like SR-TE has a way to go on the asic side to support very long
explicit paths.

Warm regards,

Gyan

On Mon, Dec 16, 2019 at 6:19 PM 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
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
> 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
>
> --

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